Proposal 069: Corpus — Topic-Routed Collaborative Reasoning¶

Based on:

doc/project/40-proposals/003-question-envelope-and-answer-channel.md
doc/project/40-proposals/011-federated-answer-procurement-lifecycle.md
doc/project/40-proposals/016-supervised-prepaid-gateway-and-escrow-mvp.md
doc/project/40-proposals/021-service-offers-orders-and-procurement-bridge.md
doc/project/40-proposals/047-classification-label-propagation.md
doc/project/40-proposals/055-bounded-deferred-operation-contract.md
doc/project/40-proposals/057-user-and-operator-notifications.md
doc/project/40-proposals/063-inquirium-model-inquiry-organ.md
doc/project/40-proposals/066-inquirium-assistant-channel.md
doc/project/40-proposals/067-shared-offer-catalog-over-agora.md
doc/project/40-proposals/070-room-primitive.md
doc/project/40-proposals/073-agent-orchestration-organ.md
doc/project/40-proposals/074-multi-node-federation-harness-and-trace-explorer.md
doc/project/40-proposals/082-sensorium-interfaces.md
doc/project/40-proposals/083-sensorium-interactive-interfaces.md
doc/project/40-proposals/085-operator-sovereign-extensibility-and-experiment-packages.md
doc/project/60-solutions/003-arca/003-arca.md
doc/project/60-solutions/004-dator/004-dator.md
doc/project/60-solutions/023-artifact-delivery/023-artifact-delivery.md
doc/project/30-stories/story-002-federated-peer-learning.md
doc/project/30-stories/story-006-voluntary-swarm-exchange.md

Extended by:

doc/project/40-proposals/090-inference-execution-provenance-and-non-local-disclosure.md

Promoted to:

doc/project/60-solutions/038-corpus/038-corpus.md

Status¶

promoted

Date¶

2026-06-23

Executive Summary¶

Corpus lets a node convene a bounded set of participants around a taxonomically named subject and coordinate their collaborative reasoning toward one signed outcome. Participants may be people, participant-controlled Agents, or node/service roles represented by Agents. Finding and hiring topic-expert providers is the first procurement path, not the definition of who may participate or which problems Corpus may address.

The flow has two phases of different nature and different readiness:

Procurement (the MVP). Keywords resolve to one canonical topic term (e.g. IT:programming:C++). The offer catalog is queried for nodes advertising a corpus.provider competence on that topic. A query carrying a price bracket is broadcast; each responder bids or stays silent; the asker selects a subset. This rides Artifact Delivery (Solution 023), reusing the proven Arca/Dator request→result pattern generalized to fan-out. Buildable on existing infrastructure; this is the MVP slice.
Live deliberation (post-MVP). The asker opens a room (Proposal 070), invites selected providers and any other explicitly admitted participants under an access list, and participants that use models do so through accountable Agents backed by Inquirium. Latency matters and chatter is expected, so the deliberation is a live chat. A requester-appointed chair manages bounded completion (full arbiter election is later). Completion produces one signed answer envelope, whose outcome may be a synthesis, preserved alternatives or disagreement, a recommendation, an assistance plan, a hypothesis set, or a creative work rather than one objectively best answer.

Corpus is a thin role plus a small protocol that composes existing strata and adds a topic-taxonomy resolver, a topic field on offers, and a deliberation policy. Its post-MVP live-deliberation layer composes the implemented node-local slices of the generic Room primitive (P070 / Solution 036) and the Agent organ (P073), which provides the bounded reasoning session. Federated Room transport now has one named owner and shape: P070 Phase 6A relocates the existing WSS runtime through signed relay endpoint epochs. Remote Room-authority trust remains a later Corpus admission profile. The hard-MVP procurement slice needs neither Room nor Agent.

The live in-room chat is reasoning, not protocol facts: the protocol does not persist it. Only explicitly admitted protocol facts, their bounded provenance, the room skeleton, and the signed outcome envelope are durable. Any member MAY locally capture and audit the chat under its own classification and retention policy.

Terminology Boundary¶

corpus-entry.v1 already exists as a curated/training corpus artifact (requirements 002–005). That "corpus" means a body of curated knowledge for training and retrieval. It is unrelated to the Corpus component defined here (live collaborative reasoning over a topic). To prevent drift:

the component keeps the human-facing name Corpus;
its wire contracts use the corpus-reasoning-* namespace, never bare corpus-*, so they never collide with corpus-entry.v1;
topic contracts use topic-*; room contracts live in P070 (room.v1, …).

Domain and Outcome Boundary¶

Corpus deliberation is domain-general. A technical diagnosis or repair session, optionally observing a terminal or another enacted environment through an explicitly admitted Sensorium Interface, is one profile rather than the defining Corpus workflow. The same protocol may coordinate scientific inquiry, social problem-solving and mutual aid, or creative work such as collaborative literature.

Corpus owns topic routing, participant admission, bounded deliberation policy, provenance, disagreement preservation, and formation of one signed outcome envelope. It does not install a universal domain ontology, evidence theory, role vocabulary, or definition of success. It supports two deliberately separate levels:

General prose deliberation. Participants may reason about any admitted topic and publish plain-text or markdown content, including ordinary code fragments, without a domain-claim profile or machine truth adjudication. The signed outcome may remain meaningful to people without becoming a machine-interpreted domain verdict.
Optional thematic or structured profiles. When a host is asked to interpret domain claims or outputs mechanically, apply domain-specific success or evidence criteria, adjudicate, publish through a typed domain contract, or authorize an effect, it must use an explicitly admitted profile. Operators and communities may propose and publish namespaced, versioned profiles, and a federation may endorse one. The receiving host alone accepts or refuses the exact revision under local policy; federation policy or endorsement may be evidence for that decision but cannot compel admission.

An opaque profile ref does not close the set of legitimate domains. A wire envelope may have a closed structural shape, but its vocabulary, evidence repertory, success criteria, and the set of legitimate problem classes remain open. Machine-interpreted profiles still require explicit admission, lifecycle, trust, and conformance rules. Each admitted profile owns its vocabulary, reference validators, evidence or critique rules, completion criteria, and any accountable adjudication, effect, or publication policy. Domain families and examples below are explicitly illustrative and non-exhaustive; they are never a protocol enum and do not claim implementation or runtime acceptance for profiles that lack their own evidence.

Illustrative use	Possible participants	Optional thematic criteria (when machine interpretation is required)	Possible signed outcome	Optional effect boundary
Technical or operational	operators, topic providers, implementer/reviewer Agents	host observations, diagnostics, plans, verification and rollback criteria	diagnosis, verified plan, repair recommendation, preserved alternatives	an admitted Sensorium view is observation only; for interactive Sensorium profiles, P083 and host review remain the effect path
Scientific inquiry	researchers, reviewers, affected domain experts, Agents	hypotheses, observations, uncertainty, provenance, reproducibility and falsification criteria	hypothesis set, synthesis, experiment proposal, preserved disagreement	experiment admission remains with the accountable host or research policy
Social problem-solving or mutual aid	affected people, helpers, witnesses, mediators, accountable Agents	testimony, consent, context, support options, risk and human adjudication rules	assistance plan, recommendation, coordinated next steps, unresolved perspectives	high-impact actions require the responsible human or institution; participation grants no ambient authority
Creative or literary collaboration	authors, editors, readers, creative Agents	constraints, style, critique, contribution provenance and publication policy	a work, variants, editorial synthesis, or intentionally open ending	publication, attribution and reuse follow creator-controlled policy

Any of these uses may remain in the general-prose mode. The thematic-criteria column becomes normative only through a separately admitted profile; the table itself does not define a required profile catalog.

The wire name corpus-reasoning-answer.v1 denotes the durable outcome envelope for compatibility. It does not imply a truth claim, forced consensus, or a single best answer. Procurement is likewise one way to discover and contract participants; people affected by a problem, witnesses, helpers, mediators, or co-creators need not first be modeled as purchasable topic-expert providers.

Story 012 is the first concrete technical thematic profile and a useful foundation for the structured level. Its typed evidence, review, and host-admission seams demonstrate one specialization above general prose deliberation; they do not define the grammar of other technical work or of Corpus as a whole.

Optional thematic-profile admission and lifecycle (2026-09-06)¶

corpus-thematic-profile.v1 is an optional, code-backed semantic-registry entry, not a universal deliberation grammar. Its identity is the exact tuple entry/ref, entry/revision, and digest. The reference has the form corpus-profile:<namespace>:<name>; the namespace is not an authority claim. The digest uses the existing semantic-entry RFC 8785 algorithm and covers the issuer, open facet map, implementation/schema refs, capability requirements, compatibility declarations, and supersession relation. No facet name is a closed enum of technical, scientific, social, or creative domains.

An issuer supplies authenticated distribution/package evidence through the existing P085 admission boundary. issuer/ref in the entry does not authenticate itself. Before interpretation, the receiving host must independently verify that evidence, trust its issuer, explicitly enable the exact digest, and have the named implementation and required capabilities admitted. A profile cannot install code, fetch a vocabulary, widen authority, or grant effect permission. Facet refs remain inert data until a separately admitted implementation gives them meaning. Effects still require the ordinary capability, classification, human-in-the-loop, and lease gates.

compatible/with and supersedes contain exact revision tuples, not version ranges. They are issuer declarations, not automatic migrations or permission to substitute another digest. A superseded revision can remain locally admitted; switching to a successor requires a fresh local decision. Endorsements by a community, federation, or another host can inform this decision but cannot add to the operator-enabled set. Two hosts can legitimately disagree about the same authenticated revision without changing each other's coordination roles.

The shared semantic registry supplies activation generations, exact bindings, and deactivation. Withdrawal or revocation carries authenticated issuer evidence or an accountable local operator decision, targets the exact revision/digest, and fences new interpretation before further work. Recovery must reload the retained withdrawal/revocation facts before restoring active bindings; missing signature evidence, unavailable implementation, stale generation, changed digest, or incomplete lifecycle history refuses machine interpretation. Retained outcomes remain historical facts and are not rewritten or reinterpreted under a successor. Revocation does not erase criticism, alternatives, or published artifacts.

The Node conformance implementation composes semantic-registry-core rather than adding a parallel activation mechanism. Tests cover independent host accept/refuse, issuer substitution, exact digest admission, stale-generation recovery, deactivation and attempted authority widening. The creative fixture is a profile-definition example, not an executed literary adjudicator. General prose and signed outcomes continue to require no thematic profile, and the V1 coordination-role algebra is unchanged. This defines the admission contract; automatic thematic-package installation and a running thematic interpreter are not claimed by P069-DOMAIN-005.

Context and Problem Statement¶

The machinery exists but is spread across components: marketplace procurement (P021/P011, Arca/Dator), Artifact Delivery (023), the answer-room/Whisper room lineage (P003/P013, consolidated by P070), and Inquirium (P063/P064/P066). What is missing is the glue: a deterministic way to name a subject from keywords, a way to discover topic-expert offers, and a live reasoning session whose raw chat stays ephemeral while explicitly admitted protocol facts and one signed outcome envelope remain durable. Semantic Index (Solution 022) is vector similarity over local memory, not a topic taxonomy.

Goals¶

Resolve a keyword set to one canonical topic term, or to an explicit ambiguous candidate set, deterministically and auditably.
Let providers advertise topic-scoped corpus.provider competence in the existing offer catalog, with defined indexing, validation, and withdrawal semantics.
Reuse Artifact Delivery for discovery, broadcast query, bidding, and selection (MVP), with an explicit, timestamped bid-state read-model.
Layer a live synchronous deliberation room (on P070) with access list, a requester-appointed chair, and bounded time/step/token budgets.
Keep the live chat ephemeral; persist only explicitly admitted protocol facts and a concrete, content-addressed, signed outcome envelope with bounded provenance.
Preserve domain-specific vocabulary, evidence, adjudication, and outcome semantics in admitted profiles rather than the Corpus core.
Bridge to P011 settlement (single contracting provider for MVP; N-way later).

Non-Goals¶

Not the curated/training corpus (corpus-entry.v1).
Not the Room primitive (P070) nor the Inquirium runtime (P063/P066).
Not a new settlement rail; it bridges to P011/P016.
Not a frozen scoring algorithm, seed taxonomy, or reputation backend.
Not a closed taxonomy of problem domains, meanings, evidence kinds, success criteria, or legitimate outcome forms.
The MVP excludes the live room, arbiter election, and N-way settlement.

Prerequisites and Dependencies¶

Prerequisite	Needed for	Status
AD deferred + fan-out + single-owner acceptors (023)	MVP procurement	partial, usable
Offer catalog + Dator offers (003/004/067)	MVP discovery	partial, usable
P011 procurement artifacts + P016 escrow	MVP settlement (single provider)	partial
Room primitive (P070 / Solution 036)	live deliberation (post-MVP)	ready for the node-local slice: durable contracts, projection core, signed membership attestation, bounded WSS plus optional Matrix bridge, Corpus policy/invite admission, live WSS join/readiness/message flow, metadata-only authority observations, and restart-safe endpoint/session/sequence recovery are implemented; relocatable member-visible relay epochs are tracked by P070 Phase 6A and the non-member federation relay by Phase 6B
Agent organ (P073) — bounded reasoning session	live multi-turn reasoning (post-MVP)	runtime and Corpus join ready: the durable node-local lifecycle, bounded active controller, Room-attested Corpus-chair and participant bindings, memory projection, Inquirium/child execution, effect proposals/dispatch including `corpus.room.turn`, Agent-owned lease lifecycle, content-addressed outcome projection, and Corpus-owned inert answer-draft acceptance exist
Sensorium Interfaces (P082 / Solution 046) + Sensorium Workbench (Solution 042)	optional shared terminal or enacted-environment views during live deliberation	implemented: the WSS Room adapter exposes only a bounded `latest-state` projection, intersects Room observe rights with current interface grants, omits source cursors, and never grants terminal control

The MVP depends only on the first three rows. The generic Room live-plane runtime, the Agent runtime, and their Corpus-chair join are no longer blockers. The node-local live Room carrier hookup and the separately authorized conversion of inert chair drafts into signed Corpus answers are now implemented. Remaining work concerns federated transport profiles, remote Room-authority trust, arbiter election, and N-way settlement. Sensorium Interfaces is not a prerequisite for an ordinary live deliberation. It becomes a prerequisite only for a Corpus profile that explicitly shares a Workbench or Sensorium-backed view with room participants.

Room is a generic swarm primitive, not a Corpus-owned subsystem. Corpus depends on Room; Room must not depend on Corpus or import Corpus reasoning semantics. Corpus-on-Room is therefore a domain protocol layered over a neutral room: Corpus may decorate room policy, invite, role, and answer facts, but membership, presence, live transport, lifecycle, attestations, and room projections remain owned by the Room layer.

Corpus also does not select or operate the production relay. It consumes the active authority-signed P070 relay epoch. Requester placement is the default because the requester commonly chairs the deliberation, but relay failover, keepalive, cursor recovery, and optional non-member encryption remain Room responsibilities.

Bounded reasoning session (Agent organ, P073)¶

Full Corpus needs a multi-turn reasoning session bound to a room, with bounded steps/deadline/tokens, context ingestion, and explicit draft boundaries. That is exactly the Agent organ (P073): a host-owned, bounded, stateful controller with a budget (steps / deadline / tokens), Memarium-backed session context, and no self-authorization. Corpus should consume the Agent organ as its deliberation session — its deliberation budget maps directly onto the Agent budget/controller contract — rather than define a smaller Corpus-only LLM surface or a parallel "Inquirium thread/session runtime". The current Agent slice already supplies durable Memarium-backed state, fork/suspend/resume, bounded controller execution, effect-proposal routing, and consumer-owned outcome drafts. It now supplies the Corpus deliberation execution substrate as well: a signed, fresh Room membership attestation admits one query- and room-bound chair, and Corpus can accept its content-addressed outcome as an inert answer draft. A separate local-control Corpus transition may then validate the current ready quorum, exact room high-water, accountable chair participant, content-addressed Agent output, and idempotency before signing and publishing the signed outcome envelope. The first publication profile accepts text output blocks only and signs the artifact under the dedicated corpus-reasoning-answer-signature.v1 domain, not under the answer schema name. The Agent itself still cannot authorize signing, publication, settlement, or room-policy effects.

Proposed Model / Decision¶

1. Component Boundary¶

Corpus is a role plus protocol, not a parallel marketplace authority. The demand-side (asker) path extends the Arca demand surface; the supply-side (provider) path extends the Dator supply surface; both consume host capabilities for every signed act. Corpus contributes only the topic resolver, the offer topic field, the deliberation policy, the chair/arbiter logic, and the answer contract.

2. Topic Resolution: Signed Versioned Data + Deterministic Matcher¶

topic-taxonomy.v1 is an open, signed, versioned governance artifact, not an enum. It carries taxonomy/id, federation/id, version + versioning/scheme, digest, issuer/nym, issuer/public-key-ref, valid/from, valid/until, supersedes + supersession/proof, an extension/policy sub-schema, and a signature. Terms and per-term labels are unique (validated). Federations may extend subtrees; nodes pin taxonomy/digest.
Resolution is a pure deterministic weighted matcher returning a canonical topic/term or an explicit ambiguous candidate set. topic-resolution.v1 records the epsilon, matched/labels[], resolver/version, and is itself signed, so a result is reproducible and auditable.

3. Topic-Scoped Offers, Indexing, Validation, Withdrawal¶

service-offer.v1 (service/type = "corpus.provider") gains a corpus extension. It remains a full service-offer.v1 (all base required fields apply); the extension adds, not replaces. Decisions:

One offer, multiple topic scopes. One offer carries a corpus/topics set, plus corpus/model-class (enum: local-llm | remote-llm | human-curated | hybrid-llm-curated), corpus/taxonomy-digest, and corpus/taxonomy-issuer (so a consumer can fetch the issuer key and verify the taxonomy signature — the digest alone does not enable verification).
corpus/topics ⊆ terms(taxonomy/digest). Arbitrary strings must not enter the topic index. JSON Schema cannot express set-membership against an external artifact, so the offer/catalog admission layer enforces it after resolving the pinned taxonomy: given corpus/taxonomy-digest, every corpus/topics[*] must be a term of that taxonomy. Missing or untrusted taxonomy material fails closed.
Indexing. The shared catalog (P067) builds a topic index keyed by canonical topic/term (and parent terms for fallback): { offer/id, sequence/no, taxonomy/digest, provider/node-id }.
Withdrawal (incl. partial). Reuse the offer sequence/no + withdrawal marker (P067). There is no per-topic withdrawal: removing a single topic is a supersession — publish a new offer revision with a higher sequence/no and the reduced corpus/topics; the index replaces the prior revision. A full withdrawal marker removes all of the offer's topic-index entries. record/supersedes is not the offer-catalog revision authority for this flow; it remains available on Agora envelopes, while the catalog read-model reconciles offers by offer/id, monotonic sequence/no, status, and expiry.

