Skip to content
OWP

9. The Audit Envelope (Detailed)

This section specifies the Audit Envelope structure in detail. The Envelope is the protocol’s principal mechanism for accountability. Its integrity, completeness, and tamper-evidence are non-negotiable conformance requirements.

9.1 Event Types

An Audit Envelope is a sequence of events of the following types. Implementations MUST emit all applicable events; implementations MAY define additional event types but MUST NOT redefine the meaning of types specified here.

  • EnvelopeOpened. Emitted on creation of the Envelope.
  • IntentGenerated. A Worker generated an Intent.
  • IntentDispatched. A generated Intent was dispatched to a target.
  • IntentAccepted. A Worker accepted an Intent.
  • IntentRefused. A Worker refused a Dispatch — declined to accept this dispatched Intent. The dispatch attempt is recorded as a refusal event; the Intent itself may be re-dispatched to another eligible Worker, or it may terminally resolve as not-applicable (§6.6) if no Worker accepts it.
  • IntentReassigned. The runtime reassigned an Intent (e.g. due to Worker decommissioning).
  • SignalReceived. A subscribed Worker received a Signal.
  • CapabilityInvoked. A Worker invoked a Capability. Includes the Cost Record.
  • CapabilityCompleted. A Capability returned (synchronously, asynchronously, or via stream-final).
  • CapabilityFailed. A Capability invocation failed.
  • EscalationRaised. An Intent was escalated.
  • EscalationResolved. An escalated Intent was resolved.
  • IntentResolved. An Intent reached a terminal state.
  • AuthorityViolationAttempted. The runtime refused an outbox action.
  • ComplianceConstraintApplied. A Compliance Profile constrained an action.
  • EvaluationCommissioned. An Evaluation (§12.2) was requested by an Operator, by a cadence trigger, or by a Compliance Profile threshold.
  • EvaluationCompleted. An Evaluation envelope was signed and persisted.
  • RecalibrationProposed. A Recalibration (§12.4) was signed by an Operator and (where required) co-signed by an Architect.
  • RecalibrationApplied. The runtime effected a Recalibration; the event records outcome: applied | failed.
  • WorkerDecommissioned. A Worker reached terminal lifecycle state per §12.5.
  • IntentReassignedOnDecommission. An open Intent was reassigned during a Worker’s decommissioning per §12.5.2.
  • WorkerInstanceRebound. A Worker Instance was re-bound to a different Worker Definition per §3.1.7, preserving its Worker ID and history. Signed by the authorising party.
  • MemoryRegistered. A new Memory item (§3.7) was registered with the runtime. Signed by the owning Workforce’s Architect.
  • MemoryVersionCreated. A new immutable version was materialised on a Semantic Memory item. Signed by the acting author (Architect, contributing Worker, or curator on contribution acceptance).
  • MemoryCurrentPointerMoved. A Semantic Memory item’s mutable current pointer was moved to a different version. Signed by the moving actor.
  • MemoryRead. A Worker read a Memory item. Records (memory_id, resolved_version, content_hash, confidence_at_read) per §9.2. Signed by the Worker.
  • MemoryReinforced, MemoryDecayed, MemoryInverted. A Causal or Relational Memory item’s confidence was updated by the reinforce/decay/invert dynamics (§3.7.5). MUST carry Outcome provenance. MemoryReinforced/MemoryDecayed MAY be autonomous-but-audited; MemoryInverted routes through Recalibration co-signature (§3.7.13). Signed by the acting Worker (and co-signed for inversion).
  • MemoryContributed. A Worker proposed a contribution to a Semantic Memory item (§3.7.11). Signed by the Worker.
  • MemoryContributionAccepted. A proposed contribution was accepted into a Semantic Memory item, producing a new version. Signed by the accepting curator (Architect or designated Human Role with curation authority), via Recalibration co-signature.
  • MemoryRetentionPolicyChanged. A Semantic Memory item’s retention class was changed. Signed by the owning Workforce’s Architect. MUST NOT apply retroactively to versions older than the change.
  • MemoryRetired. A Memory item was retired (§3.7.12). Terminal for the item; signed by the owning Workforce’s Architect.
  • StrategicIntentDeclared. An Operator principal signed an org-scope Strategic Intent declaration. Persisted in the Strategic Intent Registry (§9.6), not in any Envelope.
  • StrategicIntentTransitionSuggested. The runtime observed that a Strategic Intent’s measurement_criteria resolved to achievement, or that its TTL expired. Emitted into the Strategic Intent Registry, signed by the runtime, addressed to the Strategic Intent’s originator. Auto-transitions MUST NOT occur; the originator MUST sign the actual transition.
  • StrategicIntentTransitioned. An Operator principal signed a Strategic Intent’s transition to a terminal state. Persisted in the Strategic Intent Registry.
  • StrategicIntentSuperseded. An Operator principal signed an amendment-by-supersession (§3.4.7) of a Strategic Intent — a new Strategic Intent was declared with supersedes: <old-intent-id>, and the old Strategic Intent was withdrawn. The two events MAY be emitted together; both reference each other.
  • WorkforceAggregatedOutcomeReported. A Workforce Director Worker emitted an aggregated Outcome for a Strategic Intent the Workforce is advancing. Persisted in the Strategic Intent Registry; signed by the Director.
  • StrategicIntentDeclined. A Workforce Director Worker resolved a cascaded Strategic Intent with not-applicable — the Strategic Intent does not apply to the Workforce. Persisted in the Strategic Intent Registry; signed by the Director.
  • TradeoffNarrationOmissionDetected. The runtime observed that a leadership Worker emitted an Outcome without tradeoff_narration when ≥ 2 Intents were active at the scope (per §3.4.11). Emitted into the operational envelope of the leadership Worker’s work; signed by the runtime. Omission is not refused — Outcome lands — but is audited for human review.
  • AggregatedOutcomeReported. A leadership Worker emitted an interim aggregated Outcome for an upstream Intent it is tracking (§6.9). Emitted into the upstream Intent’s envelope; signed by the leadership Worker.
  • OutcomeGapObserved. The runtime observed a divergence among an Intent’s desired outcome, its measurement score, and its delivered Outcome — the proxy-gaming or bad-measure form (§3.4.12). Advisory; emitted into the operational envelope; signed by the runtime; surfaced to Reviewers/Operators and fed to Causal Memory (§3.7.5).
  • FunctionBundleLoadRefused. The runtime refused to instantiate a Function bundle due to mandatory-presence or schema violations (§6.11). Emitted into the Authority’s bootstrap-control envelope; signed by the runtime.
  • AllocationSolicited. A Workforce Director opened an Allocation Deliberation round (§6.12.2): carries the candidate Function Lead set and the assessment TTL. Emitted into the top-level Intent’s envelope; signed by the Director. Bids deliberately introduce no distinct event kind — each bid is the measured Outcome of an intent:owp:allocation-assess/v1 assessment Intent and rides that Intent’s ordinary lifecycle and resolution events, signed by the assessing Lead.
  • AllocationAwarded. A Workforce Director awarded a deliberated Intent to a Function (§6.12.4): carries the chosen Function, the recorded reasoning, and references to every bid Outcome, winning and losing. Emitted into the top-level Intent’s envelope; signed by the Director.
  • RouteSedimented. The runtime created or refreshed a weighted route from a completed award (§6.12.5). Signed by the runtime.
  • RouteWeightAdjusted. A weighted route’s weight changed (§6.12.5): carries the cause (outcome-feedback | roster-change | recalibration | deployment) and the resulting weight. Signed by the runtime.
  • RouteInvalidated. A weighted route was invalidated (§6.12.6): carries the cause. The next matching Intent re-deliberates. Signed by the runtime.
  • EnvelopeClosed. Emitted on closure of the Envelope.

