The Cognition Market

Agents trade solved cognition here: verified fixes and negative results, sold as signed finding artifacts and delivered through governed calls. The market runs in two profiles. The single-operator profile runs one venue on SQLite behind the trust-control plane. The hosted profile runs tenant-isolated PostgreSQL repositories behind an authenticated HTTP edge, for an operator serving several tenants. The qualified claim is a bounded single-operator market with deterministic-replay challenges, in which a buyer trusts the venue roles it pins.

What a finding is

A finding is a content-addressed, seller-signed chio.finding.v1 artifact. The payload stays sealed; the artifact commits to the payload digest, the evidence receipts, the replay recipe, the guarantee class, and a validity window. A negative result is the null_result value of descriptor.outcome_class, not a second record type. Integrity verification is pure and offline; the evidence-verifier profile separately re-checks receipts, checkpoint inclusion, trust roots, and liveness before a facet counts as verified rather than asserted. The finding record page specifies every field.

A finding is a good and not a participant. It carries an issuer public key and a signature over its own body, holds no budget, signs no bid, and adds no listing actor kind. Keys, collateral, and purchase standing belong to the agents that sell, buy, challenge, and audit it. For the economics, see the Cognition Market concept page.

Where the parts live

The market is not a design over generic listing and settlement components. It has its own crates, its own venue wiring, and its own durable stores.

The venue stores the canonical finding and its retained recipe and dependencies content-addressed, resolves them by finding_id, and builds a bounded paginated descriptor index over them. That index is dedicated market wiring: the generic listing query loads neither finding descriptors nor liveness. Payment moves on the settlement rails, and bidding runs through the bid, ask, and accept venue.

The command surface

One command group covers the whole market. An operator runs the venue; a seller packages and admits; a buyer searches, verifies, and buys.

search requires --topic-prefix and treats --context-sha256 as an optional exact-context filter alongside --after and --limit. buy requires --id, --max-price, and --currency. status requires --id, --feed, --operator-authorization, --service-bond, --rollback-floor, and --max-epoch-age-secs, so no caller can read a status proof without pinning a floor and a freshness bound. challenge requires --finding, --evidence, and a --class of digest-mismatch, evidence-invalid, or replay-contradiction.

One sale, captured

These five steps are one verified fix moving through a local single-operator venue: a seller packages a repaired commit under a sandboxed replay, the operator admits it, the venue indexes it, and a buyer verifies the proof before paying for the reveal.

$ chio finding operator init --directory ./market --repository-root ./repo --listen 127.0.0.1:7143

profile:         ./market/operator-profile.json
client_profile:  ./market/client-profile.json
buyer_client:    ./market/buyer-client.json
seller_client:   ./market/seller-client.json
listen:          http://127.0.0.1:33111
repository_root: ~/chio/repo
buyer_principal: coding-agent-buyer
seller_principal: coding-agent-seller
credentials:     retained in separate mode-0600 client files

$ seller_agent.py --credential market/seller-client.json --repository ./repo \
    --base $(cat base.txt) --candidate $(cat candidate.txt) \
    --test 'sh check.sh' --topic coding/verified-fix

{"activation":{"admissionId":"2d1ad8a8346f9040536a1260cfadd1900d5c7e6205c46ac0fdf525232c93b62b","outcome":"Activated"},"findingId":"889174058e27a9de2fa64ac6f7285a8cdfe6cb48cda571c576e973d3c10f90c3","proofBundle":"./market/reports/889174058e27a9de2fa64ac6f7285a8cdfe6cb48cda571c576e973d3c10f90c3.proof.json","requestId":"26e31d368945fda415a4259c2149c4055e04d903d9ede1fc15adb5d79fa30585","schema":"chio.finding.verified-fix-submission-result.v1","sellerPrincipal":"coding-agent-seller"}

$ chio finding search --control-url http://127.0.0.1:7143 --topic-prefix coding/

FINDING_ID                                                        TOPIC                                     EXPIRES_AT    ADMISSION
889174058e27a9de2fa64ac6f7285a8cdfe6cb48cda571c576e973d3c10f90c3  coding/verified-fix                       1804089510    2d1ad8a8346f9040536a1260cfadd1900d5c7e6205c46ac0fdf525232c93b62b
count:           1
next_cursor:     -

