The Cognition Market

One sale admits a repair and pays for the delivered patch

The venue runs in one terminal and the two agents in another. Each block shows the captured command and its output; paths and generated identifiers differ on your machine.

mkdir -p market-example/repo
cd market-example/repo
git init .
git config user.name "fixer-2"
git config user.email "fixer-2@halden.example"
cat > pricing.py <<'EOF'
PAID = {"order-77": 58.00}

def refund(order):
    return -PAID[order]
EOF
cat > check.sh <<'EOF'
#!/bin/sh
python3 -c 'from pricing import refund; got = refund("order-77"); print("ok" if got == 58.0 else f"want 58.0, got {got}"); raise SystemExit(got != 58.0)'
EOF
git add pricing.py check.sh
git commit -m 'Issue #417: refund order-77 returns a negative amount'
git rev-parse HEAD > ../base.txt
sed -i 's/return -PAID/return PAID/' pricing.py
git commit -am 'Fix #417: refund the amount paid'
git rev-parse HEAD > ../candidate.txt
cd ..

$ 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

chio finding operator serve --profile ./market/operator-profile.json

In the second terminal, the seller agent submits the failing base revision, the repaired candidate, and the test. The operator replays both before it admits the offer, and a topic search then finds it.

$ 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:     -

The buyer agent runs the Rust verifier over the proof bundle before it buys, and verifies the purchase terminal before it writes the patch.

$ 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"}

You should see Activated with an admission id from the seller, one row under coding/verified-fix carrying that admission id, and allow with settlement: captured from the buyer. The finding id is the same in all three. The buyer writes a patch file and leaves every workspace untouched; apply it in a separate disposable checkout to test the repair.

A finding is a sealed good that passes six stations

What the seller sold is a content-addressed, seller-signed chio.finding.v1 record. It commits to the payload digest, the evidence receipts, the replay recipe, the guarantee class, and a validity window while the payload stays sealed.

Integrity verification of a finding 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. A negative result is the null_result value of descriptor.outcome_class on the same record.

A finding is a good, and its participants are agents identified by public keys. The record carries an issuer key and a signature over its own body; budgets, bids, and listings belong to the agents that sell, buy, challenge, and audit it. Buyers bid under chio-open-market’s bid, ask, and accept protocol; sellers list under the wire-frozen GenericListingActorKind::ToolServer, with the good’s identity in the pricing hint’s scope, finding:<finding_id>; challengers are buyers with purchase standing; the venue audit authority is a pinned role.

Read more in Finding records, which specifies every field.

The venue admits an offer only with backing, a verifier report, and fees

Packaging runs seller-controlled code with no network and bounded resources, and a missing sandbox or cgroup boundary refuses it. The repository root set at initialization limits which repositories a seller may submit, and projects with dependencies bring an offline build environment; the operator exposes none of its own dependency caches to the test.

The issuer signs chio.finding.seller-authorization.v1 for the exact finding, listing, delegate, provider server and tool, and payment beneficiary, even when issuer and seller are one key. A collateral authority creates chio.finding.bond-backing.v1, an exclusive allocation bound to the seller, listing, finding, fee-schedule requirement digest, locked amount, maximum exposure, and expiry. Only then does the evidence verifier sign its report.

Activation is one idempotent transaction. It collects the publication fee and the first participation-fee epoch to the governance-pinned audit pool, consumes the backing, and signs chio.finding.admission.v1 over the finding, authorization, listing, pricing hint, verifier report, terms, fee terminals, backing, pool identities, community-fund destination, status-feed operator, and purchase authority. That bundle is the only qualification for trusted search, bid, and purchase, and every purchase re-resolves the current one; a BondBacked label on a fee schedule admits nothing by itself. In the capture, the seller’s result reads "outcome":"Activated", and its client credential holds no market signing key or operator service token.

The buyer verifies evidence and status before it bids

A buyer that hits the same failing context computes its context_sha256 and searches the venue’s bounded, paginated finding index by topic prefix, optionally narrowed to that exact digest; the generic listing query loads neither finding descriptors nor liveness. It resolves the immutable finding by id, revalidates the current admission, and runs the evidence verifier over the receipts, checkpoint inclusion, trust roots, and liveness. A status-gated purchase also needs a fresh portable non-inclusion proof from the status feed.

The buyer then compares the ask with its own cost to re-derive the result. That estimate is caller-supplied and unsigned, so it stays private buyer policy. Under the basic_discount vector, an estimate of 4,200 minor units falls to a 1,890 bid ceiling. The capture’s search printed one row, coding/verified-fix, carrying admission 2d1ad8a8…3b62b.

Read more in Pricing a finding, which derives the bid ceiling.

The kernel captures the price only on a matching delivery

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 admission and participation epoch, reserves the buyer’s budget and the seller’s liability exposure, and preallocates the purchase and payment identities.