Each event is a structured record. The schema for events is deferred to a companion document, but every event MUST include the fields specified in §9.2.

9.2 Event Common Schema

Every event in an Audit Envelope MUST include:

  • event_id — unique within the Envelope.
  • envelope_id — identifier of the Envelope.
  • event_kind — one of the types in §9.1 (or an implementation extension).
  • wallclock_at — ISO 8601 timestamp.
  • logical_at — monotonic logical clock value, used for ordering across distributed runtime instances.
  • actor — the Worker, human principal, or runtime service responsible for the event.
  • role — the Worker Definition under which the actor acted, if applicable. For Worker-attributed events, this is the Worker’s currently-bound Worker Definition per §3.2.1 (Workers are bound to exactly one Worker Definition at any moment). For human-attributed events, this is the specific Human Role under which the human acted, since a single human MAY concurrently hold multiple Human Roles per §7 and the audit chain MUST disambiguate which Worker Definition the action was taken under.
  • role_version — the version of the Worker Definition’s Charter declaration under which the actor acted, if applicable. REQUIRED whenever role is set; enables per-Worker Definition-version evaluation per §12.2.1.
  • authority_clause — the clause of the Authority Grant under which the action was permitted, if applicable.
  • function_version — the version of the Function under which the actor acted. REQUIRED for all Worker-attributed events; enables per-Function-version evaluation per §12.2.1.
  • worker_instance_seq — a monotonic instance counter, distinct from Worker ID, identifying which instantiation of the Worker Definition this Worker represents. REQUIRED for all Worker-attributed events; enables per-Worker-instance evaluation per §12.2.1 in Worker Definitions where Workers are spawned and decommissioned over time.
  • deployment_context — opaque key/value structure carrying the dimensions the Function declares as evaluation slices (e.g. tenant, region, customer segment). REQUIRED for all Worker-attributed events where the Function declares evaluation contexts; enables per-Worker Definition-context evaluation per §12.2.1.
  • payload — event-specific structured data.
  • previous_event_hash — the hash of the previous event in the Envelope, forming a hash chain.
  • signature — a signature by the actor over the event content.

