Public technical reference · audit event v1

Complete sanitized AI agent execution record

This reference makes one existing sanitized audit-event thread easy to follow. It connects the published action request, policy decision, approval event, audit event, downstream result, and evidence bundle manifest without adding a second synthetic lifecycle.

Open the complete JSON Open the denied example

Lifecycle reference · synthetic records · audit event v1

Definition: A joined record trail for one governed execution.
Used when: A reader needs the full action lifecycle in one place.
Thread: Request → policy → approval → tool → outcome → evidence.
Integrity: RFC 8785-style record hash plus detached Ed25519 signature.

Lifecycle map

The existing complete-execution example joins the six stages below through correlation IDs, event IDs, lineage, and the evidence manifest reference.

1 · RequestThe agent requests credit.application.set_disposition for a tokenized synthetic application and records the requester, service identity, purpose, resource, amount, and boundary.Schema reference
2 · PolicyThe policy record returns require_approval with policy version, input digest, matched rule, and reason code.Schema reference
3 · ApprovalA senior underwriter approves the bound request before the tool call. The approval record carries expiry, reviewer, decision, rationale reference, and presented evidence digest.Schema reference
4 · Tool actionThe idempotent tool call succeeds and records argument and result digests plus before and after state digests for the downstream effect.
5 · OutcomeThe execution record reports an achieved synthetic business outcome and a rollback status.
6 · EvidenceThe audit event points to bundle_manifest_synthetic_20260721_01, which is the export identifier in the evidence bundle manifest reference.Schema reference

Complete record preview

The preview selects the fields that connect request, policy, approval, action, outcome, evidence, and integrity. The downloadable JSON remains the complete sanitized record.

{
  "execution_id": "run_01JZ8V4K2D9A6N3P7M5R1C8X0E",
  "request": {
    "action": "credit.application.set_disposition",
    "resource": {
      "type": "credit_application",
      "id": "app_synthetic_74291"
    },
    "requested_at": "2026-07-21T09:14:29.122Z"
  },
  "policy": {
    "decision": "require_approval",
    "policy_version": "4.2.1",
    "reason_codes": [
      "amount_requires_senior_underwriter"
    ]
  },
  "approval": {
    "status": "decided",
    "decision": "approved",
    "decided_at": "2026-07-21T09:14:31.902Z"
  },
  "tool": {
    "status": "succeeded",
    "downstream_effect": "credit_disposition_updated"
  },
  "outcome": {
    "status": "achieved",
    "summary": "The approved disposition was recorded in the synthetic core-banking record.",
    "reference": "outcome_synthetic_91084"
  },
  "evidence": {
    "manifest_ref": "bundle_manifest_synthetic_20260721_01",
    "artifacts": [
      {
        "artifact_id": "artifact_policy_decision_01",
        "artifact_type": "policy-decision",
        "content_digest": "sha256:cd2eb0837c9b4c962c22d2ff8b5441b7b45805887dcc65d14f916888635af041"
      },
      {
        "artifact_id": "artifact_tool_receipt_01",
        "artifact_type": "tool-receipt",
        "content_digest": "sha256:9d6f965ac832e40a5df6c06afe983e3b41e705464b706fef489a51e6d02eb9e9"
      }
    ]
  },
  "verification": {
    "status": "valid",
    "verified_at": "2026-07-21T09:14:33.041Z",
    "verifier": {
      "id": "vendor-neutral-reference-verifier",
      "version": "1.0.0"
    },
    "failure_codes": []
  }
}

Stable example URLs

The existing audit-event downloads remain the source files for this page. The page adds a readable lifecycle entry point.

Download complete-execution.json

Read the audit event field dictionary for the full envelope and record distinctions.

Denied action and tamper failure

The same reference set includes a terminal block path and a structurally valid record whose business outcome was changed after signing.

Denied action

The policy decision is block. The execution remains not_started, tool_calls is empty, and the business outcome records that the synthetic payment instruction remained unreleased.

Download denied-action.json

Tamper failure

The example changes the downstream business outcome and retains the signed record hash. Signature verification still authenticates the stale hash; recomputing the canonical payload returns record_hash_mismatch.

Download tamper-failure.json

Field dictionary

The lifecycle guide points to fields in the existing audit-event envelope and its component references.

