Agent Runtime Lineage Export
Status: informative. Event-sourced and durable-execution runtimes can keep local lineage; PEAC can record selected reported events as portable signed records for independent verification. This guide describes how such a runtime exports run lineage as existing PEAC records that a third party can verify offline, without access to the runtime's database.
PEAC is not a runtime, graph engine, scheduler, orchestrator, replay engine, or fork engine. It records what the runtime reports. This guide introduces no new wire format, schema, registry entry, receipt type, or extension group.
What gets recorded
The runtime chooses which reported events to export. Each event becomes an existing agent-action record:
| Runtime event | PEAC record type |
|---|---|
| Model call, tool call | org.peacprotocol/agent-action-invoked-observed |
| Delegation to another agent | org.peacprotocol/agent-action-delegated-observed |
| Run finalization / export | org.peacprotocol/agent-action-invoked-observed (a run-summary-export action) |
Raw prompts, model outputs, tool inputs and outputs, headers, and credentials are never placed in a record. Event content is represented by digests and opaque references; the records also carry normal PEAC envelope, issuer, time, type, and correlation metadata. This is a single-issuer pattern: every record is signed by, and verifies under, one issuer key.
The run manifest and event descriptors
The runtime builds an application-level run manifest (not a PEAC record) listing ordered event descriptors. Each descriptor carries an opaque event_ref, a sequence_index, the agent and action references, and a strict RFC 3339 (seconds-precision) observed_at. Invoked-event descriptors carry sha256: input and output digests; delegation descriptors carry a sha256: input digest and the delegated_to_ref. Each event record binds:
- its event descriptor by digest, through
upstream_artifact_ref(theevent_ref) andupstream_artifact_digest(the RFC 8785 JCS + SHA-256 digest of the descriptor); and - the whole-manifest digest, through an example-local
com.example/agent-run-lineageextension (run_ref,run_manifest_digest,sequence_index).
Run order comes from the manifest sequence_index, not from timestamps. Timestamps are issuer-reported observation times.
Chaining records
Records are chained with existing PEAC fields, not a new lineage mechanism:
- the agent-action
parent_refbinds the previous record'sreceipt_ref; org.peacprotocol/correlationcarriesworkflow_id,parent_jti, anddepends_onfor the causal edge.
The first event is a root (no parent metadata); each later record links to exactly the preceding one; the finalization record links to the last event.
Run-finalization coverage assertion
The run-finalization record carries a coverage set of event-record refs (canonically sorted, excluding the finalization record's own ref), the count, and a Merkle commitment over exactly those refs, produced with @peac/audit buildReceiptMerkleCommitment (a CT-style RFC 9162 sorted-set commitment).
Given the manifest, run records, issuer public key, and expected issuer identifier, the verifier checks that the supplied records exactly match the coverage set asserted by the signed finalization record. This establishes internal consistency between the issuer-supplied manifest, the run records, and the signed summary. It does not prove that the issuer recorded or disclosed every real-world runtime event, and the Merkle commitment proves inclusion in the committed set, not chronology or real-world completeness.
Third-party verification
A relying party verifies offline with only the issuer's public key, the issuer identifier, and the manifest. No access to the runtime's database is required. Verification uses RFC 8785 JCS + SHA-256 digesting and standard PEAC signature and schema validation.
Boundary
PEAC does not replay, fork, execute, or govern runtimes. Example-local com.example/* keys are not new PEAC extension groups. This guide makes no adoption, integration, endorsement, partnership, or conformance claim about any runtime.