7. Surface contracts

Repository

bloque-app/aledgent

Commit

5ca6b8a

Version

0.4.27

Status

draft

Rendered

2026-10-17T19:30:18Z

Source

SPEC.md, last changed in 5ca6b8a

Six surfaces, specified by meaning and fields. Wire formats, transports and encodings do not bind.

7.A CTR-CMD — the command surface

Who: any authorised principal.

REQ-CS-1 Every command MUST carry:

• the operation kind;
• the initiating principal;
• the principal it acts for, where that is different;
• the accounts and assets it touches;
• exact minor-unit amounts;
• a client key.

REQ-CS-2 A command MUST return synchronously, with its operation reference and the operation’s state at that moment. For a command acknowledged at Received (REQ-CS-8), that state is Received, and the reply is an acknowledgement, not an outcome. For a command answered with its decision, the reply is that decision: the state the command reached, or its refusal named (REQ-CS-4). A reply MUST NOT wait on the settlement layer.

REQ-CS-8 Every command is answered in exactly one of two ways:

• Acknowledged at Received. The commands that move value between ledger accounts, or out of them: transfer, reserve, and a withdrawal, that is a reservation that carries its outbound leg (REQ-SO-1). The reply is Received, with the operation reference, within NFR-1. The decision follows by query and notification (REQ-CS-3). The one exception is REQ-CS-9.
• Answered with its decision. Every other command (OQ-63, closed by the owner on 2026-10-02: capture, release, issue and redeem stay answered with their decision). The reply carries the decision within NFR-16: the command’s result, or its refusal named. It MUST NOT be Received.

The account and security commands MUST always be answered with their decision. They are the commands that open identities; open or close ledger accounts; register or remove credentials; grant or revoke authority, issuance authority and operator authority included; initiate, cancel or complete a recovery; name a successor or claim a succession; change custody; and every command of the operator surface (CTR-OPS). Only an amendment may move a command from one way to the other.

The answering setting of REQ-CS-9 does not move a command from one way to the other. It chooses, per principal, which of the two ways that principal’s transfer and reserve are answered.

REQ-CS-9 Answered with the decision, per principal. A principal’s transfer and reserve commands MAY be answered with their decision instead of acknowledged at Received. This is the principal’s answering setting.

• Who sets it. The principal itself, or another principal of the integrating party it is tied to (REQ-ID-7). A principal tied to no party sets its own. Setting it is an account and security command: it is answered with its decision and attributed (REQ-CS-8, REQ-AU-7). The setting is kept with the principal that set it and when, and every change is logged. It is not a record of the audit trail (REQ-AT-1): it moves no value, changes no balance and grants or revokes no authority. Ruled by the owner on 2026-10-04 (amendment 0018).
• Default. Acknowledged at Received.
• What it covers. transfer and reserve, and nothing else. A withdrawal stays acknowledged.
• The wait. The setting states how long the reply may wait for the decision. That wait MUST NOT exceed the bound REQ-CS-7 sets for every command answered with its decision. Unless the setting states a shorter one, it is NFR-16’s.
• Past the wait. The reply is ERR-DecisionUnavailable. The command is kept and decided like any other (REQ-CS-7). Its decision reaches the principal by notification and by query (REQ-EV-1, REQ-CS-6), and a retry under the same client key returns it.
• A command keeps the way it was taken in. A change of the setting applies to commands taken in after it. A command taken in before is answered, and re-answered on a retry, as it was taken in.
• No other effect. The setting changes when the reply carries the decision, not the decision. The operation, its states, its postings, its deadline and its notifications are those of REQ-CS-3 and §5.6, whichever way it was answered.

Trade-off, stated plainly. A principal answered with its decision holds a request open while the decision is made. A decision that misses the wait is still made, after the principal’s caller was told it was not. An integrating party that sets this MUST be ready to act on a late decision: to release a reservation it already told its caller was declined, for example.

REQ-CS-10 Multi-leg submissions. A transfer MAY carry several legs. It is one operation and one unit: every leg applies or none does (REQ-KER-10, AC-B3.1). “Atomic” covers that one submission, and nothing across submissions.

• The maximum is published. The deployment declares the most legs one submission may carry, and publishes it on the query surface (limits(), §8.2). A submission over it is refused at submission with ERR-BatchTooLarge, and nothing is taken in (AC-B3.3).
• aledgent does not split. A caller with more legs than the maximum divides them into submissions within it. Each is a separate operation with its own client key, atomic on its own. aledgent makes no promise across them: one may apply and another be refused.
• Internal only. A multi-leg submission moves value between ledger accounts. An outbound leg is always submitted on its own, and only aledgent composes what goes to the settlement layer (REQ-SO-2).