Field	Status	Purpose
schema_version	Required	Selects the audit-event contract.
audit_event.event_id	Required	Identifies the terminal event in the thread.
audit_event.correlation.execution_id	Required	Joins every lifecycle record to one execution.
audit_event.actors	Required	Records requester, delegated user, service identity, agent, and accountable owner when present.
audit_event.requested_action	Required	States the action, purpose, resource, data boundary, amount, and request time.
audit_event.policy	Required	States the policy version, inputs digest, outcome, and reasons.
audit_event.approval	Conditional	Appears for require_approval and records the human decision before effects.
audit_event.tool_calls[]	Required	Lists requested and completed tool effects with idempotency and result digests.
audit_event.execution	Required	Records execution status and downstream business outcome.
audit_event.lineage	Required	Orders request, policy, approval, tool, and terminal event references.
audit_event.evidence.manifest_ref	Required	Points to the evidence bundle export identifier.
audit_event.privacy	Required	States classification, tokenization, redactions, and access-policy reference.
integrity.record_hash	Required	Commits to the canonical signed payload.
integrity.previous_event_hash	Optional	Links the record to its predecessor when the chain includes one.
integrity.signature	Required	Carries the Ed25519 key reference and public verification material.
integrity.verification	Required	Records the documented verification outcome and failure codes.

Verification procedure

The record verifier and the evidence-bundle verifier protect separate integrity boundaries. Run both when the execution record is exported with a bundle.

01Parse the audit-event schema and keep the lifecycle fields in their published types.
02Build the signed payload from schema_version, audit_event, and the integrity metadata that excludes record_hash and signature.value.
03Canonicalize the payload with the published RFC 8785-JCS reference behavior and hash it with SHA-256.
04Compare the computed record hash with integrity.record_hash and verify the Ed25519 signature over the raw digest bytes with the published sample key.
05Check lifecycle ordering: policy follows the request, approval precedes effects for require_approval, tool calls follow policy, and execution completion follows execution start.
06Join the manifest_ref to the evidence bundle reference and apply the bundle verifier to the on-disk export when bundle integrity is required.

Audit event schema Evidence bundle procedure

Current implementation mapping

The page names the source contracts and verifiers behind each lifecycle statement.

Contract	Repository source path	Mapping	Status
Action request	apps/platform/src/lib/ai-agent-action-request/v1/schema.json	Standalone request object linked by action, resource, boundary, and correlation fields.	Published reference
Policy decision	apps/platform/src/lib/ai-agent-policy-decision/v1/schema.json	Four-outcome policy response with require_approval in the worked thread.	Published reference
Approval event	apps/platform/src/lib/ai-agent-approval-event/v1/schema.json	Human decision bound to the request and expiry before tool effect.	Published reference
Audit event and examples	apps/platform/src/lib/ai-agent-audit-event/v1/complete-execution.json; apps/platform/src/lib/ai-agent-audit-event/v1/denied-action.json; apps/platform/src/lib/ai-agent-audit-event/v1/tamper-failure.json	Existing sanitized records supply the complete, denied, and tampered lifecycle cases.	Current examples
Record verifier	apps/platform/src/lib/ai-agent-audit-event/v1/verify.ts	Computes the record hash, verifies the Ed25519 signature, checks chain links, and checks lifecycle ordering.	Reference verifier
Bundle verifier	packages/evidence-verifier/src/verifier.ts	Verifies the manifest and applicable bundle checks after manifest_ref resolves to an export.	Production verifier

Deliberate abstractions

The page reuses the existing complete-execution.json, denied-action.json, and tamper-failure.json files. It preserves their identifiers, hashes, and field values.
The lifecycle is a joined reading guide. The audit-event example is the terminal envelope, while the standalone schema pages define the component contracts.
The records use tokenized synthetic references and contain no customer data or production credentials.
The per-record Ed25519 integrity block and the evidence-bundle ES256 manifest seal are separate verification layers.
Authorization, tenant isolation, and retention decisions remain properties of the owning runtime and evidence services. This page records the references present in the sanitized thread.

Source files

The existing sanitized examples and reference verifier remain the implementation sources for this page.

Open the source example

Questions readers ask

The answers keep the joined record distinct from population and service-level conclusions.

Why is the policy result require_approval?

The synthetic policy record matches the manual-review-above-20000 rule and records amount_requires_senior_underwriter. The approval record binds the human decision to the request before the tool call starts.

Where is the denied action?

The denied-action.json example records a block decision, zero tool calls, not_started execution, a not-achieved outcome, and its own evidence manifest reference.

What does the tamper example change?

tamper-failure.json changes the downstream business outcome while retaining the original record_hash. The record remains schema-valid, the signature over the stale hash still verifies, and the recomputed record hash fails with record_hash_mismatch.

Does a complete record prove a complete population?

It proves the fields and links represented by this one sanitized thread. Population completeness requires reconciliation against the authoritative source population and export scope.

How does OpenTelemetry fit?

The trace_id and span_id join telemetry to the audit event. The audit event carries the governed action, decision, approval, effect, outcome, and integrity references that a trace alone cannot establish.

Related references

Read the component contracts beside the joined record.

The schema pages describe each object. The evidence bundle page describes the export seal and six-check offline procedure.

Open the audit schema