Chio/Docs
LOGIN · JOIN

Build a cognition marketplace

Generate a repair, have a venue replay it, purchase verified work within a bid, and apply the patch to a separate customer project.

Guide chio@5f63e6e

On this page

A repair marketplace sells an outcome the buyer can check. This application starts from a failing project; a seller supplies or generates a candidate, the native Chio operator replays its tests inside Linux isolation, and the Python SDK verifies the venue proof before it purchases the patch, which a separate customer checkout applies and tests.

Run the purchase

A replayed repair is purchased and passes the customer’s own tests

Build it. Run it. Inspect it.

Acquire a repair that the venue has replayed

A seller produces a patch, a native Chio venue verifies it, and a buyer applies the purchased delivery to a separate broken project.

Download project
Your inputs

Hosted records are retained for seven days. Use the downloaded project for local work and your own model credentials.

Loading the verified example result…

Start with the supplied offer to follow the full purchase path, or select model mode for a newly generated seller repair. Set the maximum bid below the asking price to get an actionable refusal, then raise it to purchase. The result shows the failing customer baseline, the delivered diff, the passing customer tests, and the retained purchase terminal.

The venue replays the work and the buyer checks the proof and the outcome

Seller, venue, and buyer each act on the candidate once. The venue’s replay and signed proof come before the purchase, and the customer copy’s tests come after it.

Cognition marketplaceChoose a lens.
Isolated venueproposesreplaydeliversappliessigned proofcheckedterminalbidpurchasebelow the aska₁Sellerfactory workercCandidateKVenueρPurchase recordσProof checka₂BuyerBMaximum biddCustomer copysame testsIsolated venuebelow the aska₁SellercCandidateKVenueρRecordσProofa₂BuyerBBiddCustomer copy

The purchase stays within the bid

The buyer makes a bounded purchase request. A maximum bid below the asking price is refused with the required correction and no patch is delivered; repeating the same purchase recovers the existing request and terminal result. Verify proof and purchase within the bid.

The cognition marketplace application: seller, isolated venue, buyer, and the customer copy that receives the patch. The local work credits that record the purchase stand in for an optional payment rail, which is left out.

The software factory is the seller

The model seller runs the same governed repository application as the software factory chapter, and its output becomes a candidate Git revision. The marketplace treats a model’s claim that a patch works as a claim to test: it submits the repository, base, candidate, and explicit test command for replay.

cognition-marketplace/src/lib.rsL45–59rust
        let seller_input = json!({"issue":input["issue"],"mode":if mode=="model" {"model"}else{"deterministic"},"exercise_denials":true});
        let seller_run = Run::create(&root.join("seller-runs"), Factory.name(), &seller_input)?;
        let repair = Factory.execute(seller_input, seller_run.clone()).await;
        seller_run.finish(&repair)?;
        let repair = repair?;
        anyhow::ensure!(
            repair["tests"]["passed"] == true,
            "Seller has no passing candidate to offer"
        );
        run.emit(
            "market.seller",
            "seller",
            "Produced and tested the candidate using the factory",
            seller_run.snapshot()?,
        )?;

Open this excerpt in the complete source

In the verified run, event 01 records the seller producing and testing the candidate with the factory.

The venue replays the candidate before admitting it

The seller SDK packages the proposed fix and asks the native operator to admit it. The operator checks the supplied failure and candidate under its required namespace and cgroup profile and refuses an unchanged or non-fixing candidate. The seller’s project and the venue workspace stay separate from the customer copy.

cognition-marketplace/client.pyL26–40python
    if config["action"] in {"offer", "nonfix"}:
        async with CognitionMarketSeller(venue / "seller-client.json") as seller:
            try:
                package = await seller.package_verified_fix(
                    repository=config["repository"], base=config["base"], candidate=config["candidate"],
                    tests=["python3 -m unittest -v test_analysis"], topic="coding/sliding-window-analysis", price=config["price"],
                )
                admitted = await seller.admit(package)
            except CognitionMarketError as error:
                if config["action"] == "nonfix":
                    return {"refused": True, "reason": str(error)}
                raise
            if config["action"] == "nonfix":
                raise RuntimeError("A non-fixing candidate was admitted")
        return {"offer": admitted}

Open this excerpt in the complete source

Event 02 records the isolated venue replaying the failure and the candidate, with admission outcome Activated.

The buyer checks the proof and purchases within the bid

The buyer runs the Rust proof verifier through the Python SDK, then makes a bounded purchase request. The example repeats that request and compares the retained terminal, so a repeated response is recognized as the same purchase. Tamper checks alter signed evidence, so the refusal exercises verification itself.

