Status & Retraction

Proposed Status Feed

The design reuses Chio's sparse-Merkle revocation oracle for credential revocation: a subject is a leaf key, an insert marks it revoked, and a signed epoch root lets a verifier check inclusion or absence without re-trusting the oracle's live process. A finding's status feed would be a second deployment of that oracle, keyed per finding instead of per credential, using RevocationKey, a subject id paired with a domain nonce:

struct RevocationKey {
    subject_id: SubjectId,   // finding_id, encoded as the oracle's leaf key
    epoch_nonce: String,     // domain separator, fixed per deployment
}

The feed pins one fixed nonce, epoch_nonce: "chio.finding.status.v1", so inserts and proofs use the same pairing. Two nonces for the same finding id would split one sparse tree into two partitions, letting a retraction filed under one nonce coexist with a fresh non-inclusion proof checked under the other, each valid in isolation while disagreeing about whether the finding remains valid. The fixed nonce prevents that split.

The feed's state publishes as chio.finding.status-epoch.v1, which MUST contain, or reference, the oracle's exact SignedEpochRoot, root and signature together:

{
  "schema": "chio.finding.status-epoch.v1",
  "finding_id": "finding-7f3a9c2e",
  "epoch_nonce": "chio.finding.status.v1",
  "signed_epoch_root": {
    "root": "b64:2f8ad1...",
    "signature": "b64:91cde7..."
  }
}

The signature checks the exact bytes signed by the oracle. A verifier can check those bytes offline with the oracle's public key.

Non-Inclusion Proofs: Local Today

A non-inclusion proof is how a buyer confirms a finding has not been retracted before paying. Two obligations follow: a buyer MUST pull a fresh proof at purchase time, and SHOULD subscribe to epoch-root updates afterward so a later retraction is not missed silently. Today's proof shape is NonInclusionProof:

struct NonInclusionProof {
    key: RevocationKey,
    epoch_root: EpochRoot,
    checked_at: Timestamp,
    // no Merkle path bytes: absence is read from the verifier's own
    // oracle state, not proven by bytes a third party can replay
}

Retraction, Governed Memory, and Invalidation

Ingestion sends a purchased finding through the governed-memory path. It binds the destination store and key to the purchase capability and delivery receipt, allowing an audit to trace the entry to its purchase.

Retraction does not change data already written to memory. An opt-in policy-selected guard rule can change what a later read returns. It extends MemoryGovernanceGuard can enforce a denial when a read's provenance traces to a retracted finding. It does not invalidate previously derived entries. Automatic invalidation is out of scope and requires a downstream process that uses the receipt trail.

Governance: One Adjudication Path

Retraction determines whether a finding remains valid. Responsibility for an incorrect finding is a governance question. Fabrication slashing, the bond forfeiture a seller faces when an audit or re-execution shows a finding was fabricated, funnels through the existing, enforced chio-governance sanction case. Cognition adds no adjudication authority, charter, or case kind. An audit result, re-execution digest, bond reference, and slash amount are checked mechanically. Human adjudicators decide matters those checks cannot resolve.

Pool-Level Purchasing at Swarm Scale

The proposed pool-level purchasing rule prevents members of a swarm from buying a finding another member has already purchased. This is a core purpose of the cognition market .

The proposed rule uses one buyer per pool. Each SwarmBudgetPool would transact through one purchasing principal. A sub-swarm planner aggregates reported failing contexts and deduplicates descriptor matches within the pool. Several reports of the same failure then become one purchase, reducing sibling_redundancy_bps and issuing at most one bid per descriptor from a dedicatedSwarmBudgetAllocation. This planner convention and allocation dimension require no kernel changes.

v1 does not aggregate demand across pools. Organizations pursuing the same failing context can therefore buy the same finding once per pool. Cross-organization aggregation remains future research because it combines combinatorial matching with public-goods funding.

Summary

1. Finding status oracle. A finding's status feed is a second deployment of Chio's revocation oracle, keyed per finding under one fixed domain nonce.
2. Signed epoch root. chio.finding.status-epoch.v1 contains or references the oracle's SignedEpochRoot.
3. Local check. NonInclusionProof answers for one verifier at one moment; buyers still need a fresh check at purchase time and a subscription afterward.
4. Retraction and reads. A policy-selected guard rule can deny reads that trace to a retracted finding; it does not rewrite what was already derived.
5. Governance and pooled purchasing. The proposed design routes fabrication slashing through a chio-governance sanction case and uses one bid per descriptor.

Next Steps

• Pricing, Bonds & Audits · the price ceiling, bond, and audit mechanics a status feed assumes
• Threat Model · the adversary model retraction and non-inclusion proofs answer to
• Governance Charters · the charter and case lifecycle fabrication slashing runs through
• Federation & Swarms · the shared budget pools pool-level purchasing spends from
• Trust Boundaries & Limits · why a local check is not yet the same trust boundary as a portable proof