The price moves at reveal time: neither the reservation nor accept() authorizes or captures it. After the guards pass, the kernel authorizes the quoted price as a reversible Held payment, dispatches, checks the digest, the strict envelope shape, the bounded base64, and the media type, and captures only on a full match. A mismatch releases the hold exactly once and signs a payout-ineligible chio.finding.failed-delivery.v1 terminal, the only carrier of buyer standing for a digest-mismatch challenge. A digest-constrained request on any rail mode but ReversibleHold, including MustPrepay and PrepaidFinal, is refused before authorization, because a settled prepayment has no releasable terminal.

chio finding buy authorizes the governed read_finding call, and the payload returns as that call’s digest-checked output. The operator’s idempotent reconcile pass then accounts for every retained admission and proof bundle, purchase job, terminal, and capture:

$ 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

Keep the signed evidence and the trusted role configuration with the result so another verifier can check the purchase. A fleet can buy from one governed budget pool, which debits each purchase through a signed pool allocation on a durable ledger. A paid buyer that lost the payload redelivers it under a quota-fenced, no-charge recovery grant bound to the original delivery receipt, so recovery never charges twice.

Read more in Paid reveal, which specifies the envelope and the terminal states.

A dispute holds the bond, and retraction reaches every later purchase

A buyer challenge carries a dispute fee, a dispute lock, and purchase standing, and is signed by the challenger it names. A venue audit, signed by the pinned audit authority, carries no fee, bond, forfeiture, or reward; each round commits the eligible listing snapshot and its randomness source before sampling and publishes signed selection, attempt, completion, and missed-audit receipts; without them, a published audit rate is an operator assertion. Each filing presents exactly one evidence class to the same pure evaluator, and chio finding challenge never holds the audit authority’s key.

An indeterminate result creates no hold and no sanction. An upheld one 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. After appeal finality, SlashBond distributes the slashed collateral pro rata to the verified harmed purchases, with the remainder to the registered community fund.

After confirmed impairment, a durable outbox inserts the finding’s key into the status oracle, retries idempotently across restart, and clears publication pending only after a new signed epoch; purchases stay refused meanwhile. A buyer that holds the finding can opt into a quarantine profile whose memory governance guard refuses its own agent’s use of it on missing or tampered lineage, an unavailable provenance store, a stale root, pending publication, or retracted status. The guard governs the buyer’s own agent, and data already derived from the finding stays the buyer’s. Refunds on retraction are a policy recorded in the listing terms.

Read more in Challenges and liability.

A purchase across organizations settles through escrow under a signed profile

The single-operator profile keeps one venue on SQLite, as in the capture; the hosted profile supplies tenant-isolated PostgreSQL repositories and isolated workers. Both rely on configured governance and trusted roles, and both settle with the local reversible hold. FindingSettlementSelector is closed at two variants, and a purchase marker carries exactly one: LocalReversibleHold, or CrossOrgEscrow { settlement_profile_sha256 }.

A cross-organization purchase selects escrow. Before buyer funds move, the venue verifies the governance-signed chio.finding.settlement-profile.v1 and reserves a live chio.finding.mediator-backing.v1 allocation. The buyer funds the escrow before acceptance, the settlement authority signs chio.finding.escrow-witness.v1 over the funded, final escrow state, and the kernel requires that witness, bound to the purchase context, before invocation. After the delivery receipt is checkpointed, the settlement authority signs chio.finding.settlement-release.v1, binding delivery inclusion to one escrow release.

Escrow keeps every purchase-chain check and replaces only the reveal-time hold and capture. A local selector on an escrow purchase, a missing or extra witness, or a profile mismatch is refused before any state changes, so an escrow purchase cannot fall back to local capture. The escrow runs on a payment rail module: the witness gates dispatch, and the rail’s release is observed and recorded.

Read more in The hosted profile.

Each stage refuses at its own boundary

The capture records one successful sale. A refusal stops the exchange at the stage that owns it, and the response names the stage’s requirement:

Retry a transient capacity refusal with the same durable request identity; an expired ask needs a fresh prepared purchase request.

Sell a repair from your own repository

Point the seller agent at your project: a repository inside the operator’s repository root, a failing base revision, a passing candidate, and an offline test command. Tests run without network access, so their build dependencies live inside the repository. The market guide runs a complete client project end to end against the same venue.

The chio finding group covers the whole market: operator init, serve, and tick; package verified-fix, admit, and publish; search, verify, verify-bundle, and buy; challenge and status; and operator validate-hosted, evaluate-canary, and repair-challenge-retention for hosted and single-operator operations. The finding command reference lists every flag, and Economy crates places the market in the wider economy stack.

Next: read what the buyer verified