# OpenAgents invariant ledger

These contracts define the current Simply OpenAgents release. A change to a listed

contract must update this ledger and its named test or model in the same

commit.

## OpenAgents identity and canon

### CANON-001 — Persona sources are immutable and status-labeled

Every historical source admitted to author OpenAgents's persona is pinned by

repository revision, path, content SHA-256, source status, admitted uses, and

explicit exclusions. The complete manifest has a canonical digest admitted by

the application and is validated before the supervision tree starts. Founder

direction, retired product material, unscheduled drafts, and scoped

performances cannot silently become runtime authority or ordinary voice.

Episode numbers are not source identity. The conflicting Episode 263 file is

quarantined, and the final Omega Alpha transcript is pinned by its actual path.

Evidence: `OpenAgents.Persona.SourceManifest`,

`priv/openagents/persona/openagents.v1.sources.json`, and

`OpenAgents.Persona.SourceManifestTest`.

### PERSONA-001 — Each inference uses one immutable persona artifact

OpenAgents's core identity, voice, and first-conversation greeting come from one

versioned artifact admitted by its exact content SHA-256. The artifact and its

source-manifest identity are validated and installed before the supervision

tree starts. Every provider request receives instructions composed from that

installed artifact; provider adapters contain no independent OpenAgents persona.

Evidence: `OpenAgents.Persona`, `priv/openagents/persona/openagents.v1.md`,

`OpenAgents.Context.Composer`, `OpenAgents.Turns.TurnServer`, and `OpenAgents.PersonaTest`.

### PERSONA-002 — One core OpenAgents identity composes with an admitted role

Protected identity and host safety precede surface truths, the selected role,

Blueprint expression facts, captured capabilities, and recalled evidence in a

deterministic composition. The public application selects only

`general_collaborator.v1`. Role selection accepts only typed host surface,

authority, request, and capability inputs; its canonical input/catalog receipt

is persisted immutably for text turns and voice sessions. User text, Blueprint,

profile memory, and bounded recalled evidence cannot select a role or replace

protected layers. Inactive coding, sales, company-operations, and public-

broadcast registers fail closed to the compatible general baseline or no role.

Evidence: `OpenAgents.Context.Composer`, `OpenAgents.Roles`, `OpenAgents.Roles.Catalog`,

`OpenAgents.Roles.GeneralCollaborator`, `docs/ROLE_PROGRAMS.md`,

`OpenAgents.Context.ComposerTest`, and `OpenAgents.RolesTest`.

### PERSONA-003 — Persona promotion requires revision-bound regression evidence

Every persona candidate is evaluated against the committed, source-labeled

behavior corpus. Promotion requires a complete passing report bound to the

exact persona, source manifest, corpus, and model revisions. All cases must

pass, so military, founder-voice, sales, false-recognition, or generic-assistant

containment failures cannot be averaged away.

Evidence: `OpenAgents.Persona.Evaluation`,

`priv/openagents/evals/persona/corpus.v1.json`,

`OpenAgents.Persona.EvaluationTest`, and `mix openagents.persona.verify_promotion`.

### BLUEPRINT-001 — Platform facts are source-linked immutable revisions

Every admitted OpenAgents Blueprint revision is a complete canonical snapshot of

typed platform facts. Facts carry stable IDs, source refs/status/time/digests,

compatibility, introduction/retirement revisions, and admission provenance.

Appending or retiring creates a revision; PostgreSQL rejects edits or deletion

of admitted rows. Compilation is deterministic and refuses conflict, stale

compatibility, missing provenance, private-memory sources, and prose that

claims data, pricing, tool, or action authority.

Every inference immutably pins the verified Blueprint revision and digest, or

pins the explicit-none state when no revision exists. Blueprint informs

expression below protected host layers and cannot attach a capability or

authorize execution.

Evidence: `OpenAgents.Blueprint`, the OpenAgents Blueprint schemas and migration,

`OpenAgents.Context.Composer`, `OpenAgents.Conversations.begin_inference/5`,

`docs/SARAH_BLUEPRINT.md`, and `OpenAgents.BlueprintTest`.

### PROGRAM-001 — Model programs are immutable typed data, never effect authority

Every admitted model-program artifact has one full canonical digest covering

its signature, compiler/model/decoding identity, compatibility, Prompt IR,

parameters, independent datasets, optimizer budget, evaluator, metrics and

uncertainty, provenance, approval, predecessor, and activation status. Training

or validation cannot alias true holdout. Boot admits only pinned digests with

known predecessors.

The OTP reader returns only typed artifact data. Program outputs are proposals,

selections, or scores and cannot execute a tool, add a catalog entry, mutate

policy or protected identity, write memory, or promote/activate themselves.

Each applicable turn captures one immutable artifact identity before provider

work; an in-flight capture cannot observe another catalog.

Evidence: `OpenAgents.ProgramArtifacts`, `OpenAgents.ProgramArtifacts.Reader`,

`priv/openagents/programs/`, `docs/PROGRAM_ARTIFACTS.md`,

`OpenAgents.Conversations.begin_inference/5`, and `OpenAgents.ProgramArtifactsTest`.

### DEGRADE-001 — Missing program artifacts degrade explicitly to a baseline

If an applicable signature has no admitted compatible artifact, capture returns

the deterministic baseline with no artifact ID/digest and a bounded degraded

receipt. Invalid or unapproved artifacts never enter the boot catalog. The turn

receipt immutably records either the exact artifact and catalog identity or the

explicit baseline reason before provider work.

Evidence: `OpenAgents.ProgramArtifacts.capture/1`,

`turn_receipts.program_artifact_receipt`, its database constraint/trigger,

`OpenAgents.ProgramArtifactsTest`, and degraded capture tests in

`OpenAgents.TurnProvenanceTest`.

### PROGRAM-002 — Shadow programs have no live effect or private report payload

Shadow signatures validate bounded typed input/output and run under a separate

task supervisor. The live turn never consumes their result. Memory and

collective outputs remain proposals; routing can name only a capability in its

captured input catalog. Malformed, late, failed, incompatible, and missing-

artifact paths degrade explicitly without writing memory, tools, policy,

Blueprint, collective data, or the user-visible answer.

PostgreSQL stores immutable terminal comparison metadata, digests, latency,

usage, and withheld output shape, never raw inputs or candidate values.

Replay data is explicitly synthetic or must enter through a future consented

fixture path; production conversations/profile memory are not datasets.

Evidence: `OpenAgents.ShadowPrograms`, `OpenAgents.ShadowPrograms.Signatures`,

