Provenance and Observability

Every statement in the context graph is an observation made by a specific agent, at a specific time, as part of a specific process. Nothing exists in the graph without a record of who put it there and why. This makes the entire operating model auditable by default.

This isn't logging bolted onto the side. It's the fundamental data model. When you query for a task's status, you're reading an observation. When you trace who changed it, you're following the provenance chain. When you evaluate whether an autonomous actor's output is trustworthy, you're examining the process tree that produced it.

Everything Is an Observation

In most systems, data just exists. A row in a database has a value, and unless you've built a separate audit table, there's no record of how it got there. In Poliglot, every statement is an observation with provenance attached:

• Who observed it: the agent that made the claim (rars-os:accordingTo)
• Where it was recorded: the process that produced it (rars-os:recordedIn)
• What was observed: the specific statements attested to be true (rars-os:attests)
• What was withdrawn: statements observed to no longer be true (rars-os:retracts)

Attestation and retraction are two aspects of the same observation. When an action updates a task's status from "open" to "in-progress", that's a single observation that attests the new status and retracts the old one. Both the assertion and the withdrawal are attributed to the same agent and process.

The Process Tree

Every operation in a context creates a process. Processes form a tree that traces the full execution path:

Each node in the tree is a process with its own identity, status, timestamps, and the observations it produced. You can trace from any statement in the graph back through the observation, to the process, up through the process tree, all the way to the original user utterance that started the work.

This means you can always answer:

• What happened? Walk the process tree to see every action that was invoked.
• What changed? Look at the observations to see what was attested and retracted.
• Who is responsible? Each observation records the agent that made the claim.
• Why did it happen? Trace the process tree to the parent action, script, or user request that triggered it.

One Unified Model

There's no distinction between "system data" and "business data" in the observation model. The platform itself is just another domain. When the system creates a process, tracks an authorization context, or records a script execution, those are observations made by the system agent, following the exact same provenance model as your business data.

This means the same tools and queries you use to audit business operations work for auditing platform behavior. You can trace a system process the same way you trace a task update. You can query who authorized an escalation the same way you query who changed a work order's status. Everything is observations, all the way down.

Validity and Time

Observations don't just track who and what. They track when. Every statement has a validity period:

• When a statement is attested, it gets a validFrom timestamp (open-ended: it's true from now until further notice)
• When a statement is retracted, the validity period closes with a validTo timestamp
• A statement can have multiple validity periods if it was true, then retracted, then re-asserted

This means the graph has a temporal dimension. You can ask not just "what is the status of this task?" but "what was the status at 2pm yesterday?" or "how many times has this status changed?" The history is preserved, not overwritten.

Retractions don't delete data. They record that a previous observation is no longer considered true. The original observation and its provenance remain in the graph as a permanent audit record.

Named Graphs and Provenance

The platform operates primarily on the default graph, where all provenance tracking applies. Named graphs exist as an internal mechanism for scratch-pad style temporary data and are exempt from statement-level provenance tracking. The data inside a named graph does not carry per-statement observations. This is an explicit design decision.

However, the named graph itself (its existence, creation, and lifecycle) is tracked through the provenance system. You can trace when a named graph was created, by which process, and under which agent's authority.

Auditing What Happened

The combination of observations, process trees, and validity tracking gives you several ways to audit a context:

Tracing: walk the process execution tree to see every action that was invoked, in order. Each process node shows its status (completed, failed, interrupted), timing, and the observations it produced.

Diff view: see what the AI changed, presented as a unified diff with additions and retractions. Each line traces back to the specific observation and process that produced it. This is the quickest way to review what happened during a session.

Entity provenance: for any entity in the graph, see every observation that contributed to its current state. Who set each property? When? As part of which action? Was anything retracted?

Cross-agent attribution: when multiple matrices and agents contribute to a context, provenance tracks which agent made each claim. If a reporting matrix and a task matrix both produce data, you can see exactly which agent is responsible for which observations.

Trust and Verification

Provenance is what makes AI-produced data trustworthy. When RARS executes an agentic action and produces a result, the entire reasoning chain is traceable:

• The sub-agent's task and its script executions
• Every action it invoked along the way
• Every observation it made, attributed to its process identity
• The I/O contract validation on the final result (see Designing Actions)

If you need to verify that an AI-produced assessment is sound, you can trace through the process tree to see what data it consulted, what actions it took, and whether its intermediate observations are consistent with the final result.

This is equally valuable for deterministic actions. When a service integration returns unexpected data, you can trace the observation to the HTTP request, see the response that was mapped, and understand exactly where the unexpected value came from.

What Affects Auditability

Provenance tracking is automatic. You don't need to design for it or opt into it. But one design decision does affect the quality of your audit trail: how you split work between the matrix and the system of record.

If you have a single action that calls one API endpoint which internally creates a task, assigns it, notifies stakeholders, and updates a dashboard, the provenance shows one action invocation with one result. Everything that happened inside your backend is opaque to RARS.

If those are separate actions (create task, assign task, send notification, update dashboard), the provenance shows four observable steps, each with its own process, timing, and observations. The platform can trace exactly what happened and in what order.

This doesn't mean you should split every API call into micro-actions. It means the boundary between what the matrix orchestrates and what the backend does internally determines how much visibility you get. If auditability matters for a workflow, model the meaningful steps as separate actions so the provenance system can track them.

Summary

• Every statement has provenance: who observed it, when, and as part of which process
• Process trees trace execution: from user utterance through scripts, action invocations, and service requests
• One unified model: system operations and business data use the exact same observation model
• Named graph contents are exempt: but the graph's existence and lifecycle are tracked
• History is preserved: retractions close validity periods, they don't delete data
• Temporal queries are possible: the graph knows not just what is true, but what was true when
• AI outputs are fully traceable: agentic reasoning chains are auditable through the process tree
• Action granularity determines visibility: the split between matrix orchestration and backend logic defines the audit boundary