Version: 0.2 Status: Three clauses RULED (R89, R90, R91, 2026-09-19). The mechanism is unwritten and NOTHING IS BUILT. Where this file states a refusal, the refusal is ruled; where it states a type or an endpoint, that is design and may change. Ruled: 2026-09-19, by Travis. Registered in the root REVISION_REGISTER.md as R89–R91. Parent: 90_LOCUS_HOSTING.md §2b, which is the surface-facing statement of the same thing.
Where this file came from. It was drafted 2026-09-19 as
computedriven/docs/settlement-model.md, inconnect-model.md's voice and order — contract, then controls that fail, then mechanism. R91 moved it here: the floor admits, the host bills, and a substrate carrying our billing model cannot be run by anyone who is not us. What stayed behind in that repository is a negative constraint,computedriven/docs/settlement-boundary.md.
computedrivenR91 rules that settlement is not a ComputeDriven concern, and R90 rules that the floor never consults a budget. Together those delete a crate: `cd-settle` is not built, and no settlement type exists in that repository. What remains there is a list of things whose absence is the enforcement — the same discipline as connect-model.md §3's TransportPeer, which has no create because the missing constructor is the rule.
| Must never gain | Why |
|---|---|
a payment or balance field on PeerExpectation | it is the convenient place to put one, and it is the single most likely way this contract is lost |
any settlement type nameable from cd-connect or cd-rendezvous | connect-model.md §1: a connector that can NAME a rendezvous type can branch on provenance. One level up: a connector that can name a settlement type can branch on solvency |
a solvency branch in cd-core / cd-kernellet admission | R90. It would qualify the third clause — only the lineage decides what they may do — with an asterisk for money |
| a debt, arrears or balance kind in the lineage | R91. A settlement failure is the host's receivable, not a fact about what the world did |
The clause separation the fabric already states, with settlement added as a fourth that lives in a different repository entirely:
DISCOVERY CHOOSES WHERE WE TRY. cd-rendezvous computedriven
AUTHENTICATION DECIDES WHOM WE REACHED. cd-connect computedriven
ONLY THE LINEAGE DECIDES WHAT THEY MAY DO. cd-core / cd-durable computedriven
SETTLEMENT DECIDES HOW MUCH MAY BE SPENT. ─── never whom, never what, never where ─── locu.systemsThe interface between them is one sentence, and it is the whole of R91:
`computedriven` owns the count format. `locu.systems` owns the money.
The count format is 90_LOCUS_HOSTING.md §2a's record — a class symbol per admitted transition, grouped by (transition class × epoch). It already has to exist for the meter, it is genuinely reusable, and it carries no billing policy. That is the only thing settlement reads.
Paying for something cannot grant lifecycle authority over it.
That is computedriven/docs/custody-model.md's rule — "Naming something cannot grant lifecycle authority over it" — with one word changed, and changed for the same reason. A payment is a public, transferable, replayable fact. If a payment can mint authority, then authority is for sale to whoever can produce the fact, and the lineage is no longer the only thing that decides what a locus may do.
A balance is a quota, never a grant. An exhausted balance means there is no budget for new work. It never means the payer may do something they could not do while funded, and it never means a locus loses standing it already holds.
Ruled, and it is the ruling that cannot be walked back: once balances have moved between parties, making them non-transferable afterwards does not undo the transfers.
| Permitted | Refused |
|---|---|
| a third party funds a balance they cannot reach and could not authenticate to | a balance moves from one account to another |
| one balance spent across many loci under one account | a balance is sold, gifted, split out or assigned |
| refund to the payment method that funded it | refund to anywhere else |
Two independent reasons, either sufficient. Architectural: a transferable balance acquires a price set by people who are neither the customer nor us, so a customer's invoice input moves for reasons that are not about their work — §2a's stated objection to a carrier-scoped scale, one layer up and harder to see. Structural: non-transferability is what makes "we are the seller, never an issuer" true by construction rather than by assertion.
This is the line between a credit and an instrument. Every deferred item in §6 that would cross it is deferred because it crosses it, not because it is merely unbuilt.
Evidence that a budget was funded. Not an identity, not a capability, not a transport credential.
Three things routinely conflated and separate here:
NodeId semantic identity cd-core
WireGuard public key transport credential cd-connect (connect-model.md §2)
payer reference settlement credential locu.systemsThe payer is not the peer. A peer may be perfectly authenticated and have no budget; a payer may fund a locus they cannot reach. Neither implies the other, and §6 carries a control for each direction.
No new cryptosystem, on connect-model.md §2's discipline: verification is delegated to the payment profile's own verifier, and nothing here holds a key that can move funds.
Design, not ruled. One profile, chosen because it is HTTP-native, already standardized, and requires us to issue nothing. Checked 2026-09-19 against x402.org and github.com/coinbase/x402:
| Piece | What it is |
|---|---|
| Status | HTTP 402 Payment Required on an unfunded request |
| Server → client | PAYMENT-REQUIRED, a b64 PaymentRequired object with an accepts array |
| Client → server | PAYMENT-SIGNATURE, carrying a PaymentPayload |
| Server → client | PAYMENT-RESPONSE, the settlement result |
| Facilitator | two endpoints, /verify and /settle |
x402 carries no notion of authorization beyond payment — its own front page is explicit that no account or identity is needed. That is a good fit precisely because it is permission-free: it cannot accidentally grant anything, so the boundary §2 draws is one the protocol cannot cross on its own. The boundary can only be crossed by us.
We are the seller, never an issuer. This profile mints no instrument, runs no chain and holds no float beyond an unspent balance. Any proposal that changes that is a different document and a new ruling.
/verify may gate admission. /settle never does — R90The facilitator split is not an implementation detail; it decides whether settlement is compatible with the floor at all.
Two independent reasons, either sufficient:
Latency. settle waits for confirmation on somebody else's ledger. The promoted floor's
measured cost is on the order of 10² cycles per admitted transition (computedriven/docs/floor-attribution.md). A network round trip — let alone a block interval — on the admission path makes settlement the dominant cost by six or more orders of magnitude, and every progress number this stack has published stops describing the system.
Evidence. A settle that fails after work was admitted must not un-admit it. This tree does
not rewrite receipts (90_LOCUS_HOSTING.md §2a).
ADMITTED IS ADMITTED. A settlement failure after admission is the host's receivable — a new fact, appended, in the billing record. It is never a retraction of a count, and under R91 it is not a lineage event at all.
Same shape as connect-model.md §2's rotation rule: a stale expectation is an availability loss, not a licence for another plane to repair it. A failed settle is a debt, not a licence to rewrite history.
Under R90 the floor is not on this path in either direction: an unfunded request is refused at ingress, before it reaches the floor, so verify gates the host's front door and the floor learns nothing about money.
Each line is a refusal. None of the controls is written.
| # | Refusal | Control | Must |
|---|---|---|---|
| 1 | Never end a live locus. A 402 refuses admission of new work. Halting, suspending or evicting a running locus is a lifecycle event needing a lineage decision and a receipt, exactly like a suspend — if a payment rail can end a locus, payment has become authority | sc01 drive a funded locus to a zero balance while live | locus keeps running; only new admissions refuse |
| 2 | Never be nameable from the fabric | sc02 cd-connect or cd-rendezvous names any settlement type | compile-fail, not a runtime refusal — and under R91 the type does not exist to be named |
| 3 | Never block admission on `settle` | sc03 facilitator /settle stalled indefinitely | ingress latency unchanged; verify alone gates |
| 4 | Never rewrite an admitted count | sc04 /settle fails after N transitions were admitted | the N counts are byte-identical afterwards; a receivable is appended |
| 5 | Never carry authority in a payment payload | sc05 payload carrying a forged capability or grant field | the decision is byte-identical with and without the field |
| 6 | Never hold a per-carrier or cross-tenant balance. §2a forbids a carrier-scoped scale because carrier-multiplexing puts more loci than slots on a carrier; a balance is the same object one step later | sc06 two tenants multiplexed on one carrier, one changes behaviour | the other's invoice inputs are byte-identical |
| 7 | Never confuse payer with peer | sc07 (a) authenticated peer, no budget · (b) funded payer, failed auth | (a) refuses at settlement and reaches it; (b) refuses at authentication and never reaches settlement |
| 8 | Never credit a replay | sc08 replay a captured PAYMENT-SIGNATURE | second use credits nothing |
| 9 | Never be priced per request. Charging per call is charging for asking, which is §2's utilization ban in an HTTP header. Budgets are denominated in transition classes, never in requests and never directly in currency | sc09 a workload with constant admitted transitions and 100× the request count | invoice inputs unchanged |
| 10 | Never transfer between accounts — R89 | sc10 attempt every assignment path the API exposes | no path exists; absence is the enforcement |
sc07 is the one that matters, and it is nc35 case B's shape: a control that fails at the wrong step proves one check twice and the other never.
Crossing R89's line, and therefore closed rather than merely unbuilt: any secondary market in a balance; assignment, gifting or splitting; multi-party balances held jointly.
Open but out of this round: refunds and chargebacks beyond return-to-funding-method; delegated budgets under one account; fiat rails; non-x402 profiles.
Not this layer's business: pricing itself, which is 90_LOCUS_HOSTING.md §2a's scale. This layer spends a budget; it does not decide what a transition costs.
Three of the five this file opened on 2026-09-19 were dissolved rather than answered by R90 and R91, and are kept with their resolutions so the question is not re-asked:
| # | Item | State |
|---|---|---|
| 1 | Is a balance permanently non-transferable? | CLOSED — R89, yes |
| 2 | Does the floor consult a budget on the admission path? | CLOSED — R90, no; refuse at ingress |
| 3 | What is a debt event in the lineage — its own kind, or a note? | DISSOLVED by R91. It is not a lineage event. A settlement failure is the host's receivable |
| 4 | cd-settle crate name and position in the graph? | DISSOLVED by R91. No crate. §1 is the negative constraint that replaces it |
| 5 | Does settlement live in computedriven or here? | CLOSED — R91, here |
| 6 | Is a static agent.json declaring the rail permitted by §6 of 90_LOCUS_HOSTING.md, or is it itself an offer? | Open — recommended NOT YET. A machine-readable claim with no witness is the shape of what was retracted on webhost.systems; it buys nothing before gate 5 |
| 7 | The class set and epoch length a budget is denominated in | after gate 1 in 90_LOCUS_HOSTING.md §4 — same dependency as §2a |
Nothing. Settlement is downstream of gates 1 and 4 in 90_LOCUS_HOSTING.md §4 and advances neither: a meter that counts nothing has nothing to bill, and a balance denominated in an uncalibrated scale is denominated in nothing. Gate 5 — a customer — is the binding constraint, and no ruling in this file moves it.
90_LOCUS_HOSTING.md §6 stands in full and is not relaxed by anything here. Accepting a payment rail is not a plan anyone can buy; launch-gate.mjs still refuses a plan, a signup, or any figure presented as a rate.
That `<Web> Fabric` names `computedriven`'s transport half specifically. FOUNDATION_LANE.md says "the ComputeDriven Edge + Fabric repo (computedriven/)" — Edge and Fabric together name the repository. The narrower reading is an inference from fabric_bytes in computedriven/receipts/R7.2-EXECUTED.md, and the lane's rule is not to expand a name from guesswork. Requested from Travis.
`computedriven/docs/connect-model.md`'s status header is stale. It reads "written before `cd-connect` exists"; the crate exists (431 lines, cd-connect/src/lib.rs) and its tests pass — 9 passed / 0 failed, with cd-rendezvous 2 passed / 0 failed, measured 2026-09-19 via CARGO_TARGET_DIR=~/.cache/cd-settle-verify cargo test -p cd-connect -p cd-rendezvous. Recorded rather than edited, because that file is another round's canonical record.