corpus/model-class remains a compatibility and discovery projection. It combines locality-like labels with production mode and therefore MUST NOT be treated as the source of truth for either an offer's inference posture or a delivered result's execution provenance.

3A. Inference Posture and Delivered-Result Provenance¶

When Proposal 090 is accepted and implemented, a Corpus-capable offer may carry the separate inference-execution-posture.v1 contract defined canonically by Proposal 090 and introduced into service offers by Proposal 021. It binds the assertion owner, exact offer subject/generation/scope, and versioned processing-boundary ref. Corpus may route or filter on its shared locality ceiling and optional open provider refs only after explicit boundary comparison, but the declaration describes only what the provider may use. It is not evidence of any later execution. An unrelated sender boundary is a non-match or unknown, never an implicit match for the buyer's local-only requirement.

Every inference-derived bid product, participant contribution, answer draft, and answer must then preserve or reference the realized inference-execution-provenance.v1 produced by the executing boundary. Corpus validates the realized descriptor independently against the selected offer and local buyer or Room policy. A mismatch is a typed refuse, quarantine, or warn decision; it never rewrites non-local, mixed, or unknown to match the offer.

Provider refs and evidence profiles remain open, namespaced, and locally admitted. Neither Corpus nor the Shared Offer Catalog defines a closed global provider list, problem-class repertoire, deliberation profile catalog, or universal success and evidence policy.

4. Procurement over Artifact Delivery (the MVP)¶

The asker broadcasts corpus-reasoning-query.v1 to candidate nodes through one AD delivery plan (?mode=deferred, a single parallel stage). The query is a Corpus decorator over question-envelope.v1 (P003), not a sibling question primitive. It adds the topic, corpus/taxonomy-digest, original query/keywords (for audit reproducibility), requester ids, price bracket, max/candidates (fan-out cap), and deadline-at.
Each provider's single corpus-reasoning-query.v1 acceptor replies with a signed corpus-reasoning-bid.v1 (§4.1) to reply/target, correlated by correlation/id + query/id. The bid signature must be checked before a bid can affect selection; the daemon MVP verifies its local-runtime-assertion against key/public and binds that key to bidder/node-id.
The asker maintains a timestamped corpus-reasoning-bid-state.v1 read-model so silence is not conflated with refusal (§4.2), then selects a subset.

Identifier relationships. Three ids live in one flow and MUST be mapped explicitly: query/id is minted by the asker and is the spine of the bid round; correlation/id ties one query↔bid pair across AD; when a bid embeds a procurement-offer.v1, that offer's question/id is set equal to the Corpus query/id so the later procurement-contract.v1 chains back to the original query.

4.1 Bid is an envelope around `procurement-offer.v1`¶