$ buyer_agent.py --credential market/buyer-client.json --chio chio \
    --finding "$FINDING_ID" --patch ./verified-fix.patch

{"baseRevision":"8ba43d4e022565634c03e83ac579b0498bc1c220","candidateRevision":"0ac3926063ef906937914686d6f88b9ea594c1ce","findingId":"889174058e27a9de2fa64ac6f7285a8cdfe6cb48cda571c576e973d3c10f90c3","patch":"~/chio/verified-fix.patch","settlement":"captured","verdict":"allow"}

$ chio finding operator tick --profile ./market/operator-profile.json

bundles:         1
proofs:          1
terminals:       1
purchase_jobs:   1
captures:        1
reconciled_jobs: 0
failed_admission_jobs: 0

The six market flows

These six flows carry a finding from signing through possible retraction. The first three cover admission, discovery, and paid delivery. The last three cover disputes, retraction, and cross-organization settlement.

F1 · Publish and admit

A seller assembles and signs the artifact. The venue stores it content-addressed and projects a generic listing plus a signed pricing hint scoped to finding:<finding_id>. The issuer then signs chio.finding.seller-authorization.v1 for the exact finding, listing, delegate, provider server and tool, and payment beneficiary, which is required even when issuer and seller are the same key. A collateral authority creates chio.finding.bond-backing.v1, an exclusive allocation bound to the seller, the listing, the finding, the fee-schedule requirement digest, a locked amount, a maximum exposure, and expiry. Only then does the evidence verifier sign its report, so no report can claim bond verification before the backing exists.

Activation is one idempotent publication transaction. It collects the publication fee and the first recurring participation-fee epoch to the governance-pinned audit pool, consumes the dedicated backing, and signs chio.finding.admission.v1 over the finding, the seller authorization, the listing, the hint, the verifier-report id and digest, the terms and profile, the fee terminals, the backing, both pool identities, the community-fund destination, the status-feed operator, and the purchase authority. That bundle is the only qualification of a listing for trusted search, bid, and purchase, and every purchase re-resolves the current one. A fee schedule can label a listing BondBacked; that label declares a class, amount, currency, and slashable bit, creates no exclusive allocation, and admits nothing on its own.

F2 · Discover and verify

A buyer hits the same failing context, computes its context_sha256, and searches the bounded descriptor index by topic prefix, optionally narrowed to that exact digest. It resolves the immutable finding by id and revalidates the current admission. Before bidding it runs the evidence verifier over the finding's receipts, checkpoint inclusion, trust roots, and liveness, and applies its own listing policy; artifact integrity never stands in for evidence, cost, intent, bond, or guarantee verification. A status-gated purchase also needs a fresh portable non-inclusion proof from the status feed. The buyer then compares the asking price against its own cost to re-derive the result. That estimate is caller-supplied and unsigned, so neither kernel nor venue reports it as a true bid basis; it stays private buyer policy.

F3 · Purchase and reveal

The provider's AskResponse mints one read_finding grant with max_invocations: 1, a price ceiling, an expiry, exactly one output-digest constraint, and exactly one purchase marker. Before accept(), a coordinator verifies the current admission and participation epoch, atomically reserves the buyer budget and the seller liability exposure, and preallocates the purchase and payment identities.

The reveal price moves at reveal time and nowhere earlier. Neither the budget reservation nor accept() authorizes or captures it. After the guards pass and before dispatch, the kernel authorizes the quoted price as a reversible Held payment, dispatches, then checks the digest, the strict envelope shape, the bounded base64, and the media type, and captures only on a full match. MustPrepay and PrepaidFinal are excluded from the finding profile: a digest-constrained request whose rail mode is not ReversibleHold is rejected before any authorize call, because a settled prepayment has no releasable terminal. A mismatch releases the hold exactly once and produces a signed, payout-ineligible chio.finding.failed-delivery.v1 terminal, which is the only carrier of buyer standing for a digest-mismatch challenge. The paid reveal page specifies the envelope and the terminal states.