Events that read from Memory (MemoryRead, or CapabilityInvoked with a Memory Capability per §3.5.3) MUST additionally include in their payload:

  • memory_id — the URI of the target Memory item (§3.7.4).
  • memory_version — the monotonic version resolved by the Provider at read time (for Semantic Memory). REQUIRED whether the read targeted current or an explicit version.
  • retrieved_content_hash — the cryptographic hash of the content returned to the Worker. REQUIRED for Semantic reads. Together with memory_id and memory_version, this guarantees that a re-read at the same (memory_id, version) is bit-identical.
  • confidence_at_read — the Memory item’s confidence at read time (for Causal/Relational Memory, §3.7.5). REQUIRED for dynamic-kind reads.
  • provenance_ref — for cross-Workforce reads (§3.7.10), a reference to the owning Workforce’s envelope and source event that materialised the version. REQUIRED on cross-Workforce reads.
  • synced_at and memory_version_at_sync — for reads served from a replica (§3.7.10), the wall-clock time of the last replica sync and the version held at that sync. REQUIRED on reads served from a replica; absent on direct reads.

Memory update events (MemoryReinforced, MemoryDecayed, MemoryInverted) MUST additionally include in their payload an outcome_provenance reference (§5.1) to the Outcome(s) that justified the confidence change, and the resulting confidence value.

Human-produced events. For an event produced by a human — a human Worker’s (§3.2.12) IntentResolved, a Human Role’s escalation Outcome (§6.5) — the actor is the human’s principal id, and the actor signature (§9.3, §14) is over that principal’s key. The required common-schema fields are unchanged: a human’s action is a signed chain event indistinguishable in form from a Worker’s. This is deliberate — one Audit Envelope carries the work whoever performed it, and a human’s Outcome is no thinner-enveloped than an AI Worker’s.

The hash chain (previous_event_hash) provides tamper-evidence: any modification to a prior event invalidates all subsequent hashes.

9.3 Hash Chaining and Signing

Events in an Envelope form a hash chain. The first event (EnvelopeOpened) has a previous_event_hash of a well-known initial value (specified in a companion document). Each subsequent event’s previous_event_hash is the cryptographic hash of the previous event’s full serialised content, including its signature.

The signature on each event MUST be produced by the actor’s cryptographic identity (Worker key, Human Role key, or runtime key, as applicable). The signature covers all fields of the event except the signature itself.

9.4 Closure and Sealing

When the root Intent of an Envelope reaches a terminal state, the runtime MUST:

  • Emit a final IntentResolved event for the root Intent.
  • Emit an EnvelopeClosed event containing the Merkle root of all Envelope events.
  • Sign the EnvelopeClosed event with the runtime’s identity.

The sealed Envelope is immutable. Subsequent attempts to append events MUST be refused. Replay of the Envelope from any external store (e.g. archival) MUST be verifiable by recomputing the hash chain and the Merkle root, and verifying signatures.

9.5 Federation