REQ-CS-3 A command that reserves MUST be acknowledged like every command that moves value, unless its principal’s answering setting says otherwise (REQ-CS-9): its reply is Received, with its operation reference (REQ-CS-2, REQ-CS-8, NFR-1). Its decision, Reserved or a refusal, MUST reach the caller asynchronously, through the channel every outcome uses: operation(reference) and the requester’s notification (REQ-CS-6, REQ-EV-1). The reservation reduces available in the same atomic step that decides it (REQ-BA-4). The decision is part of the command’s completion (NFR-15); it has no budget of its own. Any command refused after its acknowledgement MUST be recorded as Received → Rejected with the refusal named in its notification. A repeat of the same request under the same client key MUST return that refusal.

REQ-CS-6 A caller learns that an operation completed by notification (CTR-EVT), its primary contract (REQ-EV-7), or by query (operation(reference)), to recover or to confirm. It never infers completion from the acknowledgement. A reply whose state is not terminal MUST be labelled non-terminal (REQ-OP-7). There is no blocking “wait until terminal” reply. A command answered with its decision (REQ-CS-8) waits for that decision and for nothing else: never for the settlement layer or any other external event.

REQ-CS-7 A Received command MUST survive the unavailability of the deciding component. Once that component returns, the command MUST be decided within a stated bound (REQ-AR-7). That bound is Received’s deadline (§5.6). A command answered with its decision (REQ-CS-8) that cannot be decided in time MAY be answered with ERR-DecisionUnavailable, and MUST NOT be answered Received instead; the command is kept, and a retry with the same client key returns its decision.

REQ-CS-4 A refusal MUST name a condition from §10. A refusal MUST NOT be expressible as a success body carrying an error. An automated test MUST check the runtime shape of a refusal against its published description. The test fails the build if they disagree.

REQ-CS-5 The command surface MUST NOT offer:

• arbitrary posting;
• arbitrary state mutation;
• deletion of an entry;
• rewriting of history;
• an unbounded query.

These are the specific temptations that make a private ledger unverifiable.

7.B CTR-QRY — the query surface

REQ-QR-1 Queries MUST support:

• balances by account and by identity, across assets;
• movements filtered by account, asset, direction, counterparty and time range;
• a statement for a period;
• an operation by reference;
• an asset registry listing;
• open reservations, by account and by the principal that made them, aggregated per (account, asset) and itemised (REQ-QR-7).

REQ-QR-2 A query MUST be answered from a single consistent view. It is unsafe for a caller to combine two reads into one answer. That MUST NOT be the only way to get a fact.

REQ-QR-3 Queries MUST be free of side effects.

REQ-QR-4 A holder of authority over an account MUST be able to see every entry against it, and which authority made each one. This includes entries made under operator authority.

REQ-QR-5 Paged queries MUST use a cursor over the entry sequence. They MUST NOT use an offset. They MUST be stable under concurrent writes.

REQ-QR-6 The query surface MUST NOT require a caller to know a settlement-layer address, a coordinate or any other external concept in order to read their own facts.

REQ-QR-7 Open reservations. A caller MUST be able to read the reservations that are open now, in one consistent view (REQ-QR-2):

• Selected by account, by identity, or by the principal that made them; optionally by asset; and, for the principal that made them, optionally only those whose deadline falls before a stated time.
• Aggregated per (account, asset): how many are open, the sum reserved, and the earliest and latest deadline.
• Itemised, paged by cursor (REQ-QR-5): each open reservation’s operation reference, account, asset, amount, deadline, the principal that made it, and its client key where that principal is the caller.
• The view’s position. The answer names the last entry its view includes, so that a later movement, notification or report can be placed before or after it.
• Who sees what. A principal sees the reservations it made. A holder of authority over an account sees every reservation against it (REQ-QR-4). Nothing else.
• Bounded. A request MUST state its subject. An unbounded one is refused with ERR-QueryUnbounded (REQ-CS-5).

“Open” means Reserved, Submitted, Observed, Orphaned or Expired: the value is held. An operation in Needs-Review with its value still held is open, and the answer says it is under review.

7.C CTR-EVT — the event and notification surface

