Docs / Reference
Evidence event fields
Evidence events preserve ordered protocol facts for audit, replay, debugging, and telemetry export.
Plain English
Evidence events are not log lines; they are structured records of what happened at the capability boundary.
Why it exists
Independent infrastructure needs enough stable fields to replay an invocation without reading private host logs.
Formal definition
ExecutionEvidence is an ordered record containing event type, invocation identity, capability identity, host identity, correlation context, sequence, timestamp, payload, redaction state, and assurance metadata.
Concrete example
Ground the concept before the schema.
execution_denied records an approval_required decision for schedule_technician under session-abc.
{ "event_id": "evt_8f3a1c", "event_type": "execution_denied", "invocation_id": "inv_session_abc_001", "capability_id": "schedule_technician", "capability_version": "1.0.0", "host_id": "service-ops-host", "correlation": { "correlation_id": "session-abc" }, "sequence": 2, "timestamp": "2026-06-16T15:14:22.104Z", "outcome": "denied", "payload": { "policy": "manager_approval" }, "redacted": true, "denial": { "code": "approval_required", "message": "manager_approval must approve before execution.", "retryable": true }, "assurance": { "level": "S1" }}Developer reference
Evidence event field reference
Evidence should preserve the minimum stable fields needed to inspect and replay a protocol decision.
Unique evidence event identifier.
Stable event type such as execution_started, execution_completed, execution_failed, execution_denied, or execution_skipped.
Invocation that produced this evidence event.
Capability involved in the decision or execution.
Capability contract version at invocation time when known.
Host that evaluated or executed the invocation.
Replay key shared across invocation, outcome, and telemetry.
Ordered position in the evidence stream.
When the event occurred.
Protocol result associated with this event.
Structured, usually redacted event payload.
Whether sensitive payload values were redacted.
Evidence assurance level and policy metadata.
Relationships
Where this sits in the protocol.
Each concept should explain its neighbors so implementation teams can preserve the boundary across manifests, invocation, evidence, and tests.
Reference pages turn protocol concepts into implementation checks.
Field names, outcome codes, and conformance cases should stay stable across hosts.
Examples should map every field back to capability, host, policy, context, or evidence.
Visual model
- 01Read the field or code before implementation.
- 02Map it into manifest, invocation, outcome, or evidence behavior.
- 03Add route, conformance, or unit coverage for each failure-sensitive field.
Implementation notes
- Prefer explicit protocol fields over framework-specific inference.
- Treat absent required fields as malformed protocol input.
- Keep examples close to the failure cases they are meant to prevent.
Common mistakes
- Letting transport status codes carry protocol meaning alone.
- Hiding required protocol state in logs or application glue.
- Testing only successful invocations.
Related concepts