`OpenAgents.ShadowPrograms.OpenAI`, `shadow_program_runs`,

`priv/openagents/evals/shadow/corpus.v1.json`, `docs/SHADOW_PROGRAMS.md`, and

`OpenAgents.ShadowProgramsTest`.

### PROGRAM-003 — Promotion is offline, human-approved, and rollback-capable

A compiled candidate, pinned independent evaluation, human approval, and human

activation are separate append-only artifacts/events. Evaluation is bound to

distinct train/validation/true-holdout manifests, exact evaluator identity,

complete bounded cost, metrics/uncertainty, and passing safety/privacy gates.

Datasets are synthetic or carry an explicit consent receipt; private production

data has no implicit admission path.

Only a human actor receipt can approve, activate, or roll back. Activation

atomically advances a PostgreSQL pointer generation for later turn captures;

an in-flight capture remains unchanged. Rollback selects the pinned predecessor

and preserves the complete prior trail.

Evidence: `OpenAgents.ProgramLifecycle`, its artifact/event/activation schemas and

database guards, `docs/PROGRAM_LIFECYCLE.md`, the synthetic sample promotion

report, and `OpenAgents.ProgramLifecycleTest`.

## Identity and authorization

### IDENTITY-001 — GitHub-authenticated account identity

Every OpenAgents interaction requires an active local user established through the

GitHub OAuth authorization-code flow. The immutable external key is GitHub's

numeric user ID; login and avatar URL are refreshable projections and never

authority. OAuth start uses high-entropy state plus PKCE S256. A short-lived

PostgreSQL attempt receipt makes state one-time even if an old encrypted cookie

is replayed. Phoenix exchanges the code and rereads `/user` server-side, then

discards the access token. The browser session contains only OpenAgents's local user

ID and is encrypted, signed, HTTP-only, same-site, and secure in production.

Evidence: `OpenAgents.GitHubOAuth`, `OpenAgents.Accounts`, `OpenAgentsWeb.AuthController`,

`OpenAgentsWeb.Endpoint.session_options/0`, `OpenAgents.GitHubOAuthTest`,

`OpenAgents.AccountsTest`, and `OpenAgentsWeb.AuthControllerTest`.

### IDENTITY-002 — Conversation lookup never accepts a client database ID

The browser supplies only its encrypted OpenAgents session. Server code loads the

active local user and resolves that user's internal storage owner and canonical

conversation. A route parameter, form value, mutable GitHub login, or LiveView

event must not select another user, owner, or conversation. All typed, memory,

data, voice, and telemetry routes fail before mutation without an active user;

health endpoints remain public and create no identity state.

Evidence: `OpenAgentsWeb.UserAuth`, `OpenAgentsWeb.Router`,

`OpenAgentsWeb.ChatLive.mount/3`, `OpenAgents.Conversations.get_conversation_for_user/1`,

and `OpenAgentsWeb.AuthGateTest`.

### IDENTITY-003 — Account continuity supersedes browser portability

One GitHub-authenticated user resolves the same canonical OpenAgents owner across

browsers and devices; no export/import ceremony is required for that account.

The disabled encrypted portability adapter remains only an explicit transfer

mechanism into the currently authenticated destination account. It does not

link accounts, change GitHub identity, grant authorization, or create automatic

sync between distinct users.

Each export derives a fresh AES-256-GCM key from a person-held passphrase using

the pinned PBKDF2 envelope and persists no key, passphrase, envelope, ciphertext,

payload, or claim in the portability plane. Decrypted claims may persist only by

passing the existing destination profile-memory admission contract. Portability

receipts may retain the opaque ciphertext-envelope digest for replay plus

bounded lifecycle metadata; they may not retain or index plaintext or a

content-derived claim derivative.

Destination replay/sequence, conflict, tombstone, and revocation receipts are

explicit. Rotation cannot revoke offline old bundles, tombstones propagate only

when a newer bundle is imported, and a lost bundle/passphrase is unrecoverable

by OpenAgents. Adapter failure leaves account-local operation unchanged.