REQ-EV-1 aledgent MUST emit a notification on every state transition of an operation (§5.6), terminal or not, Received → Accepted and Received → Rejected included: every state a caller can query is also pushed to it (REQ-EV-7, REQ-OP-12). A notification MUST carry: the operation reference; the state; the outcome, where terminal; and the named error condition, where refused. A notification MUST also carry the latest anchor whose publication had reached finality when the transition was recorded (REQ-PR-8): its number, the last entry it commits to (REQ-PR-7), and its coordinate on the settlement layer. Where no anchor was final yet, it says so. What it carries is fixed when the transition is recorded, so that a redelivery carries the same body (REQ-EV-3).

REQ-EV-2 Delivery is at-least-once and unordered. Each notification MUST be understandable on its own. It MUST NOT require the previous notification to have arrived.

REQ-EV-3 Every notification MUST carry a stable identity: derived from (operation, transition) for a notification of a transition, from (operation, posting, credited account) for a credit notification (REQ-EV-9), and from (recipient, period) for a reservation report (REQ-EV-8). This makes a redelivery recognisable. A notification identity MUST NOT contain a timestamp or anything else that varies between attempts.

REQ-EV-4 aledgent relays each notification to the destination its recipient registered. A recipient registers its destination, and the secret it shares with aledgent, through the command surface (§7.A), under its own authority, and replaces either the same way. A notification MUST be authenticatable by its recipient and MUST NOT be replayable. It is authenticated by a message authentication code over its body, keyed with a secret that aledgent shares with that recipient alone. The body carries the notification’s identity (REQ-EV-3), so a replay is recognised as one and changes nothing. aledgent does not sign notifications: it holds no signing credential for them, per recipient or otherwise. The shared secret is the only credential a notification involves, and REQ-AU-8 binds it. If a recipient has registered no destination, or shares no secret, delivery MUST fail. Delivery never proceeds unauthenticated.

REQ-EV-5 aledgent MUST NOT make a synchronous call into a caller as part of reaching an outcome. Every operation MUST reach a terminal state even when every caller is unavailable.

REQ-EV-6 Delivery MUST be recorded durably. Undelivered notifications MUST be visible with their age.

REQ-EV-7 Every kind of principal MUST have a push contract. A person, an organisation, an agent and an integrating party’s service principals all receive their notifications pushed to their destination (REQ-EV-1, REQ-EV-4). Polling is not an acceptable primary contract for any kind of principal: it would put the system under load with no policy to absorb it. A query of one operation (operation(reference)) remains available to recover or to confirm an outcome. It is never the way a caller is expected to learn of one.

REQ-EV-8 Reservation reports. A recipient (REQ-EV-4) MAY register a cadence at which it receives a reservation report: the aggregate of REQ-QR-7 for the reservations its principal made, at one consistent view.

• The cadence is the recipient’s to choose, between one hour and one day. It registers, changes and removes it through the command surface, under its own authority, like its destination.
• A report carries: the period it closes; the view’s position (REQ-QR-7); the aggregate per (account, asset); and the latest final anchor, as every notification does (REQ-EV-1).
• A report is delivered and authenticated like every notification (REQ-EV-2, REQ-EV-4, REQ-EV-6). Its identity derives from (recipient, period), never from a time of attempt (REQ-EV-3).
• A report is a summary, not an outcome. A caller still learns each outcome from its operation’s notifications (REQ-EV-7). A report never replaces one, and a missed report is recovered by the query of REQ-QR-7.

REQ-EV-9 Credit notifications. When a posting credits a ledger account’s available balance with value from outside the account, aledgent MUST notify the account’s serving principal.

• Which postings. Transfer (each credited leg), Capture (the destination), Issue (the destination, an inbound arrival’s included) and Reversal (each account it credits). Not Release, which returns the account’s own reservation, and not Opening (REQ-RC-4).
• The serving principal of an account is the principal that opened it (REQ-ID-6). For an account its own identity opened, it is the principal that opened that identity. The notification reaches that principal’s registered destination (REQ-EV-4), and so its integrating party (REQ-ID-7).
• What it carries. The credited account; the asset; the amount credited; the posting kind; the operation reference and the operation’s state when the posting was appended; and the latest final anchor, as every notification does (REQ-EV-1). The counterparty is shown only as far as a movement of that account shows it to the serving principal (REQ-QR-4). Pass-through data only if the serving principal’s party is the requester’s (REQ-PO-5).
• Its identity derives from (operation, posting, credited account) (REQ-EV-3).
• Also to the requester. A serving principal that is also the requester, or of the requester’s party, receives both the transition notification and the credit notification. Each has its own identity, and neither replaces the other.
• Delivery is as for every notification: at least once, unordered, authenticated, recorded (REQ-EV-2, REQ-EV-4, REQ-EV-6). A serving principal with no destination is parked like any other recipient. A credit notification is never a condition of the credit.