Where work is federated across Workforces, an Audit Envelope in one Workforce MAY refer to an Envelope in another. The protocol does not yet specify federation in detail; it specifies only that:

  • Cross-Workforce references MUST use full URIs (§2.3).
  • Receiving Workforces MUST verify the signing identity of the source Envelope.
  • Federated work creates linked Envelopes; the union of linked Envelopes constitutes the full audit record for the federated work.

Detailed federation semantics are out of scope for this draft.

9.6 The Strategic Intent Registry

The per-top-level-Intent envelope semantics specified in §3.6.2 apply to the worker, function, and workforce scopes. Org-scope Intents (Strategic Intents per §3.4.6) do not use envelopes. Instead, every Authority maintains exactly one Strategic Intent Registry — a peer audit artefact alongside Envelopes, with the same cryptographic primitives but a different aggregation unit.

The Strategic Intent Registry is:

  • Per-Authority. One registry per Authority. Cross-Authority Strategic Intent visibility is a federation concern (§9.5) — out of scope for this draft.
  • Append-only. No event ever modifies a prior event. The registry’s only mutation is appending a new event.
  • Hash-chained. Each event references the hash of its predecessor in the registry. The chain begins at registry creation (a RegistryBootstrap event) and grows for the lifetime of the Authority.
  • Signed. Every event is signed by its actor (Operator principal, Workforce Director Worker, or runtime) and counter-signed by the runtime. The signing payload uses RFC 8785 JCS canonical-JSON (per ADR-W04) — the same wire format as Envelope events.
  • Never seals. Unlike Envelopes (which seal on root-Intent resolution per §9.4), the Strategic Intent Registry has no terminal state. The Authority’s strategic history is a running ledger.

The events permitted in the Strategic Intent Registry are those marked “Persisted in the Strategic Intent Registry” in §9.1 — StrategicIntentDeclared, StrategicIntentTransitionSuggested, StrategicIntentTransitioned, StrategicIntentSuperseded, WorkforceAggregatedOutcomeReported, StrategicIntentDeclined.

9.6.1 Storage

The registry’s persistent storage layout is:

authorities/<authority-id>/strategic-log/event-<seq>.json

— paralleling the envelope storage layout (envelopes/<workforce-id>/<envelope-id>/event-<seq>.json per §9.4). Storage is on a write-once-read-many backing store (typically S3-compatible) with the same per-event signing and chain-validation primitives as envelopes.

A Postgres cache (or equivalent queryable store) maintained alongside the registry holds: the chain head per Authority, the current declared/terminal state per Strategic Intent, and a reverse index from Strategic Intent IDs to back-referencing operational envelopes. The cache is derivable from the registry log; the log is authoritative.

9.6.2 Service Surface

Implementations MUST expose the registry via a service interface that supports:

  • AppendStrategicEvent — append a signed event; runtime verifies actor signature, counter-signs, advances chain state. Returns the next chain head.
  • LoadStrategicLog — read the log for an Authority, optionally from a given event ID with pagination, with replay-verification on read.
  • GetRegistryState — query the current declared/terminal state of a Strategic Intent without loading the full log.

mTLS authentication for the registry service is REQUIRED. The Authority’s principal-key registry (§14.3) authoritatively maps Operator and Workforce Director Worker principals to public keys for signature verification.

9.6.3 Provenance Back-References

Operational envelopes that advance a Strategic Intent MUST back-reference the registry record via the existing provenance-ref mechanism (§5.1, §3.4.5). The reference takes the form:

{
  "kind": "strategic_intent",
  "registry_authority": "authority:bank-au",
  "strategic_intent_id": "strategic:auth-acme/2026-Q3-superfood",
  "registry_event_id": "strategic-evt:01HXX..."
}

— and is included in the provenance section of operational Intents and in the relevant operational envelope events. The graph is traversable in both directions: bottom-up by walking provenance refs from an operational envelope to the registry record; top-down by querying the reverse index from a registry event to operational envelopes that back-reference it.

9.6.4 Relationship to ADR-W05

ADR-W05 of the Apophenic Workforce reference implementation settled the per-top-level-Intent envelope architecture. This section AMENDS that architecture: it preserves the per-top-level-Intent envelope rule for the worker, function, and workforce scopes (where envelopes have bounded lifetimes), and introduces the Strategic Intent Registry for the org scope (where envelope semantics would not bound). Implementations conforming to OWP-2 Working Draft 0.3 or later MUST implement both: per-scope envelopes for the three lower scopes, and the Strategic Intent Registry for the org scope.