cognition-marketplace/client.pyL41–67python
    async with CognitionMarketBuyer(venue / "buyer-client.json", chio_binary=Path(config["chio"])) as buyer:
        proof = await buyer.verified_proof(config["finding_id"])
        if config["action"] == "tamper":
            altered = json.loads(proof.proof)
            # Alter signed evidence, preserving JSON readability.
            altered["bundle"]["finding"]["payload_sha256"] = "0" * 64
            try:
                await buyer.verify_proof(json.dumps(altered).encode())
            except CognitionMarketError as error:
                return {"refused": True, "reason": str(error)}
            raise RuntimeError("Changed proof was accepted")
        before = purchase_state(venue)
        try:
            purchased = await buyer.purchase_verified_fix(proof, max_price_units=config["max_price"])
        except CognitionMarketError as error:
            after = purchase_state(venue)
            if before != after:
                raise RuntimeError("Refused purchase advanced venue purchase state") from error
            return {"status": "refused", "reason": str(error), "purchase_state_unchanged": True, "purchase_state": after}
        repeated = await buyer.purchase_verified_fix(proof, max_price_units=config["max_price"])
        if repeated.request != purchased.request or repeated.purchase != purchased.purchase:
            raise RuntimeError("Repeated purchase did not recover the same terminal result")
        Path(config["patch"]).write_text(purchased.patch, encoding="utf-8")
        return {"status": "delivered", "finding_id": purchased.finding_id,
                "base_revision": purchased.base_revision, "candidate_revision": purchased.candidate_revision,
                "patch": purchased.patch, "request": purchased.request, "purchase": purchased.purchase,
                "repeated_purchase": "same request and retained terminal; no second purchase"}

Open this excerpt in the complete source

The customer’s tests decide whether the work was useful

A fresh customer repository starts with the failing implementation. The application applies only the delivered patch, runs the immutable tests, and retains the before-and-after result. This check establishes what the buyer received, independently of the venue’s own statement about the seller’s candidate.

cognition-marketplace/src/lib.rsL207–245rust
        let customer = Repository::create(&root.join("customer"))?;
        git(&customer.directory, &["init", "--initial-branch=customer"]).await?;
        let before = customer.test(true).await?;
        anyhow::ensure!(
            before["passed"] == false,
            "Customer copy did not reproduce the defect"
        );
        let patch = root.join("purchased.patch");
        git(
            &customer.directory,
            &[
                "apply",
                "--check",
                patch.to_str().context("Invalid patch path")?,
            ],
        )
        .await?;
        git(
            &customer.directory,
            &["apply", patch.to_str().context("Invalid patch path")?],
        )
        .await?;
        let after = customer.test(false).await?;
        run.emit(
            "market.customer-tested",
            "customer",
            "Test the purchased delivery in the customer repository",
            json!({"before":before,"after":after}),
        )?;
        anyhow::ensure!(
            after["passed"] == true,
            "Delivered patch did not repair the separate customer project"
        );
        run.emit(
            "market.repaired",
            "customer",
            "The purchased patch repairs a separate customer copy",
            json!({"before":before,"after":after,"finding_id":finding}),
        )?;

Open this excerpt in the complete source

Events 03 and 04 record the customer copy passing its focused tests after the purchased patch.

A non-fixing candidate, altered proof, and a low bid deliver nothing

The verified run is the successful purchase; the refusals below are exercised by the downloadable tests and by the bid field in the form.

Terminalbash
./run --run input.json
Retained events, captures/verified.json
01  market.seller             seller
    Produced and tested the candidate using the factory
02  market.admitted           venue
    The isolated venue replayed the failure and candidate
03  market.customer-tested    customer
    Test the purchased delivery in the customer repository
04  market.repaired           customer
    The purchased patch repairs a separate customer copy
  • Submit a non-fixing candidate: the venue refuses admission.
  • Alter signed proof evidence: verification fails before purchase.
  • Bid below the quoted price: no patch is delivered and the refusal names the required correction.
  • Repeat the same purchase: the existing request and terminal result are recovered.

The downloadable tests assert each effect or its absence: run cargo test --locked -p chio-cognition-marketplace from the extracted project.

Run the marketplace on your machine

Keep the run directory to inspect the offered candidate, the verified proof, the purchased patch, and the retained purchase result.

From the extracted projectbash
cd chio-cognition-marketplace
./run

The archive holds the application, the shared host code, tests, sample input, pinned dependencies, and a README. The launcher builds and runs the Rust source included in this archive. Install Rust 1.94.1 and the README’s native prerequisites; filesystem isolation and operator workloads require the listed Linux host profile. Cargo resolves immutable public dependencies, so a sibling checkout is unnecessary.

For model workers, set OPENROUTER_API_KEY on the local host and select model mode; credentials stay on that host and never enter the docs form. The qualified model is openai/gpt-4.1-mini. Analysis, retrieval, and deterministic worker modes run without a model key. Ctrl-C stops the local web process and its active child work and keeps the run directory.

Download identity and source revision

Download complete project · View public source

Project archive SHA-256text
68fa550681e8eac971b486f2ced09f500c943dae68bb1455a9dc9161d9a8a177

Sell a fix for your own failing test

Replace the sample defect with your own focused failure and tests. Keep the operator’s Linux isolation in the execution path and the buyer’s final check independent. Local credits record market accounting, and a payment rail plugs in as an optional module. The downloadable operator profile documents its cgroup and namespace requirements.

Next: build a software factory