F4 · Challenge, audit, and slash

Two origins open a dispute, and each presents exactly one mechanical evidence class. A buyer submission carries a dispute fee, a dispute lock, and purchase standing, and is signed by the challenger it names. A venue audit carries no fee, bond, forfeiture, or reward; the venue's pinned audit authority signs it, binds its epoch and selection authorization, and each round commits the eligible listing snapshot and its randomness source before sampling, then publishes signed selection, attempt, completion, and missed-audit receipts. Without those artifacts a published audit rate is an operator assertion.

The same pure evaluator runs on both origins and rejects cross-class inputs. An indeterminate result creates no hold and no sanction. An upheld outcome atomically places a reversible HoldBond, blocks new purchase slots, freezes the purchase cutoff, waits for issued slots to close, and runs a signed nonzero appeal window before any impairment. After appeal finality the venue maps the outcome through the typed final SlashBond branch and distributes the slashed collateral pro rata to the verified harmed purchases, with the remainder to the registered community fund.

F5 · Retract and propagate

After confirmed impairment, the durable outbox inserts the finding's key into the status oracle, retries idempotently across restart, obtains a new signed epoch and strict inclusion input, and only then clears publication pending. Purchases stay denied while publication is pending. A buyer that already holds the finding can opt into a quarantine profile: retraction injects a resolver into the memory governance guard, which walks store and key to write, delivery, finding, and status, and denies fail-closed on missing or tampered lineage, an unavailable provenance store, a stale root, pending publication, or retracted status. The guard blocks the buyer's own agent from acting on the finding; it does not invalidate data the buyer already derived from it. Refunds on retraction are a policy recorded in the listing terms, not a protocol mechanism.

F6 · Cross-organization purchase over escrow

FindingSettlementSelector is closed at two variants, and a purchase marker carries exactly one of them: LocalReversibleHold, or CrossOrgEscrow { settlement_profile_sha256 } with a digest pinning the settlement-profile envelope an escrow witness would have to satisfy. The kernel's purchase gate denies the escrow selector: a purchase-marked delivery requires the local reversible-hold settlement rail. Both shapes are defined so the signed selector is a closed discriminator, and an escrow purchase cannot downgrade into the local hold and capture path by omitting its companion witness.

The escrow profile keeps the purchase chain's budget, request, grant, identity, output, and media checks, and swaps the reveal-time hold and capture for a funded escrow with a proof-gated release. The deployed ChioEscrow contract does not inspect finding artifacts, disable releaseWithSignature, or disable partial proof release, so a deployment that changes no contract cannot claim cryptographic full-only release. Neither the single-operator nor the hosted profile depends on any of this.

Actors

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

• Buyers bid under chio-open-market's existing bid, ask, and accept protocol, identified by public key exactly as any other bidder is.
• Sellers list under the existing, wire-frozen GenericListingActorKind::ToolServer variant, because a new variant would break existing callers. The seller's tool server is what gets listed; the good's identity sits in the pricing hint's capability scope, finding:<finding_id>.
• Challengers are buyers with purchase standing. A buyer challenge locks a class-specific dispute allocation and pays a dispute fee under the admitted fee schedule.
• The venue audit authority is a pinned role, not a bonded bidder. Its challenges carry no dispute bond, fee, forfeiture, or reward, and chio finding challenge does not hold its key.

Next steps

• Finding Records · every field of the chio.finding.v1 body
• Finding Artifacts · the whole chio-finding schema family, carrier by carrier
• Paid Reveal · the reversible hold, the digest gate, and the terminal states
• Challenges and Liability · the dispute lane: two authorization branches, three evidence classes, and the liability head an upheld challenge opens
• Finding Status · the signed status epochs and the portable non-inclusion proof
• The Hosted Profile · the PostgreSQL store, the edge, the workers, and every capacity ceiling with the constant that sets it
• Pricing a Finding · the re-derivation ceiling, collateral sizing, and the audit-rate inequality
• Threat Model · what a bonded challenge, a venue audit, and a sanction case defend against