The Coordination Contract

§ 1

The four parts

The coordination contract is the institution that CommandAGI runs on. It has four parts and no others:

• Kernel: fixed text, pinned by hash.
• Law: changes only by an adopted RFC.
• Engine: the pinned models that the contract decides through. It changes only by an adopted RFC.
• Ledger: accounts, holdings, agreements, cases, facilities, determinations.

There are no offices, branches, executives, juries or human adjudicators. The contract acts only through determinations. A determination is a closed question over one committed record. The contract puts it to the engine tier by tier and records every seat's answer. A determination has one of three outcomes:

• decided: a unique label at the tier's confidence;
• unresolved: the top tier tied or was unsure;
• unavailable: no tier could seat a panel that answered.

Each use says what unresolved means for it (for example, a claimant's burden, or the status quo). Label order never makes a label win.

§ 2

The kernel

The kernel has 12 articles (kernel.ts; current hash above). History: v0.4.1 changed the text, so it is a different contract from v0.4's 9af475d6…. Nothing had happened under v0.4 (no RFC, no case). Migration 0541 withdraws that genesis only under exactly that condition.

The code enforces the numbers in KERNEL_FLOORS (now including minTopTierPanels: 2 and minRenderers: 2).

§ 3

People

A person is an entity of a kind that the law recognizes, holding a valid proof for that kind.

• Humans prove it with the identity verification on their account. Stripe Identity reports the verified first name, family name and birth date. It reports the birth date only to the restricted STRIPE_IDENTITY_KEY. The contract derives the voice key under the never-rotated PERSONHOOD_KEY (personhood-key.ts). Every issuer of human personhood shares that namespace.
• Other kinds prove it with a proof signed by an issuer that the law names (ed25519:<key>, POST /public/contract/personhood). Only a key can issue a kind: a law that names an issuer by name alone (no ed25519: key) admits no proof for that kind, and every submission fails closed with issuer_cannot_sign.

The contract's side of the second bullet is exercised for a non-human kind (routes/contract.test.ts, "a kind the law names is proven by its issuer's signature"). A generated ed25519 key is the issuer of a law-written kind agent, whose uniqueness rule is lineage. The route records the signed proof, and the entity answers an RFC under agent:<lineage key>. A copy of the lineage is a person with the same key and cannot answer, because one lineage holds one voice. The route refuses a human proof (the account is a human's door), an issuer the law does not name, a signature lifted onto another uniqueness key, and a replayed older issuance. A revocation stays a tombstone, and a later issuance restores the voice. No such issuer runs yet: no law names one, and a person opens the law RFC that does. The platform's agent index (docs/agents.md) records a lineage, but an issuer of personhood must sit outside the platform, as the attestors must, or it puts the platform back in the trust path. Because POST /contract/anonymity/commitment needs a named principal (the person or an agent key, never a program's token; owner decision 2026-10-31), each commitment is recorded with the principal that made it.

A human's verification is a personhood statement like any other kind's, so it joins the transparency log. The act is keyed by a digest of the voice key: the log stores only digests and names neither the person nor the account. The holder of the key can recompute the digest and find their own statement. A re-verification that keeps the key adds no second entry.

An issuer's statements apply in issuedAt order. A revocation stays as a tombstone, and the contract refuses a replayed older issuance as stale. The earliest valid proof holds a key's voice. Name and birthday are an imperfect proxy: collisions, changed names and transliterations prevent any claim of proven unique personhood. A re-verification cannot overwrite an established key.

Correction works through POST /public/contract/personhood/resolve. It accepts a domain-separated, signed IdentityResolution from an ed25519 human issuer that the law admits. It also needs a final, executed correction judgment for that person's voice interest. The route atomically records the signed resolution in the private case and changes the key, only between open RFC windows. RFC opening checks the resolution epoch, so a race cannot pin the old identity tree. The unused commitments of the replaced key are withdrawn. The signature binds the entity, the previous and resolved keys, the judgment, the issuer and the issue time, so a replay cannot apply twice.

No such human resolution issuer is configured at genesis. The issuer must substantiate identity continuity or distinctness; a model's assertion alone does not do so. A continuing sequence of open RFCs can delay corrections.

§ 4

RFCs: how the law and the engine change

1. Opening. Anyone opens an RFC that changes law or the engine. It has distinct options and a refundable deposit (rfcDepositCents). The contract refuses options that produce the same resulting law, including reordered independent changes. The RFC pins what it began under: the contract version, the engine that will interpret and concur, the kinds of people who may respond, and the state that its options were drafted against.
2. Responses and receipts. A response (text, images or audio that the law admits) gets a receipt: its id and digest. The response counts only when the respondent confirms that digest. A later confirmed response replaces an earlier one until close. A person in the RFC's pinned anonymity set responds anonymously instead (§ anonymous voice); the proof over the digest is the confirmation.
3. Interpretation. After close, the contract renders media and interprets each response per option. It reads the option's actual changes, not only its summary. The result is a score from −2 to +2 (0 for neutral, not addressed, unresolved or unprocessable). The contract shows each interpretation to its respondent (a notice). The respondent can contest it for extractionContestMs from when it became available. A contest re-runs the interpretation at the top tier on groups that took no part.
4. Tally. The scores are descriptive (binding only for binding_score). An option's score is the sum of every voice's score for it, independent of the other options. So adding, duplicating or reordering options moves no other option's score. A change is favored when its score is positive and uniquely highest. The tally is public after interpretation, with its histogram and a record digest.
5. Deliberation and concurrence. Under deliberative, rfc.deliberate chooses an option or the status quo. It uses the substantive merits, the strongest objections, the number of respondents, unprocessed comments and the limits of representativeness. Self-selected comments are not a population sample, one comment represents its author, and silence is not consent. A change may be justified despite its score or with no comments. The contract publishes the determination and its seat reasons; the decision records its id and the participation limitations. Under binding_score, only the favored option is eligible. In either procedure, the pinned engine reads the whole tally and a seeded sample of responses with their interpretations (rfcConcurrenceSample; anyone who recomputes it gets the same sample). The engine answers concur or withhold. The contract classifies a withholding's ground separately, for the record. Only a decided concur counts.
6. Engine RFCs. The contract asks the proposed engine only after the outgoing one concurs. It asks through a candidate executor that renders no media and reads no private record. If the outgoing engine cannot seat a panel for a further window as long as the RFC's own, the proposed engine's concurrence suffices.
7. Adoption. The decision, the deposit and the new contract version commit in one batch. The batch claims the RFC's revision and the contract version that was read. If the RFC's base state changed meanwhile, the RFC is not adopted (adopt.superseded): its voice was given on a contract that no longer exists. An on-chain adoption binds the decision's hash (decisionHash).

§ 5

The engine

• A seat moves by RFC; once, before mainnet, by the owner. After mainnet, a seat moves only by an engine RFC (§ RFCs). The contract is not yet live on mainnet, so on 2026-10-13 the owner decided a direct edit of genesis.ts without an RFC: DashScope answers qwen3-max with 404 model_not_found, and the seat moved to qwen3.8-max (same operator, same lineage, so the groups and the panel rules do not change). Every other seat answered a live call that day (docs/verification.md, 2026-10-13). The new seat's error and climb are qwen3-max's evaluated figures, held as a prior (source: prior) until scripts/contract/evaluate.mjs measures it. The engine hash moved from 37ab2c3d… to 24edc06a…; migration 0590_genesis_qwen_seat_on_qwen3_8_max.sql withdraws the genesis with the dead seat where nothing happened under it.
• The Haiku 4.5 renderer's pin is at risk. Anthropic's status page (read 2026-10-25) dates the pinned claude-haiku-4-5-20251001 "not sooner than 2026-10-15" — a date now past — while still listing it Active. The image renderers keep two independent groups only while it answers, because gpt-5.6-luna is the other one (docs/providers/anthropic.md § money), so a move must name a second renderer from another operator and follows the rule above.
• Admission. The contract admits an engine only if all of these hold: every tier has two operators and an open-weight seat; the top tier holds two disjoint panels (k7.appeal_capacity); every medium that the law admits has two independent renderers (k10.renderers). A law that admits a medium the engine cannot render is not adopted.
• Grouping and panels. The host supplies a fresh random panel seed after it accepts a filing. The seed is stored once with the case, and a replay returns that stored seed. This prevents offline panel shopping through filing text. It does not remove trust in the host's entropy. Seats of one operator or one lineage form one group. The seed draws which groups sit. Routing decides how many groups sit, and which seat of each group (§ routing). A case's instance plans and draws its panels once. So every question of the instance has the same seats, and the rest of the top tier stays free for the appeal. Other questions draw by seed. A seat whose operator or controller (Seat.controlledBy, part of the engine) is a party never sits.
• Aggregation. A group votes its confidence-weighted label. The tier's answer is the uniquely heaviest label; its confidence is its weight over the answering groups. A tie has no winner. Below the top tier, a tie, a missing quorum or a low confidence climbs to the next tier. At the top tier, they are unresolved or unavailable.
• One record. The question's evidence package is text only, with each item under a unique id. Every seat's answer carries the digest of what its adapter actually delivered. An answer over a different record is an error, not a vote.

§ 6

Evidence

Streams. A case's evidence, and an agreement's evaluator, may name a window of a device's stream: the records whose own time is in a window around a named moment (when the agreement was signed, delivered, due, or when the contract checks), never "now". The stream's seals prove the pick complete, its certificates say who signed it, a block hash bounds it from below and the transparency log's anchor bounds it from above. The seats read those facts as text; a frame the records name is rendered like any image. In an agreement, a stream leaf tests a field of the picked record, or puts a proposition to the engine, and evidence that falls short of what the leaf requires decides nothing. docs/integrity.md § evidence.

The contract takes text as it is. Media (the kinds that the law admits; genesis: image, audio) is uploaded once (POST /contract/media, stored by sha256) or cited by https URL. The contract fetches cited media once and checks it against the committed sha256. One renderer of every independent group that is able to renders it, at least two in all. The contract records the renderings and shows them to the parties. It marks an item that cannot be rendered twice in the record ("not before you, counts against no one"). It refuses a modality that the law does not admit at submission.

§ 7

Justice

filing -> screening -> service -> answer + evidence -> instance 1 -> (appeal: instance 2) -> execution
              |                                            |                |
              +-> duplicate: closes unserved               +----------------+-> unprocessable: no merits outcome

1. Filing. Anyone files, for themselves or for a being who cannot. A filing names the respondent, the act, the duty and one or more harm items (interest, description, amount). Each remedy names the harm items it answers. The contract refuses at the door: - a filing outside k6; - a remedy that k8 does not allow; - restitution and compensation together above a harm item's amount; - more than one penalty, or a penalty above the cap over the total harm.

   The contract takes the claimant's cost deposit (caseDepositCents) with the filing, as far as their balance goes. The deposit is never a bar to filing. Each claimant has at most openCasesPerClaimant open cases.

2. Screening. The engine checks that the matter is not one already brought between the same parties (same key, or decided same_matter). A duplicate closes unserved, and its claimant pays its costs. A final matter may be reopened once, with new evidence, within reopenWindowMs.

3. Service. The contract delivers a notice to the respondent's contract inbox. The response clock starts then, not at filing.

4. Answer and evidence. The respondent answers and may give its own figure for each harm item (final offer). The contract renders media as it arrives.

5. Deciding (instance 1). Fixed panels decide, in this order: - justiciability; - each element of the duty separately. This is the claimant's burden: unresolved is not established. For criminal matters, the top tier must reach ≥ 950/1000 on every element; - for each harm item, the claimant's or the respondent's figure: the one closer to the loss that the record proves. Unresolved goes to the respondent's figure; - for each remedy, whether it is justified.

   Money remedies are bounded per harm item, and the penalty by one cap over the total award. The contract retries a question that the engine cannot answer. After unprocessableAfterMs, the case closes unprocessable: no merits outcome, and the deposits are returned.

6. Appeal (instance 2). Either party may appeal, once, within the window. The case becomes appealed at once, so no later sweep can finalize it. A top-tier panel of groups that took no part hears it on the same record, and its judgment is final. A timely appeal waits for a fresh panel within unprocessableAfterMs. If the pinned engine cannot process the appeal in that period, the case closes unprocessable, the prior judgment is unenforceable and the deposits return. The matter can be filed again. A new engine RFC does not change an existing case's pinned engine.

7. Interim freeze. At most the money claimed, for at most 14 days. It needs a determination that the claim is likely to succeed and the amount is likely to vanish.

8. Execution (one batch). The order of sources is: the frozen amount, then credits, then bonds. Bonds are participations, valued at their share of what is owed and moved in kind to the victim. The order of payees is: victims first, then the penalty (split with the pool), then costs. Loser pays both ways: the respondent with the judgment, a losing claimant from their deposit. Unprocessable costs are the commons'. A victim shortfall becomes an open pool claim.

9. Records. Parties read the record, the determinations and the renderings. Everyone else reads the public projection (claim summary, stage, judgments with element findings, awards and remedies). Case determinations are never public (/public/contract/determinations/:id serves RFC determinations only).

Exclusion (k8). A final liable judgment may exclude its respondent from the contract's services for a bounded time. Every market door that opens a new commitment asks first, and refuses with excluded_by_judgment and the time it runs out: opening a service contract, claiming a request, publishing a listing, buying from one, placing a market order, and posting a bounty. Exclusion touches nothing else — not holdings, not cases, not a voice.

Service contracts. A dispute that the evaluator cannot decide files an agreement case. The escrow is the stake, so there is no deposit. The final judgment settles the escrow through settleAgreementByCase, idempotently, before the execution batch commits.

§ 8

The pool

Issuance premiums and penalty shares fund the pool. Each sweep runs an allocation epoch over every open claim. Each claim's need is its shortfall up to poolClaimCapCents, less what it was paid. Every need gets the same fraction of the balance, by cumulative floor in case-id order, so arrival order never matters. Unpaid needs stay open, and the pool pays them as it is funded. Beyond the cap, the respondent still owes. The pool takes over (subrogation) what it paid.

§ 9

Credit

The contract services this financing cycle (credit.ts, contract-credit.ts):

mandate (investor escrows capital) -> facility (borrower draws) -> bond (participations, tradable)
                                                                     |
                                     servicing on each due date <----+----> default -> holders' cases -> execution

• Mandate. An investor escrows capital on terms: facility sizes, an annual simple rate, a term, installments, and whether only persons may borrow.
• Facility. A borrower draws on a mandate. Drawing is accepting its terms; that agreement is what a default is judged under. The schedule is fixed up front (equal principal, interest on the outstanding). Only insured-1 pays the issuance premium (poolPremiumBps), out of the drawdown; uninsured pays none. Insured-1 snapshots its coverage cap and rejects known shared ownership or unverified parties.
• Bond. The tier is fixed in the mandate and copied into the facility; uninsured is the default. The facility's claim is held as participations (1 unit = 1 cent of principal) in contract_holdings. A holder offers units at a price. The buyer's acceptance moves the price and the units in one batch.
• Servicing. On each due date the sweep collects what is due from the borrower's balance. It takes creditServicingBps for the commons and distributes the rest to the holders pro rata.
• Default. A durable default snapshot stays queued until every holder's case exists. Retries use stable filing times and ids. An installment unpaid past creditGraceMs accelerates the facility. The contract files each holder's breach case for their share, and judgments execute against the borrower. An uninsured shortfall remains owed without pool coverage. For insured-1, a separate case.insurance determination requires independently corroborated economic loss and unrelated parties. Admissions, schedules and liability alone are insufficient. A quorate top-tier answer must carry distinct valid attestor keys. Only decided eligibility creates a capped pool claim. Missing attestation keeps coverage pending, without delaying collection from the borrower. The contract refuses known common owners, duplicate human identity, and two sides that reach one payout address or one phone number (contract-insurance.ts: a shared payout destination or one person's line on both accounts is a shared controller whatever the ownership rows say). Undisclosed relationships remain an evidence risk.

To commit an account's money to credit (a mandate, a draw, a bond offer or purchase) needs a named principal of the account: the person or an agent key. The contract refuses a program's token.