Evidence: ADR 0002 (which supersedes ADR 0001's identity decision),

`OpenAgents.Memory.Portability`, its envelope and receipt schemas,

`docs/MEMORY_PORTABILITY_THREAT_MODEL.md`, and `OpenAgents.MemoryPortabilityTest`.

## Data authority and synchronization

### DATA-001 — PostgreSQL is authoritative

Visitors, conversations, messages, and turns are persisted before their state

is presented as accepted. PubSub and LiveView streams are projections; losing

either must not lose accepted data.

Evidence: `OpenAgents.Conversations.create_turn/2` and

`OpenAgentsWeb.ChatLiveTest` durable-turn test.

### DATA-002 — One canonical conversation per authenticated user

Database uniqueness enforces one internal storage owner per local user and one

conversation per owner. Initial greeting creation is coupled to first

conversation creation. Distinct users remain isolated; multiple sessions for

one user converge on the same conversation and therefore the same text and

voice limits. Pre-authentication browser rows remain inaccessible legacy data

and are never silently claimed during login.

Evidence: unique indexes and identity-source constraint in

`create_github_users`, `OpenAgents.Conversations.ensure_conversation/1`, and

account continuity/isolation/rate tests in `OpenAgents.AccountsTest`.

### DATA-003 — History is bounded and stable

The newest page and every older page contain at most the configured page size.

Ordering uses persisted timestamp plus UUID, and rendered rows use stable

message IDs.

Evidence: `OpenAgents.Conversations.list_messages/2` and bounded-history test.

## Memory and recall

### MEMORY-001 — Recall is confined to the current account conversation

Every recall snapshot and search is bound to one canonical conversation

resolved from the authenticated local user. A snapshot from another

conversation or user is refused, and no API offers a cross-conversation or

unscoped fallback. GitHub identity establishes account continuity but does not

turn conversation evidence into verified facts about a person.

Evidence: `OpenAgents.Memory.RecallSnapshot`, `OpenAgents.Memory.LexicalRecall`, and

cross-scope tests in `OpenAgents.Memory.LexicalRecallTest`.

### MEMORY-002 — Recalled history is classified evidence, not current profile truth

Every materially used read source is represented by a host-built

`openagents.memory_evidence.v1` value with validated source/scope, observed and

recalled times, bounded claim and relevance, host classification, and validated

corroboration/conflict refs. The model cannot supply scope or classification,

fabricate a source that passes the scoped database read, or promote weak,

stale, conflicting, or irrelevant evidence. Current user correction outranks

older history. Conversation evidence never enters the separate profile-memory

plane through repetition, model confidence, or recall classification.

Historical source content remains untrusted quoted data. It cannot change

OpenAgents's identity, safety rules, captured catalog, execution scope, authority,

or host limits. Terminal receipts immutably retain each materially used source

ref and its host classification.

Evidence: `OpenAgents.Memory.Evidence`, `OpenAgents.Tools.ConversationRead`,

`OpenAgents.Context.Composer`, `turn_receipts.used_memory_evidence`, its terminal

database trigger, `OpenAgents.Memory.EvidenceTest`, and

`OpenAgents.TurnMemoryEvidenceJourneysTest`.

### MEMORY-003 — Profile memory is explicit, inspectable, correctable, and forgettable

Durable profile claims live in a separate account-owner plane. A record

is only active with a same-owner complete user-message source or a host-recorded

explicit owner assertion. Candidates never activate through repetition or

model confidence. Claims and their identity/provenance fields are immutable;

correction atomically supersedes the old record with a source-linked new one.

Lifecycle transitions are explicit and optimistic-generation checked.

Every record and source is available to bounded owner export. Forget and expiry

are terminal states retained for audit; explicit purge is allowed only after a

terminal state and removes the record plus every derived source link without

deleting the independent conversation source message.

Evidence: `OpenAgents.ProfileMemory`, the profile-memory schemas and database

constraint triggers, `OpenAgentsWeb.ChatLive`, `OpenAgentsWeb.MemoryExportController`,

`docs/MEMORY_CONTROLS.md`, `docs/PROFILE_MEMORY.md`, `OpenAgents.ProfileMemoryTest`,

and memory-control journeys in `OpenAgentsWeb.ChatLiveTest`.

### MEMORY-004 — Scope and snapshot boundaries are database predicates

Recall scope is enforced by `messages.conversation_id` in every PostgreSQL

query, never by prompt instructions. Each inference immutably records a

`message:<uuid>` high-water ref for the last eligible message before the current

user turn. Searches apply its ordered timestamp/UUID cursor and admit only

complete user/assistant rows, so streaming or failed assistant text and normal

later inserts cannot enter the turn's recall view.

Evidence: `OpenAgents.Conversations.begin_inference/5`, the generated `search_vector`

and partial GIN migration, `OpenAgents.Memory.LexicalRecall`, immutable turn receipt

triggers, and snapshot/status/index tests in `OpenAgents.Memory.LexicalRecallTest`.

Search is discovery only. `conversation_search.v1` returns bounded excerpts;

`conversation_read.v1` must reread an exact source and bounded neighborhood

under the same host-supplied conversation/snapshot before historical wording is

treated as grounded. Foreign and unknown source UUIDs share one `not_found`

outcome, while materially returned refs are recorded on the turn receipt.

Evidence: `OpenAgents.Tools.ConversationSearch`, `OpenAgents.Tools.ConversationRead`,

`OpenAgents.Tools.RecallContext`, `OpenAgents.Tools.ConversationRecallToolsTest`, and the

end-to-end recall loop in `OpenAgents.TurnToolLoopTest`.

Recall's source universe covers durable tool activity as well as messages.

`conversation_search.v1` lexically matches terminal tool steps from both

surfaces (`turn_tool_steps`, `voice_tool_steps`) over tool name, status, and

bounded result/error text, returning typed `turn-tool-step:<uuid>` /

`voice-tool-step:<uuid>` refs classified as `tool_activity` with the same

excerpt bound and deterministic score/timestamp/id ordering as messages. A

tool step is observable at a snapshot only when it completed at or before the

watermark message's insertion instant, or when the assistant message that

concluded its work unit (turn or voice response) is itself admitted by the

message fence — both predicates compare immutable persisted values with the

immutable snapshot, so work later than the frozen turn never enters its recall

view. `conversation_read.v1` resolves those refs within the same

conversation/snapshot scope into a bounded step context (tool name, status,

bounded result/error, timestamps, executor disclosure) plus the nearest

admitted neighboring messages; foreign and unknown step refs share the

messages' single `not_found` outcome.

Evidence: tool-step queries and step reads in `OpenAgents.Memory.LexicalRecall`,

step-ref usage items in `OpenAgents.Memory.Evidence`, and the tool-step recall,

scope-refusal, and snapshot-fencing tests in

`OpenAgents.Tools.ConversationRecallToolsTest`.

Profile-memory queries likewise require `owner_visitor_id` in every predicate.

An opaque persisted snapshot pins both the owner's monotonic scope generation

and capture time. Activation and terminal generations reconstruct the active

set after concurrent correction, forgetting, or expiry; another account cannot

load or use the snapshot. Multiple authenticated sessions for the same account

intentionally share it. Unknown scope has no global fallback.

Evidence: `profile_memory_scopes`, `profile_memory_snapshots`, generation

columns and indexes in the profile-memory migration, `OpenAgents.ProfileMemory`, and

cross-browser/concurrent-snapshot tests in `OpenAgents.ProfileMemoryTest`.

### MEMORY-005 — Memory writes require exact current consent

A sampled tool call is a proposal, not write authority. `memory_remember.v1`

accepts only an exact bounded claim directly authorized by the current complete

user message, an exact host-recorded confirmation, or an exact first-party UI

action in the same account scope. Repetition, recalled text, classifier

confidence, and model arguments cannot substitute. `memory_forget.v1` applies

the same rule to one record, one category, or the whole account scope and is

idempotent without revealing foreign-record existence.

Each turn captures a persisted profile-memory snapshot before provider work.

List/search use only that frozen generation, while remember/forget return a

bounded reversible receipt after PostgreSQL commits. OpenAgents may acknowledge

only the exact successful result returned in the durable tool outcome.

Evidence: `OpenAgents.Memory.Consent`, the four `OpenAgents.Tools.Memory*` tools,

`turn_receipts.profile_memory_snapshot_ref`, `docs/MEMORY_TOOLS.md`, and

`OpenAgents.Tools.ProfileMemoryToolsTest`.

### MEMORY-006 — Semantic recall is scoped, disposable, and lexically degradable

Authoritative durable conversation rows — messages, and for lexical

tool-activity recall the terminal tool steps — remain the sole recall

authority; semantic embeddings exist only for messages. Embeddings are

asynchronous derivatives bound to the source message, exact conversation,

content digest, model/version manifest, and active generation. Hybrid queries

repeat the conversation and frozen snapshot predicates in PostgreSQL and admit

only ready rows whose digest still matches the authoritative complete message.

Correction, deletion, and rebuild invalidate derivative rows and produce

append-only receipts; a new manifest generation cannot read an older one.

Receipts cannot be edited or deleted while their authoritative conversation

exists. Exact authenticated-owner product-data deletion first removes that conversation and

may then delete its now-unlinked content-free receipts in the same transaction.

The pinned hybrid rank is deterministic reciprocal-rank fusion with stable

timestamp/UUID ties. A provider, manifest, shape, query, or incomplete-index

failure is explicitly `semantic_degraded` and returns the unchanged lexical

page. Hybrid recall is disabled by default and cannot be activated merely by

creating vectors; its committed comparison must preserve lexical fallback and

scope isolation while improving synonym recall.

Evidence: `OpenAgents.Memory.SemanticIndex`, `OpenAgents.Memory.HybridRecall`, semantic

derivative tables and triggers, `docs/HYBRID_RECALL.md`,

`priv/openagents/evals/recall/hybrid-comparison.v1.json`, and

`OpenAgents.SemanticRecallTest`.

### MEMORY-007 — Learned preferences require confirmation and never confer authority

Behavior preferences occupy an account-owner plane separate from conversation

evidence, profile facts, roles, tool catalogs, routing authority, and collective

artifacts. An observation or model confidence can create only a candidate. The

only admitted effects are finite presentation/interaction choices; every

candidate must pass policy review, an exact owner confirmation receipt, and a

separate durable activation receipt before it can affect composition.

Every turn freezes a monotonic preference snapshot. Applied and

current-instruction-overridden preferences are immutably recorded with exact

preference, effect-digest, and activation-receipt refs. A current user request

wins for that turn without rewriting the stored preference. Suspension,

correction, and deletion end the effect for later snapshot generations while

preserving historical turn provenance. Outcomes can be recorded only for a

preference actually applied to that exact owner turn.

Preference evidence and receipts remain append-only while their owner exists.

Exact authenticated-owner product-data deletion is the only exception: PostgreSQL cascades

the complete preference graph after the visitor root is gone, while rejecting

direct or foreign-scope receipt deletion.

Evidence: `OpenAgents.Preferences`, the preference schemas and database guards,

`OpenAgents.Context.Composer`, `turn_receipts.used_preferences`,

`docs/GOVERNED_PREFERENCES.md`, the committed preference comparison, and

`OpenAgents.PreferencesTest`.

### MEMORY-008 — Experience is private, terminal, evidenced, and advisory

Work experience occupies an exact account-owner and conversation-work-scope

plane separate from profile facts, learned preferences, roles, tool authority,

and collective artifacts. Requested and running cases never enter recall.

Success requires a target receipt emitted by a succeeded governed tool step in

the same owner conversation; failure remains explicitly labeled failure. A

single success is one scoped observation, never a universal pattern.

Each turn either has no experience capture or freezes one deterministic,

bounded bank at a monotonic scope generation. Every projection names its

applicability and evidence; storage and projection both pass redaction.

Corrections create a new record, inspection/export remain bounded, and deletion

removes evidence, pattern, and bank derivatives while invalidating affected

banks. Crossing into collective work requires the independent exact-consent

candidate workflow and cannot directly publish or write a global pattern.

Default activation remains off until the committed memory-on/off evaluation

shows measured task benefit without scope or provenance regression.

Experience deletion receipts remain append-only while their owner exists.

Exact authenticated-owner product-data deletion is the only exception: PostgreSQL cascades

the scoped experience graph, including frozen banks linked to deleted turns,

then removes standalone deletion receipts only after the visitor root is gone.

Direct and foreign-scope receipt deletion remain rejected.

Evidence: `OpenAgents.ExperienceMemory`, the experience schemas and database guards,

`OpenAgents.Context.Composer`, `turn_receipts.used_experiences`,

`docs/PRIVATE_EXPERIENCE_MEMORY.md`, the committed benefit comparison, and

`OpenAgents.ExperienceMemoryTest`.

### MEMORY-009 — Graph memory is a disposable, generation-atomic projection

The relationship graph is never memory authority. Every node and edge belongs

to one account owner, one conversation work scope, one immutable manifest

generation, and at least one exact authoritative experience-record or pattern

membership. Deterministic identities preserve explicit entity, version, and

conflict fields without collapsing differing outcomes into asserted truth.

Source mutations emit an outbox row in the same PostgreSQL transaction. A

pending mutation makes the current graph unavailable; rebuild locks the source

scope, pins and digests one source snapshot, constructs a complete building

generation, and atomically retires the old generation and exposes the new one.

Dropping every graph table loses no authoritative memory, and replaying the same

source snapshot produces the same build digest.

Traversal requires the exact owner/work scope, current source policy eligibility,

finite depth and result bounds, and source provenance on every returned artifact.

Deletion uses an inspectable exact-generation cascade plan and append-only

completion receipt. Graph use remains disabled by default until its committed

paired evaluation demonstrates material relationship benefit with no scope or

membership regressions.

Graph operation receipts remain append-only while their owner exists. Exact

authenticated-owner product-data deletion is the only exception: manifest-owned projections

cascade with the visitor, and the same transaction removes standalone

memberships, mutation events, cascade plans, and operation receipts after the

visitor root is gone. Direct and foreign-scope receipt deletion remain rejected.

Evidence: `OpenAgents.GraphMemory`, graph manifests/artifacts/memberships/outbox and

database guards, `docs/DERIVED_GRAPH_MEMORY.md`, the committed graph comparison,

and `OpenAgents.GraphMemoryTest`.

### PRIVACY-001 — Secret-bearing profile memory is rejected, never scrub-stored

Before candidate storage, the host applies the pinned

`openagents.memory.policy.v1` policy to the claim, provenance/artifact metadata, and

same-owner source content. Credential, API/auth token, wallet/seed/payment,

encoded-secret, and local-path material rejects the whole candidate. The

rejected value, a hash of it, or a partially scrubbed shell is never persisted.

Only owner scope, fixed policy version, bounded reason/category, size bucket,

and time enter the rejection audit.

Every export or future model/UI projection re-applies

`openagents.memory.redaction.v1`. A value that fails revalidation is withheld as a

whole field. Stored policy identities are immutable, so later policy changes

cannot silently relabel old records or rejection evidence.

Evidence: `OpenAgents.Memory.Policy`, `OpenAgents.Memory.Redaction`,

`profile_memory_policy_events`, immutable policy-version trigger,

`docs/MEMORY_PRIVACY_POLICY.md`, and `OpenAgents.Memory.PolicyAndRedactionTest`.

## Turn and provider lifecycle

### TURN-001 — At most one active turn per conversation

An active turn is `queued` or `streaming`. A partial unique PostgreSQL index is

the final arbiter; the UI's disabled composer is only feedback.

Evidence: `turns_one_active_per_conversation_index` and active-turn test.

### TURN-002 — Every accepted turn has durable paired messages

The user message, empty streaming assistant message, and turn record are

inserted in one transaction. Completion, failure, and cancellation update both

assistant-message and turn terminal state.

Evidence: `OpenAgents.Conversations.create_turn/2`, `finish_turn/5`, and turn tests.

### TURN-003 — Provider work never blocks the LiveView

Each response executes in a temporary `TurnServer` under a dynamic supervisor;

the outbound provider call executes in a supervised task. Text deltas cross a

typed provider callback and are persisted before broadcast.

Evidence: `OpenAgents.Turns.TurnServer`, `OpenAgents.ProviderTaskSupervisor`, and

`OpenAgentsWeb.ChatLiveTest` streaming test.

### TURN-004 — Interrupted work becomes explicit failure

Active records left by a runtime restart are marked failed during application

startup. A response is never left permanently presented as in progress without

an executing turn process.

Evidence: `OpenAgents.Conversations.recover_interrupted_turns/0`, the

`OpenAgents.TurnRecovery` application child, and startup-recovery test.

### TURN-005 — Tool continuations are serial, bounded, and commit-first

One turn may request a bounded number of tool calls and provider continuations

(sixteen of each today). Calls execute one at a time; parallel calls fail the

turn. Hitting an execution bound refuses the over-limit call with a durable

typed step outcome and drives one final tool-free report response, so the

person receives partial findings instead of a failed turn; only runaway

behavior past the report path fails the turn. Each continuation uses the exact

provider call ID and previous response ID only after rereading the matching

committed outcome. Cancellation reaches provider and tool tasks, while prior

text, receipts, provider steps, and tool outcomes remain durable on every

terminal path.

Evidence: `OpenAgents.Turns.TurnServer`, `OpenAgents.Providers.OpenAI.request_payload/1`,

`OpenAgents.TurnToolLoopTest`, and `OpenAgents.Providers.OpenAI.RequestPayloadTest`.

### PROVENANCE-001 — Every new inference has an immutable receipt

Before provider work starts, OpenAgents durably captures the exact model, persona,

role, instruction digest, canonical input digest, optional runtime artifact

identities, and first provider step. Identity fields never change; terminal

receipts and provider steps cannot be rewritten. Failures, cancellation, and

restart recovery preserve the captured chain. Turns created before this

contract remain explicitly legacy rather than receiving invented provenance.

Evidence: `OpenAgents.Conversations.begin_inference/4`, PostgreSQL provenance

triggers, `OpenAgents.Provenance.Canonical`, and `OpenAgents.TurnProvenanceTest`.

### PROVIDER-001 — Model providers are replaceable

Conversation and web code depend on `OpenAgents.Providers.Provider`, not OpenAI

event shapes. Adapters emit typed OpenAgents-domain lifecycle, text, tool-call,

usage, completion, failure, and cancellation events. A response ID is persisted

when announced, and matching explicit completion is required; stream closure

alone cannot produce a completed turn. Provider-specific events, credentials,

and raw errors never reach the receipt or browser.

Evidence: `OpenAgents.Providers.ProviderEvent`, `OpenAgents.Providers.OpenAI`,

`OpenAgents.Providers.OpenAI.StreamDecoderTest`, `OpenAgents.Providers.Test`, and

`OpenAgents.TurnProviderEventsTest`.

## Tool authority and execution

### TOOL-001 — A turn uses one immutable tool catalog

The registry validates configured tool specifications at boot. Before provider

work, each turn captures one catalog snapshot and writes its canonical digest

to the immutable receipt. Every call must match the exact tool name and version

in that snapshot; later registry builds or deployments affect only later turns.

Evidence: `OpenAgents.Tools.Registry`, `OpenAgents.Tools.Snapshot`,

`OpenAgents.Turns.TurnServer`, and `OpenAgents.Tools.RegistryAndRunnerTest`.

### COLLECTIVE-001 — Private material crosses scope only through exact consent

A collective candidate can be created only in the same transaction as an active

`collective_contribution` receipt from the owning person. The receipt binds the

exact browser-owned source refs and their content digest, source-scope digest,

category, intended use, attribution and compensation disclosures, policy

version/digest, confirmation nonce/digest, and grant time. Model suggestions,

profile-memory consent, product terms, and tool approval are different authority

types and cannot satisfy this gate.

The candidate remains keyed and queried by its private visitor owner. It stores

only the scope digest, opaque per-source provenance refs, redaction-policy

identity, generalized-kind placeholder, evaluator/status, and bounded

review/publication refs; it does not copy source refs, quotes, or identifying

context into candidate fields and has no registry/discovery/execution path.

Owner withdrawal atomically marks consent withdrawn and the unpublished

candidate terminal. If publication refs later exist, withdrawal instead creates

`revocation_pending` propagation state. Consent never publishes or admits a

module; those require separate independent operator review.

Evidence: `OpenAgents.Collective`, `OpenAgents.Collective.ConsentReceipt`,

`OpenAgents.Collective.Candidate`, database scope/state/transition constraints, and

the consent, isolation, raw-copy, and withdrawal cases in `OpenAgents.CollectiveTest`.

### COLLECTIVE-002 — Generalization is bounded, content-free, and reproducible

Only an authenticated privacy reviewer in the candidate owner's scope can run

generalization or inspect opaque lineage. The versioned fixed-vocabulary

generalizer recognizes a bounded supported signal and emits one admitted schema

for evaluation cases, prompt examples, module patterns, or reusable work

patterns. Output is scanned again for secrets, contacts, identifiers, paths,

exact source fragments, authority-bearing fields, and size before storage. It

cannot copy private sources or manufacture executable capability/authority.

The append-only generalization receipt contains candidate/source/policy/

generalizer/output digests, kind-support signal, source count, risk/utility, and

bounded reason codes—never rejected content. Unsupported/high-risk material is

terminally rejected with no generalized payload. A successful payload becomes

immutable, and identical kind/signal/policy inputs produce the same output

digest. This is conservative de-identification, not a claim of mathematically

irreversible anonymity, and it still grants no publication/module authority.

Evidence: `OpenAgents.Collective.Generalizer`,

`OpenAgents.Collective.GeneralizationReceipt`, generalized-candidate database

constraints/triggers, and adversarial schema, reproducibility, lineage, and leak

scans in `OpenAgents.CollectiveGeneralizerTest`.

### COLLECTIVE-003 — Publication requires independent evidence and operator authority

A generalized candidate reaches the cross-user collective catalog only when its

contribution consent remains active, its privacy generalizer is bound to an

authenticated reviewer, and a different authenticated evaluator records a

pinned artifact, pinned dataset, versioned policy, and passing privacy, safety,

regression, novelty, utility, compatibility, and no-authority-expansion result.

A separately authenticated operator, distinct from both reviewers, must then

write the publication receipt. Self-review, self-approval, missing digests,

failed dimensions, withdrawn consent, and legacy unbound generalization receipts

fail closed.

Publication creates a new immutable `openagents.module_artifact.v1` through the same

artifact validation and registry dependency admission used by first-party

modules. The artifact contains only the reviewed generalized payload and opaque

attribution lineage. It begins `disabled` in a staged collective catalog and

has no installed executable, discovery, routing, or invocation path. Review,

operator-decision, and publication receipts are append-only and bind all actor,

policy, evaluation, artifact, predecessor, attribution, and derived-data-plan

evidence. An operator rejection is terminal for that immutable candidate and

publishes nothing.

Consent withdrawal creates revocation propagation. Revocation or staged

regression rollback writes a successor receipt and revoked artifact digest,

excludes the module from all new catalog projections, and marks the bounded

delete/rebuild plan required while preserving content-free historical evidence.

A privacy revocation cannot be rolled back, and an already published module

version is never overwritten.

Evidence: `OpenAgents.Collective.Reviewer`, `OpenAgents.Collective.Publisher`,

`OpenAgents.Collective.ReviewReceipt`, `OpenAgents.Collective.OperatorDecisionReceipt`,

`OpenAgents.Collective.PublicationReceipt`,

`OpenAgents.Modules.Artifact.from_collective/1`, database transition/append-only

guards, and `OpenAgents.CollectivePublicationTest`.

### COMPENSATION-001 — Attribution accounting never creates payout authority

Technical invocation cost, contributor attribution, compensation eligibility,

and payment are distinct facts. An event is compensation-eligible only when an

operator-admitted policy with `payout_authority: false` binds an exact immutable

module artifact to contribution allocations totaling one million parts, the

invocation is uniquely persisted and billable, its terminal outcome is accepted

by an authenticated outcome reviewer, the artifact is not revoked, and the

invocation/outcome has not already been classified. A model proposal, module

publication, invocation, or successful tool result alone cannot make an event

eligible or payable.

Eligible units are allocated deterministically by contribution reference with

integer remainder handling. Unique invocation and outcome keys prevent double

counting. Revocation blocks future eligibility but never rewrites historical

events. Refund, chargeback, fraud/dispute, and policy-migration handling occurs

only through append-only signed adjustments; statements deterministically

reconcile gross, adjustment, and net units for one policy and contributor.

Every policy, module allocation, outcome decision, event, share, adjustment,

and statement is append-only. Contributor/operator projections expose opaque

lineage, digests, counts, units, and reconciliation state but never arguments,

results, conversation content, user identity, payment instructions, custody, or

a payout operation.

Evidence: `OpenAgents.Compensation`, its seven typed receipt schemas and database

constraints, `docs/COMPENSATION_ACCOUNTING.md`, and duplicate, revocation,

allocation, adjustment, reconciliation, privacy, and no-payout cases in

`OpenAgents.CompensationTest`.

### MODULE-001 — Every invocation pins one immutable admitted module

The captured turn registry contains provider-neutral module artifacts whose

canonical digest covers typed input/output, lifecycle state, side-effect and

approval classes, capability/data scopes, policy facets, executor identity,

publisher/maintainer, provenance, compatibility/dependencies, predecessor,

deprecation, rollback, and attribution policy. The artifact also binds the

loaded BEAM executor identity. Immediately before invocation the runner verifies

that loaded identity; missing or changed bytes fail closed. Durable tool-step

identity records the registry, route receipt, artifact, executor, module version,

attribution-policy version/digest, side-effect class, arguments, invocation key,

and explicit billing identity.

Only admitted or explicitly deprecated modules are projected into discovery and

provider schemas. Disabled and revoked artifacts remain visible to provenance

inspection but are unavailable to new turns. A registry replacement can affect

only a later turn; predecessor and rollback metadata never mutate an already

captured snapshot. First-party recall remains subject to `TOOL-001` through

`TOOL-004` and its existing conversation/profile scope predicates.

Evidence: `OpenAgents.Modules.Artifact`, `OpenAgents.Modules.Registry`,

`OpenAgents.Tools.Registry`, the module identity columns and database transition

constraint on `turn_tool_steps`, `OpenAgents.Modules.RegistryTest`, and module

invocation reconciliation tests in `OpenAgents.ToolStepPersistenceTest`.

### MODULE-002 — Discovery and lifecycle never grant model authority

The model-facing discovery tool receives the exact registry already captured by

its turn and returns at most twenty bounded public metadata references. It cannot

register a module, reveal executable/provider schemas or private configuration,

or grant execution, scope, approval, or authority. Every later use must

revalidate both the registry and artifact digests against the same capture;

stale references fail closed. Deprecated modules are excluded from default new

selection but remain available to an explicit historical projection.

Stage, admit, deprecate, disable, revoke, and predecessor rollback are host-only

operator operations requiring an authenticated operator identity and a unique

approval receipt. Artifact, provenance, policy, compatibility, and dependent

impact checks run before an append-only PostgreSQL receipt is committed. Text

and voice surfaces apply the latest receipts only when capturing a new registry;

an in-flight turn/session keeps its prior snapshot. Revoked modules cannot be

restaged or admitted, and active dependents block disable/revoke.

Evidence: `OpenAgents.Modules.Discovery`, `OpenAgents.Tools.ModuleDiscover`,

`OpenAgents.Modules.Lifecycle`, `OpenAgents.Modules.LifecycleReceipt`, the append-only

database trigger, and the discovery/lifecycle tests.

### MODULE-003 — Routing proposals cannot weaken explicit policy

Module routing receives a captured registry, a versioned/digested host policy,

an intent digest, required capability/effect/data scope, and application-created

authorities. Publisher, cost class and numeric budget, quality, privacy,

residency, jurisdiction, censorship-resistance, approval, side effect, runtime,

scope, and authority are hard filters applied before deterministic ranking. A

model/program proposal is only a reference to revalidate. It cannot add a

candidate, change policy, infer away a stricter constraint from casual language,

or trigger an unauthorized fallback.

The exact decision is persisted before tool-step dispatch without raw prompt

content. Immediately before execution the host revalidates registry, artifact,

policy, scope, and authority; the tool runner then independently repeats its

scope/authority/effect checks. No eligible module produces a typed unavailable

or refused outcome. An unadmitted routing-program identity is rejected, and an

absent/degraded optional program uses the reproducible deterministic baseline.

Evidence: `OpenAgents.Modules.RoutingPolicy`, `OpenAgents.Modules.Router`,

`OpenAgents.Modules.RouteReceipt`, `OpenAgents.Modules.RoutingReceipts`, the append-only

route-receipt trigger, `OpenAgents.Turns.TurnServer`, and router/tool-loop tests.

### MODULE-004 — Every capability surface preserves the same authority boundary

Every route and invocation names exactly one admitted surface from `text`,

`voice`, `search`, `computer`, `repository`, `mcp`, or `agent`. The selected

artifact must admit that surface, kind, and effect; revalidation refuses a

surface change. Voice and text share the admitted persona, role, Blueprint,

memory authorities, registry, and outcome envelope rather than forking OpenAgents's

identity.

Read-only work requires exact application-created scope and authority.

Reversible writes require exact current-user consent, and external effects

require an external or operator approval receipt bound to module, version, and

scope. Every successful non-read effect returns a target receipt, and every

outcome discloses the actual executor. Large catalogs are bounded by schema

count and encoded size; above either ceiling only discovery is exposed, and

its proposals pass ordinary revalidation. Missing executors fail honestly.

Evidence: `OpenAgents.Modules.SurfacePolicy`, the `surface` field on module route

decisions/receipts, `OpenAgents.Tools.Registry.prompt_catalog/1`,

`OpenAgents.Tools.Runner`, `docs/MODULE_SURFACES.md`, and the surface, catalog,

approval, receipt, voice-interruption, and degradation tests.

### TOOL-002 — Model requests never widen host authority

Tool name, arguments, recalled text, and prompt content grant no scope or

authority. The runner checks the application-created execution context against

the captured specification before implementation code runs. It admits read-only

tools, explicitly scoped reversible writes, and external effects only with the

surface-specific approval and target-receipt contract.

Reversible memory writes still pass their current-consent, owner, policy,

conflict, and optimistic-generation gates.

Evidence: `OpenAgents.Tools.ExecutionContext`, `OpenAgents.Tools.Runner`, and the scope,

authority, schema, and side-effect runner tests.

### TOOL-003 — Tool outcomes are durable before provider continuation

Every provider call ID maps to one ordered immutable request row. A worker must

atomically claim `requested -> running`; duplicate requests return the existing

row and duplicate claims cannot execute it again. Provider continuation output

can be constructed only by rereading a committed terminal outcome. Active

steps block normal turn completion and become explicit cancelled, failed, or

interrupted outcomes with the containing turn.

Evidence: `OpenAgents.Conversations.ToolStep`, the `turn_tool_steps` constraints and

transition trigger, `OpenAgents.Conversations.tool_continuation_output/1`, and

`OpenAgents.ToolStepPersistenceTest`.

### TOOL-004 — Every outcome identifies the actual executor

Every success, failure, refusal, cancellation, timeout, or unavailable result

is a bounded `openagents.tool_outcome.v1` envelope naming the captured module version

and actual executor/disclosure. Attribution and target receipt refs are bounded

and validated; one OpenAgents interface never implies OpenAgents performed hidden work.

The terminal invocation adds an immutable normalized outcome receipt and bounded

usage/cost projection before provider continuation. OpenAgents's continuation and UI

activity disclose the executor; UI activity renders at most the bounded

durable outcome projection UI-002 sanctions, never an unbounded payload.

Success may rely on the normalized outcome receipt for local/read-only work;

target-system refs remain separately preserved whenever an effect or source

produces them.

Evidence: `OpenAgents.Tools.Tool`, `OpenAgents.Tools.ExecutionResult`,

`OpenAgents.Tools.Runner`, `OpenAgents.Conversations.ToolStep`, the invocation-ledger

database constraints, normalized-outcome tests, and executor-disclosure UI tests.

### DEGRADE-001 — Tool degradation is explicit and deterministic

Unknown versions, invalid schemas or arguments, scope/authority refusal,

unsupported effects, cancellation, timeout, crashes, and oversized/invalid

output become typed bounded outcomes. They never silently execute a substitute

tool, widen scope, expose raw exceptions, or fabricate success.

Evidence: `OpenAgents.Tools.Runner` and its failure-path tests.

Lexical recall unavailability is the typed `lexical_unavailable` tool failure.

The failed step remains in the receipt and the provider may only describe the

available path honestly; it may not guess at history or silently substitute a

different authority plane.

Evidence: the committed recall evaluation, `OpenAgents.TurnToolLoopTest`, and

degradation tests in `OpenAgents.Tools.ConversationRecallToolsTest`.

## Delegated work

### WORK-001 — Delegated jobs are durable, budgeted, governed, and never die silently

A `deep_work.v1` call is only delegation, never execution: it starts one

durable `work_jobs` row scoped to the caller's conversation and owner and

returns immediately with a job reference, so the requesting turn or voice

response acknowledges in one sentence while the work runs server-side. The

worker drives the same configured text provider under the same composed

persona instructions, the same captured tool-catalog snapshot, and the same

governed `OpenAgents.Tools.Runner`, with each tool call committed as an ordered

`work_job_steps` row before execution and continued only from its committed

terminal outcome. A job's authorities never include `work.delegate` or

`memory.write`, its provider request never advertises `deep_work`, and an

arriving recursion call is refused with a durable typed outcome, so

delegation depth stays at one and a job cannot widen the caller's authority.

Every job is bounded — thirty-two tool calls, thirty-two continuations, a

ten-minute wall clock — and a tripped bound refuses the over-limit call with

a durable typed step outcome, forces one final tool-free report response, and

ends the job as explicit `budget_exhausted`. Every terminal path (`completed`,

`failed`, `interrupted`, `budget_exhausted`) stores a non-empty report:

streamed report text is persisted as it arrives, and a job that dies before a

narrative gets an honest host summary of its committed step evidence.

PostgreSQL constrains status transitions and makes terminal jobs and terminal

steps immutable. Startup recovery RESUMES orphaned active jobs (#97): it

restarts each job's supervised worker, which re-claims through the generation

fence and continues — a delegation by its durably checkpointed ACP session id,

deep work from its committed evidence. A job whose cluster singleton is still

alive (a fleet survivor) answers `already_started` and is never disturbed or

double-adopted; the restart is recorded as a degraded `runtime_restarted`

incident; and only a job whose worker cannot start at all is finalized

`interrupted` with its partial report intact. On terminal state the

bounded report becomes a durable assistant conversation message linked to the

job, so it enters ordinary recall and later provider context; a live voice

session receives the report through the existing typed-message injection as a

best-effort projection that can never rewrite the committed terminal state.

Evidence: `OpenAgents.Work`, `OpenAgents.Work.Job`, `OpenAgents.Work.JobStep`,

`OpenAgents.Work.JobServer`, `OpenAgents.WorkRecovery`, `OpenAgents.Tools.DeepWork`, the

`create_work_jobs` migration triggers, `OpenAgents.WorkJobTest`, and

`OpenAgents.DeepWorkToolLoopTest`.

### SELF-EDIT-001 — Every behavior change is anchored to a pushed commit (2026-08-19)

OpenAgents may edit her own source only through governed repository tools acting

on a per-job clone of her own forge, and nothing she writes becomes running

behavior except through the receipted pipeline. Concretely:

- **The pushed commit is the artifact.** Every behavior change to the

  running system is anchored to a commit pushed to the forge; the WAL entry

  that acked that push is its durable digest. Hot-loaded code is a

  *projection* of a pushed commit, never authority: a node restart that

  converges to the promoted fleet target (or, absent one, to the image) is

  always correct and loses nothing that was ever authority.

- **Mutation stays inside the job's clone.** Repository write tools operate

  only under that job's workspace clone whose origin is the local forge —

  never GitHub, never the baked source, never another job's clone. Pushes go

  only to that job's own `openagents/job-<id>` branch; a push to any other ref is

  refused with a typed outcome. The clone is removed when the job ends.

- **Promotion is an operator action.** No OpenAgents tool can promote, deploy, or

  hot-load. The job's report links the pushed SHA; the `/admin/forge`

  Promote click (ADMIN-001 as amended) is the human approval receipt, and

  the allowlist of hot-loadable modules remains operator-owned data.

- **Receipts reconstruct what ran.** Tool outcome receipts carry the commit

  SHA of every push; push, build, and deploy receipts chain from that SHA;

  together they let an operator reconstruct exactly which code was live

  when, with no step inferred.

Evidence: `OpenAgents.Tools.Repository` (clone confinement, branch discipline,

typed refusals), `OpenAgents.Work.Coding`, `OpenAgents.Forge.Pushes` /

`OpenAgents.Forge.Targets` / `OpenAgents.Forge.HotLoader` receipts, ADMIN-001, and

`OpenAgents.Tools.RepositoryTest` / `OpenAgents.CodingJobTest`.

## Interface and release

### VOICE-001 — Spoken identity is admitted before media

Standalone OpenAgents's first voice artifact is `openagents.voice.openai.marin.v1` using

native OpenAI Realtime `gpt-realtime-2.1` at low reasoning effort. It is a

deliberate repository-local revision of the earlier Leda direction, not a

silent fallback or a change to One. Boot refuses unadmitted architecture,

provider, model, voice, reasoning, or duration values. Any future custom voice,

Leda cascade, or built-in replacement requires a reviewed artifact revision

and regression evidence.

Evidence: `OpenAgents.Voice.Config`,

`docs/voice/OPENAI_REALTIME_DECISION.md`, and `OpenAgents.Voice.ConfigTest`.

### VOICE-002 — Browser media admission cannot acquire server authority

Voice is default-disabled. When enabled, an active authenticated user may send

only a bounded SDP offer through the same-origin, CSRF-protected endpoint.

Phoenix supplies the OpenAI credential, session configuration, and stable

privacy-preserving safety identifier derived from OpenAgents's local user ID. The browser receives only a bounded SDP

answer; provider credentials, call identity, protected configuration, and

future tool control remain server-side. Invalid identity, configuration, SDP,

provider location, and provider failure all fail closed without raw provider

details.

Evidence: `OpenAgentsWeb.VoiceCallController`,

`OpenAgents.Voice.OpenAI.CallClient`, `OpenAgents.Voice.OpenAI.CallClientTest`, and

`OpenAgentsWeb.VoiceCallControllerTest`.

### VOICE-003 — Durable voice history is generation-fenced

PostgreSQL owns every admitted voice generation and permits at most one active

generation per conversation. Provider events, response receipts, and

transcript items repeat the admitted generation; both runtime matching and

database constraints reject stale work. Ordered normalized events commit under

a locked session row, exact provider-event retries are idempotent, immutable

session provenance cannot be rewritten, and a terminal generation rejects

late events.

The supervised runtime owns only live connection state. Startup or process

loss makes the affected generation explicitly failed; it never invents a

successful resume or transcript.

Evidence: `OpenAgents.Voice`, the `create_voice_runtime` migration,

`OpenAgents.VoiceSessions.SessionServer`, `OpenAgents.VoiceRecovery`,

`docs/voice/VOICE_RUNTIME.md`, `OpenAgents.VoiceTest`, and

`OpenAgents.VoiceSessionsTest`.

### VOICE-004 — Only bounded provider-neutral voice evidence becomes durable

OpenAI wire events are decoded behind the provider adapter. Audio deltas,

partial transcript deltas, credentials, SDP, provider error text, and unbounded

wire payloads never enter OpenAgents's durable voice domain. Final user

speech may be stored; OpenAgents speech is bound to a started response receipt and

is marked interrupted when barge-in supersedes it. Completion without a

started receipt rolls back. Provider-reported usage remains absent when the

provider did not report it rather than being invented as zero.

Call audio is the single deliberate exception, and it enters through a

different door: not the provider event path but a browser upload, under the

separate bounds of VOICE-012. The distinction is the point — a bounded recorded

artifact is not the same as letting the provider wire into the database.

Evidence: `OpenAgents.Voice.ProviderEvent`,

`OpenAgents.Voice.OpenAI.EventDecoder`, `OpenAgents.Voice.ResponseReceipt`,