corpus-reasoning-bid.v1 is not a parallel pricing type. It is a thin envelope: decision (enum accept | decline | counter) + bid/valid-until (TTL) + policy/digest + an embedded procurement-offer.v1. The embedded offer carries the procurement-required fields (responder/participant-id, price/*, answer/min-length, answer/max-length, execution/mode, specialization/tags, reputation/evidence) so the later contract has everything it needs. decline carries no offer; counter carries an offer with a price outside the original bracket.

4.2 Bid-state read-model (no silence/refusal conflation)¶

Per candidate, corpus-reasoning-bid-state.v1 carries state (bid-received | declined | timed-out | delivery-failed | policy-denied | unreachable), received-at, updated-at, a reason/diagnostic-code, and delivery/attempt-id correlating to the AD delivery. Each candidate's delivery is itself a deferred-operation-status.v1; the bid-state is the multi-candidate aggregation over those, not a replacement for them. Default selection treats only bid-received as eligible.

5. Live Deliberation (post-MVP, on the Room primitive)¶

The deliberation runs entirely on Room (P070): the asker opens a room.v1, attaches a corpus-reasoning-room-policy.v1, and invites selected nodes under the room access list (corpus-reasoning-room-invite.v1). Participants join the room's ephemeral live plane and reason synchronously through the Agent organ (P073) bounded reasoning session. The chat is ephemeral reasoning, never a protocol fact (P070 §1).

This is a use of the generic Room primitive, not a special Corpus room family. Room provides the neutral substrate for many workflows; Corpus supplies only the topic-routed deliberation protocol layered on top of that substrate. A profile may recruit topic experts, but expertise procurement is not a Room-membership requirement.

corpus-reasoning-room-policy.v1: exposure (enum bound to P009 exposure modes, not a new namespace), answer/acceptance (enum chair-signed | n-of-m | unanimous), chair/mode (requester-appointed for MVP-of-this-layer, elected later), chair/nym + chair/credentials (a capability-passport ref proving the chair is authorized — not a bare nym), quorum/required, tie-break, revocation-policy, and budgets budget/time-ms + budget/steps + budget/tokens (tokens matter because the LLM cost is per-token, not only per-step).

The future elected-chair extension adds first-judgment/visibility = isolated-until-barrier, first-judgment/barrier = all-eligible | quorum-or-deadline, first-judgment/commitment = salted-sha256-jcs-v1, and disagreement/handling = preserve. These fields are not retrofitted into the implemented requester-appointed profile until the elected-arbiter tracker item is implemented and schema-gated.

Chair before election. For the first live layer the requester appoints a chair (or acts as chair); a fallback/revocation policy is required even for that case. Full arbiter election (eligibility, COI, quorum, deadline, tie-break, revocation, fallback) is a later layer.

First-judgment visibility is a protocol contract. Fan-out topology and parallel execution do not by themselves guarantee independent first judgments once a chair or arbiter can observe submissions. A deliberation profile that claims this independence MUST declare first-judgment/visibility = isolated-until-barrier; the future chair/mode = elected profile requires it. Each eligible participant's initial judgment uses a dedicated commit/reveal value, not a reusable content digest. Its commitment/digest is SHA-256 over the canonical JCS object containing the domain orbiplex.corpus.first-judgment-commitment.v1, exact Room, round, participant, judgment body, and a fresh per-judgment 32-byte cryptographically random salt. Before the barrier, other participants and the chair/arbiter receive the digest and bounded commitment metadata, but neither the judgment body nor the salt. Barrier release reveals both; the host verifies the commitment before counting the judgment, and a missing or invalid reveal never counts as an independent first judgment. Distinct salts prevent equal low-entropy judgments from exposing agreement through equal commitments.

Barrier release is an auditable transition that closes the first-judgment phase. A late first-judgment submission is refused as first-judgment-closed; the participant may contribute only through an explicit post-barrier or rebuttal lane whose provenance records independent-first-judgment = false, and that contribution does not enter the initial quorum or independent-judgment set. Raw judgments remain subject to their own classification and retention policy rather than becoming durable Room chat facts.

Disagreement is data, not failure. Conflicting admitted judgments constitute a successful deliberation state. Synthesis may resolve, supersede, or preserve each bounded disagreement, but it must not erase it by forcing consensus. Draft/final provenance for profiles that preserve disagreement carries issue id, position refs, unresolved assumptions, and conditions that would change the decision; it does not copy raw private judgments into generic Room facts.

Agent as chair delegate. The requester MAY appoint its own host-owned Agent (P073) as the chair delegate for the room, but this does not make the Agent a new authority root. The room policy still names the accountable chair subject (chair/nym + chair/credentials) and may additionally reference chair/agent-ref; the host remains responsible for the Agent's budget, lifecycle, grants, and stop/resume controls. An Agent-chair may coordinate the discussion, propose turns, detect conflicts, request summaries, and propose the outcome draft, but it cannot self-authorize publication, settlement, membership changes, or effects outside the grants accepted by the host and the room policy.

Agent-chair conversation governance. When P070 Phase 7 is available, the requester MAY ask the Agent-chair to organize the conversation, but requester intent is not Room authority. Corpus resolves one effective chair-control policy by monotone intersection:

protocol bounds
AND distributor configuration
AND local operator configuration
AND requester intent
AND admitted Agent profile and grants
AND current scoped Room delegation

Every layer may narrow the result; none may widen a preceding layer. The requester must explicitly select an Agent chair and request any non-default control. The local operator may disable Agent chairing entirely, restrict the available floor modes, require human review per operation, cap temporary bans, or deny selected controls. Absence, ambiguity, stale policy evidence, or an unavailable Room primitive fails closed to no Agent-held moderation authority; it does not silently fall back to an unbounded chair.

The content-addressed corpus-reasoning-chair-control-policy.v1 carries the requested and effective values separately. It binds the exact query, Corpus round, Room, accountable chair subject, optional Chair Agent, policy generation, issue/expiry, and:

Corpus policy field	Room Phase 7 projection	Safe baseline
`floor/mode = organic`	`open`	default
`floor/mode = moderated`	`moderated`	explicit opt-in
`floor/mode = baton`	`round-robin`	explicit opt-in
`controls/floor`	floor assign, advance, release	allowed only for an admitted Agent chair
`controls/voice`	scoped `grant/speak` grant-set replacement	operator-configurable; no root target
`controls/kick`	scoped `membership/remove`	human review by default
`controls/ban`	scoped `membership/deny`	human review and bounded TTL by default

organic and baton are Corpus/operator vocabulary; their Room projections are the canonical modes. voice is likewise a human-facing alias for speak, not a second grant. Permanent Agent-issued bans are denied by default. The root Room authority cannot be muted, removed, banned, or demoted through this policy.

The v1 policy deliberately has no separate review/floor axis. Enabling controls/floor is the operator-bounded review decision; assign, advance, and release then schedule subjects that already hold speak and do not alter membership or grant authority. Voice, kick, and ban remain separate review-bearing effects. A future policy that makes floor scheduling itself high-impact requires an additive contract revision rather than an adapter-local review rule.

CORPUS_CHAIR_FLOOR_MODE_MAP in corpus-core is the single closed mapping from organic | moderated | baton to P070 open | moderated | round-robin. Configuration may select or narrow its keys but cannot redefine their Room meanings. Adding another mode requires a contract revision, one mapping-table change, fixtures, and the corresponding P070 support; adapters do not maintain private translations.

Operator-resolved turn order. The baton -> round-robin mapping defines the distribution default for floor movement, not an immutable Corpus speaking order. A local operator MAY activate a P085 select-turn-order producer that ranks only the participants currently eligible for the next turn. Corpus owns eligibility and the meaning of the candidate projection; NSE owns producer composition and the one offer-bound validator; Room remains the sole owner of floor admission.

Corpus builds one immutable corpus-turn-order-offer.v1 after checking current Room membership, denial and sanctions, the speak grant, accepted role assignments, instruction-overlay state, Chair policy, round and turn, previous floor holder, and Room-policy generation. Each candidate binds the exact participant subject plus the current role-assignment ref, revision, and digest. The offer contains no selected target. It is resolved before a floor target is bound, before any target-specific HIL, and before a Room mutation is attempted.

The admitted order result is a permutation or stable ranked subset of that exact candidate set. Corpus takes its first member as the proposed floor target, binds that choice into the inert floor intent, then performs the ordinary current-policy, HIL, delegation, and Room admission checks. A producer cannot add a participant, repair missing eligibility, change a role, or turn connected presence into membership. If no operator producer applies, Corpus uses the explicit distribution policy for the current floor mode: round-robin for baton, while organic and moderated retain their canonical P070 semantics. Ambiguity, an empty admitted order, stale role or membership evidence, producer revocation, or a changed policy generation refuses instead of falling back to a previously active order.

A JSON-e Flow may consume the same host-issued opaque offer/ref through its P049 decision step. The admitted projection carries a host-owned decision/ref; Flow may branch on the result but cannot construct candidates, rewrite the order, or submit a participant ref as authority. Corpus applies only the stored admitted decision behind that ref. Direct Corpus resolution and Flow-mediated consumption are two entry paths to one resolution, not two independent evaluations for the same turn.

For Story 012, solver is a scenario label for the participant bound to the admitted implementer role policy, reviewer names the admitted reviewer role, and chair names the accountable Chair slot rather than a newly registered Corpus role. The operator policy may therefore express solver -> reviewer -> chair without widening the closed role registry or teaching Room those labels.

Facilitator role. A future additive role revision MAY register facilitator as a bounded reasoning role. Its purpose is to improve the deliberation process rather than supply a privileged answer: it asks discriminating questions, makes hidden assumptions and unresolved disagreements explicit, requests concrete evidence, and suggests the next bounded experiment when discussion stalls. A facilitator MAY cite retained Room turns and terminal evidence and MAY emit inert experiment suggestions, but it cannot create or admit a CandidatePlan, approve an experiment, answer an HIL question, select a terminal product, publish a Corpus answer, mutate Room authority, or invoke Sensorium. Those transitions remain with their existing host, Chair, executor, and operator boundaries.

The corresponding local instruction overlay uses the closed semantic kind facilitation-guidance. Its rendered instruction must remain question-oriented and bounded: no shell command or effect payload is executable merely because it came from the facilitator. A distributor or operator may omit the role entirely, and the requester may only narrow its use. Adding it requires v2 revisions of every role-bearing accepted contract and table vocabulary; v1 continues to mean exactly the four-role set and MUST reject facilitator fail-closed.

Ban TTL is resolved in the same admission pass as every other chair control. The effective ban/max-ttl-seconds is the monotone minimum of protocol, distributor, operator, requester, Agent-profile, and current Room-delegation ceilings. Requested and effective values are persisted together. No later endpoint, HIL path, or effect adapter may apply an independent, more permissive TTL calculation.

Distributor or operator ceiling changes take effect fail-closed. Before opening a Room or admitting a moderation effect, the host recomputes the monotone intersection. If it differs from the persisted effective value, the old policy generation becomes unusable and the requester must admit a new content-addressed generation; the host does not silently mutate the durable policy or honor it until its original TTL expires.

The policy grants only permission to propose typed controls. The Agent emits inert floor, speak, removal, or denial intents; the host verifies the recovered binding, current Room delegation and projection, per-control review rule, policy generation, target, TTL, and idempotency before calling the canonical Room admission path. Room commits the authority fact before applying transport effects. Agent output never directly mutates Room state.

Stopping, quarantining, or replacing the Chair Agent revokes its live floor lease and its effective use of delegated controls. Corpus then applies the configured fallback: return control to the accountable human/requester, appoint another already-admitted chair, or suspend deliberation. It never promotes another participant or Agent merely because that subject remains connected.

Room participants are subjects or Agents, not raw model adapters. A Corpus deliberation room may contain human participants, participant-controlled Agents, or node/service roles represented by Agents. A raw Inquirium adapter or model runtime MUST NOT appear as a room member. Inquirium is invoked by an Agent or by another host-owned flow as bounded inference; it does not own room identity, memory, lifecycle, budget, stop/resume semantics, or accountability. A single-turn model response MAY be represented as a degenerate Agent profile with one step, no fork, no durable autonomous memory, and an explicit budget.

Participant roles and instruction overlays. The chair MAY propose the closed task-role set implementer, reviewer, adversarial-critic, and summarizer through explicit Corpus policy facts. These roles are not ambient authority and do not override local node policy. They become effective only after acceptance by the participant or a registered node-local role policy. This closed v1 set is coordination vocabulary, not a universal Corpus ontology of domains, meanings, evidence, or success. The completed P085-029 V1 role algebra remains the current baseline and configuration may narrow but not extend it. The same roles may organize general prose deliberation or an explicitly admitted thematic profile without defining the subject matter or its result criteria. Ordinary participants may deliberate in text without a specialized machine-interpreted claim vocabulary. The chair MAY also propose a per-turn instruction overlay with one closed semantic kind: task-guidance, review-criteria, adversarial-check, or summary-criteria. The proposal text remains inert data. A registered local prompt policy must accept it and produce the bounded instruction/rendered value that Inquirium may consume. Recovery and prompt assembly MUST reproduce and verify that policy rendering rather than trusting persisted or remote text. class/key is a closed Public/Community/Personal minimum-tier selector for the local prompt layer, not a Room membership grant or a classification override. This prevents coordinator-controlled prompt injection while still allowing the room to organize expert perspectives.

Shared enacted views through Sensorium Interfaces. A Corpus deliberation MAY make a terminal viewport or another Sensorium/Workbench-backed representation visible to authorized room participants through a Sensorium Interface (P082). The source chain remains stratified:

Workbench or Sensorium provider
  -> bounded admitted projection
  -> Sensorium Interface resource
  -> participant-scoped interface grants
  -> WSS-backed Room latest-state carrier
  -> authorized room participants
  -> daemon Room/Sensorium resolver
  -> opaque bounded Agent observation need

The view is not embedded into Corpus chat and Room does not own the PTY, source cursor, interface lease, or source credentials. Room membership alone is never interface authority: every participant who may observe the view must receive a current resource-scoped interface grant. The first Room carrier exposes only the bounded visible latest-state viewport and refuses ordered terminal-event replay. A full transcript requires the existing explicit classified Workbench capture path. Terminal input, command execution, resize, signals, file mutation, and other actuation remain separate Workbench/Sensorium directive operations with their own grants and review policy; publication of a read interface never grants control.

The exact interface publication also owns its P082 sensorium-operational-context.v1 value and source/generation-ref. Corpus and the chair may not lower or replace either. Room carries the complete P082 result without interpretation, and every participant node validates the context before admitting the shared view into an Agent passage. Validation uses P082's single freshness predicate: the source generation must still be current and the interface/id must still be the effective publication for its source/projection slot. Corpus defines no additional TTL. Its host then renders a local, versioned caution layer through P064 before that Agent deliberates over the feed. This gives all collaborators the same source-declared operational posture pre-emptively while allowing a local host to be more conservative.

An environment context change or correction is source-owned and produces a new immutable P082 publication. The superseded publication is no longer admissible to a Corpus passage, irrespective of whether the class was raised or corrected downward. Relay sequence resolves temporary availability, not immutable identity: a newer latest-state result may resume a suspended publication, while any withdrawn or expired status is terminal for that interface/id. A contradictory later snapshot for the same terminal publication fails closed and cannot reactivate it.

The optional publisher summary remains observation data rather than an instruction, so this path cannot smuggle a remote system prompt through a Room. If several enacted views are admitted later, each source retains its own evidence ref and the host uses the highest impact class for caution framing. The class changes reasoning posture; it does not change Room membership, interface grants, Agent grants, chair authority, or effect admission.

6. Outcome / Answer Contract (concrete, content-addressed, signed)¶

Bounded completion yields one corpus-reasoning-answer.v1 outcome envelope. One durable envelope does not require one objectively best conclusion: ordinary prose or thematic-profile-owned content may preserve alternatives or disagreement, carry a recommendation or assistance plan, record a hypothesis set, or contain a creative artifact. The envelope carries answer/id, query/id, room/id, topic/term, corpus/taxonomy-digest, content/ref or inline content plus content/digest (so a verifier can confirm the inline content matches what was signed), answer/format (plain-text | markdown | json | edn), classification (the small classification.v1 lattice tier Public | Community | Personal, expanded to a full classification.v1 object at the AD answer-envelope boundary; see Resolved Decision 21), policy/digest (required), provenance/refs, contribution/refs, contributor/weights[] (present even though N-way settlement is post-MVP, so a later settlement can use the same answer), attestation/evidence (e.g. the deliberation room-event.v1 high-water mark, proving the answer came from the room and not a single responder), and signatures[] per answer/acceptance.

The first implemented single-provider slice uses a narrower but stricter contract: corpus-reasoning-answer.v1 is accepted only after schema validation, content digest verification, signature verification, and round binding. The signer key must derive the same node:did:key as responder/node-id; responder/node-id must match the provider of the selected bid; selected/bid-id, when present, must match the round's selected bid; and policy/digest must equal the round's corpus/taxonomy-digest. This makes the answer a provider-originated fact attached to a selected round, not a requester-local JSON note.

The Proposal 090 extension is additive and not part of the current answer contract. Once its canonical schema exists, a compatible answer-contract revision or admitted sidecar ref carries either the bounded realized descriptor or its immutable content-addressed ref, and any synthesis joins the provenance of all inference-derived parents conservatively. Classification, human/model origin, contributor attribution, and inference execution provenance remain separate dimensions; corpus-reasoning-answer.v1 is not extended in place implicitly.

7. Settlement Bridge (single contracting provider for MVP)¶

For the MVP and first live layer there is one contracting party — a single contracting provider, or the chair as counterparty — so settlement is the ordinary P011 path (procurement-offer → procurement-contract → procurement-receipt) with escrow host-owned (P016). N-way split is post-MVP, deferred to a dedicated contribution-allocation.v1 (a candidate future proposal; the name prefix is reserved here to avoid collisions), informed by the Creator-Credits attribution graph and by contributor/weights[] already carried on the answer.

Schema Conventions, Identifiers, and Invariants¶

All Corpus contracts MUST follow the repo's existing signed-artifact conventions (as in service-offer.v1, procurement-offer.v1), not ad-hoc styles:

Schema version: top-level schema/v is the numeric schema version (1 for v1 contracts), matching service-offer.v1 and procurement-offer.v1. The contract name comes from the enclosing schema id or transport context; do not encode name.vN into schema/v. Embedded contracts that already use schema (for example classification.v1) keep their own discriminator.
Namespacing: slash-namespaced, hyphenated segments — query/id, room/id, bidder/node-id, topic/term, correlation/id, idempotency/key, etc.
Identifier patterns (explicit, required):
query/id ^query:[A-Za-z0-9][A-Za-z0-9:-]*$; bid/id ^bid:…$; answer/id ^answer:…$; room/id ^room:…$; correlation/id ^corr:…$;
participants/nodes/nyms reuse the existing DID forms: ^participant:did:key:z[1-9A-HJ-NP-Za-km-z]+$, ^node:did:key:z…$, ^nym:did:key:z…$.
Timestamps: created-at, published-at, expires-at, deadline-at, received-at, updated-at, valid-until (RFC3339).
Price: pricing/* for standing-offer/request intent (pricing/amount, pricing/max-amount [+ Corpus-only optional pricing/min-amount], pricing/currency, pricing/unit, pricing/unit-kind ∈ per-item | per-character-block | per-request | per-task | flat); price/* (price/amount + price/currency) only for a concrete bid/procurement price. Amounts are integers in minor units. MVP examples use ORC (service-credit is a future federated symbol, not used in MVP wire examples). Fractional per-token/per-step rates would need a separate pricing-calculator contract that resolves to an integer pricing/amount before it enters an offer/bid.
Signatures (one canonical form): signature: { alg: "ed25519", value: "…" } for a single signer; signatures: [ { by: "<did>", alg: "ed25519", value: "…" } ] for multi-signer (the answer). Do not mix in auth/nym-signature for these contracts.
Canonicalization: every signature and idempotency key is computed over orbiplex-canonical-json-jcs-v1, the language-neutral Corpus profile implemented by node/canonical-json as CanonicalJsonProfile::JcsV1. It sorts object keys recursively using JSON Canonicalization Scheme ordering, preserves array order, preserves string code points without NFC folding, emits the shortest stable JSON form without insignificant whitespace, and does not strip or transform fields unless the calling artifact contract explicitly defines a pre-canonicalization pruning step. Implementations MUST NOT perform Unicode normalization before canonicalization; UTF-8 bytes are derived from the original JSON string code points. This makes replay protection real and cross-implementation stable.
Idempotency-key derivation: default idempotency/key = "sha256:" + base64url(sha256(canonical_json_string(<domain tuple>))), e.g. for a bid the tuple is (query/id, bidder/node-id, decision, bid/valid-until).
Validation invariants (JSON Schema where expressible; offer/catalog admission constrainers where the check depends on external artifacts):
pricing/min-amount <= pricing/max-amount (default pricing/min-amount = 0 when omitted);
deadline-at > created-at; valid-until > created-at;
corpus/topics ⊆ terms(corpus/taxonomy-digest);
taxonomy term unique; per-term labels uniqueItems;
content/digest matches the inline content when inline.
Classification: the answer carries the small classification.v1 lattice tier (Public | Community | Personal); the AD answer envelope maps it to a full classification.v1 object (Proposal 047 / classification.v1.schema.json) with tier-correct bound_subjects at the envelope boundary. See Resolved Decision 21.
Privacy/retention: room durability and retention for room.v1 / room-membership.v1 / room-event.v1 are governed by P070 policy; Corpus does not define its own retention and explicitly defers to P070's per-exposure retention rules.

Data Contracts¶

Schema	Status	Phase	Purpose
`corpus-thematic-profile.v1`	accepted contract and pure conformance (`P069-DOMAIN-005`)	optional post-MVP	Exact issuer/revision/digest, open thematic facets, compatibility, non-compelling admission and shared-registry lifecycle. No automatic installation or interpretation.
`topic-taxonomy.v1`	new	MVP	Signed, versioned, federated taxonomy governance artifact.
`topic-resolution.v1`	new	MVP	Signed resolver output: canonical term or ranked `ambiguous` (with `epsilon`, `matched/labels`).
`service-offer.v1` (`corpus` extension)	extend	MVP	`corpus/topics`, `corpus/model-class`, `corpus/taxonomy-digest`, `corpus/taxonomy-issuer`.
`corpus-reasoning-query.v1`	new	MVP	Corpus decorator over `question-envelope.v1`: topic, keywords, requester ids, price bracket, `max/candidates`, deadline.
`corpus-reasoning-bid.v1`	new	MVP	Envelope: `decision` + `bid/valid-until` + `policy/digest` + embedded `procurement-offer.v1`.
`corpus-reasoning-bid-state.v1`	new	MVP	Asker read-model: per-candidate state + timestamps + reason + AD `delivery/attempt-id`.
`corpus-reasoning-room-policy.v1`	new	post-MVP	Exposure, acceptance, chair + credentials, quorum, budgets (incl. tokens).
`corpus-reasoning-chair-control-policy.v1`	implemented	post-MVP, P070 Phase 7	Content-addressed requester intent plus distributor/operator-resolved effective Agent-chair floor, voice, kick, ban, review, expiry, and fallback policy. `corpus-reasoning-room-policy.v2` binds its exact ref and digest.
`corpus-reasoning-room-invite.v1`	implemented	post-MVP	Room subject + live-transport binding + exact v1 or v2 policy digest. The stable invite envelope accepts both policy revisions and validates the embedded revision at the Corpus boundary.
`corpus-reasoning-role-assignment.v1`	new	post-MVP	Chair-issued participant role assignment with local-acceptance semantics.
`corpus-reasoning-instruction-overlay.v1`	new	post-MVP	Suggested per-role/per-turn instruction overlay consumed only through local prompt policy.
`corpus-turn-order-offer.v1`	implemented (`P069-TURN-001`)	post-MVP	Host-built immutable candidate projection for one exact Room turn, including current eligibility, role-assignment provenance, round/turn context, previous floor holder, and Room-policy generation; it contains no preselected target or authority grant.
`corpus-reasoning-experiment-proposal.v1`	implemented	post-MVP	Signed portable envelope binding one content-addressed inert `inquirium.candidate-plan.v1` to the exact query, Room, retained turn, author node, requester-selected executor, classification, expiry, and HIL requirement. A portable candidate must omit `adapter.manifest/ref`; that field remains optional producer provenance only for the separate adapter-authored compilation path. The envelope carries no adapter, Sensorium grant, generation, or lease authority.
`corpus-deliberation-review-claims.v1`	accepted contract; first profile implemented (`P069-CLAIM-001`, `P074-033`)	optional post-MVP profile seam	Domain-neutral envelope for structured review claims. Its refs are opaque to Corpus; a profile ref is not admission. Explicitly admitted profiles own vocabulary, evidence adjudication, dispositions, and legal next moves. It is not required for every deliberation or outcome. Generic profile admission remains `P069-DOMAIN-005`.
`corpus-reasoning-experiment-review.v3`	implemented by the first Story 012 profile (`P074-033`)	Story 012 technical profile	Technical experiment-review revision that embeds the optional claim envelope. Its CandidatePlan and terminal bindings are Story/profile semantics, not requirements for scientific, social, mutual-aid, or creative deliberation.
`corpus-reasoning-arbiter-nomination.v1`	new	later (Tracker P8)	Arbiter nomination (durable room record).
`corpus-reasoning-arbiter-vote.v1`	new	later (Tracker P8)	Arbiter vote (durable room record).
`corpus-reasoning-answer.v1`	new	post-MVP, first slice implemented	Content-addressed signed answer incl. `policy/digest` (required), `contributor/weights[]`.
`inference-execution-posture.v1`	implemented contract in P090	cross-cutting, scoped consumers	Separate signed offer/binding declaration with assertion owner, exact subject/scope/generation, and processing-boundary ref; Corpus consumes it for explicit boundary-aware routing but does not own the schema.
`inference-execution-provenance.v1`	implemented contract in P090	cross-cutting, scoped consumers	Provider-neutral realized execution provenance preserved by bids/products, contributions, drafts, and answers; Corpus consumes but does not own the schema. Broader consumer completion remains tracked separately.
`contribution-allocation.v1`	future (reserved)	post-MVP	N-way settlement split (separate proposal).

Reused: room.v1 / room-membership.v1 / room-event.v1 (P070), artifact-delivery-envelope.v1, deferred-operation-status.v1, procurement-offer.v1, procurement-contract.v1, procurement-receipt.v1, classification.v1.

Relationship to Existing Mechanisms¶

Swarm Broadcast Assistance (077, advisory companion): an assistance request may hire a Corpus deliberation as one of its resolution steps, and a Whisper-born association room may use Corpus repeatedly (sponsored or gift-priced) — see doc/project/20-memos/whisper-corpus-composition.md for the composition decisions (side-room first, in-room later; the community-work marker stays coarse and never identifies the room).
Artifact Delivery (023): carries MVP procurement (query/bid), the room invite, and the signed outcome envelope. Corpus is a second marketplace-style AD consumer after Arca/Dator. It does not carry the live chat.
Room (P070): live deliberation substrate and durable skeleton. Hard prerequisite for phase 2. Corpus imposes specific transport requirements on P070: low latency, no retention, and a small participant count. These belong in P070's live-transport profile as input requirements.
Sensorium Interfaces (P082) + Sensorium Workbench (P071 / Solution 042): optionally expose a bounded read-only terminal viewport or another enacted representation to authorized deliberation participants. P082 owns publication, grants, subscriptions, cursors, classification, revocation, and the WSS-backed Room latest-state carrier. Corpus owns only the decision to request that view for a deliberation. Room membership is not interface authority, and terminal control remains on separately granted Workbench/Sensorium actuation paths.
Question Envelope (P003): corpus-reasoning-query.v1 decorates question-envelope.v1; Corpus does not create a parallel question primitive.
Arca/Dator/offer-catalog (003/004/067): extended with corpus/topics indexing, not forked.
Inquirium (P063/P064/P066): per-participant model access via a full thread/session runtime with tool support is the target prerequisite for phase 2.
Operator-Sovereign Extensibility (P085): optional post-MVP Corpus hook policies and room-envelope negotiation may order or narrow already admitted bids, turns, participants, and tie candidates. They do not replace Corpus room policy, Agent budgets, Room membership, capability admission, or publication authority. P085 owns the common hook/envelope contract, operator producer and package lifecycle; Corpus owns the typed candidate set, pre-HIL turn-resolution boundary, and domain validator adapter. P049 owns optional Flow consumption of the same opaque offer and admitted decision ref.
P011 / story-006 / P016: procurement lifecycle and escrow.
Classification (047): the answer carries a small classification.v1 lattice tier, mapped to a full classification.v1 object at the AD answer envelope.
P057 notifications: requester/operator notifications for bids, readiness, answer.

Failure Modes and Mitigations¶

Mechanical¶

Failure mode	Risk	Mitigation
Ambiguous topic forced to a wrong term	Misrouted experts	Resolver returns `ambiguous` + `matched/labels`; asker disambiguates.
Silence conflated with refusal	Lost signal, wrong retries	`corpus-reasoning-bid-state.v1` distinguishes states with timestamps + reason.
Arbitrary topic strings indexed	Catalog pollution	`corpus/topics ⊆ terms(taxonomy/digest)` offer/catalog admission constrainer; missing or untrusted taxonomy fails closed.
Stale bid reused later	Wrong contract	`bid/valid-until` TTL.
Inline answer tampered after signing	Forged answer	`content/digest` self-reference + canonical-json signatures.
Replay of bids/invites	Duplicate work	Canonical idempotency keys + `correlation/id`/`query/id`.
Chat treated as a shared fact	Reification / privacy leak	Protocol never persists chat (P070); capture is private, classified.
Room membership treated as terminal-view authority	Unauthorized observation	Require a current participant-scoped P082 interface grant in addition to Room membership; the carrier grants no authority.
Shared viewport treated as a transcript or control channel	Unintended retention or actuation	Room carries only bounded `latest-state`; full transcript capture and all Workbench/Sensorium commands use separate classified, explicitly granted paths.
Shared enacted view omits, downgrades, or contradicts its source operational context	agents reason with an unsafe model of live-system impact	validate the exact P082 context and source generation before prompt assembly; missing or inconsistent evidence, a generation mismatch, or a superseded publication fails the collaborative-live turn closed without a Corpus-specific TTL.
Publisher context summary is promoted to privileged prompt text	remote prompt injection through interface metadata	preserve it as inert retrieved data and render caution only from the closed impact class through host-owned P064 policy.
Requester-selected Agent controls widen operator policy	Remote intent becomes local moderation authority	Resolve and persist requested and effective chair-control policy separately; every layer may only narrow the distributor/operator ceiling.
Agent emits a moderation-shaped model response	Model output mutates Room authority	Accept only a typed inert effect proposal, then recheck binding, review policy, current scoped Room delegation, target, generation, and TTL through Room admission.
Chair Agent disappears while holding the floor	Deliberation stalls or another participant gains authority implicitly	Release its floor and effective controls, then apply the explicit fallback; connected presence never elects a replacement.
Turn-order policy runs only after target-specific HIL	Operator policy can merely veto an already approved target and cannot schedule the turn	Build and resolve one target-free offer before binding the floor target or requesting HIL; apply the admitted first candidate through the ordinary Corpus and Room path.
Flow output is treated as a floor target	Declarative orchestration becomes a second source of Room authority	Flow receives only an opaque offer and bounded decision projection; Corpus reloads the host-owned admitted `decision/ref` and Room performs the final admission.
Direct and Flow-mediated paths resolve the same turn independently	Two current policies can produce divergent speakers	Bind one resolution to the exact Room, turn, offer digest, producer set, and policy generation; every consumer reuses that decision or refuses.

Abuse model (LLM + marketplace)¶

Abuse	Risk	Mitigation
Fake expertise offers	Low-quality answers	Reputation-weighted selection; post-answer rating; provider stake.
Topic stuffing	Offer spam	Bounded `corpus/topics`; topic⊆taxonomy gate; reputation penalty.
Collusive bids	Price fixing	Cartel detection on reputation graph; diversify selection; requester caps.
Prompt injection in the room	Hijacked reasoning	In-room content is untrusted input to Inquirium; per-node guardrails; chair review.
Leakage via answers	Exfiltration	`classification.v1` + egress guard; private capture stays local.
Price griefing / budget exhaustion	Cost attacks	Brackets, `budget/time-ms\|steps\|tokens`, Inquirium caps, escrow precheck.
Taxonomy poisoning	Misrouting	Signed `topic-taxonomy.v1` (issuer key, validity, supersession proof); pinned digest.

Trade-offs¶

Benefits: MVP reuses existing procurement/delivery; live chat (later) gives low latency; ephemeral reasoning keeps memory small; forces the Room consolidation (P070).
Costs: phase 2 depends on two unbuilt prerequisites; new (separated) N-way settlement; a taxonomy governance surface to curate and sign.

Resolved Decisions¶

Identifier governance. query: / room: / answer: prefix allocation is a core protocol registry concern, not a per-federation policy surface.
JSON canonicalization across implementations. Corpus uses orbiplex-canonical-json-jcs-v1 for signatures, digests, and idempotency keys. The Rust implementation is node/canonical-json::CanonicalJsonProfile::JcsV1, and the profile is specified here as a language-neutral contract rather than as a Rust-only behavior.
Taxonomy migration between versions. Providers and requesters may resolve against both the old and new taxonomy only when a valid supersession proof links the two digests. Without such proof, exact digest mismatch fails closed.
Query vs question-envelope.v1. corpus-reasoning-query.v1 is a decorator over question-envelope.v1, not a sibling question primitive.
Canonical topic hashing. taxonomy/digest is byte-stable canonical JSON over the taxonomy artifact. topic/term is an exact wire string; no Unicode folding or case-insensitive normalization is performed in the wire contract.
Discovery style. Catalog-rich discovery through the offer-catalog topic index is the default. capability-many remains available as an explicit addressing mode, not the default.
Chair vs election. MVP uses requester-appointed chair. Arbiter election is post-MVP.
Pricing model. MVP uses flat per-answer minor-unit pricing. A pricing-calculator contract is deferred until token/step/participant pricing is required.
N-way settlement. contribution-allocation.v1 becomes a separate proposal; P069 only reserves the name and carries references/weights needed by that future contract.
Bid-state retry strategy. Requester local policy decides retry budget and backoff. AD reports delivery state and diagnostics; it does not own Corpus retry semantics.
Inquirium session surface. Phase 2 targets a full Inquirium thread/session runtime with tools, not a minimal single-call or minimal open/continue/close surface, because the component is strategically required beyond Corpus.
Shared semantic validators. schema-gate depends on orbiplex-node-corpus-core for Corpus taxonomy/query semantic validation. This keeps tree, digest, topic, price, and bid-state invariants in one semantic kernel rather than maintaining an independent edge-validator copy.
Empty bid-state representation. corpus-reasoning-bid-state.v1 may represent discovery or dispatch failure before candidate selection as candidates: []. Requesters should not invent synthetic candidate rows for providers that were never selected.
extensions byte budgets. Corpus extensions fields on query, bid, taxonomy, and resolution artifacts have a maximum canonical JSON size of 16 KiB per field. Admission must reject larger extension payloads before network fan-out or digest materialization.
Trusted taxonomy loader boundary. Corpus offer admission is performed through a taxonomy-aware loader/verifier path. The generic service-offer catalog remains reusable and does not become a Corpus governance authority; Corpus indexing and production admission fail closed when trusted taxonomy material is missing.
Taxonomy issuer trust policy. Taxonomy issuer acceptance uses a composed trust policy: local node policy is authoritative for local use, while Seed Directory governance facts and/or Agora authority records may supply scoped trust evidence. No single published fact becomes a trust decision without local policy acceptance.
AD-mediated answer delivery. Production provider answer delivery uses a normal artifact-delivery-envelope.v1 carrying corpus-reasoning-answer.v1; Corpus does not define a separate corpus.answer transport. The local POST /v1/corpus/rounds/{query_id}/answers surface remains operator/test/admin control-plane only, while requester nodes admit provider answers through the in-process AD corpus.answer acceptor.
Zero-bid operator notification. no-routable-candidates and no-provider-bids stay synchronous dispatch diagnostics by default. P057 notifications are emitted only when Corpus policy explicitly enables retry/escalation visibility for such zero-bid states.
Story-011 trust hardening. Story-011 should run under full sovereign-policy verification rather than signature-only; acceptance coverage should exercise the production trust mode instead of the shortcut fixture mode.
Direct bid registration surface. POST /v1/corpus/bids remains a local-control operator/test helper, requires bid signature verification, and is not a remote federation surface.
Classification propagation. corpus-reasoning-answer.v1 carries the small classification.v1 lattice tier (Public, Community, or Personal) and the AD answer envelope maps it to a full classification.v1 object with tier-correct bound_subjects supplied by the provider/requester context. Confidential is intentionally not a Corpus answer tier in this phase: confidential deliberation is modeled by room/private capture and local policy, while a signed outcome artifact carried by the answer envelope must stay in the Public/Community/Personal lattice. Missing answer classification is treated as Public only for legacy/admin compatibility; production providers SHOULD set it explicitly. corpus-reasoning-query.v1 should still grow a first-class classification field before Personal or higher-tier Corpus queries are supported.
Answer revision validation. A local answer read-model may replace an answer by the same answer/id or by a new answer whose supersedes points at an existing answer from the same responder. If revision/no is present, the first revision is 1 and a superseding revision must be greater than the superseded revision. The counter is advisory for humans and diagnostics; append-only fact order plus the supersedes edge remains authoritative.
Independent judgment and disagreement. Independence of an initial judgment is a visibility-barrier property, not an implication of procurement fan-out or parallel model execution. Any elected-arbiter profile must enforce isolated-until-barrier with salted commit/reveal values. Barrier release closes the first-judgment phase; later contributions carry explicit non-independent provenance and do not enter the initial quorum. Admitted disagreement remains bounded provenance data rather than a failed round or material silently flattened by synthesis.
Operator-bounded Agent chairing. Requester intent may opt into Agent-led conversation governance but cannot create Room authority. Corpus binds a content-addressed requested/effective control policy; distributor and local operator configuration set the ceiling, the Agent receives only proposal capabilities, and Room remains the sole moderation and floor admission authority.

Open Questions¶

No open questions remain for the hard-MVP procurement slice. Post-MVP live deliberation questions are tracked under the Room/Inquirium/Agent phases below.

Resolved post-MVP Story 012 discovery decision: the second guest-attested PowerDNS challenge is powerdns-bind-missing-zone-data.v1. Its prepared system has a valid loopback listener, BIND backend activation, and authoritative zone declaration whose referenced zone-data file is absent. The image must not contain the final localdomain records. This preserves a real incomplete system, exercises model-authored reference following, and differs structurally from the current unconfigured challenge.

The runner must read challenge/id and the verifier contract ref/digest from pinned guest/image evidence. A profile literal, runner default, or renamed copy of the first image cannot satisfy the second-variant gate. Both variants use the same typed plan, admission, review, HIL, P083, and report semantics; only prepared system state and corresponding observation evidence may differ.

Resolved answer publication decision: local daemon round snapshots may replace a repeated answer/id or a superseded answer as a latest read-model convenience, after signature, selected-bid, and policy-digest validation. Federated answer publication is append-only: an updated answer is a new corpus-reasoning-answer.v1 fact with supersedes and optional revision/no, not an overwrite. Local validation rejects dangling supersedes references, cross-responder supersession, and non-monotonic advisory revision numbers.

Implementation Contract¶

2026-09-06 compatibility and receiving-host correction¶

The receiving host freezes a named catalog-admitted offer declaration when it admits the bid, before ranking. An unresolved, malformed, expired, inactive or foreign source refuses the new bid. Current accepted/countered bid signatures require the source ID; source-less refusals and retained legacy absence do not assert local inference. Later selection reuses this immutable checkpoint rather than consulting today's catalog. Offer expiry does not erase an already admitted commitment; the bid's own validity still limits selection. Historical bids without a checkpoint require current admission and cannot gain a fabricated past declaration. This corrects P090-009c without widening provider authority or redefining Corpus participation.

The accepted corpus-reasoning-answer.v1 identifier grammar has a validator erratum: answer/id and supersedes admit _, already emitted by the existing base64url SHA-256 answer-ID producer. Old V1 validators may reject these answers. Deploy corrected validators on both peers before enabling digest-derived publication; never rewrite signed IDs as a fallback. V2 embeds V1 and inherits this requirement. Signature domains and canonicalization are unchanged. This is an explicit V1 compatibility correction, not a backward-compatibility claim for uncorrected peers or a new acceptance result.

This section is the execution bridge between the proposal and code. Runtime work MUST advance slice-by-slice, and each runtime slice is blocked until its contract gate is complete. Corpus should not introduce ad-hoc payloads in middleware or AD before the corresponding canonical schema, examples, validation path, and negative tests exist.

Substrate and Canonicalization¶

Corpus separates domain payloads from their durable carrier:

durable/federated Corpus facts are published as agora-record.v1 envelopes with content/schema set to the Corpus schema name and content set to the domain payload;
local read-models such as corpus-reasoning-bid-state.v1 are host-owned projections, not Agora authority;
record/id, author/participant-id, author/nym-proof, record/parent, record/supersedes, relay metadata, and envelope signatures remain Agora envelope concerns when the payload is published through Agora;
all Corpus signatures, digests, idempotency keys, and content-addressed refs use orbiplex-canonical-json-jcs-v1, whose Corpus test vector is:

{
  "input": {"z": [3, 2, 1], "a": {"b": true, "a": "ą"}, "n": 1},
  "canonical": "{\"a\":{\"a\":\"ą\",\"b\":true},\"n\":1,\"z\":[3,2,1]}",
  "digest": "sha256:r2bAYdhk5FfM2FDmWq2HlGY4jDKM2Dcg6SG84tw7g7o"
}

Artifact-specific host-owned fields, such as taxonomy/digest, are removed only when the artifact contract says so before canonicalization. The canonical JSON profile itself does not know domain fields.

The first contract gate must define which Corpus payloads are public/federated Agora facts and which are local control-plane projections. The expected default is: topic-taxonomy.v1, topic-resolution.v1, corpus-reasoning-bid.v1, and final corpus-reasoning-answer.v1 may be Agora-carried facts; corpus-reasoning-bid-state.v1 remains local to the requester.

MVP Contract Gate¶

The MVP procurement slice may start only after these contract artifacts exist:

topic-taxonomy.v1 schema with positive/negative examples, signed fixture, and canonical digest rule.
topic-resolution.v1 schema with resolved, ambiguous, and unresolved fixtures.
service-offer.v1 Corpus extension contract: corpus/topics, corpus/model-class, corpus/taxonomy-digest, and corpus/taxonomy-issuer.
corpus-reasoning-query.v1 as a decorator over question-envelope.v1, with examples showing the underlying question envelope fields and Corpus extension fields.
corpus-reasoning-bid.v1 as an envelope over schema-valid procurement-offer.v1.
corpus-reasoning-bid-state.v1 as an asker-owned read-model, not a wire authority.
Schema-gate sync to node/protocol/contracts, plus admission constrainers for checks that depend on external artifacts, especially corpus/topics ⊆ terms(taxonomy/digest).
Refusal/replay tests for invalid signatures, stale deadlines, invalid taxonomy supersession, duplicate idempotency keys with different payloads, and offer withdrawal between discovery and dispatch.

The post-MVP live-deliberation slice has a separate gate: P070 Room contracts, the Agent organ (P073) bounded reasoning session, corpus-reasoning-room-policy.v1, corpus-reasoning-room-invite.v1, and corpus-reasoning-answer.v1.

Host Runtime Reuse¶

Corpus must reuse existing host-owned primitives instead of creating parallel runtime machinery:

Artifact Delivery (023) owns fan-out, delivery diagnostics, retry surfaces, and transport-specific failures.
Bounded Deferred Operations (029) owns long-running query/bid/settlement handles that cannot complete synchronously.
Replay Scheduler (020) owns periodic cleanup/retry wakeups for bid-state and catalog projections.
Inquirium (063/064/066) may be used by a provider as a local model executor for drafting an answer, but it is not a Corpus room participant, chair, or settlement authority. The provider host turns local Inquirium output into a signed corpus-reasoning-answer.v1 fact.
Temporal Storage Convention (028) owns retention, compaction, and bounded replay rules for local bid-state projections.
Middleware (019) is the extension surface for supervised provider acceptors; it does not own Corpus state semantics.
P011/P016 own procurement, contracts, receipts, disputes, and escrow after a bid is selected.

Capability and Service Type Boundary¶

corpus.provider is both an operational capability and a marketplace-visible service category, but those layers must not be conflated:

capability_id = "corpus.provider" is the routing/authorization capability used by AD, passports, and local allow policy;
service-offer.v1.service/type = "corpus.provider" is the advertised marketplace category exposed through Dator/offer catalog;
topic expertise is never embedded into the capability id; it remains offer/passport data (corpus/topics, corpus/taxonomy-digest, topic/term);
before runtime implementation, corpus.provider must be added to the capability registry and linked to the service-offer.v1 Corpus extension.

External Call Budgets¶

Every Corpus path that crosses a component or node boundary must carry explicit budgets:

AD fan-out uses max/candidates as a hard cap; the initial implementation default is 50 unless a stricter federation or requester policy is configured.
Query dispatch has a request timeout, max response bytes, retry budget, backoff with jitter, and terminal failure class.
Provider bid acceptors have a bounded execution time and must return a retryable vs terminal failure classification.
Catalog lookups must cap result count and page size before AD target expansion.
Settlement handoff inherits P011/P016 timeout and idempotency rules.

Budget exhaustion is diagnostic data. It must not be reinterpreted as provider refusal.

Identifier and Idempotency Rules¶

Identifier patterns are contract, not UI labels:

query/id: ^query:[A-Za-z0-9][A-Za-z0-9:-]*$;
bid/id: ^bid:[A-Za-z0-9][A-Za-z0-9:-]*$;
answer/id: ^answer:[A-Za-z0-9][A-Za-z0-9:-]*$;
topic/term: exact taxonomy term string, case-sensitive, no wire-time Unicode folding.

Default query idempotency key:

sha256(canonical_json({
  question/id,
  requester/node-id,
  topic/term,
  corpus/taxonomy-digest,
  pricing/min-amount,
  pricing/max-amount,
  pricing/currency,
  deadline-at
}))

Default bid idempotency key:

sha256(canonical_json({
  query/id,
  bidder/node-id,
  decision,
  bid/valid-until,
  procurement-offer.digest-or-null
}))

The schema/admission layer must enforce pricing/min-amount <= pricing/max-amount and deadline-at > created-at.

Runtime Components¶

MVP implementation should be stratified into small components:

Topic taxonomy loader/verifier: resolves trusted taxonomy artifacts by digest, verifies issuer/signature/supersession, and exposes immutable taxonomy values to resolver and catalog admission code.
Deterministic topic resolver: pure weighted matcher over a taxonomy value, returning topic-resolution.v1.
Offer-catalog topic index: projects active service-offer.v1 records into topic/term -> offer refs, including parent-term fallback and supersession. The public query surface is path-first: GET /v1/offer-catalog/corpus/taxonomies/{taxonomy_digest}/topics/{topic}/offers. Runtime toggles that would make the path noisy or inefficient stay in query parameters, for example limit, offset, and active=false. The response exposes has_more and HATEOAS-style links.self / links.next / links.prev where applicable. service/type = "corpus.provider" is fixed by the corpus path segment, not a caller-selected query parameter.
Corpus query dispatcher: builds a question-envelope.v1 + Corpus decorator, selects candidate targets from the catalog-rich index, and submits one AD fan-out.
Provider bid acceptor: validates query authority, deadline, taxonomy digest, local capability, and price constraints before returning corpus-reasoning-bid.v1.
Bid-state read-model: aggregates AD delivery attempts, received bids, declines, timeouts, and retry decisions without treating silence as refusal.
Single-provider settlement bridge: converts the selected bid's embedded procurement-offer.v1 into the ordinary P011/P016 contract/receipt path.

State Machines¶

Topic resolution states are closed for MVP:

unresolved
ambiguous
resolved

ambiguous is not an error; it is a decision point requiring requester disambiguation. unresolved is a terminal no-routing result unless the requester changes keywords or taxonomy.

Bid-state values are requester-local:

candidate-selected
query-sent
bid-received
declined
countered
timed-out
delivery-failed
unreachable
retry-scheduled
selected
rejected
settled

Only bid-received or explicitly accepted countered candidates are eligible for selection. delivery-failed and unreachable flow into requester local retry policy; AD reports diagnostics but does not decide Corpus retry semantics.

Bid-State Lifecycle¶

corpus-reasoning-bid-state.v1 is a requester-owned temporal projection:

owner: requester node;
key: (query/id, candidate node/id);
idempotency: (query/id, candidate node/id, delivery/attempt-id) plus canonical bid digest when a bid is received;
retention: active until query deadline, selected settlement completion, or terminal cancellation; after that, compact according to the Temporal Storage Convention;
cleanup trigger: deadline-at + local grace period, settlement completion, or explicit requester cancellation;
indexes: query/id, candidate node/id, state, deadline-at, and delivery/attempt-id;
safety rule: cleanup must not remove an active settlement, active deferred operation, or unresolved dispute.

Room Integration Contract¶

Post-MVP live deliberation must use P070 instead of inventing a Corpus room:

Room is independent infrastructure. It owns room identity, membership, presence, lifecycle, live transport, attestations, projections, and generic room events. Corpus is only one consumer.
corpus-reasoning-room-policy.v1 is a Corpus decorator over room-policy.v1; it adds chair/acceptance/quorum/budget fields but does not replace room access policy.
chair/agent-ref may name a requester-owned Agent acting as the chair delegate, but the accountable chair subject and credentials remain explicit in the room policy.
Agent-chair moderation requires an exact content-addressed corpus-reasoning-chair-control-policy.v1 bound into the next Corpus room-policy revision. Requester intent may select only operator-permitted controls and modes; the effective policy records the monotone intersection and its generation.
Corpus maps organic, moderated, and baton to P070 open, moderated, and round-robin through the single closed CORPUS_CHAIR_FLOOR_MODE_MAP. It maps voice, kick, and ban to scoped Room authority rather than implementing parallel membership, denial, or floor state.
A Chair Agent receives only capability grants necessary to propose admitted control intents. The host and Room recheck current policy and delegation on every use; the Agent never receives the root authority or direct Room mutation authority.
Live-room speakers are accountable subjects or Agents. Raw Inquirium adapters and model runtimes are inference providers only and must not be admitted as room members; single-turn model participation is represented as a degenerate Agent profile.
corpus-reasoning-room-invite.v1 references room.v1, the live transport binding, and the room access list; actual join decisions rely on P070 membership attestations.
corpus-reasoning-role-assignment.v1 records task roles for participants. A role is valid only after local participant acceptance or local policy acceptance, and it cannot widen the participant's authority, classification ceiling, or grants.
corpus-reasoning-instruction-overlay.v1 records suggested prompt/instruction overlays for a role or turn. It is never injected directly into a remote model prompt; each participant's local Inquirium prompt-assembly policy decides whether and how to apply it.
corpus-reasoning-answer.v1 cites room/id, room-event/high-water, policy digest, and relevant provenance refs. It must not embed live chat content.
room authority, revocation, retention, live transport, and membership projection remain P070 responsibilities.

Adoption and Migration Plan¶

Corpus is a new role, but it modifies adjacent projections:

Existing service offers remain valid; only offers that opt into the Corpus extension enter the topic index.
Shared Offer Catalog (P067) adds the topic index as a projection over existing service-offer.v1 records; it does not replace the base offer catalog.
P011 procurement artifacts are reused unchanged; Corpus only supplies the query/bid wrapper and the selected embedded procurement-offer.v1.
No historical records are migrated into Corpus automatically. Operators may publish new Corpus-extended offers when providers intentionally opt in.

Admission and Failure Rules¶

Corpus admission MUST fail closed for:

missing, untrusted, expired, or unverifiable taxonomy material;
corpus/topics that are not terms of the pinned taxonomy;
taxonomy migration without a valid supersession proof;
stale bids (bid/valid-until <= now) or queries past deadline-at;
embedded procurement-offer.v1 that fails the existing procurement schema;
price outside the requester bracket unless decision = "counter";
duplicate bids with the same idempotency key but different canonical payload digest;
missing requester authority, missing reply target, or mismatched question/id;
provider offers that were withdrawn or superseded before query dispatch;
classification/egress violations on signed outcomes carried by answer envelopes.

Failures should be diagnostic events with redacted payload references, not silent drops.

MVP Acceptance Slice¶

The first acceptance pack should prove the narrow MVP without rooms:

one requester, two providers, one signed taxonomy, and one topic term;
both providers publish Corpus-extended service-offer.v1 records;
requester resolves keywords to the canonical topic and queries the catalog topic index;
requester broadcasts one corpus-reasoning-query.v1 over AD to selected targets;
one provider returns an accept bid with embedded schema-valid procurement-offer.v1;
the other provider returns decline or times out, and bid-state distinguishes both;
requester selects one bid and completes the single-provider P011/P016 settlement path;
replay or repeated dispatch is idempotent and does not create duplicate selected bids.

Implementation Recommendations¶

These recommendations are implementation guidance for the Corpus role and protocol. They are intentionally more concrete than the architecture model above, but they do not replace the canonical schemas, schema-gate checks, or tracker. Field names in examples follow §Schema Conventions; final schemas are gated in doc/schemas/ and the node schema-gate. … elides obvious values.

Design Commitments¶

Corpus is a thin domain layer over existing host-owned strata. It MUST NOT become a second marketplace, a second delivery system, a second room system, or a second LLM session runtime. Its implementation should add only the domain vocabulary needed for topic-routed collaborative reasoning: topic taxonomy, topic resolution, Corpus-extended offers, query/bid facts, requester-local bid state, and later Corpus-specific room decorators.

The MVP implementation should optimize for contract clarity over clever routing. Each state transition should be explainable as data: taxonomy material is verified, keywords resolve to a topic, topic-scoped offers project into an index, one AD fan-out is planned, bids are admitted or rejected, bid-state is updated, and one accepted bid bridges into the existing procurement path. Hidden in-memory shortcuts are acceptable only as caches over these facts, never as the source of authority.

Primary Rule: Compose Existing Authorities¶

Corpus coordinates expertise; it does not own the authority of adjacent systems. Artifact Delivery owns delivery attempts and transport diagnostics. Dator/offer catalog owns service offers and topic projections. P011/P016 own procurement, contracts, escrow, and receipts. Room owns room identity, membership, live transport, presence, and room projection. Inquirium owns model inquiry through host-selected runtime candidates.

Implementation should therefore pass typed data across those boundaries rather than calling through private APIs. For example, a Corpus query dispatcher may build an AD delivery envelope, but it must not directly mutate AD delivery state. A Corpus settlement bridge may export the selected embedded procurement-offer.v1, but it must not create a parallel settlement ledger. This keeps Corpus understandable as a role and protocol instead of a hidden orchestration subsystem.

Reuse Map (existing components, do not reinvent)¶

The Primary Rule is operationalized by reusing these existing strata rather than rebuilding them inside Corpus:

Corpus need	Reuse	Note
Bounded reasoning session (deliberation)	Agent organ (P073); `agent-core` budget/controller	Deliberation `budget` (`time-ms`/`steps`/`tokens`) is the Agent budget contract, not a Corpus-local one.
`corpus.provider` capability id + admission	Capability Registry (P072 / Solution 037)	Register `corpus.provider`; admission is fail-closed via the registry, not a Corpus allow-set.
Taxonomy / resolution / answer signing	`agora-core` canonical (deterministic, domain-separated)	Same canonicalization discipline as `node-advertisement.v1`; no Corpus-specific canonical form.
Query dispatch + bid collection to a deadline	Bounded Deferred Operations (Solution 029)	Operation id, status, cancellation, deadline — not a Corpus-private task queue.
`retry-scheduled` dispatch retries	Replay Scheduler (Solution 020)	Backoff/jitter/launch accounting — not a private timing loop.
Answer provenance / durable facts	Memarium fact-plane; object-store / AD for large content (`content/ref`)	Answer facts are Memarium facts; bulk content stays by reference.
Answer acceptance (verified / refuted / amended)	`inquirium.inquiry-feedback.v1` (P066)	Reuse the inquiry-feedback contract pattern for chair-signed acceptance.
Deliberation room + attestation	Room (P070) "Corpus Deliberation Rooms" hook (Solution 036); high-water attestation	Already reused (`room-event/high-water`); decorate room policy, do not fork a room model.
Delivery / settlement / escrow	AD (Solution 023); P011 procurement; P016 escrow	Bridge to these; never a parallel ledger.

Stratify Corpus the same way as the other organs. The pipeline stages below are pure functions and narrow ports, so Corpus should follow the <organ>-core / daemon template (DEV-GUIDELINES Layering 5) already used by inquirium-core and agent-core: a thin corpus-core crate owning the contracts, the deterministic resolver, the pipeline stages, the typed failure taxonomy, and the effect-intent values (DispatchPlan, BidAdmissionDecision, SelectionDecision, SettlementBridgeIntent); the daemon performs effects (AD dispatch, persistence, settlement bridge) and supplies the read-ports. Guard the crate with a dependency-direction lint mirroring check-inquirium-core-deps.py, so Corpus never accretes daemon coupling. Decisions are values; the daemon is the imperative shell.

Corpus Vocabulary and Strata¶

Use the following implementation vocabulary consistently:

taxonomy artifact: signed, content-addressed taxonomy material;
trusted taxonomy: a host-loaded taxonomy value that has passed issuer, signature, validity, supersession, and digest checks;
topic resolution: deterministic resolver output for one keyword set under one trusted taxonomy digest;
Corpus-capable offer: a normal service-offer.v1 with a valid Corpus extension;
topic index entry: read-model projection from active Corpus-capable offers;
Corpus query: requester-owned question decorator plus topic and pricing bracket;
Corpus bid: provider response envelope around an embedded procurement offer;
bid state: requester-local temporal read-model, never a federated authority;
selected bid: one admitted bid chosen by local selection policy;
settlement bridge: conversion from selected bid to the existing P011/P016 path;
Corpus-on-Room: post-MVP deliberation protocol layered on generic Room.

These names should appear in code modules, tests, operator status, and tracker evidence. Avoid names such as room_for_corpus, corpus_delivery, or corpus_contract when they suggest ownership that belongs to Room, AD, or procurement.

Phase Boundary: Procurement First, Live Deliberation Later¶

The MVP procurement slice must remain shippable without Room live transport and without the Agent organ (P073) reasoning session. It should prove that a requester can discover topic experts, solicit bids, select one provider, and enter the existing settlement path. That is the first useful vertical slice and the least entangled one.

Live deliberation is a later layer. It should start only after P070 live-plane runtime integration and the Agent organ (P073) runtime exist. Corpus should not fill that gap with a smaller ad-hoc chat loop, temporary room model, or direct model adapter membership. The boundary is important: MVP Corpus procurement can mature independently, while Room and Inquirium continue to harden as reusable primitives.

Request Pipeline as Explicit Stages¶

Implement the MVP request path as explicit stages with stable intermediate values:

Load taxonomy: resolve trusted taxonomy material by digest and issuer policy.
Resolve topic: transform keywords into topic-resolution.v1.
Select offers: query the topic index under the chosen taxonomy digest.
Plan dispatch: construct one bounded AD fan-out plan.
Admit bids: validate bid envelope, embedded procurement offer, deadline, price, requester/provider identities, taxonomy digest, and idempotency key.
Update bid-state: append or recompute requester-local projection facts.
Select bid: choose from eligible accepted/countered bids using local policy.
Bridge settlement: hand the selected procurement offer to P011/P016.

Each stage should be testable as a pure function or a narrow port. The daemon or host composition root may perform persistence and side effects, but domain decisions should remain data-driven and replayable from inputs.

Taxonomy Loader and Resolver¶

The taxonomy loader is a trust boundary. It should accept only signed, valid, content-addressed taxonomy artifacts from configured issuers or governance roots. It should return immutable trusted taxonomy values to downstream code; downstream code should never re-parse untrusted taxonomy JSON from arbitrary Corpus payloads.

The resolver should be pure and deterministic. Unicode normalization, label matching, weighting, epsilon comparison, ranking, and tie-breaks must be pinned by tests and fixtures. ambiguous is a normal outcome requiring requester choice; it must not be silently collapsed to the first candidate. unresolved is a terminal no-route result unless the requester changes keywords or taxonomy.

Offer Projection and Capability Boundary¶

The Corpus offer index should be a read-model over ordinary service-offer.v1 records. Only offers with service/type = "corpus.provider" and a valid Corpus extension enter the topic index. Invalid Corpus extensions should fail closed for Corpus indexing while leaving the base offer record available to non-Corpus consumers if it is otherwise valid.

The corpus.provider capability identifies the service class, not the topic. Topic expertise belongs in offer/passport data (corpus/topics, corpus/taxonomy-digest, corpus/model-class) and in the topic index. Do not mint capability IDs such as corpus.provider.cpp; that would mix routing authority with evolving domain taxonomy.

Provider status is opt-in and conjunctive. A node is a Corpus provider only when it publishes a Corpus-capable service-offer.v1, carries or publishes an accepted corpus.provider capability passport, and exposes a Corpus query acceptor. A generic daemon that merely has the code installed must not auto-publish corpus.provider nor accept Corpus queries by default.

Dispatch and Bid-State Ownership¶

AD owns delivery attempts; Corpus owns the interpretation of those attempts for one reasoning query. The bid-state projection should distinguish declined, timed-out, delivery-failed, unreachable, and retry-scheduled. Silence is not refusal, and a delivery failure is not a provider judgment.

Bid-state should be append/recompute friendly. Persist enough stable keys to make replay idempotent: (query/id, candidate node/id, delivery/attempt-id) and the canonical bid digest when present. A duplicate idempotency key with the same canonical digest is a replay; the same key with a different digest is an admission failure.

Selection and Settlement Boundary¶

Selection is requester-local policy over admitted bids. It should never mutate a provider's embedded procurement-offer.v1; if the price is outside the bracket, reject or counter according to the bid decision contract. The first implementation may choose the cheapest valid accepted bid with deterministic tie-breaks, but the selection decision should be recorded as a fact or operator-visible transition.

After selection, Corpus should hand off to the existing procurement path. The settlement bridge should export the selected embedded offer, selected bid digest, provider identity, and query id. It should not create Corpus-specific escrow, receipt, dispute, or contract records. If settlement fails after selection, the round should move to an explicit operator-visible recovery state instead of silently selecting another provider.

Room and Inquirium Composition¶

Post-MVP Corpus deliberation should compose Room and Inquirium as independent strata. Room supplies accountable participants, membership, access policy, live transport, presence, revocation, and high-water attestations. Inquirium supplies bounded inference through host-selected runtime candidates and prompt assembly policy. Corpus supplies topic routing, admitted profile roles, deliberation policy, answer acceptance, and answer provenance.

The implementation must not admit raw model adapters as room participants. If a model participates in deliberation, it does so through the host-owned Agent organ (P073), or a degenerate single-turn Agent profile, with explicit budget and accountability; the deliberation budget is the Agent budget/controller contract, not a Corpus-local one. Corpus instruction overlays are suggestions consumed by each participant's local Inquirium policy; they are not remote prompt injection. The first node-local slice resolves only a closed host-owned policy catalog. An accepted overlay carries both its inert source suggestion and the policy-produced instruction/rendered; the latter is the only value admitted into prompt assembly and is deterministically reverified during restart recovery and immediately before use. Corpus task roles remain a separate axis from Inquirium protocol roles: distinct fixed role-aware framing may still use the protocol-level Developer role without collapsing Corpus role semantics.

Operator Status and Observability¶

Expose Corpus progress as operator-facing state rather than logs only. A useful MVP status shape includes: query/id, topic resolution result, taxonomy digest, selected candidate count, delivery attempts by state, admitted bid count, selected bid, settlement state, and next operator action if blocked. Do not include full question text in generic operator traces when a digest/ref is enough.

Trace records should preserve causality: keyword resolution, offer index snapshot, dispatch plan, delivery attempt ids, bid admission decisions, selection decision, and settlement bridge outcome. Payloads that may contain private question text, answer text, or provider-specific details should be referenced by digest or artifact ref and governed by classification.

Failure Taxonomy¶

Use typed failure classes instead of free-form strings at boundaries. At minimum: taxonomy-untrusted, taxonomy-expired, topic-unresolved, topic-ambiguous, offer-invalid, offer-withdrawn, dispatch-failed, bid-invalid, bid-stale, price-out-of-bracket, duplicate-conflict, selection-empty, settlement-unavailable, and settlement-failed.

Each failure class should declare whether it is retryable, operator-actionable, or terminal for the current query. For example, topic-ambiguous is operator-actionable, dispatch-failed may be retryable, and duplicate-conflict is fail-closed until the conflict is inspected.

Conformance, Golden Fixtures, and Test Gates¶

Before runtime wiring, ship schema and semantic gates for every Corpus payload. Positive fixtures should include the happy-path procurement slice. Negative fixtures should cover invalid taxonomy signatures, duplicate terms/labels, invalid supersession, ambiguous and unresolved resolution, invalid topic references in offers, stale deadlines, price bracket violations, bidder/responder mismatch, duplicate idempotency conflicts, and invalid bid-state transitions.

The acceptance pack should exercise one requester and two providers end to end without requiring Room. It should prove that a decline is distinct from timeout, that repeated dispatch is idempotent, that withdrawn offers are not selected, and that only an admitted selected bid can reach settlement. The later live-deliberation pack should be separate and blocked on P070/Inquirium readiness.

Performance and Resource Hardening¶

Corpus paths are fan-out paths, so default limits matter. Cap taxonomy size, label count, keyword count, candidate count, AD target count, bid-state rows per query, response bytes, and settlement retry attempts. Catalog queries should page before target expansion, and the dispatcher should never create unbounded per-provider tasks.

All payload byte budgets should be checked before canonicalization where possible and again after canonicalization where the digest/idempotency contract depends on bytes. Large answer content belongs in the artifact store by reference, not inline in Corpus state or bid-state projections.

Adoption Strategy¶

Adopt Corpus by adding projections and contracts, not by migrating historical records. Existing offers remain valid. Providers opt in by publishing Corpus-capable offers. Operators can stage rollout by first enabling trusted taxonomy loading and topic-index projection, then requester-side query dispatch, then provider bid acceptors, and finally the settlement bridge.

The first production-ready switch should be conservative: no live rooms, no N-way settlement, no automatic fallback to untrusted taxonomy material, no implicit provider selection after settlement failure, and no direct model orchestration outside Inquirium.

Reference Wire Shapes¶

A. Signed Topic Taxonomy and Deterministic Resolver¶

{
  "schema/v": 1,
  "taxonomy/id": "orbiplex.core", "federation/id": "orbiplex",
  "version": "2026.06.0", "versioning/scheme": "calver", "digest": "sha256:...",
  "issuer/nym": "nym:did:key:z...", "issuer/public-key-ref": "key:did:key:z...",
  "valid/from": "2026-06-01T00:00:00Z", "valid/until": "2027-06-01T00:00:00Z",
  "supersedes": "sha256:...prev...", "supersession/proof": { "alg": "ed25519", "value": "..." },
  "extension/policy": { "allow-federation-subtrees": true, "override": "issuer-only" },
  "nodes": [
    { "term": "IT",                 "parent": null,             "labels": ["IT", "informatyka"] },
    { "term": "IT:programming",     "parent": "IT",             "labels": ["programming", "programowanie", "coding"] },
    { "term": "IT:programming:C++", "parent": "IT:programming", "labels": ["C++", "cpp", "cplusplus"] }
  ],
  "signature": { "alg": "ed25519", "value": "..." }
}

topic-resolution.v1 (signed; reproducible):

{
  "schema/v": 1,
  "taxonomy/digest": "sha256:...", "resolver/version": "matcher-1.0.0", "epsilon": 1.0,
  "query/keywords": ["programowanie", "C++", "kwestia", "sortowanie"],
  "result": "resolved", "topic/term": "IT:programming:C++", "score": 7.0,
  "matched/labels": [ { "keyword": "programowanie", "term": "IT:programming", "kind": "alias" },
                      { "keyword": "C++", "term": "IT:programming:C++", "kind": "leaf" } ],
  "candidates": [ { "topic/term": "IT:programming:C++", "score": 7.0 },
                  { "topic/term": "IT:programming",     "score": 3.0 } ],
  "ambiguous/reason": null,
  "resolver/node-id": "node:did:key:z...", "signature": { "alg": "ed25519", "value": "..." }
}

Deterministic weighted matcher:

WEIGHTS = { exact_leaf: 4, exact_ancestor: 2, alias: 1, path_coherence_bonus: 2 }
resolve(keywords, taxonomy, weights, epsilon):
  matched = []
  for kw in normalize(keywords):                  # lowercase, strip, deterministic diacritic fold
    for node in taxonomy.nodes:
      if kw in node.labels: matched.push((node.term, classify(node)))   # leaf | ancestor | alias
  scores = {}
  for (term,_) in matched:
    s = 0
    for (m,kind) in matched:
      if m == term:                  s += weight_for(kind)
      elif is_ancestor(m,term):      s += weights.exact_ancestor
    if all_on_one_path(terms_for(term)): s += weights.path_coherence_bonus
    scores[term] = s
  ranked = sort_desc(scores, tie_break = lexicographic(term))
  if empty(ranked):                              return {result:"unresolved"}
  if len(ranked)==1 or ranked[0].score-ranked[1].score >= epsilon:
                                                 return {result:"resolved", term:ranked[0].term, candidates:ranked, epsilon, matched}
  return {result:"ambiguous", candidates:ranked, epsilon, matched, ambiguous/reason:"top scores within epsilon"}

B. `service-offer.v1` with the Corpus extension (full required set)¶

{
  "schema/v": 1,
  "offer/id": "offer:corpus:abc123", "sequence/no": 7,
  "created-at": "2026-06-23T09:00:00Z", "published-at": "2026-06-23T09:00:01Z",
  "expires-at": "2026-07-23T09:00:00Z", "offer/status": "active",
  "provider/node-id": "node:did:key:z...", "provider/participant-id": "participant:did:key:z...",
  "service/type": "corpus.provider",
  "service/description": "Collaborative C++ reasoning by a local LLM expert.",
  "pricing/amount": 4, "pricing/currency": "ORC", "pricing/unit": "1 answer", "pricing/unit-kind": "per-item",
  "delivery/max-duration-sec": 600, "queue/auto-accept": false, "queue/max-depth": 8, "hybrid": false,
  "corpus/topics": ["IT:programming:C++", "IT:programming"],
  "corpus/taxonomy-digest": "sha256:...", "corpus/taxonomy-issuer": "nym:did:key:z...",
  "corpus/model-class": "local-llm",
  "corpus/reasoning": { "max-steps": 8, "languages": ["pl", "en"] },
  "signature": { "alg": "ed25519", "value": "..." }
}

The corpus/* block is an extension: the offer is still a full service-offer.v1 with all base required fields and the same signature. Catalog topic index entry: key topic/term → { offer/id, sequence/no, taxonomy/digest, provider/node-id }, with parent-term fallback keys.

C. Procurement over AD¶

corpus-reasoning-query.v1:

{
  "schema/v": 1,
  "query/id": "query:q1", "correlation/id": "corr:c1", "idempotency/key": "sha256:...",
  "requester/node-id": "node:did:key:zASKER", "requester/participant-id": "participant:did:key:zASKER",
  "topic/term": "IT:programming:C++", "corpus/taxonomy-digest": "sha256:...",
  "query/keywords": ["programowanie", "C++", "kwestia", "sortowanie"],
  "question": "stable_sort with a custom comparator keeps crashing on...",
  "pricing/max-amount": 10, "pricing/min-amount": 1, "pricing/currency": "ORC",
  "max/candidates": 5, "created-at": "2026-06-23T11:00:00Z", "deadline-at": "2026-06-23T12:00:00Z",
  "reply/target": { "selector/kind": "node", "node/id": "node:did:key:zASKER" }
}

pricing/min-amount is a Corpus-only buyer-bracket field (not in service-order.v1); the schema MUST enforce pricing/min-amount <= pricing/max-amount and deadline-at > created-at.

AD broadcast plan: one parallel stage, success/policy: any, artifact.delivery.send?mode=deferred. Pick one addressing style per request: catalog-rich uses explicit node targets from the offer-catalog topic index; addressing-only uses one capability-many target (corpus.provider, max/nodes = max/candidates). If combined, AD deduplicates by canonical target key (inac:node:<node-id>), so each provider is queried once.

corpus-reasoning-bid.v1 (envelope around an embedded procurement-offer.v1):

{
  "schema/v": 1,
  "bid/id": "bid:b1", "query/id": "query:q1", "correlation/id": "corr:c1",
  "bidder/node-id": "node:did:key:zP1",
  "decision": "accept", "bid/valid-until": "2026-06-23T12:30:00Z", "policy/digest": "sha256:...",
  "procurement-offer": {
    "schema/v": 1, "offer/id": "offer:po1", "question/id": "query:q1",
    "created-at": "2026-06-23T11:05:00Z",
    "responder/node-id": "node:did:key:zP1", "responder/participant-id": "participant:did:key:zP1",
    "price/amount": 4, "price/currency": "ORC", "deadline-at": "2026-06-23T12:00:00Z",
    "answer/min-length": 200, "answer/max-length": 4000, "execution/mode": "single-responder",
    "specialization/tags": ["C++", "sorting"],
    "reputation/evidence": [
      { "kind": "service-offer", "ref": "offer:corpus:abc123", "score": 0.8 }
    ]
  },
  "signature": { "alg": "ed25519", "value": "..." }
}

Note the embedded offer's question/id equals the Corpus query/id, so a later procurement-contract.v1 chains back to the query.

corpus-reasoning-bid-state.v1:

{ "schema/v": 1, "query/id": "query:q1",
  "candidates": [
    { "node/id": "node:did:key:zP1", "state": "bid-received",   "received-at": "2026-06-23T11:05:10Z", "updated-at": "2026-06-23T11:05:10Z", "delivery/attempt-id": "del:1" },
    { "node/id": "node:did:key:zP2", "state": "timed-out",      "received-at": null, "updated-at": "2026-06-23T12:00:00Z", "reason": "no bid before deadline", "delivery/attempt-id": "del:2" },
    { "node/id": "node:did:key:zP3", "state": "delivery-failed", "received-at": null, "updated-at": "2026-06-23T11:06:00Z", "diagnostic/code": "adapter-permanent", "delivery/attempt-id": "del:3" } ] }

D. Deliberation Policy, Invite, and Answer (post-MVP, on P070)¶

{ "schema/v": 1, "room/id": "room:r1",
  "exposure": "private-to-swarm", "answer/acceptance": "chair-signed",
  "chair/mode": "requester-appointed", "chair/nym": "nym:did:key:zASKER",
  "chair/credentials": "capability-passport:...",
  "quorum/required": 2, "tie-break": "chair", "revocation-policy": "chair-or-requester",
  "budget": { "time-ms": 120000, "steps": 12, "tokens": 200000 } }

{ "schema/v": 1,
  "room/id": "room:r1", "query/id": "query:q1",
  "transport": { "transport/kind": "wss-pubsub", "transport/ref": "room-live:r1", "endpoint": "wss://..." },
  "policy/digest": "sha256:...", "access/list": ["nym:did:key:zP1", "nym:did:key:zP3"],
  "signature": { "alg": "ed25519", "value": "..." } }

The signed invite carries endpoint and membership-attestation material, never a live session bearer. The invitee obtains its private session/ref only from the Room join response and does not publish it back into Corpus observations.

{ "schema/v": 1,
  "answer/id": "answer:a1", "query/id": "query:q1", "room/id": "room:r1",
  "topic/term": "IT:programming:C++", "corpus/taxonomy-digest": "sha256:...",
  "content/ref": "artifact-store:...", "content/digest": "sha256:...", "answer/format": "markdown",
  "classification/ref": "classification.v1:sha256:...",
  "policy/digest": "sha256:...",
  "provenance/refs": ["..."], "contribution/refs": ["..."],
  "contributor/weights": [ { "node/id": "node:did:key:zP1", "weight": 60 },
                           { "node/id": "node:did:key:zP3", "weight": 40 } ],
  "attestation/evidence": { "room-event/high-water": 31 },
  "signatures": [ { "by": "nym:did:key:zCHAIR", "alg": "ed25519", "value": "..." } ] }

E. Test Data / Fixtures (must-have for the deterministic matcher)¶

Ship golden fixtures so the matcher is testable and stable across implementations:

fixtures/topic-taxonomy.orbiplex-core.json — the signed taxonomy above.
fixtures/resolution.cpp-sort.json — keywords ["programowanie","C++","kwestia","sortowanie"] → resolved IT:programming:C++, score 7.0, with matched/labels.
fixtures/resolution.ambiguous.json — keywords that tie under epsilon → ambiguous with two candidates.
fixtures/resolution.unresolved.json — keywords with no taxonomy hit → unresolved.

Each fixture pins resolver/version, epsilon, and taxonomy/digest, so a CI test asserts byte-stable output.

F. MVP Flow (procurement only)¶

sequenceDiagram
  participant A as Asker
  participant C as Offer Catalog
  participant P as Providers (P1..Pn)
  A->>A: resolve keywords -> IT:programming:C++ (or ambiguous)
  A->>C: query corpus topic index
  A->>P: AD broadcast corpus-reasoning-query.v1 (deferred, fan-out, max/candidates)
  P-->>A: corpus-reasoning-bid.v1 (accept|decline|counter) or silence
  A->>A: corpus-reasoning-bid-state (states + timestamps + reason)
  A->>A: select subset by price/reputation
  Note over A,P: MVP stops here: single contracting provider answers via P011;<br/>live deliberation is the post-MVP layer on P070

Implementation Tracker¶

Status legend: [ ] not started · [~] in progress · [x] done (with code evidence) · [!] blocked/needs decision. Each item notes its tier and blocked-by.

Cross-cutting domain and outcome boundary¶

[x] P069-DOMAIN-001 — Freeze the domain-general Corpus invariant and bounded outcome semantics. The Executive Summary, dedicated Domain and Outcome Boundary, Goals/Non-Goals, Live Deliberation, and Outcome / Answer Contract now state that technical Sensorium-assisted work is one optional profile; procurement is one participant-discovery path; and one signed envelope does not mean one objectively best answer or forced consensus. Ordinary text deliberation requires no specialized profile and may publish plain-text or markdown, including ordinary code fragments; optional thematic profiles begin at machine interpretation, domain success/evidence criteria, adjudication, typed publication, or effects, and opaque refs do not themselves admit those profiles. Done criterion: all six locations carry the same ownership boundary without introducing a domain enum or claiming new runtime acceptance.
[x] P069-DOMAIN-002 — Record contrasting, non-normative profile examples and their ownership split. The dedicated boundary now covers technical, scientific, social/mutual-aid, and creative/literary work and identifies profile-owned grammar, evidence, outcome, and effect policy. Done criterion: every example preserves Corpus routing/provenance semantics while leaving domain vocabulary and authority outside the core and remains explicitly illustrative and non-exhaustive.
[x] P069-DOMAIN-003 — Propagate the boundary to Solution 038 and mark technical acceptance as a non-defining specialization. Solution 038 now carries the same general-prose/thematic-profile split, links the ownership boundary back to this proposal, and labels Story 012 / P074 evidence as technical-profile evidence rather than Corpus-wide domain completeness. Done evidence: Solution 038 no longer relies on terminal examples to communicate Corpus purpose and makes no unsupported implementation claim.
[x] P069-DOMAIN-004 — Separate generic review-claim evidence from the Story 012 experiment wrapper. The corpus-reasoning-experiment-review.v3 accepted example remains technical, while the scientific illustration validates directly against the optional corpus-deliberation-review-claims.v1 envelope. Negative fixtures preserve each contract's structural boundary, and Data Contracts plus generated indexes state that both schemas are accepted contracts while runtime/profile adoption remains in progress. Done evidence: no non-technical fixture inherits CandidatePlan or terminal requirements merely to demonstrate domain neutrality. Social or creative machine fixtures remain deferred until separately admitted profiles exist.
[x] P069-DOMAIN-005 — Define admission and lifecycle for optional machine-interpreted thematic profiles. Specify the additive Corpus contract by which an operator or community may propose a namespaced, versioned vocabulary, evidence, success, adjudication, publication, or effect profile. The seam must bind issuer and exact revision, compatibility and supersession, receiving-host trust and admission, non-compelling community/federation endorsement, withdrawal/revocation, conformance fixtures, and fail-closed recovery. This task does not open or redesign the completed V1 coordination-role algebra. Done criterion: an untrusted profile ref cannot acquire semantics or authority, two hosts can independently accept or refuse the same revision, federation policy cannot compel either result, and general prose signed outcomes still require no profile. Depends on P069-DOMAIN-001 and P069-DOMAIN-002. Definition checkpoint (2026-09-06): the normative lifecycle section, canonical corpus-thematic-profile.v1, creative definition fixture, four-boundary Schema Gate, and pure corpus-core::CorpusThematicProfile conformance freeze these invariants using the existing semantic registry. This closes the definition task, not deployment of a thematic interpreter or automatic package installation; existing role dispatch and general prose are unchanged.

MVP — Procurement slice (no live room)¶

Most implementable value in the current architecture: topic resolver + offer lookup + AD query/bid + single-provider answer. No Room runtime, no Inquirium thread/session runtime, no N-way settlement.

Phase 0 — Preconditions¶

[x] Confirm AD deferred mode, capability-many, single-owner acceptors usable for a second marketplace consumer. Evidence: Artifact Delivery supports capability-many recipient selectors, private/direct policy checks, deferred delivery status, and single-owner acceptor admission; Corpus uses those seams rather than adding a transport authority.
[x] Confirm P011 artifacts + P016 escrow reachable for a single contracting provider. Evidence: Corpus exports the selected embedded procurement-offer.v1, and the daemon /v1/corpus/rounds/{query_id}/settle bridge opens the selected-responder execution, registers the selected procurement offer, selects it, and accepts the resulting contract through the existing execution/procurement host path.
[x] Extract the language-neutral normative profile from node/canonical-json for Corpus signatures and idempotency keys. Evidence: this proposal now names and specifies orbiplex-canonical-json-jcs-v1; orbiplex-node-corpus-core has a byte-stable canonical JSON and digest vector for the profile, and Corpus digests/idempotency keys use CanonicalJsonProfile::JcsV1.
[x] Complete the MVP Contract Gate: canonical schemas, positive/negative examples, node schema sync, schema-gate validation, and admission constrainers for the MVP procurement slice. Evidence: topic-taxonomy.v1, topic-resolution.v1, corpus-reasoning-query.v1, corpus-reasoning-bid.v1, and corpus-reasoning-bid-state.v1 exist in doc/schemas/, are synced to node/protocol/contracts/, and are covered by orbiplex-node-schema-gate Corpus tests. schema-gate now delegates Corpus semantic validation to orbiplex-node-corpus-core, including taxonomy tree/digest checks, topic resolution invariants, query price brackets, bid-state invariants, and the 16 KiB canonical byte budget for extensions. corpus-reasoning-bid-state.v1 explicitly allows an empty candidates list for dispatch failures before provider selection.

Phase 1 — Topic taxonomy + resolver¶

[x] Define signed topic-taxonomy.v1 (issuer key, validity, supersession proof, federation id, versioning scheme, unique terms/labels) and signed topic-resolution.v1 (epsilon, matched/labels, resolver/version).
[x] Implement the pure deterministic weighted matcher with ambiguous/unresolved. Evidence: orbiplex-node-corpus-core owns the deterministic resolver and tests exact, ambiguous, and unresolved cases.
[x] Ship the fixtures (§E) and a byte-stable CI test. Evidence: orbiplex-node-corpus-core validates the synchronized taxonomy/query/bid fixtures and asserts the canonical taxonomy digest plus deterministic resolver output.
[x] Implement canonical taxonomy/digest / topic/term hashing per Resolved Decision 5. Evidence: TopicTaxonomy::canonical_digest() recomputes the pinned sha256: digest over canonical JSON with host-owned fields removed.

Phase 2 — Topic-scoped offers + catalog indexing¶

[x] Add the corpus extension to service-offer.v1 (model-class enum, taxonomy digest + issuer); Dator publishes one multi-topic offer. Evidence: Dator maps configured Corpus offer fields onto the canonical wire keys and rejects incomplete corpus.provider offers before publication; daemon/catalog snapshots preserve corpus/topics, corpus/taxonomy-digest, corpus/taxonomy-issuer, corpus/model-class, and optional corpus/reasoning.
[x] Offer/catalog admission constrainer: corpus/topics ⊆ terms(taxonomy/digest); missing or untrusted taxonomy material fails closed. Evidence: schema-gate exposes a trusted-taxonomy subset constrainer, and node/catalog::validate_corpus_offer_scope applies the same check to catalog records through TrustedTopicTaxonomy; Corpus topic-index construction fails closed instead of silently hiding invalid corpus.provider records. Generic catalog storage remains neutral and is not a Corpus authority.
[x] Offer-catalog topic index + supersession/partial-withdrawal (P067). Evidence: node/catalog::corpus_topic_index_from_entries and corpus_topic_index_from_observed project active Corpus-capable offers by topic; the shared Offer Catalog exposes the path-first /v1/offer-catalog/corpus/taxonomies/{taxonomy_digest}/topics/{topic}/offers surface; its observed snapshot projection preserves corpus/* fields and tests cover taxonomy filtering plus partial withdrawal by replacing an older multi-topic revision with a newer reduced-topic revision.

Phase 3 — Procurement round over AD¶

[x] Define corpus-reasoning-query.v1 as a decorator over question-envelope.v1 (requester ids, keywords, max/candidates, bracket, deadline; invariants), corpus-reasoning-bid.v1 (envelope + embedded procurement-offer.v1; decision enum; TTL), corpus-reasoning-bid-state.v1 (timestamps, reason, delivery/attempt-id).
[x] Implement broadcast fan-out, the bid-state read-model, and local selection. Evidence: orbiplex-node-corpus-core builds a schema-valid artifact-delivery-envelope.v1 for capability-many fan-out, materializes the requester-owned corpus-reasoning-bid-state.v1, validates bid/query price semantics, enforces bidder/node-id == procurement-offer.responder/node-id, exposes the default bid idempotency key, preserves decline as refusal even after bid TTL, and selects the cheapest valid accepted/countered bid with longer bid/valid-until as the price tie-breaker. The daemon now persists Corpus rounds, registers query/bid facts, restores bid-state read models, exposes local provider bid acceptor endpoints and an AD inbound Corpus query acceptor, signs generated local bids with the node Ed25519 identity key, verifies admitted bid signatures against bidder/node-id, filters dispatch candidates by taxonomy digest plus exact/parent topic support, rejects offers outside the query price bracket rather than mutating their price, dispatches requester queries through AD capability-many over INAC, collects accepted bids from INAC admission diagnostics, emits P057 operator notifications for bid readiness, and has operator round visibility plus passing Story-011 acceptance coverage.
[x] Move Story-011 Corpus fan-out smoke from signature-only capability lookup to full sovereign-policy verification. The managed Story-011 ad-smoke path now creates B/C participants, pins them as Node A's sovereign capability passport issuers, restarts Node A, and exercises Seed Directory provider lookup through the production trust mode.

Phase 4 — Single-provider answer + settlement¶

[x] Single contracting provider answers; bid → procurement-offer.v1; close via procurement-contract.v1 / procurement-receipt.v1 with host-owned escrow. Evidence: orbiplex-node-corpus-core::settlement_selection exports the selected embedded procurement-offer.v1 with bid digest and selected provider node; the daemon bridge now opens the selected-responder execution, registers/selects the offer, and accepts the contract. Bridge failures after selection mark the Corpus round settlement-failed for operator-visible recovery. Story-011 now exercises the selection, settlement, corpus-reasoning-answer.v1 attachment, and requester-satisfied close path over AD/INAC. The first answer slice includes schema-gate validation, answer-text digest binding, daemon round persistence, provider-local inquirium.generate drafting through the deterministic local runtime, selected-bid responder binding, answer signature verification, policy-digest binding to the round taxonomy digest, bounded answer storage, chronological answer ordering, provider-originated AD answer delivery through the in-process corpus.answer acceptor, AD answer envelope construction, tier-correct answer classification propagation, local latest-read-model replacement for superseded revisions, and Story-011 smoke coverage. Multi-provider contribution receipts remain post-MVP.

Post-MVP — Live deliberation¶

Phase 5 — Room consolidation `[x] Solution 036 foundation`¶

[x] Land the generic Room primitive (P070 / Solution 036). Durable room schemas, deterministic projection, signed membership attestation, and bounded WSS transport plus the optional Matrix bridge satisfy one carrier-neutral authority contract. Corpus still owns its room policy, invitations, chair admission, and answer semantics; it must not add a third live transport. Relocatable federated WSS endpoint epochs and failover are tracked only by P070 Phase 6A/6B.

Phase 6 — Corpus chair over Agent `[x] implemented foundation`¶

[x] Land the general Agent organ (P073) reasoning session with tool support, budgets, deadlines, context windows, durable orchestration, stop/resume, and explicit draft boundaries.
[x] Admit a Corpus-chair Agent only from a schema-valid, signed, fresh Room membership attestation bound to the exact query, room, participant, grants, and Agent deadline. The node-local first slice also requires the attestation signer to be the local Corpus round authority; future remote Room authorities require explicit room-policy trust, never arbitrary self-signing. The signer reference must carry one canonical Ed25519 did:key, and embedded evidence is schema-gated again at answer-draft acceptance. Persist only the attestation's content-addressed reference in the recovered binding.
[x] Accept a terminal agent.outcome.v1 through the Corpus-owned, content-addressed answer-draft contract. Exact retries replay, conflicting retries and actor changes fail closed, only local control can perform this first-slice acceptance, restart restores the draft, and publication/authorized remains false. A separate Corpus transition must create and sign any final corpus-reasoning-answer.v1.

Phase 7 — Deliberation room policy + invite + join `[x] node-local live slice implemented`¶

[x] Define corpus-reasoning-room-policy.v1 with the P009 exposure enum, acceptance mode, accountable chair credentials, quorum/tie-break/revocation, bounded time/step/token budget, sorted access list, and fail-closed rejection of raw model/runtime subjects. Evidence: synchronized schemas/examples plus pure corpus-core validation, canonical digest, and neutral room-policy.v1 projection.
[x] Define the content-addressed, node-signed corpus-reasoning-room-invite.v1. The invite embeds the exact policy and signed Room membership attestation, binds recipient/inviter nodes, transport, grants, policy digest, source peer, and bounded lifetime, and fails closed on stale, altered, or mismatched evidence.
[x] Add schema-gate ingress/egress validation and pure admission/join/readiness projections over generic Room facts. The Corpus layer decorates Room state; it does not introduce a second membership or attestation authority.
[x] Persist the control plane in the daemon's append-only storage/corpus-deliberation.sqlite, expose operator-session room/invite/join/ readiness routes, and deliver invites through the ordinary AD node selector and the single-owner corpus.room-invite acceptor. Exact invite retry reuses the signed artifact and AD delivery identity; conflicting room policy fails closed. Canonical Ed25519 key validation, exact Room grant projection, AD-owned transport idempotency, Corpus-owned semantic replay by signed invite/id, typed HTTP failure classes, configured remote sovereign-root verification, and bounded SQLite contention handling are enforced at their owning boundaries.
[x] Cover the control plane with the three-node Story-011 process smoke: policy mismatch and ambient model-binding admission are denied, the signed invite is delivered and replayed idempotently, the recipient joins and signals local readiness, the ready inbox projection survives restart, and a dispatch replay after recipient restart preserves both invite/id and AD delivery/id. The shared Story 011/012 topology assigns A/B/C distinct loopback addresses and address-specific peer TLS identities, while naming the evidence honestly as multi-address single-host rather than multi-host federation. An explicit single-address fallback supports unattended execution without silently weakening the default profile; its result is marked as port-isolated single-host evidence.
[x] Connect admitted participants to the concrete bounded Room live carrier and propagate join/readiness/message observations to the room authority. Evidence: the daemon owns a bounded loopback WSS runtime, refreshes its neutral Room projection after admission, narrows session grants, persists only metadata observations and subject sequence checkpoints, acknowledges exact replay without redelivery, validates checkpoints before append and restore, pages startup recovery against one fixed SQLite high-water, retains a stable local bind across authority restart, and performs a typed controlled rejoin when only the ephemeral session was lost. Story-011 sends real messages and proves both authority-side and recipient-side restart recovery.

Phase 8 — Chair, participants, and local role overlays `[x] implemented`; arbiter deferred¶

[x] Requester-appointed chair resolves the first node-local Agent-chair path into a signed corpus-reasoning-answer.v1. Publication is a separate local-control transition that requires the current ready quorum, exact room high-water, accountable participant, classification, content-addressed output and evidence, text-only output blocks in the first profile, the dedicated corpus-reasoning-answer-signature.v1 domain, and actor-bound idempotency; exact replay returns the same answer and conflicts fail closed.
[x] Support requester-owned Agent as chair/agent-ref, with host-owned budget, lifecycle, grants, and stop/resume controls; the Agent coordinates but does not self-authorize publication, settlement, membership changes, or effects. Evidence: the process smoke spans dirty restart, bounded controller execution, inert draft recovery, absence of ambient publication, explicit Corpus publication, replay, and conflict rejection.
[x] Admit selected providers as Room-attested corpus-participant Agents without treating raw model runtimes or unselected bidders as Room subjects. Evidence: agent.binding.v1 requires the exact durable Corpus invite and signed, fresh Room attestation, narrows grants and budget, stores only the evidence reference, and recovers the binding after restart. Story-011 selects B while C remains a competing bidder, and rejects altered membership evidence.
[x] Route participant reasoning turns as inert corpus-reasoning-turn-proposal.v1 values through the explicit corpus.room.turn effect policy and ordinary HIL lifecycle. The Agent proposal classification cannot exceed its ceiling, payload class/key must equal the admitted proposal classification, and exact dispatch replay cannot redeliver the Room turn. Positive and closed-schema negative fixtures cover required fields, unknown fields, and the canonical turn/id prefix. Turn expiry uses the same five-second clock-skew tolerance as Room membership admission but never permits a turn to outlive the Room policy.
[x] Expose Room turns to the chair through the host-owned Interaction Broker room-event watch source. Live delivery is bounded and may carry the ephemeral turn; durable replay retains an explicit metadata allowlist only. Cursor epochs include host entropy and bind watches to one ephemeral Room source instance, so a cursor from before daemon restart fails closed instead of silently skipping or replaying content. An explicit cursor older than the retained bounded event window also fails closed rather than returning a misleading partial stream. Module callers require daemon-issued grant/interaction.watch material bound to the exact room/ref; local control is the explicit administrative path, and participant/ref is only a filter. Idempotent replay rechecks authority against the stored source. The authenticated Room transport seq/no remains the first-slice monotonic replay guard; the ephemeral semantic turn/no does not introduce a second, restart-ambiguous ordering store.
[x] Cover the first A-chair ↔ selected-B-expert exchange in Story-011. B invokes Inquirium under the participant Agent's grants, sends one approved turn, A wakes through Interaction Broker, runs its chair Agent, and Corpus accepts the result only as an unpublished answer draft. Restart recovers both bindings and the chair outcome, and exact draft acceptance replay returns the same durable draft; C remains outside the selected exchange.
[x] Define and implement corpus-reasoning-role-assignment.v1 for task roles such as implementer, reviewer, adversarial critic, or summarizer, with local participant or local-policy acceptance. Evidence: corpus-core owns the pure proposal and decision transitions; the schema cannot carry grants or classification overrides; the daemon resolves the registered local-policy:corpus-roles, exposes idempotent operator-session APIs, and persists bounded append-only delta facts in the Corpus round stream. Recovery requires sequential revisions and rejects malformed or conflicting facts rather than constructing a partial authority view.
[x] Define and implement corpus-reasoning-instruction-overlay.v1 for per-role and per-turn suggested instructions. Evidence: an overlay is inert until accepted by the registered local decision and prompt policies; accepted overlays are bound to the exact Room, participant, role assignment, mandatory turn, closed semantic kind, expiry, and closed class key. The prompt policy emits bounded instruction/rendered; recovery and the read path reproduce and verify that value before supplying it as a trusted operation-scope input to PromptAssemblyPolicyProvider. The 16-layer operation cap fails closed instead of silently discarding accepted deliberation semantics. The Corpus-chair process smoke proves acceptance, decline, expiry filtering, exact replay and conflict, two dirty restarts, bounded Agent execution, local host framing, and absence of ambient publication.
[x] Bind operator-defined Agent inference Flows to current Corpus authority through corpus-reasoning-inference-flow-binding.v1. The immutable Corpus-owned value pins the exact query, Room, participant, Agent and Flow lineage, accepted role and instruction-overlay revisions and digests, turn, Room-policy ref/digest and generation, prompt policy, classification, exposure, local intermediate visibility, expiry, and an unpublished-draft terminal disposition. Corpus revalidates those edges before passage admission, invocation, product commit, and terminal selection. Only the verified locally rendered overlay enters P064 as a required operation layer; Room prose remains inert and cannot become an instruction or effect. Intermediate products stay local, and only existing Corpus transitions may accept or publish an answer. A node-local participant binding may omit an inbox invite only for local-control, current effective local Room membership, no denial, and an exact current owner-signed attestation; federated participants still require the ready admitted invite. Process evidence covers stale overlay, membership loss, policy generation drift, Flow substitution, conflicting binding replay, bind-only admission followed by later execution without rebinding, local visibility narrowing, unpublished multi-pass selection, dirty restart, and exact replay.
[ ] Later: arbiter election (corpus-reasoning-arbiter-nomination.v1 / …-vote.v1) with eligibility, COI, quorum, deadline, tie-break, revocation, fallback, host-enforced salted first-judgment commit/reveal, auditable barrier closure, refused or explicitly non-independent late contributions, and bounded disagreement-preserving answer provenance.

Phase 8A — Operator-bounded Agent-chair moderation `[x] P070 Phase 7 implemented`¶

[x] Freeze corpus-reasoning-chair-control-policy.v1 and the next compatible corpus-reasoning-room-policy revision that binds its exact ref and digest. Carry requested and effective values separately; bind query, round, Room, accountable chair, optional Agent, policy generation, issue/expiry, floor mode, per-control review, temporary-ban ceiling, and fallback. Add positive and closed-schema negative fixtures plus canonical digest golden vectors, and register the exact schema family in the JSON-schema validation/sync mapping rather than relying on filename discovery.
[x] Add distributor/operator configuration for Agent-chair availability, allowed floor modes, default mode, per-control allow | require-human | deny, maximum ban TTL, permanent-ban policy, and fallback. Resolve it once at admission through the documented monotone intersection; requester fields can only narrow it. Resolve the effective ban TTL as the minimum ceiling inside this same pass, never in a later endpoint or effect adapter. Persist requested/effective policy, ref, and digest, and refuse unknown, stale, widened, or ambiguous values.
[x] Compile Corpus organic | moderated | baton into Room open | moderated | round-robin through one named CORPUS_CHAIR_FLOOR_MODE_MAP in corpus-core, without introducing Corpus-owned floor state or adapter-local translations. Bind floor operations to the exact Room, current policy generation, Chair Agent, floor lease, expiry, and idempotency key; restart or Chair replacement invalidates stale floor authority.
[x] Compile optional voice, kick, and ban controls into typed inert Agent effect proposals backed respectively by P070 grant/speak, membership/remove, and membership/deny scopes. Recheck the current Agent binding, operator review rule, Room delegation and projection, target, and TTL before canonical Room admission. Deny root-authority targets and permanent Agent bans by default. A voice mutation asks Room to toggle only speak; the host derives the full grant snapshot and proves every other grant unchanged. The durable snapshot therefore advances general Room membership high-water and attestation freshness, but it MUST NOT advance P070's derived sealed recipient-set epoch or rotate sender keys.
[x] Implement Chair failure and replacement policy. Stop, timeout, quarantine, policy revocation, or binding loss releases the floor and control authority, then deterministically returns control to the accountable requester, appoints an already admitted replacement, or suspends deliberation according to policy. Connected presence alone cannot trigger promotion.
[x] Add node-local and federated process acceptance covering organic, moderated, and baton deliberation; operator denial; requester narrowing; HIL approval/refusal for kick and ban; voice revoke/restore; bounded ban expiry; Chair crash/restart and replacement; stale delegation and policy generations; exact retry; sealed relay fencing; and proof that Agent proposals cannot mutate Room or publish the Corpus answer without their separate canonical admissions.

Implementation evidence spans corpus-core, the daemon-owned Corpus policy store and host adapter, agent.binding.v2 recovery, Room Phase 7 admission, and Story 011. The process profile resolves distributor/operator ceilings, persists one exact Chair policy, binds it into Room policy v2 and the Chair Agent, proves pre-approval moderation denial, admits mute and unmute after HIL approval, checks exact replay, restarts the authority node, and still requires a separate Corpus transition before any answer is published.

Phase 8B — Operator-resolved turn order `[x] done, post-MVP`¶

[x] P069-TURN-001 — Freeze the target-free Corpus turn-order offer. Add the closed corpus-turn-order-offer.v1 contract, canonical digest vectors, and positive and refusal-first fixtures. The offer MUST bind one exact query, Room, round, turn, previous floor holder, Room-policy ref/digest/generation, Chair policy, current membership and sanction high-water, and the accepted role-assignment ref/revision/ digest for every candidate. Corpus constructs the candidate set only after current membership, denial, sanction, speak, role, overlay, and expiry checks. The value contains no chosen target, grant, floor lease, prompt content, or effect authority.
[x] P069-TURN-002 — Resolve and apply one turn-order decision before HIL. Dependencies: P069-TURN-001, P049 P049-008, and the already implemented P085 generic select-turn-order validator (P085-007). Corpus invocation now runs at the pre-target resolution boundary rather than the former post-target veto boundary. Resolve the immutable offer exactly once, take the first admitted candidate as an inert proposed target, then recheck current policy and pass through ordinary HIL, delegation, and P070 Room floor admission. Direct and Flow-mediated callers MUST reuse the same admitted decision ref; changed offer, policy generation, candidate evidence, producer activation, or revocation refuses. The no-producer path records the explicit distribution policy selected by the current floor mode, including round-robin for baton, and MUST NOT claim an operator decision. Process evidence covers an alternate valid order, empty/foreign/duplicate candidates, stale role or membership evidence, exact replay, restart, producer revocation, and proof that presence, Flow output, and NSE policy cannot grant the floor.

The daemon now builds the target-free offer, resolves it through the centrally registered host-local agent.turn-order.resolve capability, and durably stores one exact decision. This capability is an internal host route: it is dispatchable only inside the admitted Agent Flow boundary, is not advertised, and is not passport eligible. It replays the decision idempotently after restart and revalidates the current authority snapshot at floor admission, and rejects a target other than the first admitted candidate. Process evidence now covers the complete pre-HIL route with reference and alternate package-owned orderings, exact retry and changed-body conflict, node-A restart with durable decision replay, terminal producer revocation without semantic fallback, target-specific ordinary Chair HIL and Room floor admission, and a separate no-producer run that records source=distribution-policy. The Flow exposes only an opaque decision carrier and neither it, connected presence, nor scenario helpers can grant or mutate the floor.

P049-008 may expose the resulting host-owned offer to JSON-e Flow, and P085-044 may package an operator-owned producer, only after the P069 contract exists. Neither task owns candidate construction or final Room admission.

Phase 8C — Bounded facilitator role `[ ] post-MVP`¶

[ ] P069-ROLE-001 — Freeze and implement the additive facilitator role. Introduce compatible v2 revisions for role assignment, instruction overlay, turn-order offer/table, and any semantic-registry entry that carries the closed role enum. Register facilitator and facilitation-guidance, keep all v1 values valid and unchanged, and reject cross-version role substitution. The daemon must render the facilitator overlay through the same local prompt-policy boundary as other roles, preserve it as inert data, and prove that facilitator output cannot admit a CandidatePlan, answer HIL, select or publish a product, mutate Room state, or invoke Sensorium. Add positive, wrong-version, unknown-role, authority-escalation, restart, and turn-order fixtures. Story 012 may consume the role only after this task is complete; scenario labels alone do not add it to the registry.

Optional shared enacted views `[x] P082 runtime implemented`¶

[x] Propagate P082 operational context and source/generation-ref from the exact Workbench/Sensorium publication through the Room read-result carrier and daemon observation resolver into a mandatory host-owned Inquirium caution layer before every participant's first feed-dependent turn. Refuse missing, downgraded, or inconsistent context and P082-stale evidence (generation mismatch or superseded publication), without defining another TTL; preserve per-source refs for audit; keep publisher summaries inert; and prove equal current source context plus monotone local raising across the three Story 012 nodes. The Room carrier now preserves the complete read result, the participant resolver rejects terminal non-published status and stale generations before inference, and Story 012 proves equal source qualifiers for B/C, host-owned monotone caution, immutable test -> production replacement, and refusal of the old publication.
[x] Define Story 012 and an executable acceptance profile that composes the existing Corpus/Agent Room topology with a chair-owned read-only Workbench terminal view, keeps actuation local-control-only in the first profile, and records explicit substrate gates before any smoke may run.
[x] Add the host-owned observation-admission boundary: agent-core carries only a generic need, static binding, and prompt-free resolution evidence; the daemon resolver binds one Room-delivered Sensorium Interface latest-state result and its single inline snapshot to an exact participant Agent passage under dual Room/interface authority, classification and byte ceilings, relay and Room-membership fencing, and ephemeral content lifetime. Evidence: static fail-closed JSON-e wiring, the process-local revocable Room observation registry, exact host-component Interaction Broker source, and Agent-to-Inquirium passage integration reject unbound/widened needs and retain no observation content across restart.
[x] For deliberation profiles that share a terminal or enacted-environment view, publish a bounded read-only Workbench/Sensorium representation through P082 and Solution 046, issue a resource-scoped interface grant to every admitted observer, and project it over the WSS-backed Room latest-state carrier. This optional integration must not treat Room membership as interface authority, expose ordered terminal replay, or grant terminal input and other Workbench actuation. It is not part of Phase 7 closure. The implemented carrier publishes a closed sensorium-interface-read-result.v1 with one cursor-free inline snapshot into the active relay epoch. Story 012 composes this carrier through the shared Story 011 three-node bootstrap without turning Corpus into a terminal owner.
[x] Complete and run the Story 012 three-node process smoke after every checked-in substrate gate is backed by executable evidence. The runner proves the failing chair terminal, independent B/C observations and HIL deliberation, revocation of C before repair, convergence of the relay audience, dirty restart of recipient B, local-only repair, a newer passing latest-state projection for B while C remains refused, unchanged absence of ambient terminal actuation, and Corpus acceptance of the chair result only as an unpublished answer draft. The profile closes all 17 refusal claims through either direct composed-process evidence or a named lower-stratum P070/P082/P083 owner. P070's separate host-TLS pack remains the external relay deployment evidence.
[x] Run the additive full-system vfkit profile as one vertical Workbench runtime. The deterministic repair fixture is digest-pinned in the guest image; failing and passing PTY state traverse P082, repair is fenced by P083, and the three-node Corpus/Agent round retains revocation, dirty restart, export, and an unpublished answer draft. The schema-gated report claims single-runtime-vertical rather than inferring the result from separately run harnesses.
[x] Retain one passing additive Story 012 PowerDNS/Bielik single-host full-system report. The implemented profile starts separate real local model runtimes for B and C, verifies each Agent product by content address before using its text as an inert Corpus turn, keeps model output away from actuation, and applies only the deterministic host-owned PowerDNS fixture through HIL plus the existing P083 lease. The retained 2026-07-24 run proves the exact localhost-only listener and three localdomain A records; its two distinct inference refs prove independent calls without assuming deterministic products must have different digests. The same closed report proves distinct solver/reviewer roles, two round-robin cycles, a failed first experiment and corrected plan after fresh terminal feedback, Agent propose decisions, admitted HIL, P083 claim -> invoke -> release, and zero effects derived directly from Room prose.
[x] Implement the stronger Story 012 deliberation policy as an additive consumer profile: requester opening, accepted solver/reviewer instruction overlays, the canonical baton -> round-robin mapping, at least two and at most 64 ordered cycles under a five-minute deadline, one typed failed experiment whose terminal evidence is visible before the correction cycle, and a second separately signed CandidatePlan that corrects the guest through a fresh HIL decision and P083 lease. In this evidenced profile, both plans are constructed by host-owned acceptance code and bound to retained solver turns; the report proves feedback and authority mechanics, not semantic derivation of either plan from model prose. Corpus still admits only inert turns; it neither parses model prose into an effect nor owns P083 authority.
[x] Persist the experiment execution join as append-only Corpus metadata over proposal, plan, flow node, Agent binding, P083 operation, request digest, source generation, receipt, and lease-release result. Restart converts an unfinished prepared or dispatched execution to unknown without retrying the effect. Exact terminal replay returns the retained receipt without another claim/invoke; unknown, refused, and concurrent dispatched attempts fail closed. Startup recovery drains bounded pages of 1,024 records up to a 16-page ceiling and refuses startup explicitly if work remains, rather than silently leaving an active execution. Current Room membership is rechecked before passage and execution, so author removal invalidates previously admitted effect authority.
[x] Preserve a replacement expensive Story 012 report proving the role-aware multi-cycle path with real Bielik runtimes and vfkit. The retained 2026-07-24 report passes the closed 17-check validator and Schema Gate and is the evidence for overlays, floor sequencing, terminal-feedback correction, HIL/P083 lifecycle, and the absence of effects derived directly from Room prose.
[x] Define and exercise the optional typed deliberation-to-effect handoff for Story 012 successors. Corpus may carry an inert inquirium.candidate-plan.v1 through a signed corpus-reasoning-experiment-proposal.v1 from the requester-selected local compiler, local Chair Agent, remote Chair Agent, or designated participant Agent. Node A must verify attribution and perform grant, review, budget, classification, generation, lease, and Sensorium admission. Room op, voice, Chair, and membership are not terminal authority. Admitted remote control uses P083 / Solution 046 Sensorium Interactive Interfaces claim/control/invoke rather than a Corpus-local transport. Absence of a local model is acceptable when a closed host compiler recognizes the proposal; free-form Room prose never becomes an effect. The implemented first vertical uses a requester-owned local Chair Agent: Node A verifies the solver-turn-bound proposal signature, retained Room turn, and exact mapping from the author's Room invite to the signing node, resolves distributor/operator/interface executor ceilings, digest-checks the plan artifact, compiles an entirely pending InquiryFlowV1, prepares a metadata-only passage over one fresh terminal latest-state snapshot, verifies the content-addressed Agent product under a closed propose|no-effect decision contract, and prevents no-effect from reaching claim or invoke. For propose, node A binds the exact flow node, interface pair, grant, generation, operational context, method, input schema, payload digest, classification, lease ceiling, and proposal expiry before requiring an admitted operator-question decision, and lets the P083 coordinator acquire and release the control lease only around invoke. Remote Chair, designated-participant, and deterministic compiler modes remain portable policy vocabulary, but daemon admission fails closed with executor_mode_not_implemented until their passage adapters are implemented and evidenced. The executable first slice is therefore exactly observe_only and local_agent. Every admitted effect reuses the ordinary Agent operator-question/finalize ceremony rather than a Corpus-specific approval path. A separate host-owned effect-node limit defaults to one per plan and is operator-configurable only up to the hard maximum of eight; a separate host-owned experiment-proposal limit defaults to two distinct proposals per round and is configurable only up to eight. Exact proposal and idempotency replays consume no additional slot. The independent 64-node CandidatePlan graph bound does not widen either HIL fan-out ceiling.
[x] Define the additive Story 012 critique-gated technical deliberation profile. It permits bounded shell, file, configuration, diagnostic, verification, and rollback fragments as inert Room evidence; orders each cycle as solver -> reviewer -> Chair; requires proposal, terminal-state, review, and reviewed-plan digest lineage; defaults Chair decisions to block; and preserves ordinary host admission, HIL, and P083 as the only effect path. The checked-in profile is structurally validated and is ready with retained real evidence.
[x] Freeze typed corpus-reasoning-experiment-review.v1 and corpus-reasoning-chair-experiment-decision.v1 contracts. A review must bind the exact experiment proposal, CandidatePlan, and fresh terminal-state digests and may accept, revise with a replacement plan, or reject. A Chair decision must bind that review and exact reviewed plan and may only block, request-revision, or admit-reviewed-candidate. Missing or conflicting lineage fails closed.
[x] Implement Agent-authored CandidatePlan publication and the critique-gated runner without a prose parser. Prove one unsafe technical proposal reaches a reviewer and is blocked by the Chair with no lease or effect; then prove an exact reviewed or revised plan crosses host admission, HIL, and P083. A host-created fixture merely attached to a solver turn cannot satisfy this gate.
[x] Add a closed 26-check report revision proving the technical proposal, reviewer verdict, Chair decision, exact admitted plan digest, terminal-feedback lineage, HIL, P083 lifecycle, and zero direct effects from Room prose.
[x] Retain a real vfkit/Bielik run that passes that closed report revision without the deadline-only deterministic fixture. The retained 2026-07-25 macOS arm64 report passes all 26 checks with two real Bielik runtimes, a failed experiment, reviewer revision, HIL, P083 release, and no direct Room-prose effect.
[x] Implement the additive model-authored PowerDNS discovery successor: remove the solution fixture from the guest and model-facing surfaces, compile closed process/file-write intents into content-addressed CandidatePlans, admit only an active-configuration-derived mutation scope, permit reviewer replacement through the same requester-owned policy, and retain full-plan, terminal-completion, effect-lineage, and provisioning-inventory evidence. The diagnostic ladder now provides pure contract tests, deterministic policy/review replay, a real-model stage bench, and an append-only calibration ledger before any vfkit proof run.
[x] Measure the pinned Bielik 4.5B Q8 planning boundary before deployment smoke. Five scoped zone-declaration samples yield two goal-ready plans after the host projection fix; five initial zone-data samples and five correction samples with fresh doubled-owner terminal evidence yield no goal-ready plan.
[x] Complete a bounded multi-attempt causal-correction projection for the model-authored discovery profile. The host must retain the exact source plans, while solver and reviewer receive only the last two or three admitted hypotheses, normalized process argv, historical file-write path/mode/line-count/content digest, bounded reviewer findings, Chair decision, effect receipt, verifier outcome, and terminal delta. Historical payload bytes and hidden reasoning must not cross this prompt boundary; configuration bytes subsequently observed by the host remain fresh evidence. The implemented capsule retains at most three exact lineages and is shared unchanged between solver and reviewer in one cycle.
[x] Add deterministic experiment-novelty admission above the models. The first closed policy fingerprints normalized effects and rejects an exact failed read-only experiment, or a subset of the same failed probes decorated only with service activation, in the single-writer guest profile. It emits a typed inert refusal, rechecks reviewer replacements through the same policy, and carries bounded failed-assumption, supporting-evidence, redundant-actions, and next-discriminating-test fields into signed findings and the next lineage. Deterministic replay proves that the original repeated proposal is redundant while a genuinely new reviewer replacement remains inert and admissible.
[x] Extend novelty admission to exact repeated failed mutations using an explicit digest of relevant preconditions: challenge, VM generation, effective admission scope, literal current configuration, normalized service state, and verifier result. The digest is computed only from the last complete nonce-marked, host-owned read-only snapshot in the cumulative PTY feed. Equal effect and equal digest are rejected; a changed or absent digest keeps the mutating effect novel. Every retained lineage participates in the novelty check, not only the latest attempt.
[x] Run a role-specific local-model matrix before choosing deployment defaults. Use at least ten samples per candidate for diagnostic discovery, backend configuration, zone declaration, zone data, and failed-plan correction. Keep the current Qwen2.5-Coder 7B quantization as the solver baseline; evaluate a runtime-conformant Qwen3.5 4B as a solver challenger and Qwen2.5-Coder 3B plus Phi-4-mini as reviewer candidates. Select solver and reviewer independently by domain pass rate, correction rate, contract-admission rate, and latency rather than generic benchmark rank. The bounded 2026-07-30 matrix ran 130 real-model samples. Qwen2.5-Coder 7B produced 26/50 goal-ready and 46/50 admitted plans, including 9/10 ready causal corrections, versus 2/50, 30/50, and 0/10 for Qwen3.5 4B; it remains the solver default. None of the three reviewer candidates is deployment-ready: Qwen2.5-Coder 3B, the existing Qwen2.5-Coder 7B baseline, and Phi-4 Mini reached 0/10, 1/10, and 2/10 contract admission respectively, and all reached 0/10 ready replacements. The host therefore records no reviewer deployment default rather than promoting the least-bad candidate.
[x] Compact each model turn into one bounded state capsule containing confirmed facts, refuted assumptions, next discriminating tests, three recent experiment outcomes, current terminal delta, and the effective admission scope. Process summaries carry canonical argv digests. The closed acceptance report persists bounded review analysis, the host-derived precondition digest, and both typed novelty decisions, but not raw precondition state or historical file bytes.
[x] Define and implement an additive critique-to-regeneration contract for role-separated deliberation. A reviewer may return bounded typed findings without synthesizing a replacement CandidatePlan; the solver then regenerates a candidate from those findings and the exact shared correction-state capsule, and a fresh review must bind the resulting plan digest before the Chair can select it. Preserve proposal, terminal-evidence, correction-state, and plan-digest lineage across the handoff, and reapply the existing novelty, policy, budget, and host-admission gates without granting authority to critique prose. The additive corpus-reasoning-experiment-review.v2 and corpus-reasoning-experiment-regeneration.v1 contracts now have positive and negative Schema Gate fixtures, signature-domain golden vectors, a durable daemon join and recovery projection, one requester-owned local API, live Story 012 baton integration, host-side current-role and effective-membership checks for exact implementer and reviewer assignments, and prompt-free deterministic replay. The original v1 reviewer-authored revise path remains valid for compatibility, but it is no longer the only implemented correction mechanism.
[x] P069-CLAIM-001 — Freeze an optional domain-neutral typed deliberation-review-claim envelope and profile seam. Profiles use this artifact only when their review or adjudication needs structured claims; it is not the universal grammar of Corpus deliberation or of corpus-reasoning-answer.v1. General prose outcomes, including ordinary code fragments in plain-text or markdown, do not require it. The envelope may close its structural shape but carries only opaque subject/ref, predicate/ref, object/ref, polarity, an opaque modality/ref, evidence refs, a profile-owned disposition ref, and an optional typed next move; bounded commentary is inert. Corpus and Agent do not acquire a built-in PowerDNS, software-review, scientific, social, or governance ontology. Each admitted deliberation profile owns its predicate/disposition vocabulary, reference validators, evidence-adjudication mode, and legal next-move combinations. An opaque profile/ref is not admission and does not acquire semantics merely by appearing in a valid envelope. Operators and communities may propose and publish namespaced, versioned profiles, and a federation may endorse one, but their machine interpretation requires the explicit additive admission, lifecycle, trust, and conformance seam tracked by P069-DOMAIN-005; each receiving host accepts or refuses an exact revision under local policy, and federation policy cannot compel admission. The set of vocabularies and problem classes is never closed globally. Profiles that select host facts may require an exact immutable catalog subset; future specialized scientific or social claim-adjudication profiles may instead admit schema-valid novel claims while preserving explicit evidence, epistemic status in modality/ref, disagreement, and an accountable downstream adjudicator. The first implementation target, implemented under P074-033, is the Story 012 PowerDNS catalog-select specialization; P074-033 remains partial while its explicit v2 compatibility path still adjudicates prose. Its 2026-08-31 physical-two-host-three-node diagnostic passage passed with four typed review envelopes, four model-authored experiments, no fallback, and exact DNS assertions. This proves the optional envelope/profile seam, not the still-open generic admission lifecycle. It does not claim that scientific or social vocabularies have already been designed or validated. Generative, literary, or helping profiles need not translate their work into truth claims at all; they may use an assistance-plan, critique, contribution-provenance, or creative-output contract instead. Additive domain profiles must not change the generic envelope or smuggle decision semantics back into commentary.
[ ] Establish a deployment-ready reviewer-to-solver correction rate before making critique-to-regeneration the default discovery path. The role-specific real-model bench must use at least ten pairs, one config digest, the exact staged host scope, a critique-only grammar, and a solver-only successor grammar. The 2026-08-01 run with the pinned Qwen2.5-Coder 7B artifact produced 10/10 valid regeneration requests and 10/10 fresh solver successors, but only 1/10 domain-ready staged zone-declaration plans; the measured 0.1 ready rate is below the explicit 0.6 deployment threshold. Keep the path opt-in and retain no reviewer deployment default until this task passes without weakening host admission or the oracle.
[ ] Derive time and token budgets from the append-only calibration distribution. Target at least four complete solver-reviewer-effect-feedback cycles per authority epoch; if measured p95 latency cannot fit under the canonical Room ceiling, renew authority between cycles instead of widening one grant, and continue to acquire a short P083 lease only after one concrete effect is approved. The completed matrix supplies a provisional model-only bound: selected-solver p95 73,375 ms plus the current profile reviewer's p95 58,725 ms gives 528,400 ms for four pairs and an observed maximum of 18,648 prompt-plus-completion tokens. A 25 percent rounded envelope is 720,000 ms and 24,576 tokens. This task remains open until a ready reviewer and the HIL, P083, terminal, and verifier latency distribution are included; the provisional envelope is not an authority grant. The retained 2026-08-23 deployment run now adds two complete effect-feedback cycles: four model turns consumed 15,863 prompt-plus-completion tokens and 344,259 ms of model time, while end-to-end deliberation consumed 369,053 ms. Its longest turn was 120,687 ms. These measurements confirm the current 330-second per-turn and 780-second deliberation bounds for the two-cycle acceptance path, but four such measured cycles do not fit safely under one canonical Room authority ceiling. The remaining work is therefore an explicit between-cycle authority-renewal path, not a wider individual grant.
[ ] Gate the expensive vfkit run behind the model bench and deterministic replay. Replay recorded model and terminal values through the complete novelty, review, Chair, HIL, and P083 policy path in seconds, then require repeatable seeded full-system success rather than one lucky completion. The retained report must expose prompt-free per-role latency, token, cycle, experiment, rejection, and correction measurements so future limits are derived from evidence. The first Qwen2.5-Coder deployment run now passes this closed report with those measurements. A second fresh unseeded full-system success exists; explicit fixed-seed repeatability remains open.
[x] Implement and evidence the resolved second guest-attested challenge, powerdns-bind-missing-zone-data.v1: valid loopback listener, BIND backend, and authoritative declaration referencing an absent zone-data file, with no final localdomain records in the image. Select its id and verifier contract ref/digest from pinned guest/image state, and keep the current single-variant report from claiming cross-variant generalization. The prepared-system manifest, exact source files, image completion record, and retained report bind the challenge and fixture digests; the verifier remains observation-only.
[x] Retain a passing closed story-012-powerdns-discovery-full-system-report.v1 from real vfkit, llama-server, and pinned model bytes. The run must reach the DNS goal through model-authored trial and error without the legacy fixture. Do not promote this post-MVP evidence until the stage bench demonstrates a plausible correction path. The retained 2026-08-23 macOS arm64 report passes all 31 checks with two separately supervised Qwen2.5-Coder 7B runtimes, the second prepared challenge, one nonpassing model-authored experiment, a distinct successful second plan after fresh terminal evidence, per-effect HIL, P083 claim -> invoke -> release, and no effect derived directly from Room prose. Host-owned shell framing is limited to a reported umask 022; the CandidatePlan bytes remain unchanged through admission and execution. Before deliberation, node A activates the exact P085 operator package and then consumes its four-passage Flow and package-owned turn-order producer. The report binds offer/policy/producer/decision lineage and proves post-restart stale-replay refusal, terminal revocation, and stale-authority refusal without a semantic fallback. The same run retains complete P086 recordings with zero gaps or drops for requester node A (564 observations), solver node B (19), and reviewer node C (22).

Phase 8D — Inference posture and realized provenance `[ ] partial`¶

2026-09-06 checkpoint: P090-008b/008c and P090-009a/b/c implement exact signed offer selection, inline procurement result carriage, durable Agent drafts, signed V2 publication and independent receiving-policy assessment. The scoped gate includes deterministic daemon restart, WSS/AD result delivery and exact replay without another invocation, admission or charge. General contribution joins, external descriptors and broader live/federated evidence remain outside this checkpoint; the complete items below are not closed by one text profile.

[ ] corpus-inference-posture-routing: consume the signed, open inference-execution-posture.v1 contract through Shared Offer Catalog filters; require assertion owner, exact subject/generation/scope, and processing-boundary ref; make unrelated-boundary, unknown, and withheld- provider policy explicit; retain corpus/model-class only as a compatibility projection; add no closed provider, domain-profile, or evidence-policy enumeration.
[ ] corpus-result-inference-provenance: validate every delivered inference-derived product against the selected offer posture and local buyer/Room policy, then preserve or conservatively join inference-execution-provenance.v1 through participant contributions, Agent answer drafts, signed answers, publication candidates, and settlement evidence. No known non-local/mixed fact may be dropped or downgraded, and provider redaction must not erase the non-local characteristic.
[ ] Add negative fixtures for a local-only declaration followed by non-local, mixed, unknown, missing, or provider-mismatched provenance, plus multi-parent and cache/replay cases. Acceptance must exercise both the procurement and live-deliberation paths without inferring locality from corpus/model-class, runtime names, or transport.

Phase 9 — N-way settlement¶

[ ] contribution-allocation.v1 (candidate separate proposal): contribution weights (from the answer), per-contributor receipts, dispute path.

Phase 10 — Hardening¶

[ ] Enforce budget/time-ms / budget/steps / budget/tokens and Inquirium caps.
[ ] Notifications (P057); abuse-model mitigations; observability without exposing ephemeral chat content.