Follow a task
Read a run
Read decisions, coverage, provenance, and unknown outcomes in a task timeline.
A run explains one session from task intent through its recorded outcome. Read each proposed action in the context of the work before it. Individually plausible steps can still accumulate into a material divergence.
How a trajectory reaches Runs#
Send supported model traffic through your Integrity deployment with x-triage-session-id and a persisted operation ID. The gateway records the operation before dispatch and appends supported events to a durable session ledger. Runs reads an authorized projection of that ledger; Data reads permitted source records from the same evidence.
Keep one session ID across the task, including subsequent requests containing tool results. Your application still sends the model history required by its protocol. A shared session ID does not reconstruct omitted provider history, expose hidden reasoning, or capture tools that bypass the integration.
Read the sequence#
Select a step in this representative authorization task. The paired panels show how the task narrative in Runs relates to the evidence you inspect in Data.
Fix authorization. Keep its test.
Task: repair the authorization check
Preserve: test_unauthorized_request_is_deniedThe user asks for a missing permission check to be fixed. The constitution requires authorization coverage to remain intact.
Task intent, constitution revision, session identity.
Subject to retention and access controls.The test is part of the task contract. This example shows recovery; a real continuation can remain held or fail.
| Record | What it establishes |
|---|---|
| Model request | The supported request admitted under a particular operation, session, and revision. |
| Proposal / review / hold | The proposed behavior, available review evidence, and decision before release. |
| Corrective continuation | A bounded attempt to address feedback while preserving task context and useful work. |
| Released response | The content passed its required release checks; tool execution remains with your harness. |
| Action report | What your application reported about an external action, with its available provenance. |
| Session close | Further platform admission is closed and the reported task outcome is retained. |
Inspect the evidence behind a decision#
Start with the constitution and governing revision. Compare the original proposal, supported review evidence, feedback, and any corrected proposal. Follow the source session, operation, event sequence, and available digest into Data when reviewing or exporting.
The current connection reviews actions and final outputs. Input and tool-result records can supply context without receiving a separate pre-inference review. A recorded review is evidence of a decision, not proof of access to hidden model reasoning.
Live updates and reconnects#
The evidence API pages ordered records using a cursor and reports a high-water mark and synchronization lag. Live updates resume from retained evidence after reconnecting, with access and retention checked again. Customer surfaces omit unsupported internal telemetry, so visible sequence numbers can have gaps.
A reconnect updates the view; it does not authorize repeating inference. For an interrupted model request, use the original operation ID and the operation recovery contract. A quiet connection or completed response does not close the task.
Keep unknown outcomes visible#
Missing usage is unknown, not zero. An incomplete operation is not a completed failure. Application reports and accepted signed receipts do not by themselves prove an external effect. Preserve unresolved obligations when reviewing progress or evaluating an improvement.
Once you understand the sequence, grade the behavior and record the result you expected. That feedback becomes useful input for future constitutions and adaptation without rewriting the run you just reviewed.