7.D CTR-OPS — the operator surface

REQ-OS-1 Every operator capability MUST be an explicit operation with its own authority, its own audit record and a required justification. There MUST be no “all of the above” operator capability.

REQ-OS-2 The operator surface MUST include at least:

• resolve a Needs-Review operation, and submit evidence of its outcome for the settlement adapter to verify (REQ-RC-5);
• propose and approve a reversal;
• freeze and unfreeze an account;
• register an asset;
• bind a book-only asset to the settlement layer, under issuance authority for it (REQ-AS-8);
• register an integrating party, and tie a principal to it (REQ-ID-7);
• grant and revoke the identities principal’s role (REQ-ID-6);
• grant and revoke issuance authority;
• declare the settlement adapter’s supported operations;
• initiate and complete a recovery, where completing it needs the recovery authority’s approval (REQ-AU-15);
• import credentials into an identity’s set (REQ-MG-7);
• open and cancel an enrolment (REQ-AU-22);
• upgrade the code of a writer, and migrate the construction of the state commitment (REQ-RT-16, REQ-PR-11);
• change the upgrade-authority mode (REQ-RT-18);
• from the release that ships US-C5, place and lift an encumbrance.

REQ-OS-3 Approval of a reversal MUST require a different principal from the one that proposed it. Each of the two MUST hold its own reversal authority on this surface (REQ-OS-1): one to propose, one to approve. The two approvers are two principals with two authorities. Two checks by one principal are not two approvers. Their approval is necessary and not sufficient: the reversal MUST also pass the check of REQ-RC-5, which neither of them can override.

REQ-OS-4 Every operator action MUST be visible to the affected account’s authority holders (REQ-QR-4).

7.E CTR-DSC — the disclosure and proof surface

REQ-DS-1 aledgent MUST be able to issue, at minimum, disclosures that assert:

• an account holds at least an amount of an asset at a time;
• a named operation occurred;
• a named operation moved a stated amount;
• flows in or out of a subject over a window meet a stated bound.

REQ-DS-2 A disclosure MUST name:

• its subject;
• its recipient;
• its assertion;
• the checkpoint it is anchored against;
• the assurance level (REQ-AR-5).

REQ-DS-3 A disclosure MUST be verifiable by its recipient without aledgent taking part when it is verified (REQ-PR-4).

REQ-DS-4 aledgent MUST refuse to issue a disclosure that it can determine locally to be false.

REQ-DS-5 Issuing a disclosure MUST be authorised by the subject or by an authority the subject granted. The exception is where a legal obligation applies. In that case the disclosure MUST still be recorded in the audit trail (REQ-AT-1).

7.F CTR-SET — the settlement adapter boundary

The boundary between aledgent and its settlement adapter, in both directions. It is internal to the deployment. It is stated here because INV-11 and INV-13 depend on it.

REQ-SI-1 An inbound submission from the adapter carries:

• the observation coordinate;
• the event kind;
• the settlement layer’s own payload, including its error text where there is one;
• the finality status as observed, never as asserted.

REQ-SI-2 aledgent MUST accept an observation for an event it did not originate. It MUST NOT require a correlator it created in order to ingest one. Inbound value from a counterparty has no such correlator.

REQ-SI-3 Where aledgent originated the operation, the submission MUST carry aledgent’s operation reference. Where it cannot, aledgent MUST still be able to associate the observation by coordinate.

REQ-SI-4 An observation MUST be rejected if its coordinate has been seen before (INV-12). The rejection MUST be distinguishable from a failure.

REQ-SI-5 aledgent MUST return to the submitter the outcome it derived, including “ignored”, “already applied” and “not associated”. This way the adapter learns the ledger’s verdict.

REQ-SO-5 An outbound instruction to the adapter carries:

• the operation reference;
• the asset and exact minor-unit amount;
• the destination;
• the expiry (REQ-SL-4);
• the fact that a reservation exists.

REQ-SO-6 The adapter MUST acknowledge receipt durably before aledgent considers the instruction submitted. It MUST report back only observations (REQ-SA-3).

REQ-SO-7 aledgent MUST be able to reissue an instruction after a restart. The adapter MUST replay the same instruction, not produce a second one with the same intent (REQ-SA-6).

REQ-SO-8 aledgent MUST NOT expose the settlement layer’s ordering, sequencing or scheduling concerns on any other surface. Those belong to the adapter.

