The Cognition Market

What a Finding Is

A finding is a signed Finding record with schema chio.finding.v1, recording a verified fix or a negative null_result, signed so the market can verify its source and contents. The record supplies the identifier, price, and ownership information needed for listing, bidding, challenges, and retraction.

{
  "schema": "chio.finding.v1",
  "outcome_class": "null_result"
}

This design delivers a finding through a governed call. Payment and a digest match are required before the content is delivered. For the economic rationale, see the Cognition Market concept page; this page describes the proposed workflow.

Implementation Status and Dependencies

This page describes a proposed market feature. It reuses the listed components where they are available and adds the proposedchio-finding crate.

In the proposed workflow, a finding publishes through chio-listing. Purchases use the chio-open-market bid/ask/accept venue, including its bonds and penalties. Payment uses the settlement components: ChioEscrow and MustPrepay. Every reveal, challenge, and retraction closes with a signed receipt in the log's Merkle checkpoints.

The proposed chio-finding crate contains Finding types and pure validators. The design does not introduce a settlement component, escrow contract, auction engine, or finding-content store. The following flows compose the components linked above.

Proposed Market Flows

These six flows describe a finding from signing through possible retraction. The first three cover purchase and delivery; the others cover disputes, retraction, and cross-organization settlement.

F1 · Publish and Admit

A seller signs a Finding and publishes it like any tool server publishes a capability: a chio-listing entry plus a pricing hint. Listing is bond-backed trust activation, not automatic admission: the seller's bond must clear the BondBacked admission class first, the same activation gate any other listing clears.

F2 · Discover and Verify

A buyer searches by context_sha256, the hash pinning the exact problem context a finding claims to resolve. Before bidding it verifies the finding's evidence offline, pulls a fresh non-inclusion check against the status feed (confirmation the finding has not already been retracted), and computes the elicitation/re-derivation ceiling: its own cost to re-derive the same conclusion, or elicit an equivalent answer some other way, the number a rational buyer refuses to pay above.

F3 · Purchase and Reveal

Buyer and seller clear a bid/ask/accept round through chio-open-market, opening a MustPrepay hold before the reveal capability is ever minted, so no ordering exists where a buyer holds content unfunded. The buyer calls read_finding to trigger delivery. The kernel's Constraint::OutputDigestSha256 binding checks the reveal against the agreed digest before delivery. The call produces a signed delivery receipt. The buyer then ingests the finding through a governed memory path. This document specifies the single-operator flow first; the other flows extend it.

F4 · Challenge, Audit, and Slash

A finding sold on a false claim is contestable two ways: a bonded challenge from any agent that disputes it, or a venue audit the market runs on its own published schedule. Either path runs the same pure evaluator against the finding's evidence. A finding that fails opens an enforced Sanction case and executes a SlashBond against the seller's posted bond.

F5 · Retract and Propagate

A seller, or a challenge that succeeds, can retract a sold finding. Retraction publishes into the market's status feed and folds into a new epoch root at the next checkpoint, the same propagation path any other revoked capability follows. A buyer who already holds the finding can opt into a quarantine guard that blocks their own agent from acting on it the moment its status flips to retracted.

F6 · Cross-Org Purchase over Escrow

Buyer and seller in different organizations run F3 again with one swap: the MustPrepay hold becomes a ChioEscrow lock, and release rides a Merkle-proof against the settled receipt root instead of a same-operator capture. The trade requires a neutral, or at least mutually-trusted, mediator; without one, it does not clear.

Actors

Each market participant is an agent subject identified by a public key. The market adds a type of good; it does not add a participant type.

• Buyers are bidders under chio-open-market's existing bid/ask/accept protocol, identified by public key exactly as any other bidder is today.
• No new listing subject kind. A finding lists under the existing, wire-frozen GenericListingActorKind::ToolServer because a new variant would break existing callers. The good's identity is in the pricing hint's capability scope: finding:<finding_id>.
• Challengers and auditors are bonded agent subjects too. Disputing a finding or running a venue audit costs a bond under the same fee schedule used for other open-market actions.

Scope and Rollout

The proposed market adds a signed information-good type and digest-checked delivery. It does not change the existing settlement or auction components. The planned rollout begins with coding-agent verified fixes, which have comparatively low verification and pricing cost. It can later extend to null_result findings after F3 is implemented and evaluated.

Next Steps

• Cognition Market (concept) · the design problem and Arrow's information paradox
• Finding Records · the chio.finding.v1 schema and its guarantee classes in full
• Reveal & Settlement · the MustPrepay hold, read_finding, and the digest gate, in depth
• The Open Market · the bid/ask/accept venue, fee schedules, and bond operations used by this market
• Pricing, Bonds & Audits · the re-derivation ceiling, bond sizing, and the audit-rate inequality
• Threat Model · what a bonded challenge, a venue audit, and a Sanction case defend against