Cartulary is a working design probe. The hosted service demonstrates mandates, decisions, and evidence; it does not demonstrate atomic settlement or institution-local privacy. The direction being tested is on-ledger authority combined with institution-local judgement. This page separates what is built from what remains an architectural proposal.
The hosted multi-tenant service is a prototype convenience, not the target architecture. A single service that holds authority and payment context for many institutions concentrates exactly what a need-to-know settlement network is arranged to separate. The intended direction is institution-local judgement, with transaction-critical authority represented or committed on the ledger rather than asserted beside it.
Today Cartulary is the authoritative record for everything except the transaction itself, and that concentration is the central weakness. The target is not to move it all onto the ledger. A commitment carried in a transaction does not make the ledger authoritative for a policy; it makes the ledger authoritative for the commitment, which is a different and smaller claim. The distinction is the point.
| Fact | Authoritative record | Transaction contains |
|---|---|---|
| Mandate authority | On-ledger contract, where expressible | Contract reference and its consumption |
| Full policy | Institution-local policy system | Policy version and a cryptographic commitment |
| Decision and its rationale | Institution-local decision record | Decision identifier and a commitment |
| Screening result and case file | Institution-local compliance system | Only what is needed to enforce the transaction |
| Transaction effects | The ledger | The effects themselves |
The first four authoritative records are not institution-local today; they sit in the hosted service. Transaction effects remain authoritative on the ledger. None of the right-hand column is built: no transaction currently carries a commitment to anything. The table is the target, not a description of what runs.
Cartulary decides, the transaction is prepared, the prepared transaction is checked against the decision, a key holder signs, and the ledger settles. Those are separate steps in two systems. The approval is bound to the transaction it permits and then reconciled against the ledger result afterwards. That is validation and reconciliation, not atomic composition, and we do not describe it as atomic anywhere.
The consequence is a real failure mode: settlement can succeed while the receipt write fails. The money has moved and the account of it is briefly incomplete. It is repaired by observing the ledger and writing the receipt late, which is recovery rather than a guarantee.
The key holder's signature commits to the prepared transaction and to nothing else. It says those exact bytes were authorised by that key. It says nothing about the mandate, the policy version, or the screening result, because none of them are in the bytes. Today that binding is an assertion held in Cartulary's records. Carrying a commitment to mandate, policy version, and decision inside the transaction is the change that would make it checkable, and it is not built.
Cartulary governs payments routed through it. It refuses before a transaction is constructed and holds a payment before submission. It cannot freeze an issued token, reverse a settled transfer, or reach a transfer that never passed through it. Those need the issuer or the settlement application, and the roadmap says so.
If Cartulary is unavailable, no new decisions are taken and no new payments proceed through this path. Ledger state is unaffected. An institution-local deployment makes that its own operational problem rather than a dependency on somebody else's uptime, which is one of the stronger arguments for moving there.
Every row below is a control. What differs is whether it survives Cartulary itself being wrong or compromised, which is the property that matters when you are deciding how much to depend on a vendor.
| Control | Applied by | Independent of Cartulary? |
|---|---|---|
| Mandate limits | Cartulary | No. A database row it also writes |
| Policy evaluation | Cartulary | No. The same party evaluates and records |
| Screening | Cartulary, on outside data | No. The data is independent; acting on it is not |
| Two-person approval | Two people, through Cartulary | No. It records its own four eyes |
| The signer's check before signing | The key holder | Yes. Runs beside the key, refuses what disagrees |
| Ledger validation | The ledger | Yes, for what the ledger can express |
The first four are Cartulary-enforced controls. The final two remain effective even if Cartulary is wrong or compromised. The signer's check is the interesting one: it runs in the agent's own process, next to the key, against an instrument table compiled into the client rather than supplied by the server, and it will refuse a transaction Cartulary itself proposed. It is deliberately the piece the hosted decision service cannot override at transaction time, assuming the signer-side client artefact itself is trusted.
The way to move a row from no to yes is to express the control where the value is: a mandate as a contract that spending consumes, so a breach is invalid rather than merely refused. That is the argument below, and the reason it is worth the work.
| Sees | Must never see | |
|---|---|---|
| Cartulary | The proposal it is asked to decide: payer, counterparty, instrument, amount, the mandate, the policy, and the screening inputs for that payment. | Any leg of a transaction its operator is not party to, and any other institution's payments. This column is the target, not the current state: see below. |
| The ledger | The transaction and its effects, disclosed to the parties entitled to each part of it. | Screening results, case files, investigator notes, and the internal policy. These depend on outside data and human judgement and do not belong on a ledger. |
The second column is not what runs today. Tenants are isolated at the application-query layer, which means the hosted service remains technically capable of reading multiple institutions' records, and so does whoever operates it. That is logical tenancy, not architectural privacy, and the two are easy to confuse in a screenshot. The institution-local target removes the vendor-level visibility rather than promising not to use it.
A narrow external-signing validator, run against a local Canton network, using Canton's example Iou model. It is not a stablecoin settlement, it is not integrated into this hosted application, and it has not been run on DevNet, TestNet, or MainNet.
The code and its recorded run are in the public repository.
Authority and its consumption want to be a pattern expressed where the value is. On a ledger that can express them, a mandate should be a contract, and spending should consume it, so that a payment breaching its limit is not merely refused by a service but invalid at the ledger. That makes authority and execution one transaction instead of two records to reconcile.
Screening, investigation, case management, and the human record are a product, and an institution-local one. They need vendors, deadlines, people, and an audit file, and no ledger wants them.
The evidence format and its verifier are a standard. Their value comes from other people implementing them, which is why both are published.
The cheapest useful step, and the next one, is to carry a commitment to the mandate, the policy version, and the decision inside the transaction on whichever rail is in use. It could be implemented on both rails, but is not built on either. It turns the weakest claim, that the binding is an assertion in a database, into something a counterparty can check.
Everything above is a position taken on incomplete evidence. These are the places it could be wrong, listed because a design document that omits them is a brochure.
That moving authority onto the ledger narrows this product, and that we built the version which does not. We cannot fully separate the architectural judgement from the fact that one outcome leaves more to own. The strongest case against our position is that authority belongs in contracts, evidence belongs in a standard, and what remains is a good case-management tool for compliance teams: a smaller and more honest business than a control plane. We do not know whether that is right. It is the question worth asking, and we would rather be told than discover it later.
This page describes an unresolved design question rather than a settled one. If the conclusion changes, it changes here first.