7.G Cross-cutting obligations

These bind every surface above, not just one.

REQ-SN-1 No holder-facing flow may present:

• a settlement-layer cost;
• a fee estimate;
• a funding step;
• a prompt to hold a balance in a fee asset.

aledgent bears settlement-layer costs.

REQ-SN-2 A liquidity or cost shortfall MUST be a named, parked, self-clearing condition with:

• an alert per affected position;
• an owner;
• an automatic resume when the shortfall clears.

It MUST NOT be a failure, and it MUST NOT be silent. The position that funds settlement-layer costs MUST have a balance invariant with an alarm.

REQ-AG-1 An agent is an identity with its own credential, acting for a named principal. An agent MUST NOT act under its principal’s credential.

REQ-AG-2 Every delegated authority MUST carry at least one bound that aledgent enforces at the moment of the operation. The kinds of bound are: per operation, per window, per asset and per counterparty. Exceeding a bound is ERR-BoundExceeded.

REQ-AG-3 If an operation that consumed a bound is later released, expired or reversed, the bound MUST be restored.

REQ-AG-4 An integrating party holds the credentials of its own agents. It MAY delegate authority to one of them for a specific task, a purchase for example, under the bounds of REQ-AG-2. The agent still acts under its own credential, never under the integrating party’s (REQ-AG-1).

REQ-RC-1 Every non-terminal state MUST have an operator resolution path reachable through CTR-OPS. Past its deadline, an operation moves to Needs-Review, where resolve_operation applies (REQ-OP-5).

REQ-RC-2 Reversal of a finalised posting is a reversal operation (§5.6). It MUST require deliberate human approval by a principal other than its proposer (REQ-OS-3), MUST raise an incident, and MUST NOT be automated. An automated reverser that is wrong does more harm than a human one that is slow.

REQ-RC-3 aledgent MUST be able to export its complete state and re-import it, producing identical observable state. This capability MUST be proven at production volume before an upgrade relies on it (REQ-RT-8).

REQ-RC-4 An initial state is the opening balances of accounts that existed before a deployment. Loading it MUST be:

• one Opening posting per (account, asset), against a named opening position;
• reconciled to zero divergence against every independent source before it is loaded.

It MUST NOT replay historical operations as if they were new.

REQ-RC-5 Resolving Needs-Review and approving a reversal are authority-based and check-based. Each human step needs its principal’s own authority (REQ-OS-1, REQ-OS-3). A Needs-Review operation is resolved in up to three steps. Humans decide without mechanical proof only in the last one:

1. The settlement adapter decides on its own. Whenever the records the adapter reported prove the outcome, aledgent MUST apply it at once, with no human:
   • Settled on a final record of the settlement layer that names the operation’s own reference;
   • Released on proof that the external leg did not and cannot take effect. That proof is a proved rejection (§5.6), or non-inclusion proven (REQ-SL-4) with the signing key’s nonce showing that no transaction carrying the instruction was included. For an inbound arrival, it is the arrival’s record withdrawn from the canonical chain.
2. One authority submits evidence. The adapter may fail to prove the outcome on its own, for example because it missed blocks. Then a principal with the resolution authority MAY submit where the proof is: the settlement layer’s block and transaction hash (submit_evidence). The adapter MUST fetch that transaction and verify it against the settlement layer on its own. aledgent then applies the outcome the verified records prove, as in step 1. The submitter’s word proves nothing, and one authority is enough, because the proof decides. An operator MAY also cite a record, or non-inclusion, that the adapter has already verified (resolve_operation). That citation is held to the same proof.
3. Two principals, only without proof. The adapter may check submitted evidence and still be unable to prove the outcome. Then a release MUST have two distinct principals agree, each holding its own resolution authority: one proposes, and a different one agrees (maker-checker). The release MUST raise an incident. This is the only path by which humans decide without mechanical proof, and it only releases. Two principals MUST NOT capture or settle without proof: that would book an entry before the external leg is final, which breaks INV-10. Under INV-11, the evidence this release is derived from is the adapter’s finding of no proof, both principals’ justifications and the incident.

An operation with no external leg needs no proof, because nothing outside the book can take effect. One principal releases it.

A reversal MUST pass a check that no principal, and no pair of principals, can override: its Reversal posting mirrors the postings it reverses exactly and whole (REQ-PO-3). Where the reversed operation has an external leg, that leg is subject to the proof of step 1.

A resolution that none of the three steps allows MUST be refused, and so must a reversal that fails its check. The operation stays where it is: in Needs-Review, or Accepted for a reversal awaiting approval.

REQ-RC-6 A seeded genesis. A deployment MAY start its book from a seed: an initial state committed at genesis, instead of loaded after it one command at a time.

• A seed holds identities, ledger accounts in delegated custody, aliases, opening balances with their reconciliation, and grants. Each record MUST be one that a command could have made, and the book’s first state MUST be the one those commands would make: under the operator’s authority, attributed to it (REQ-AU-7), with the same checks.
• Genesis MUST commit to the whole seed by one digest. The book’s first state is derived from the seed, not reached by executing commands: two derivations from the same seed and the same deployment MUST give the same book, and a derivation that any record makes fail founds nothing.
• The opening balances MUST pass the reconciliation of REQ-RC-4 before the book is founded, and post as REQ-RC-4 requires: one Opening per (account, asset), against the asset’s opening position.
• Until the first state is in place and checked against the commitment, aledgent MUST refuse every command with ERR-InitialStateNotSealed. Where the first state is derived outside the book’s own execution, the check MUST include a second derivation inside it, record by record from the seed, that reaches the same state; no command is taken before that passes. This is the window of NFR-17. Once sealed, the book behaves as a book founded without a seed.
• Where a seed is applied in parts, each part MUST be checked against the commitment before anything of it takes effect, MUST take effect at most once, and a part that any record of it makes fail takes no effect at all; an interrupted application resumes at the first part not applied.
• A seed MUST be applied only to the book whose genesis committed it. No command gives a book that is already live a seed: after genesis, the only initial-state load is that of REQ-RC-4.
• Replaying the book derives its first state from the seed again and applies every input after it: the same book (REQ-RT-3).
• A seed MAY commit to the prior system’s history by a digest of it alone. That history is not replayed (REQ-RC-4), and no history record becomes an input of the book. Anyone holding a record and its proof of inclusion can check it against the commitment without aledgent.
• An alias maps a prior system’s identifier to a ledger account. It carries no personal data (INV-17), and aledgent keeps only a digest of the identifier.

Trade-off, stated plainly. A seed moves the trust of the initial state to whoever built and reconciled it, as REQ-RC-4 already does for opening balances: aledgent checks that what it applies is what genesis committed, and that each record is one a command could have made. It does not check that the prior system’s figures are right.

REQ-RC-7 Aliases after genesis, and archived identifiers. Amendment 0024.

• The operator MAY name a ledger account by an alias after genesis (register_alias), with a justification, under its own policy authority: no grant gives it. An alias names one account, for good: one that already exists is never re-pointed or registered again, and is refused with ERR-NotAuthorised. It is attributed and audited like any operator command (REQ-AT-1), and aledgent keeps only a digest of its source and name (INV-17).
• alias(source, name) returns the account an alias names to a principal that can reach that account (INV-16). To anyone else, as for an alias that does not exist, it is ERR-UnknownAccount.
• grants(account) returns every authority grant whose subject is the account, live and revoked, with who granted it, when, its terms and bounds. It is the operator’s, and the account owner’s.
• account(account) returns the account as the book holds it: its owning identity, kind, custody mode, status and when it was opened. It is answered to a principal that reaches the account (INV-16), to the operator, to the identities principal (REQ-ID-6), and to a principal holding a live grant over the account’s owning identity, with a credential not limited to accounts (REQ-AU-20). To anyone else, as for an account that does not exist, it is ERR-UnknownAccount. Amendment 0028.
• grants(identity) returns the authority grants whose subject is the identity, live and revoked, with who granted each, when, its terms, its bounds and its parent. The identity itself, the operator and the identities principal (REQ-ID-6) get every one, as an account’s owner gets grants(account); any other principal gets the ones it holds. A principal that holds none, and a credential limited to accounts (REQ-AU-20), is refused with ERR-NotAuthorised. Amendment 0026.
• A deployment MAY name prior-system identifiers that its initial state deliberately left out (archived identifiers), as a list fixed with its genesis and checked against a digest. A request that names one (in its path, its parameters or its body) MUST be refused with ERR-IdentifierArchived, for good: it is never answered as unknown, never resolves to an account, and no alias is registered for it. Nothing of such a request is taken in.

Trade-off, stated plainly. ERR-IdentifierArchived tells any authenticated caller that the identifier existed and was left behind on purpose. That is the intent: a caller holding an old identifier learns to open a new one instead of retrying. The list holds identifiers only, never personal data (INV-17).

---