@serfab/cadre-core 0.10.0 → 0.11.0

package/dist/control-schema.js

@@ -9,779 +9,794 @@
  * build if they drift. Any edit here must be mirrored in `schemas/control.qsql`
  * and vice versa.
  */
-export const CONTROL_SCHEMA = `-- This manages a Sereus party's cadre, or set of nodes, and their participation in strands (networks)
-declare schema CadreControl {
-    -- A key that can authorize various control changes
-    table OwnerKey (
-        Key text primary key,
-        StampId text not null unique,   -- per-row authorization nonce, bound into the signed digests below.
-                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
-                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
-                                        -- enrollment signature cannot resurrect a removed owner.
-        -- A removed row's StampId is retired into Revocation, and this refuses any insert
-        -- naming a retired stamp: the approval that seated this row can never re-seat it after
-        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
-        -- freed the stamp and the original never-expiring signature verified again. A
-        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
-        constraint NotRevoked check on insert (
-            not exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = new.StampId)
-        ),
-        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
-        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
-        -- insert is visible at commit regardless of statement order. The tombstone must also
-        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
-        constraint RevocationRecorded check on delete (
-            exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = old.StampId and R.RowKey = old.Key)
-        ),
-        -- A party must never lose its last owner key: every other CadreControl table's
-        -- CHECK requires an OwnerKey row, so an owner-less control database can never
-        -- authorize anything again — emptying this table is a permanent denial of the
-        -- party's control plane. Deferred (subquery), so the count is the POST-delete count.
-        -- NOTE: this is a per-transaction check against locally visible rows. Two
-        -- partitioned nodes that concurrently remove different owners can each see a
-        -- survivor and still converge to zero; if partitioned rotation ever becomes a real
-        -- workflow, the floor needs a cross-node guard, not a local count.
-        constraint MinOneOwner check on delete (
-            (select count(1) from OwnerKey) >= 1
-        ),
-        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer
-        -- updates an OwnerKey row, and a self-rotation branch would double as a sole-owner
-        -- takeover: a deferred post-image count is also true of an update that re-points
-        -- the only row at an attacker key. Mirrors Strand.Manager.NoUpdate.
-        constraint NoUpdate check on update (false),
-        -- NOTE: the domain tag scopes an approval to a table and an action, not to a PARTY. Two
-        -- parties that share an owner key would accept each other's approvals. Fine today (each
-        -- party has its own owner key); if shared-owner multi-party ever ships, bind a party
-        -- identity row into these digests.
-        constraint Authorized check on insert, delete (
-            -- Every authorizer is read from the PRE-transaction snapshot (committed.*):
-            -- this CHECK auto-defers to commit (it has a subquery), by which point the row
-            -- being inserted — and any sibling inserted alongside it — is live, so a plain
-            -- from-OwnerKey would let a row authorize itself, or two strangers seat each
-            -- other. committed.* excludes both, stating the rule directly: the authorizer
-            -- must have existed BEFORE this transaction.
-
-            -- Every signed digest below (and in every other CadreControl table) leads with two
-            -- fixed literals — a 'CadreControl.<Table>' domain tag and an 'add'/'remove'/
-            -- 'vouch'/'publish' action tag (cadre-core control-authorization.ts) — so an
-            -- approval verifies ONLY against the one rule it was minted for. Without them,
-            -- e.g. a ValidationKey enrollment approval covered the identical bytes as an
-            -- OwnerKey enrollment: a narrow grant that doubled as full ownership.
-
-            -- Bootstrap: the FOUNDING transaction — one whose pre-transaction owner set is
-            -- empty — needs no authorization, and every row it inserts rides this branch
-            -- (whoever writes it already owns the party outright, so a co-founder row grants
-            -- nothing a single row would not). Gated on the PRE-transaction count, so a
-            -- same-transaction swap of the sole owner (delete the founder, insert the
-            -- attacker — post-image count still 1) cannot ride it.
-            (old.Key is null and (select count(1) from committed.OwnerKey) = 0)
-
-                -- or a pre-existing owner authorizes by signing over THIS row (Key, StampId)
-                or (old.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.OwnerKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519')))
-
-                -- or a removal authorized by ANOTHER pre-existing owner over the DISTINCT
-                -- 'remove'-tagged digest bound to the stored row's StampId, so an enrollment
-                -- signature can never be replayed as a removal (cf. CadrePeer.AuthorizedDelete).
-                -- A.Key <> old.Key: an owner cannot sign its own removal (no self-resignation).
-                or (new.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and A.Key <> old.Key and verify(digest('CadreControl.OwnerKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519')))
-        )
-    ) with context (OwnerKey text null, Signature text null);
-
-    -- A key that can validate a strand formation disclosure
-    table ValidationKey (
-        Key text primary key,
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
-                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
-                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
-                                        -- enrollment signature cannot resurrect a removed key.
-        -- A removed row's StampId is retired into Revocation, and this refuses any insert naming
-        -- a retired stamp: the approval that seated this row can never re-seat it after removal.
-        -- Same rationale as OwnerKey.NotRevoked, stated in full there.
-        -- NOTE: this table gained a consumer — FormationUsage.Authorized reads it to gate redemption of
-        -- a ValidationUrl invite — so the convergence gap noted on Strand.StampId now has teeth here: on
-        -- a node that has not yet seen the tombstone, a replayed enrollment re-seats the key and it can
-        -- approve redemptions there until the Revocation row arrives. Still no per-request READ surface to
-        -- filter (the gate is a write-time CHECK), so there is nothing to add today; if one appears, filter
-        -- retired stamps there.
-        constraint NotRevoked check on insert (
-            not exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = new.StampId)
-        ),
-        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
-        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
-        -- insert is visible at commit regardless of statement order. The tombstone must also
-        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
-        constraint RevocationRecorded check on delete (
-            exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = old.StampId and R.RowKey = old.Key)
-        ),
-        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer in the repo
-        -- updates a ValidationKey row. Required because the AuthorizedInsert / AuthorizedDelete
-        -- pair below covers neither update — and a bare \`check\`, which is what this rule used to
-        -- be, covers insert+update but NOT delete. Mirrors OwnerKey.NoUpdate.
-        constraint NoUpdate check on update (false),
-        constraint AuthorizedInsert check on insert (
-            -- Owners authorize by signing over THIS row (Key, StampId); single-use via unique StampId
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519'))
-        ),
-        constraint AuthorizedDelete check on delete (
-            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
-            -- the STORED row (Key, StampId), so an enrollment approval — which never expires — can
-            -- never be replayed as a removal. Same shape as CadrePeer.AuthorizedDelete.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519'))
-
-                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
-                -- that was offline at removal time may delete the stale row locally with no owner key.
-                -- Why committed.* and why the stamp must be bound: stated in full on
-                -- CadrePeer.AuthorizedDelete.
-                or exists (select 1 from committed.Revocation R where R.TableName = 'ValidationKey' and R.RowKey = old.Key and R.StampId = old.StampId)
-        )
-    ) with context (OwnerKey text, Signature text);
-
-    -- A network of members sharing an sApp database, each contributing peer nodes (their cadre) to the overall cohort
-    -- Cadre peers should participate in each of these strands
-    table Strand (
-        Id text primary key,    -- UUID
-        MemberPrivateKey text null unique,   -- Our private key as a member of this strand
-        Type text, -- Types: 'o' = Open, 'c' = Closed -- Open can still control writes in the sApp, but only Closed controls reads
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
-                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
-                                        -- permanently into Revocation (NotRevoked below).
-        -- NOTE: NotRevoked is a per-transaction check against LOCALLY VISIBLE rows, so a node that
-        -- has not yet converged on the Revocation row can still accept a replayed add and end up
-        -- holding the resurrected strand alongside its tombstone. CadrePeer has a read-side
-        -- mitigation for this class (CadreNode.listAuthorizedMembers drops rows whose stamp is
-        -- retired); Strand and ValidationKey deliberately do NOT, because neither has a
-        -- per-request authorization surface today. If one ever gains one, filter it there.
-        constraint NotRevoked check on insert (
-            not exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = new.StampId)
-        ),
-        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
-        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
-        -- insert is visible at commit regardless of statement order. The tombstone must also
-        -- name the removed ROW, not just its stamp — see Revocation.RowKey. That is what makes
-        -- the consent branch of AuthorizedInsert below trustworthy: a removal cannot file a
-        -- tombstone that omits or misnames the id it retires.
-        constraint RevocationRecorded check on delete (
-            exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = old.StampId and R.RowKey = old.Id)
-        ),
-        -- Strand rows are insert + delete only. Required: the consent branch of AuthorizedInsert
-        -- below authorizes by the EXISTENCE of a FormationUsage row naming (new.Id, new.StampId)
-        -- and carries no signature, so while this rule was a bare \`check\` (insert+update) it also
-        -- said "anyone may REWRITE any consent-formed strand, unsigned" — flipping Type to 'o' and
-        -- nulling MemberPrivateKey destroys the party's own membership key for that network in place.
-        -- Mirrors OwnerKey.NoUpdate / FormationInvite.Immutable.
-        constraint NoUpdate check on update (false),
-        constraint AuthorizedInsert check on insert (
-            -- Authorized by an owner signing over THIS row (Id, Type, MemberPrivateKey, StampId); single-use via unique StampId
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'add', new.Id, new.Type, coalesce(new.MemberPrivateKey, ''), new.StampId), context.Signature, A.Key, 'ed25519'))
-
-                -- or authorized WITHOUT a signature by a redemption record naming THIS EXACT ROW: a
-                -- FormationUsage row carrying both this strand's Id and its one-off StampId
-                -- (control-database.ts:redeemInvitation writes the pair in one transaction; both
-                -- CHECKs defer, so each sees the other's row at commit).
-                --
-                -- Matching the STAMP, not the id alone, is what makes a removal stick. FormationUsage
-                -- is append-only, so a redemption record outlives the strand it formed forever; keyed
-                -- on the id alone it re-authorized ANY later insert of that id, so after a legitimate
-                -- owner-signed, tombstoned removal any writer could re-seat the strand unsigned with a
-                -- fresh StampId (sidestepping NotRevoked, which retires only the removed row's stamp)
-                -- and an ATTACKER-CHOSEN MemberPrivateKey — the party's own secret for that network.
-                -- Bound to the stamp, the removal retires that stamp into Revocation and NotRevoked
-                -- closes this consent record's branch permanently.
-                --
-                -- Beyond the stamp match, the branch is deliberately NARROW — each clause closes one door:
-                --   * Type = 'o' / MemberPrivateKey null — a consent-seated strand looks exactly like
-                --     what the unbound redemption path writes (open, keyless). A closed strand carrying
-                --     a caller-chosen member key (the party's own read-gating secret for that network)
-                --     has no legitimate producer. MemberKeyClosedOnly already implies the second clause
-                --     from the first today; both are stated so this rule does not silently depend on
-                --     another constraint staying as it is.
-                --   * the inner FI.StrandId is null — only an UNBOUND invite may seat a strand at all.
-                --     A bound invite's host strand is owner-provisioned up front; letting the invite
-                --     consent-seat that id would allow an open, keyless downgrade of the real (possibly
-                --     closed, key-bearing) host row on a node where it has not converged yet. The bound
-                --     path records usage only (resolveStrand reports an absent host as missing and the
-                --     formation manager rejects cleanly).
-                --   * the not-exists over OTHER stamps — a strand id may be consent-seated once, EVER.
-                --     FormationUsage is append-only, so the first redemption's record survives a later
-                --     owner-signed removal and permanently forecloses a second consent-seating of the
-                --     id (a spare use of the same token minted a new stamp and rode this branch to
-                --     re-seat the id with an attacker-chosen row). Re-joining a removed id is
-                --     owner-gated: the owner re-seats it signed (fresh stamp, fresh signature) and
-                --     issues a BOUND invite the returning party records consent against — the id is
-                --     not blacklisted, only its unsigned re-seat is. This cannot be weaponised to
-                --     pre-block a legitimate id: StrandExists refuses a usage row naming a strand that
-                --     does not exist, so no usage row can be pre-planted for an unseated id — and ids
-                --     are 128 random bytes anyway.
-                --   * the not-exists over Revocation — a strand id may be consent-seated once EVER
-                --     and never after ANY removal of that id, however it was seated. The usage-row
-                --     rule above binds only ids that ever carried a consent record; an id seated
-                --     purely owner-signed (insertStrand, no usage row) leaves nothing behind on
-                --     removal, so its removal needs its own trace. Every removal files a Revocation
-                --     row naming the removed row's key (RowKey), and this clause refuses any id
-                --     that has ever been tombstoned. RevocationRecorded above makes that trace
-                --     mandatory AND correctly named, so no removal can slip past this clause. The
-                --     usage-row clause is arguably subsumed by this one (a usage row implies the
-                --     strand row existed, and its removal must file a tombstone), but it reaches
-                --     the same conclusion without depending on Revocation at all; both are stated,
-                --     per the style note above. The owner-signed branch is deliberately unaffected,
-                --     so re-join stays owner-gated exactly as described.
-                --     What is NOT schema-verified is a STANDALONE tombstone (one with no
-                --     accompanying delete — see Revocation.Authorized): an owner can file one
-                --     naming an id that never existed and thereby permanently foreclose
-                --     consent-seating of that id — owner-only, the owner already controls invite
-                --     issuance, and unbound ids are 128 random bytes minted at redemption, so no
-                --     escalation (same reasoning as the pre-plant note above).
-                --     NOTE: like NotRevoked above, this is a write-time check against LOCALLY
-                --     VISIBLE rows — a node that has not yet converged on the Revocation row still
-                --     accepts the re-seat. Fails in the safe direction: the tombstone wins after
-                --     merge for the STAMP, and the resurrected row coexists with it (same class as
-                --     the StampId note above).
-                or (
-                    new.Type = 'o'
-                    and new.MemberPrivateKey is null
-                    and exists (
-                        select 1 from FormationUsage FU
-                            where FU.StrandId = new.Id
-                                and FU.StrandStampId = new.StampId
-                                and exists (select 1 from FormationInvite FI where FI.Token = FU.Token and FI.StrandId is null)
-                    )
-                    and not exists (
-                        select 1 from FormationUsage FU2
-                            where FU2.StrandId = new.Id and FU2.StrandStampId <> new.StampId
-                    )
-                    and not exists (
-                        select 1 from Revocation R
-                            where R.TableName = 'Strand' and R.RowKey = new.Id
-                    )
-                )
-        ),
-        constraint AuthorizedDelete check on delete (
-            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
-            -- the STORED row (Id, StampId), so the add approval — which never expires — can never be
-            -- replayed as a removal. Note the consent branch above is deliberately NOT mirrored
-            -- here: an invitation authorizes forming a strand, never destroying one.
-            --
-            -- DELIBERATELY no REAP branch (cf. CadrePeer.AuthorizedDelete): this row carries
-            -- MemberPrivateKey — the party's own membership secret for that network, stored nowhere
-            -- else — so this is the one guarded delete whose effect is unrecoverable, and a stale
-            -- row is already inert for the purpose a tombstone serves (the consent branch of
-            -- AuthorizedInsert above refuses any id ever tombstoned). Do not "fix" the asymmetry;
-            -- tickets/backlog/debt-strand-tombstone-reap.md owns any future change.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'remove', old.Id, old.StampId), context.Signature, A.Key, 'ed25519'))
-        ),
-        constraint MemberKeyClosedOnly check (
-            -- An open strand ('o') has no membership gate, so it must not carry a
-            -- member key. A non-null MemberPrivateKey requires a closed strand ('c').
-            new.MemberPrivateKey is null or new.Type = 'c'
-        )
-    ) with context (OwnerKey text, Signature text);
-
-    -- A peer (node) that is part of the cadre, carrying a self-published,
-    -- freshness-stamped, self-signed address record (see PeerAddressRecord in cadre-core).
-    -- The row IS the peer-address record: a resolver reads it, re-verifies Sig against
-    -- PublicKey, checks freshness (UpdatedAt) and trust, then dials the addrs.
-    table CadrePeer (
-        PeerId text primary key,
-        PublicKey text null,            -- ed25519 (base64url) whose libp2p identity == PeerId (null if non-Ed25519)
-        Multiaddr text,                 -- comma-joined current addrs (signaling / p2p-circuit first)
-        UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay/rollback guard)
-        Sig text null,                  -- ed25519 self-signature over the signed payload (base64url); null until self-published
-        StampId text not null unique,    -- per-row authorization nonce, bound into the voucher/remove digests; rotates on
-                                         -- (re)insert. A removed row's stamp is retired permanently into Revocation
-                                         -- (NotRevoked below), so a captured admission approval cannot re-seat a removed peer.
-        VouchOwner text null,        -- ed25519 (base64url) owner key that vouched this membership (== insert context.OwnerKey)
-        VouchSig text null,              -- that owner's signature over the 'vouch'-tagged digest below (== insert context.Signature). A reader checks VouchOwner against its NODE-LOCAL trusted-owner anchor (not this replicated table, which a self-owner can pollute) to decide authorized membership. The domain/action tags keep this STORED, REPLICATED signature useless against every other rule (pre-tag it satisfied OwnerKey/ValidationKey inserts for Key = PeerId).
-        -- A removed row's StampId is retired into Revocation, and this refuses any insert
-        -- naming a retired stamp: the approval that seated this row can never re-seat it after
-        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
-        -- freed the stamp and the original never-expiring signature verified again. A
-        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
-        constraint NotRevoked check on insert (
-            not exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = new.StampId)
-        ),
-        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
-        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
-        -- insert is visible at commit regardless of statement order. The tombstone must also
-        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
-        constraint RevocationRecorded check on delete (
-            exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = old.StampId and R.RowKey = old.PeerId)
-        ),
-        constraint AuthorizedInsert check on insert (
-            -- Authorized by an owner key, which vouches both membership and the
-            -- PublicKey<->PeerId binding (cadre-core derives PublicKey from PeerId before insert).
-            -- The digest binds PeerId + the single-use StampId nonce (two TEXT fields),
-            -- matching cadre-core peer-authorization.ts:cadrePeerVoucherDigest. The same
-            -- 'vouch'-tagged digest is DELIBERATELY shared with the owner branch of
-            -- AuthorizedUpdate below: both mean "this owner vouches this membership row".
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
-            -- Persist the vouching (owner, signature) onto the row so a reader can later
-            -- re-check VouchOwner against its node-local anchor. The stored pair MUST equal
-            -- the pair the verify above validated, so a writer cannot store a voucher it did
-            -- not actually receive a signature for.
-            and new.VouchOwner = context.OwnerKey
-            and new.VouchSig = context.Signature
-        ),
-        constraint AuthorizedDelete check on delete (
-            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound
-            -- to the row's StampId (cadre-core peer-authorization.ts:cadrePeerRemoveDigest), so
-            -- the stored voucher (a signature over the 'vouch'-tagged digest) can NEVER be
-            -- replayed to authorize a delete. The remove signature rides in context and is never stored.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
-
-                -- or REAP: this node already holds a COMMITTED tombstone retiring THIS EXACT row
-                -- incarnation, so the party owner has already authorized this row's removal and this
-                -- node is merely catching up. That is what lets a node which was offline at
-                -- revocation time delete the stale row locally, with no owner private key
-                -- (control-database.ts:reapRevokedRow). Same shape as the consent branch of
-                -- Strand.AuthorizedInsert: authorization by the EXISTENCE of a row rather than by a
-                -- signature — and that row is itself owner-signed (Revocation.Authorized), so this
-                -- widens WHO may execute a removal, never WHO may decide one. RevocationRecorded is
-                -- satisfied by the same committed tombstone, so a reap files no second one.
-                --
-                -- committed.Revocation, NOT Revocation — and the stamp clause — are both load-bearing:
-                --   * committed.* : this CHECK defers to commit (it has a subquery), by which point a
-                --     tombstone written in the SAME transaction is live. Reading plain Revocation
-                --     would therefore let deleteGuardedRow's own sibling tombstone satisfy this
-                --     branch, making the 'remove'-tagged delete signature above dead weight and
-                --     collapsing two domain-separated approvals into one. committed.* states the rule
-                --     exactly: the tombstone must have existed BEFORE this transaction.
-                --   * R.StampId = old.StampId : binds the ROW INCARNATION, not the name. One name may
-                --     legitimately carry several tombstones over its life (seat -> delete -> owner
-                --     re-seat -> delete). Without this clause a tombstone from a PREVIOUS incarnation
-                --     would authorize deleting the CURRENT row, which the owner never removed.
-                or exists (select 1 from committed.Revocation R where R.TableName = 'CadrePeer' and R.RowKey = old.PeerId and R.StampId = old.StampId)
-        ),
-        constraint AuthorizedUpdate check on update (
-            -- Peer self-updates its own addrs + freshness, signing with its OWN ed25519 key
-            -- (the key behind PeerId). PeerId/PublicKey/StampId/voucher are immutable on
-            -- self-update, UpdatedAt must strictly increase (replay guard), and Sig is verified
-            -- against the stored PublicKey over the same payload the publish path signs
-            -- (cadre-core peer-record.ts:peerRecordSignedPayload).
-            (
-                new.PeerId = old.PeerId
-                and new.PublicKey = old.PublicKey
-                and new.StampId = old.StampId
-                and new.VouchOwner = old.VouchOwner
-                and new.VouchSig = old.VouchSig
-                and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
-                and verify(
-                        digest('CadreControl.CadrePeer', 'publish', new.PeerId, new.Multiaddr, cast(new.UpdatedAt as text)),
-                        new.Sig, new.PublicKey, 'ed25519')
-            )
-                -- or an owner re-authorizes (rotation / correction): re-vouches the row over
-                -- its current StampId, so the stored voucher is re-bound to the re-authorizing owner.
-                -- StampId is immutable here too: an update that rotated it would leave the OLD
-                -- stamp live-free and untombstoned (RevocationRecorded only retires the stamp a
-                -- delete carries), so the original admission approval — which is stored on the
-                -- replicated row as VouchSig — would resurrect the peer after a later removal.
-                -- Retiring a stamp is delete + Revocation row, never an update.
-                or (
-                    new.StampId = old.StampId
-                    and exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
-                    and new.VouchOwner = context.OwnerKey
-                    and new.VouchSig = context.Signature
-                )
-        )
-    ) with context (OwnerKey text null, Signature text);
-
-    -- A mobile cadre peer's platform push token (FCM/APNs), self-published so a
-    -- server peer can deliver a push-wake to a suspended app over the platform push
-    -- channel (a control-network dial cannot reach an OS-suspended process). The row
-    -- mirrors CadrePeer: a resolver re-verifies Sig against the CadrePeer.PublicKey for
-    -- this PeerId (see device-token.ts:deviceTokenSignedPayload), checks freshness, then
-    -- hands the token to the push sender.
-    table DeviceToken (
-        PeerId text primary key,        -- the CadrePeer this token belongs to
-        Platform text not null,         -- 'fcm' | 'apns'
-        Token text not null,            -- opaque platform device/registration token
-        UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay guard)
-        Sig text null,                  -- ed25519 self-sig over (PeerId|Platform|Token|UpdatedAt)
-        StampId text not null unique,    -- single-use authorization nonce, bound into the add/remove digests;
-                                         -- rotates on (re)insert. A cleared token's stamp is retired permanently
-                                         -- into Revocation (NotRevoked below), so the approval that published a
-                                         -- token cannot re-seat it after the owner cleared it (logout).
-        -- A removed row's StampId is retired into Revocation, and this refuses any insert
-        -- naming a retired stamp: the approval that seated this row can never re-seat it after
-        -- the clear. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
-        -- freed the stamp and the original never-expiring signature verified again. A legitimate
-        -- re-register mints a FRESH StampId and a fresh signature, so it is unaffected. This
-        -- matters more here than the stored-approval case (CadrePeer.VouchSig): a resurrected
-        -- push token has NO freshness ceiling to retire it — cadre-node.ts:resolveDeviceToken
-        -- defaults maxAgeMs to infinity by design — so retirement is the only thing that sticks.
-        constraint NotRevoked check on insert (
-            not exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = new.StampId)
-        ),
-        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
-        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
-        -- insert is visible at commit regardless of statement order. The tombstone must also
-        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
-        constraint RevocationRecorded check on delete (
-            exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = old.StampId and R.RowKey = old.PeerId)
-        ),
-        constraint AuthorizedInsert check on insert (
-            -- Authorized by an owner key (membership vouch), exactly like CadrePeer.
-            -- The digest binds the WHOLE row behind the domain/action tags — every column,
-            -- with the nullable UpdatedAt/Sig signing as '' when absent (the shape
-            -- FormationInvite and Strand already use) — so a replayed approval can only ever
-            -- reproduce the row it approved, never one carrying attacker-chosen
-            -- Platform/Token/UpdatedAt; NotRevoked above then refuses even that exact row
-            -- once it has been cleared. The DISTINCT 'remove'-tagged digest below keeps a
-            -- captured insert approval from doubling as a delete (and vice versa).
-            -- Mirrors cadre-core peer-authorization.ts:deviceTokenAddDigest.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
-                digest(
-                    'CadreControl.DeviceToken', 'add',
-                    new.PeerId,
-                    new.Platform,
-                    new.Token,
-                    coalesce(cast(new.UpdatedAt as text), ''),
-                    coalesce(new.Sig, ''),
-                    new.StampId
-                ),
-                context.Signature, A.Key, 'ed25519'))
-        ),
-        constraint AuthorizedDelete check on delete (
-            -- Bound to the STORED row's (PeerId, StampId) — cadre-core
-            -- peer-authorization.ts:deviceTokenRemoveDigest — so the never-expiring insert
-            -- approval can never be replayed as a clear, and a captured clear approval is
-            -- dead once the stamp it names is retired.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.DeviceToken', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
-
-                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
-                -- that was offline at removal time may delete the stale row locally with no owner key.
-                -- Why committed.* and why the stamp must be bound: stated in full on
-                -- CadrePeer.AuthorizedDelete.
-                or exists (select 1 from committed.Revocation R where R.TableName = 'DeviceToken' and R.RowKey = old.PeerId and R.StampId = old.StampId)
-        ),
-        constraint AuthorizedUpdate check on update (
-            -- Peer self-updates its own token, signing with its OWN ed25519 key (the key
-            -- behind PeerId). PeerId and StampId are immutable, UpdatedAt must strictly
-            -- increase (replay guard), and Sig is verified against the stored
-            -- CadrePeer.PublicKey over the signed payload (cadre-core
-            -- device-token.ts:deviceTokenSignedPayload). Platform and Token may change on
-            -- self-update (platform switch / reinstall / rotation).
-            -- StampId is immutable for the reason CadrePeer spells out: an update that
-            -- rotated it would leave the OLD stamp live-free and untombstoned, so retiring a
-            -- stamp stays delete + Revocation row, never an update.
-            -- This is the ONLY branch: there is deliberately NO owner re-touch. The branch
-            -- that used to sit beside it verified an owner signature over the peer id alone
-            -- and sat OUTSIDE the monotonicity requirement, so one captured owner approval
-            -- rewrote Platform/Token and rolled UpdatedAt BACKWARDS — and seating a
-            -- far-future UpdatedAt wedged the peer's own self-updates permanently. No writer
-            -- used it. An owner that must correct a row deletes it (retiring the stamp) and
-            -- inserts a fresh one, the same path it already takes for CadrePeer.
-            new.PeerId = old.PeerId
-            and new.StampId = old.StampId
-            and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
-            and exists (select 1 from CadrePeer P where P.PeerId = new.PeerId and verify(
-                    digest('CadreControl.DeviceToken', 'publish', new.PeerId, new.Platform, new.Token, cast(new.UpdatedAt as text)),
-                    new.Sig, P.PublicKey, 'ed25519'))
-        )
-    ) with context (OwnerKey text null, Signature text);
-
-    -- An open invitation to form a strand with this party
-    table FormationInvite (
-        Token text primary key, -- Just a random string
-        sAppId text, -- The app for the strand that will be formed
-        ExpiresAt datetime null,
-        TotalUses int null check (TotalUses >= 0),
-        ValidationUrl text null,   -- Web hook - send disclosure, IP address...
-        StrandId text null,   -- Host strand this invite binds to (provision-then-record). Non-null => the responder records consent against this pre-existing strand; null => legacy responder-provisions path.
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay)
-        constraint AuthorizedInsert check on insert (
-            -- Authorized by an owner signing over THIS row
-            -- (Token, sAppId, ExpiresAt, TotalUses, ValidationUrl, StrandId, StampId); single-use via unique StampId.
-            -- Nullable bound fields (ExpiresAt/TotalUses/ValidationUrl/StrandId) sign as '' when absent.
-            -- The 'remove'-tagged AuthorizedDelete digest below is DISTINCT, so a captured
-            -- insert approval can never be replayed to revoke-then-reissue an invite (or vice versa).
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
-                digest(
-                    'CadreControl.FormationInvite', 'add',
-                    new.Token,
-                    new.sAppId,
-                    coalesce(cast(new.ExpiresAt as text), ''),
-                    coalesce(cast(new.TotalUses as text), ''),
-                    coalesce(new.ValidationUrl, ''),
-                    coalesce(new.StrandId, ''),
-                    new.StampId
-                ),
-                context.Signature, A.Key, 'ed25519'))
-        ),
-        constraint AuthorizedDelete check on delete (
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
-                digest(
-                    'CadreControl.FormationInvite', 'remove',
-                    old.Token,
-                    old.sAppId,
-                    coalesce(cast(old.ExpiresAt as text), ''),
-                    coalesce(cast(old.TotalUses as text), ''),
-                    coalesce(old.ValidationUrl, ''),
-                    coalesce(old.StrandId, ''),
-                    old.StampId
-                ),
-                context.Signature, A.Key, 'ed25519'))
-        ),
-        -- Invites are insert/delete only: forbid in-place mutation so the row-bound
-        -- AuthorizedInsert signature cannot be sidestepped by updating consent
-        -- parameters (TotalUses/ExpiresAt/...) after a legitimate insert. A bare check
-        -- defaults to insert+update; the checks on insert / on delete above exclude update,
-        -- so this guard is required. Mirrors FormationUsage.InsertOnly.
-        constraint Immutable check on update (false)
-    ) with context (OwnerKey text, Signature text);
-
-    table FormationUsage (
-        Token text,
-        UseNumber int,
-        UsageStampId text not null unique,  -- single-use nonce for THIS redemption. The JOINING peer mints it and
-                                        -- sends it in its contact message, having signed it into its own 'consent'
-                                        -- digest (PeerConsented below); the responder inserts that same value and
-                                        -- asks the approver about it, so it is bound into the 'vouch' digest below
-                                        -- too and one sign-off is spendable exactly once. Neither side can swap it:
-                                        -- a substituted nonce fails the joiner's consent signature.
-                                        -- Unlike every other StampId in this schema, this table is append-only
-                                        -- (InsertOnly below), so the nonce is never freed by a delete: \`unique\`
-                                        -- alone makes it permanent and there is deliberately NO NotRevoked /
-                                        -- RevocationRecorded pair here — do not go looking for the missing one.
-                                        -- NOTE: \`unique\` is evaluated against LOCALLY VISIBLE rows, so two nodes
-                                        -- that have not yet converged could each admit the same nonce and both
-                                        -- rows survive the merge. Same class as the NotRevoked convergence notes
-                                        -- on OwnerKey / Strand / ValidationKey; the digest binding still holds on
-                                        -- both nodes, so the outcome is a duplicated audit row, never a join
-                                        -- nobody approved.
-        PeerKey text not null,          -- the joining peer's own ed25519 public key (base64url, 32 bytes), bound
-                                        -- into BOTH the approver's 'vouch' digest and the joiner's 'consent'
-                                        -- digest below, so an approval cannot be re-filed under a different
-                                        -- joiner's name and the named joiner provably agreed (PeerConsented).
-                                        -- The key IS the joiner's identity — its libp2p peer id is derivable
-                                        -- (identity multihash of these bytes), never stored here.
-        PeerSig text not null,          -- the joining peer's signature over the 'consent' digest — see
-                                        -- PeerConsented below for what it proves and why it is stored on the row.
-        Disclosure text,
-        StrandId text,
-        StrandStampId text not null,   -- the Strand.StampId this consent record authorizes. Consent is
-                                       -- bound to ONE strand ROW, not to a strand id forever — see
-                                       -- Strand.AuthorizedInsert's consent branch for why. NOT unique:
-                                       -- in the bound (provision-then-record) path several invitees
-                                       -- each write a usage row against the SAME host strand, so many
-                                       -- usage rows legitimately share one stamp.
-        primary key (Token, UseNumber),
-        constraint InsertOnly check on update, delete (false),
-        constraint Monotonic check (
-            -- Read the PRE-transaction snapshot (committed.*): this CHECK auto-defers
-            -- to commit (it has a subquery), by which point the row being inserted is
-            -- live, so a plain from-FormationUsage would count this row itself and make
-            -- UseNumber = max+1 unsatisfiable. committed.* excludes the in-flight row,
-            -- giving sequential 1,2,3... per token (cross-transaction; concurrent
-            -- redemptions of the same token collide on the (Token, UseNumber) PK).
-            -- ControlDatabase's use-number retry (withUseNumberRetry) is what resolves
-            -- that collision, by re-presenting the same approval under a fresh use
-            -- number. The deferred check above is the other surface the same race can
-            -- take: a concurrent row the inserting transaction's key probe did not yet
-            -- see trips this Monotonic CHECK at commit instead of the PK.
-            new.UseNumber = coalesce((select max(UseNumber) from committed.FormationUsage U where U.Token = new.Token), 0) + 1
-        ),
-        constraint Authorized check on insert (
-            -- Satisfies an invitation
-            exists (
-                select 1 from FormationInvite FI
-                    where FI.Token = new.Token
-                        and (FI.TotalUses is null or FI.TotalUses >= new.UseNumber)
-                        and (FI.ExpiresAt is null or FI.ExpiresAt > context.Now)
-                        -- An invite carrying a ValidationUrl demands a sign-off from a key the party
-                        -- ENROLLED in ValidationKey. The signature is verified against the STORED VK.Key,
-                        -- NOT against context.ValidationKey — that distinction is the whole point:
-                        -- context.ValidationKey is a plain insert parameter, so verifying against it asked
-                        -- only "did the redeemer sign its own disclosure with SOME key it holds?", which any
-                        -- redeemer answers by minting a throwaway keypair. context.ValidationKey survives
-                        -- purely to SELECT which enrolled row is being claimed; naming an enrolled key while
-                        -- signing with a different one fails the verify against VK.Key.
-                        --
-                        -- Deliberate: CHECKs run on write only, so removing a validation key later does NOT
-                        -- re-examine the FormationUsage rows it already approved. The sign-off was valid when
-                        -- given and the strand it authorized stays formed; removal narrows who may approve
-                        -- FUTURE redemptions, it is not a retroactive revocation of past ones.
-                        --
-                        -- What ONE sign-off buys: exactly ONE row. The digest covers
-                        -- (Token, UsageStampId, StrandId, PeerKey, Disclosure), so an approval is NOT
-                        -- transferable across invitations, redemptions, networks, joiners, or disclosure
-                        -- text. Replay is closed twice over, by two independent mechanisms: presenting an
-                        -- approval VERBATIM repeats its UsageStampId and is refused by that column's
-                        -- \`unique\`; presenting it under any OTHER redemption changes a signed field and
-                        -- fails this verify.
-                        -- Why a fresh nonce rather than binding UseNumber: UseNumber is derived from the
-                        -- table's current state (max+1, see Monotonic), so binding it would make the
-                        -- approver sign a value a concurrent redemption can invalidate — the loser of the
-                        -- race would need a SECOND approval for the same joiner (for a manual review
-                        -- queue, a second human review). A nonce chosen freely by the redeeming node is
-                        -- just as single-use and lets the loser retry the same approval under a new use
-                        -- number.
-                        -- Why StrandStampId is deliberately NOT bound: it names the strand ROW
-                        -- incarnation, which the unbound path (redeemInvitation) mints inside its own
-                        -- transaction, and it adds nothing on top of a strictly single-use approval —
-                        -- StrandId already pins WHICH network the approver approved joining.
-                        and (FI.ValidationUrl is null or exists (
-                            select 1 from ValidationKey VK
-                                where VK.Key = context.ValidationKey
-                                    and verify(digest('CadreControl.FormationUsage', 'vouch', new.Token, new.UsageStampId, new.StrandId, new.PeerKey, new.Disclosure), context.ValidationSignature, VK.Key, 'ed25519')))
-                        -- A bound invite (non-null StrandId) may only ever name its own host strand:
-                        -- without this, any holder of a bound token could record consent against an
-                        -- arbitrary strand id — annotating an unrelated strand, or (before
-                        -- Strand.AuthorizedInsert's consent branch was narrowed to unbound invites)
-                        -- consent-seating that id outright.
-                        -- NOTE: an UNBOUND invite is deliberately left free to name any strand, so a
-                        -- holder can spend a use appending a consent row to an unrelated existing
-                        -- strand. Harmless today (the row grants nothing, it only burns a use and
-                        -- forecloses that id's consent-seating, which is the safe direction); if
-                        -- unlimited-TotalUses invites ever become common, this is an append-only
-                        -- growth surface worth bounding.
-                        and (FI.StrandId is null or FI.StrandId = new.StrandId)
-            )
-        ),
-        -- Matched on the (id, stamp) PAIR, the same key Strand.AuthorizedInsert's consent branch
-        -- reads back: a usage row may only ever name a strand ROW that exists, so a consent record
-        -- can never be filed against a stamp of the writer's choosing and held in reserve to
-        -- re-seat the id after a removal.
-        constraint StrandExists check (exists (select 1 from Strand S where S.Id = new.StrandId and S.StampId = new.StrandStampId)),
-        -- The JOINING peer proves it consented to this redemption: PeerKey is its own ed25519
-        -- public key and PeerSig is its signature over the 'consent'-tagged digest below.
-        -- Unlike the approver's sign-off (context.ValidationSignature, checked against a STORED
-        -- ValidationKey row), the identity here IS the key, so there is no enrolled row to look
-        -- up and nothing for a writer to substitute: a forged joiner would need that joiner's
-        -- private key. Stored rather than passed in context so any later reader can re-check it
-        -- (verifyFormationConsent); the 'consent' action tag keeps this replicated signature
-        -- useless against every other rule in this schema (notably the approver's 'vouch'
-        -- digest over the same table).
-        -- NOTE: StrandId is deliberately NOT in this digest — the joiner cannot know it when it
-        -- signs (a bound invite's host strand arrives only in the result frame; an unbound
-        -- strand is responder-minted). The responder cannot substitute a strand anyway: bound
-        -- invites are pinned by Authorized's FI.StrandId check, unbound invites mint fresh.
-        constraint PeerConsented check on insert (
-            verify(digest('CadreControl.FormationUsage', 'consent',
-                          new.Token, new.UsageStampId, new.PeerKey, new.Disclosure),
-                   new.PeerSig, new.PeerKey, 'ed25519')
-        ),
-    -- Context here is only what the approver-side rules read: Now for expiry, and the
-    -- ValidationKey/ValidationSignature pair for the 'vouch' check in Authorized. The joiner's
-    -- signature is NOT context — it lives on the row (PeerSig, verified by PeerConsented above).
-    ) with context (Now datetime, ValidationKey text null, ValidationSignature text null);
-
-    -- Append-only retirement record for the one-off StampId nonces of removed OwnerKey /
-    -- CadrePeer / ValidationKey / Strand rows. Without it a removal was undoable: the add
-    -- approval is a signature over
-    -- (row key, stamp) that never expires, and deleting the row freed the stamp, so anyone who
-    -- kept a copy of the approval could resurrect the row.
-    -- Each tombstone also records WHICH row was retired (RowKey below): the consent branch of
-    -- Strand.AuthorizedInsert reads it to refuse consent-seating any strand id that has ever
-    -- been removed, whichever way it was seated.
-    -- NOTE: the guarded tables' NotRevoked CHECK runs against locally visible rows, so a node
-    -- that has not yet converged on a Revocation row can still accept the replayed add, and the
-    -- resurrected row coexists with the tombstone after merge — same class as the MinOneOwner
-    -- note on OwnerKey. The read-side mitigation is ControlDatabase.queryCadrePeers, which
-    -- drops any CadrePeer row whose StampId appears here; every membership reader inherits it.
-    -- NOTE: append-only, so this table only ever grows. Every append is owner-signed
-    -- (Authorized below), so the growth surface is the owner keys, not every writer that can
-    -- reach the control database. Cadres are a handful of peers and owner rotation is rare, so
-    -- unbounded growth is fine today; revisit if either changes.
-    -- A tombstone committed while the node was alone is local-only (never broadcast); the
-    -- ReissuedAt counter below exists so an owner can re-write — and therefore re-broadcast —
-    -- such a tombstone once peers are reachable, without changing what it means.
-    table Revocation (
-        TableName text,             -- 'OwnerKey' | 'CadrePeer' | 'ValidationKey' | 'Strand' | 'DeviceToken' (confined by RowIsGone below)
-        RowKey text not null,       -- primary key of the removed row: OwnerKey.Key / ValidationKey.Key /
-                                    -- CadrePeer.PeerId / DeviceToken.PeerId / Strand.Id
-                                    -- Every guarded table's RevocationRecorded CHECK requires the
-                                    -- accompanying tombstone to carry the removed row's key here, so
-                                    -- a REMOVAL cannot file a misnamed tombstone. A tombstone with no
-                                    -- accompanying delete is not covered by that (see Authorized).
-        StampId text,               -- the retired nonce
-        -- Bumped by an owner-signed re-issue so a tombstone written while the node was alone
-        -- (committed local-only, never broadcast) can be re-written and therefore re-broadcast
-        -- on cohort growth. Carries NO semantics: nothing reads it, and retirement is decided
-        -- by the row's existence, not by this value.
-        ReissuedAt integer not null default 0,
-        -- Keyed on the stamp, not the RowKey: stamps are unique per row incarnation, and one
-        -- name may legitimately carry several tombstones over its life (seat -> delete ->
-        -- owner re-seat -> delete).
-        primary key (TableName, StampId),
-        -- Retirement is permanent: a tombstone may never be withdrawn.
-        constraint NoDelete check on delete (false),
-        -- Pinned at 0 on insert so an owner cannot seat a tombstone at a saturated counter and
-        -- thereby freeze its own later re-issues (ReissueOnly below). Deliberately NOT folded
-        -- into the Authorized digest: the value is fixed by this rule, so signing over it would
-        -- only widen the signed surface for no gain, and would invalidate every existing
-        -- insert-side digest.
-        constraint FreshTombstone check on insert (new.ReissuedAt = 0),
-        -- A re-issue may move NOTHING but the counter, and only upward. Without the identity
-        -- clause an "update" would be a way to re-point a tombstone at a different row,
-        -- restoring exactly the replay this table exists to stop.
-        constraint ReissueOnly check on update (
-            new.TableName = old.TableName and new.RowKey = old.RowKey
-                and new.StampId = old.StampId and new.ReissuedAt > old.ReissuedAt
-        ),
-        -- A stamp may only be retired once its row is actually gone. Deferred (subquery), so a
-        -- delete in the same transaction has already landed. Retiring a stamp that never
-        -- existed is permitted and harmless: a stamp carries 128 bits of CSPRNG output
-        -- (control-database.ts:generateStampId — 16 bytes of sha256(PeerId) followed by 16
-        -- random bytes), so a future legitimate one cannot be guessed and pre-planted.
-        -- Deliberately keyed on the STAMP only, not RowKey: checking "no live row named
-        -- new.RowKey" breaks under out-of-order convergence — a peer removed (tombstone names
-        -- it, stamp1) then re-admitted (stamp2) would leave a node that converges on the
-        -- re-add FIRST rejecting the stamp1 tombstone forever, never learning that stamp is
-        -- retired. The stamp-only form passes there (stamp1 is not live).
-        constraint RowIsGone check on insert (
-            (new.TableName = 'OwnerKey' and not exists (select 1 from OwnerKey K where K.StampId = new.StampId))
-                or (new.TableName = 'CadrePeer' and not exists (select 1 from CadrePeer P where P.StampId = new.StampId))
-                or (new.TableName = 'ValidationKey' and not exists (select 1 from ValidationKey V where V.StampId = new.StampId))
-                or (new.TableName = 'Strand' and not exists (select 1 from Strand S where S.StampId = new.StampId))
-                or (new.TableName = 'DeviceToken' and not exists (select 1 from DeviceToken D where D.StampId = new.StampId))
-        ),
-        -- Appending a tombstone is an OWNER action, like every other write in this schema.
-        -- Ungated, any writer that could reach the control database could retire a stamp:
-        -- filing one against a CadrePeer row not visible locally (RowIsGone reads LOCALLY
-        -- VISIBLE rows — see the convergence note above) evicted that peer party-wide AND
-        -- permanently blocked the owner's own later re-admission of it (NotRevoked), and
-        -- filing arbitrary stamps flooded a table whose rows never go away.
-        -- The digest binds the WHOLE row (TableName, RowKey, StampId); the 'CadreControl.Revocation'
-        -- domain tag keeps it disjoint from every other rule — including the
-        -- 'CadreControl.CadrePeer' 'remove' digest the same owner signs in the SAME
-        -- transaction for the delete this tombstone accompanies.
-        -- RowKey is not cross-checked HERE against the retired row: positively binding it (e.g.
-        -- requiring a committed.Strand row carrying the pair) would reject a tombstone re-issued
-        -- in a LATER transaction — which the delete-while-alone durability path
-        -- (docs/architecture.md) plans to do — and reject it outright on a node that never
-        -- converged on the removed row. The binding lives on the other side instead: each
-        -- guarded table's RevocationRecorded requires the tombstone accompanying a DELETE to
-        -- name that row's key, which the re-issue path never trips (it files no delete).
-        -- Residual: a STANDALONE tombstone — owner-signed, naming a stamp no live row holds —
-        -- is still accepted, so an owner can name an id that never existed and thereby
-        -- permanently foreclose CONSENT-seating of that id (Strand.AuthorizedInsert).
-        -- Owner-only, the owner already controls invite issuance, and unbound ids are 128
-        -- random bytes minted at redemption — no escalation (same reasoning as the pre-plant
-        -- note on RowIsGone).
-        -- Reads LIVE OwnerKey (like ValidationKey / Strand / CadrePeer / DeviceToken), not
-        -- committed.OwnerKey. The one difference that makes: a founding transaction on an
-        -- owner-less database could seat an owner key and file a tombstone in one go. An
-        -- owner-less control database is already a total loss, and a second transaction
-        -- achieves the same thing under committed.*, so consistency with the siblings is
-        -- worth more than the distinction — do not "tighten" this without a reason other
-        -- than that one.
-        -- RowIsGone and NoDelete are unchanged: they guard an owner retiring a stamp early
-        -- or withdrawing one later, which authorization does not cover.
-        constraint Authorized check on insert (
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Revocation', 'remove', new.TableName, new.RowKey, new.StampId), context.Signature, A.Key, 'ed25519'))
-        ),
-        -- A re-issue is an OWNER action, like the original append. Distinct 'reissue' action
-        -- tag, so an append approval can never be replayed as a re-issue and vice versa. The
-        -- digest adds ReissuedAt so a captured re-issue signature cannot bump the counter to
-        -- any other value. Reads LIVE OwnerKey, matching Authorized above.
-        constraint AuthorizedReissue check on update (
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey
-                and verify(digest('CadreControl.Revocation', 'reissue',
-                                  new.TableName, new.RowKey, new.StampId, cast(new.ReissuedAt as text)),
-                           context.Signature, A.Key, 'ed25519'))
-        )
-    ) with context (OwnerKey text, Signature text);
-}
-
+export const CONTROL_SCHEMA = `-- This manages a Sereus party's cadre, or set of nodes, and their participation in strands (networks)
+declare schema CadreControl {
+    -- A key that can authorize various control changes
+    table OwnerKey (
+        Key text primary key,
+        StampId text not null unique,   -- per-row authorization nonce, bound into the signed digests below.
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
+                                        -- enrollment signature cannot resurrect a removed owner.
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A
+        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = old.StampId and R.RowKey = old.Key)
+        ),
+        -- A party must never lose its last owner key: every other CadreControl table's
+        -- CHECK requires an OwnerKey row, so an owner-less control database can never
+        -- authorize anything again — emptying this table is a permanent denial of the
+        -- party's control plane. Deferred (subquery), so the count is the POST-delete count.
+        -- NOTE: this is a per-transaction check against locally visible rows. Two
+        -- partitioned nodes that concurrently remove different owners can each see a
+        -- survivor and still converge to zero; if partitioned rotation ever becomes a real
+        -- workflow, the floor needs a cross-node guard, not a local count.
+        constraint MinOneOwner check on delete (
+            (select count(1) from OwnerKey) >= 1
+        ),
+        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer
+        -- updates an OwnerKey row, and a self-rotation branch would double as a sole-owner
+        -- takeover: a deferred post-image count is also true of an update that re-points
+        -- the only row at an attacker key. Mirrors Strand.Manager.NoUpdate.
+        constraint NoUpdate check on update (false),
+        -- NOTE: the domain tag scopes an approval to a table and an action, not to a PARTY. Two
+        -- parties that share an owner key would accept each other's approvals. Fine today (each
+        -- party has its own owner key); if shared-owner multi-party ever ships, bind a party
+        -- identity row into these digests.
+        constraint Authorized check on insert, delete (
+            -- Every authorizer is read from the PRE-transaction snapshot (committed.*):
+            -- this CHECK auto-defers to commit (it has a subquery), by which point the row
+            -- being inserted — and any sibling inserted alongside it — is live, so a plain
+            -- from-OwnerKey would let a row authorize itself, or two strangers seat each
+            -- other. committed.* excludes both, stating the rule directly: the authorizer
+            -- must have existed BEFORE this transaction.
+
+            -- Every signed digest below (and in every other CadreControl table) leads with two
+            -- fixed literals — a 'CadreControl.<Table>' domain tag and an 'add'/'remove'/
+            -- 'vouch'/'publish' action tag (cadre-core control-authorization.ts) — so an
+            -- approval verifies ONLY against the one rule it was minted for. Without them,
+            -- e.g. a ValidationKey enrollment approval covered the identical bytes as an
+            -- OwnerKey enrollment: a narrow grant that doubled as full ownership.
+
+            -- Bootstrap: the FOUNDING transaction — one whose pre-transaction owner set is
+            -- empty — needs no authorization, and every row it inserts rides this branch
+            -- (whoever writes it already owns the party outright, so a co-founder row grants
+            -- nothing a single row would not). Gated on the PRE-transaction count, so a
+            -- same-transaction swap of the sole owner (delete the founder, insert the
+            -- attacker — post-image count still 1) cannot ride it.
+            (old.Key is null and (select count(1) from committed.OwnerKey) = 0)
+
+                -- or a pre-existing owner authorizes by signing over THIS row (Key, StampId)
+                or (old.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.OwnerKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519')))
+
+                -- or a removal authorized by ANOTHER pre-existing owner over the DISTINCT
+                -- 'remove'-tagged digest bound to the stored row's StampId, so an enrollment
+                -- signature can never be replayed as a removal (cf. CadrePeer.AuthorizedDelete).
+                -- A.Key <> old.Key: an owner cannot sign its own removal (no self-resignation).
+                or (new.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and A.Key <> old.Key and verify(digest('CadreControl.OwnerKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519')))
+        )
+    ) with context (OwnerKey text null, Signature text null);
+
+    -- A key that can validate a strand formation disclosure
+    table ValidationKey (
+        Key text primary key,
+        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
+                                        -- enrollment signature cannot resurrect a removed key.
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert naming
+        -- a retired stamp: the approval that seated this row can never re-seat it after removal.
+        -- Same rationale as OwnerKey.NotRevoked, stated in full there.
+        -- NOTE: this table gained a consumer — FormationUsage.Authorized reads it to gate redemption of
+        -- a ValidationUrl invite — so the convergence gap noted on Strand.StampId now has teeth here: on
+        -- a node that has not yet seen the tombstone, a replayed enrollment re-seats the key and it can
+        -- approve redemptions there until the Revocation row arrives. Still no per-request READ surface to
+        -- filter (the gate is a write-time CHECK), so there is nothing to add today; if one appears, filter
+        -- retired stamps there.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = old.StampId and R.RowKey = old.Key)
+        ),
+        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer in the repo
+        -- updates a ValidationKey row. Required because the AuthorizedInsert / AuthorizedDelete
+        -- pair below covers neither update — and a bare \`check\`, which is what this rule used to
+        -- be, covers insert+update but NOT delete. Mirrors OwnerKey.NoUpdate.
+        constraint NoUpdate check on update (false),
+        constraint AuthorizedInsert check on insert (
+            -- Owners authorize by signing over THIS row (Key, StampId); single-use via unique StampId
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
+            -- the STORED row (Key, StampId), so an enrollment approval — which never expires — can
+            -- never be replayed as a removal. Same shape as CadrePeer.AuthorizedDelete.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
+                -- that was offline at removal time may delete the stale row locally with no owner key.
+                -- Why committed.* and why the stamp must be bound: stated in full on
+                -- CadrePeer.AuthorizedDelete.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'ValidationKey' and R.RowKey = old.Key and R.StampId = old.StampId)
+        )
+    ) with context (OwnerKey text, Signature text);
+
+    -- A network of members sharing an sApp database, each contributing peer nodes (their cadre) to the overall cohort
+    -- Cadre peers should participate in each of these strands
+    table Strand (
+        Id text primary key,    -- UUID
+        MemberPrivateKey text null unique,   -- Our private key as a member of this strand
+        Type text, -- Types: 'o' = Open, 'c' = Closed -- Open can still control writes in the sApp, but only Closed controls reads
+        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below).
+        -- NOTE: NotRevoked is a per-transaction check against LOCALLY VISIBLE rows, so a node that
+        -- has not yet converged on the Revocation row can still accept a replayed add and end up
+        -- holding the resurrected strand alongside its tombstone. CadrePeer has a read-side
+        -- mitigation for this class (ControlDatabase.queryCadrePeers drops rows whose stamp is
+        -- retired, so every membership reader inherits it); Strand and ValidationKey deliberately
+        -- do NOT, because neither has a
+        -- per-request authorization surface today. If one ever gains one, filter it there.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey. That is what makes
+        -- the consent branch of AuthorizedInsert below trustworthy: a removal cannot file a
+        -- tombstone that omits or misnames the id it retires.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = old.StampId and R.RowKey = old.Id)
+        ),
+        -- Strand rows are insert + delete only. Required: the consent branch of AuthorizedInsert
+        -- below authorizes by the EXISTENCE of a FormationUsage row naming (new.Id, new.StampId)
+        -- and carries no signature, so while this rule was a bare \`check\` (insert+update) it also
+        -- said "anyone may REWRITE any consent-formed strand, unsigned" — flipping Type to 'o' and
+        -- nulling MemberPrivateKey destroys the party's own membership key for that network in place.
+        -- Mirrors OwnerKey.NoUpdate / FormationInvite.Immutable.
+        constraint NoUpdate check on update (false),
+        constraint AuthorizedInsert check on insert (
+            -- Authorized by an owner signing over THIS row (Id, Type, MemberPrivateKey, StampId); single-use via unique StampId
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'add', new.Id, new.Type, coalesce(new.MemberPrivateKey, ''), new.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or authorized WITHOUT a signature by a redemption record naming THIS EXACT ROW: a
+                -- FormationUsage row carrying both this strand's Id and its one-off StampId
+                -- (control-database.ts:redeemInvitation writes the pair in one transaction; both
+                -- CHECKs defer, so each sees the other's row at commit).
+                --
+                -- Matching the STAMP, not the id alone, is what makes a removal stick. FormationUsage
+                -- is append-only, so a redemption record outlives the strand it formed forever; keyed
+                -- on the id alone it re-authorized ANY later insert of that id, so after a legitimate
+                -- owner-signed, tombstoned removal any writer could re-seat the strand unsigned with a
+                -- fresh StampId (sidestepping NotRevoked, which retires only the removed row's stamp)
+                -- and an ATTACKER-CHOSEN MemberPrivateKey — the party's own secret for that network.
+                -- Bound to the stamp, the removal retires that stamp into Revocation and NotRevoked
+                -- closes this consent record's branch permanently.
+                --
+                -- Beyond the stamp match, the branch is deliberately NARROW — each clause closes one door:
+                --   * Type = 'o' / MemberPrivateKey null — a consent-seated strand looks exactly like
+                --     what the unbound redemption path writes (open, keyless). A closed strand carrying
+                --     a caller-chosen member key (the party's own read-gating secret for that network)
+                --     has no legitimate producer. MemberKeyClosedOnly already implies the second clause
+                --     from the first today; both are stated so this rule does not silently depend on
+                --     another constraint staying as it is.
+                --   * the inner FI.StrandId is null — only an UNBOUND invite may seat a strand at all.
+                --     A bound invite's host strand is owner-provisioned up front; letting the invite
+                --     consent-seat that id would allow an open, keyless downgrade of the real (possibly
+                --     closed, key-bearing) host row on a node where it has not converged yet. The bound
+                --     path records usage only (resolveStrand reports an absent host as missing and the
+                --     formation manager rejects cleanly).
+                --   * the not-exists over OTHER stamps — a strand id may be consent-seated once, EVER.
+                --     FormationUsage is append-only, so the first redemption's record survives a later
+                --     owner-signed removal and permanently forecloses a second consent-seating of the
+                --     id (a spare use of the same token minted a new stamp and rode this branch to
+                --     re-seat the id with an attacker-chosen row). Re-joining a removed id is
+                --     owner-gated: the owner re-seats it signed (fresh stamp, fresh signature) and
+                --     issues a BOUND invite the returning party records consent against — the id is
+                --     not blacklisted, only its unsigned re-seat is. This cannot be weaponised to
+                --     pre-block a legitimate id: StrandExists refuses a usage row naming a strand that
+                --     does not exist, so no usage row can be pre-planted for an unseated id — and ids
+                --     are 128 random bytes anyway.
+                --   * the not-exists over Revocation — a strand id may be consent-seated once EVER
+                --     and never after ANY removal of that id, however it was seated. The usage-row
+                --     rule above binds only ids that ever carried a consent record; an id seated
+                --     purely owner-signed (insertStrand, no usage row) leaves nothing behind on
+                --     removal, so its removal needs its own trace. Every removal files a Revocation
+                --     row naming the removed row's key (RowKey), and this clause refuses any id
+                --     that has ever been tombstoned. RevocationRecorded above makes that trace
+                --     mandatory AND correctly named, so no removal can slip past this clause. The
+                --     usage-row clause is arguably subsumed by this one (a usage row implies the
+                --     strand row existed, and its removal must file a tombstone), but it reaches
+                --     the same conclusion without depending on Revocation at all; both are stated,
+                --     per the style note above. The owner-signed branch is deliberately unaffected,
+                --     so re-join stays owner-gated exactly as described.
+                --     What is NOT schema-verified is a STANDALONE tombstone (one with no
+                --     accompanying delete — see Revocation.Authorized): an owner can file one
+                --     naming an id that never existed and thereby permanently foreclose
+                --     consent-seating of that id — owner-only, the owner already controls invite
+                --     issuance, and unbound ids are 128 random bytes minted at redemption, so no
+                --     escalation (same reasoning as the pre-plant note above).
+                --     NOTE: like NotRevoked above, this is a write-time check against LOCALLY
+                --     VISIBLE rows — a node that has not yet converged on the Revocation row still
+                --     accepts the re-seat. Fails in the safe direction: the tombstone wins after
+                --     merge for the STAMP, and the resurrected row coexists with it (same class as
+                --     the StampId note above).
+                or (
+                    new.Type = 'o'
+                    and new.MemberPrivateKey is null
+                    and exists (
+                        select 1 from FormationUsage FU
+                            where FU.StrandId = new.Id
+                                and FU.StrandStampId = new.StampId
+                                and exists (select 1 from FormationInvite FI where FI.Token = FU.Token and FI.StrandId is null)
+                    )
+                    and not exists (
+                        select 1 from FormationUsage FU2
+                            where FU2.StrandId = new.Id and FU2.StrandStampId <> new.StampId
+                    )
+                    and not exists (
+                        select 1 from Revocation R
+                            where R.TableName = 'Strand' and R.RowKey = new.Id
+                    )
+                )
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
+            -- the STORED row (Id, StampId), so the add approval — which never expires — can never be
+            -- replayed as a removal. Note the consent branch above is deliberately NOT mirrored
+            -- here: an invitation authorizes forming a strand, never destroying one.
+            --
+            -- DELIBERATELY no REAP branch (cf. CadrePeer.AuthorizedDelete): this row carries
+            -- MemberPrivateKey — the party's own membership secret for that network, stored nowhere
+            -- else — so this is the one guarded delete whose effect is unrecoverable, and a stale
+            -- row is already inert for the purpose a tombstone serves (the consent branch of
+            -- AuthorizedInsert above refuses any id ever tombstoned). Do not "fix" the asymmetry;
+            -- tickets/backlog/debt-strand-tombstone-reap.md owns any future change.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'remove', old.Id, old.StampId), context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint MemberKeyClosedOnly check (
+            -- An open strand ('o') has no membership gate, so it must not carry a
+            -- member key. A non-null MemberPrivateKey requires a closed strand ('c').
+            new.MemberPrivateKey is null or new.Type = 'c'
+        )
+    ) with context (OwnerKey text, Signature text);
+
+    -- A peer (node) that is part of the cadre, carrying a self-published,
+    -- freshness-stamped, self-signed address record (see PeerAddressRecord in cadre-core).
+    -- The row IS the peer-address record: a resolver reads it, re-verifies Sig against
+    -- PublicKey, checks freshness (UpdatedAt) and trust, then dials the addrs.
+    table CadrePeer (
+        PeerId text primary key,
+        PublicKey text null,            -- ed25519 (base64url) whose libp2p identity == PeerId (null if non-Ed25519)
+        Multiaddr text,                 -- comma-joined current addrs (signaling / p2p-circuit first)
+        UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay/rollback guard)
+        Sig text null,                  -- ed25519 self-signature over the signed payload (base64url); null until self-published
+        StampId text not null unique,    -- per-row authorization nonce, bound into the voucher/remove digests; rotates on
+                                         -- (re)insert. A removed row's stamp is retired permanently into Revocation
+                                         -- (NotRevoked below), so a captured admission approval cannot re-seat a removed peer.
+        VouchOwner text null,        -- ed25519 (base64url) owner key that vouched this membership (== insert context.OwnerKey)
+        VouchSig text null,              -- that owner's signature over the 'vouch'-tagged digest below (== insert context.Signature). A reader checks VouchOwner against its NODE-LOCAL trusted-owner anchor (not this replicated table, which a self-owner can pollute) to decide authorized membership. The domain/action tags keep this STORED, REPLICATED signature useless against every other rule (pre-tag it satisfied OwnerKey/ValidationKey inserts for Key = PeerId).
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A
+        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = old.StampId and R.RowKey = old.PeerId)
+        ),
+        constraint AuthorizedInsert check on insert (
+            -- Authorized by an owner key, which vouches both membership and the
+            -- PublicKey<->PeerId binding (cadre-core derives PublicKey from PeerId before insert).
+            -- The digest binds PeerId + the single-use StampId nonce (two TEXT fields),
+            -- matching cadre-core peer-authorization.ts:cadrePeerVoucherDigest. The same
+            -- 'vouch'-tagged digest is DELIBERATELY shared with the owner branch of
+            -- AuthorizedUpdate below: both mean "this owner vouches this membership row".
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
+            -- Persist the vouching (owner, signature) onto the row so a reader can later
+            -- re-check VouchOwner against its node-local anchor. The stored pair MUST equal
+            -- the pair the verify above validated, so a writer cannot store a voucher it did
+            -- not actually receive a signature for.
+            and new.VouchOwner = context.OwnerKey
+            and new.VouchSig = context.Signature
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound
+            -- to the row's StampId (cadre-core peer-authorization.ts:cadrePeerRemoveDigest), so
+            -- the stored voucher (a signature over the 'vouch'-tagged digest) can NEVER be
+            -- replayed to authorize a delete. The remove signature rides in context and is never stored.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: this node already holds a COMMITTED tombstone retiring THIS EXACT row
+                -- incarnation, so the party owner has already authorized this row's removal and this
+                -- node is merely catching up. That is what lets a node which was offline at
+                -- revocation time delete the stale row locally, with no owner private key
+                -- (control-database.ts:reapRevokedRow). Same shape as the consent branch of
+                -- Strand.AuthorizedInsert: authorization by the EXISTENCE of a row rather than by a
+                -- signature — and that row is itself owner-signed (Revocation.Authorized), so this
+                -- widens WHO may execute a removal, never WHO may decide one. RevocationRecorded is
+                -- satisfied by the same committed tombstone, so a reap files no second one.
+                --
+                -- committed.Revocation, NOT Revocation — and the stamp clause — are both load-bearing:
+                --   * committed.* : this CHECK defers to commit (it has a subquery), by which point a
+                --     tombstone written in the SAME transaction is live. Reading plain Revocation
+                --     would therefore let deleteGuardedRow's own sibling tombstone satisfy this
+                --     branch, making the 'remove'-tagged delete signature above dead weight and
+                --     collapsing two domain-separated approvals into one. committed.* states the rule
+                --     exactly: the tombstone must have existed BEFORE this transaction.
+                --   * R.StampId = old.StampId : binds the ROW INCARNATION, not the name. One name may
+                --     legitimately carry several tombstones over its life (seat -> delete -> owner
+                --     re-seat -> delete). Without this clause a tombstone from a PREVIOUS incarnation
+                --     would authorize deleting the CURRENT row, which the owner never removed.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'CadrePeer' and R.RowKey = old.PeerId and R.StampId = old.StampId)
+        ),
+        constraint AuthorizedUpdate check on update (
+            -- Peer self-updates its own addrs + freshness, signing with its OWN ed25519 key
+            -- (the key behind PeerId). PeerId/PublicKey/StampId/voucher are immutable on
+            -- self-update, UpdatedAt must strictly increase (replay guard), and Sig is verified
+            -- against the stored PublicKey over the same payload the publish path signs
+            -- (cadre-core peer-record.ts:peerRecordSignedPayload).
+            (
+                new.PeerId = old.PeerId
+                and new.PublicKey = old.PublicKey
+                and new.StampId = old.StampId
+                and new.VouchOwner = old.VouchOwner
+                and new.VouchSig = old.VouchSig
+                and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
+                and verify(
+                        digest('CadreControl.CadrePeer', 'publish', new.PeerId, new.Multiaddr, cast(new.UpdatedAt as text)),
+                        new.Sig, new.PublicKey, 'ed25519')
+            )
+                -- or an owner re-authorizes (rotation / correction): re-vouches the row over
+                -- its current StampId, so the stored voucher is re-bound to the re-authorizing owner.
+                -- StampId is immutable here too: an update that rotated it would leave the OLD
+                -- stamp live-free and untombstoned (RevocationRecorded only retires the stamp a
+                -- delete carries), so the original admission approval — which is stored on the
+                -- replicated row as VouchSig — would resurrect the peer after a later removal.
+                -- Retiring a stamp is delete + Revocation row, never an update.
+                or (
+                    new.StampId = old.StampId
+                    and exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
+                    and new.VouchOwner = context.OwnerKey
+                    and new.VouchSig = context.Signature
+                )
+        )
+    ) with context (OwnerKey text null, Signature text);
+
+    -- A mobile cadre peer's platform push token (FCM/APNs), self-published so a
+    -- server peer can deliver a push-wake to a suspended app over the platform push
+    -- channel (a control-network dial cannot reach an OS-suspended process). The row
+    -- mirrors CadrePeer: a resolver re-verifies Sig against the CadrePeer.PublicKey for
+    -- this PeerId (see device-token.ts:deviceTokenSignedPayload), checks freshness, then
+    -- hands the token to the push sender.
+    table DeviceToken (
+        PeerId text primary key,        -- the CadrePeer this token belongs to
+        Platform text not null,         -- 'fcm' | 'apns'
+        Token text not null,            -- opaque platform device/registration token
+        UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay guard)
+        Sig text null,                  -- ed25519 self-sig over (PeerId|Platform|Token|UpdatedAt)
+        StampId text not null unique,    -- single-use authorization nonce, bound into the add/remove digests;
+                                         -- rotates on (re)insert. A cleared token's stamp is retired permanently
+                                         -- into Revocation (NotRevoked below), so the approval that published a
+                                         -- token cannot re-seat it after the owner cleared it (logout).
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- the clear. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A legitimate
+        -- re-register mints a FRESH StampId and a fresh signature, so it is unaffected. This
+        -- matters more here than the stored-approval case (CadrePeer.VouchSig): a resurrected
+        -- push token has NO freshness ceiling to retire it — cadre-node.ts:resolveDeviceToken
+        -- defaults maxAgeMs to infinity by design — so retirement is the only thing that sticks.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = old.StampId and R.RowKey = old.PeerId)
+        ),
+        constraint AuthorizedInsert check on insert (
+            -- Authorized by an owner key (membership vouch), exactly like CadrePeer.
+            -- The digest binds the WHOLE row behind the domain/action tags — every column,
+            -- with the nullable UpdatedAt/Sig signing as '' when absent (the shape
+            -- FormationInvite and Strand already use) — so a replayed approval can only ever
+            -- reproduce the row it approved, never one carrying attacker-chosen
+            -- Platform/Token/UpdatedAt; NotRevoked above then refuses even that exact row
+            -- once it has been cleared. The DISTINCT 'remove'-tagged digest below keeps a
+            -- captured insert approval from doubling as a delete (and vice versa).
+            -- Mirrors cadre-core peer-authorization.ts:deviceTokenAddDigest.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
+                digest(
+                    'CadreControl.DeviceToken', 'add',
+                    new.PeerId,
+                    new.Platform,
+                    new.Token,
+                    coalesce(cast(new.UpdatedAt as text), ''),
+                    coalesce(new.Sig, ''),
+                    new.StampId
+                ),
+                context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Bound to the STORED row's (PeerId, StampId) — cadre-core
+            -- peer-authorization.ts:deviceTokenRemoveDigest — so the never-expiring insert
+            -- approval can never be replayed as a clear, and a captured clear approval is
+            -- dead once the stamp it names is retired.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.DeviceToken', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
+                -- that was offline at removal time may delete the stale row locally with no owner key.
+                -- Why committed.* and why the stamp must be bound: stated in full on
+                -- CadrePeer.AuthorizedDelete.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'DeviceToken' and R.RowKey = old.PeerId and R.StampId = old.StampId)
+        ),
+        constraint AuthorizedUpdate check on update (
+            -- Peer self-updates its own token, signing with its OWN ed25519 key (the key
+            -- behind PeerId). PeerId and StampId are immutable, UpdatedAt must strictly
+            -- increase (replay guard), and Sig is verified against the stored
+            -- CadrePeer.PublicKey over the signed payload (cadre-core
+            -- device-token.ts:deviceTokenSignedPayload). Platform and Token may change on
+            -- self-update (platform switch / reinstall / rotation).
+            -- StampId is immutable for the reason CadrePeer spells out: an update that
+            -- rotated it would leave the OLD stamp live-free and untombstoned, so retiring a
+            -- stamp stays delete + Revocation row, never an update.
+            -- This is the ONLY branch: there is deliberately NO owner re-touch. The branch
+            -- that used to sit beside it verified an owner signature over the peer id alone
+            -- and sat OUTSIDE the monotonicity requirement, so one captured owner approval
+            -- rewrote Platform/Token and rolled UpdatedAt BACKWARDS — and seating a
+            -- far-future UpdatedAt wedged the peer's own self-updates permanently. No writer
+            -- used it. An owner that must correct a row deletes it (retiring the stamp) and
+            -- inserts a fresh one, the same path it already takes for CadrePeer.
+            new.PeerId = old.PeerId
+            and new.StampId = old.StampId
+            and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
+            and exists (select 1 from CadrePeer P where P.PeerId = new.PeerId and verify(
+                    digest('CadreControl.DeviceToken', 'publish', new.PeerId, new.Platform, new.Token, cast(new.UpdatedAt as text)),
+                    new.Sig, P.PublicKey, 'ed25519'))
+        )
+    ) with context (OwnerKey text null, Signature text);
+
+    -- An open invitation to form a strand with this party
+    table FormationInvite (
+        Token text primary key, -- Just a random string
+        sAppId text, -- The app for the strand that will be formed
+        ExpiresAt datetime null,
+        TotalUses int null check (TotalUses >= 0),
+        ValidationUrl text null,   -- Web hook - send disclosure, IP address...
+        StrandId text null,   -- Host strand this invite binds to (provision-then-record). Non-null => the responder records consent against this pre-existing strand; null => legacy responder-provisions path.
+        StampId text not null unique,   -- single-use authorization nonce (anti-replay)
+        constraint AuthorizedInsert check on insert (
+            -- Authorized by an owner signing over THIS row
+            -- (Token, sAppId, ExpiresAt, TotalUses, ValidationUrl, StrandId, StampId); single-use via unique StampId.
+            -- Nullable bound fields (ExpiresAt/TotalUses/ValidationUrl/StrandId) sign as '' when absent.
+            -- The 'remove'-tagged AuthorizedDelete digest below is DISTINCT, so a captured
+            -- insert approval can never be replayed to revoke-then-reissue an invite (or vice versa).
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
+                digest(
+                    'CadreControl.FormationInvite', 'add',
+                    new.Token,
+                    new.sAppId,
+                    coalesce(cast(new.ExpiresAt as text), ''),
+                    coalesce(cast(new.TotalUses as text), ''),
+                    coalesce(new.ValidationUrl, ''),
+                    coalesce(new.StrandId, ''),
+                    new.StampId
+                ),
+                context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
+                digest(
+                    'CadreControl.FormationInvite', 'remove',
+                    old.Token,
+                    old.sAppId,
+                    coalesce(cast(old.ExpiresAt as text), ''),
+                    coalesce(cast(old.TotalUses as text), ''),
+                    coalesce(old.ValidationUrl, ''),
+                    coalesce(old.StrandId, ''),
+                    old.StampId
+                ),
+                context.Signature, A.Key, 'ed25519'))
+        ),
+        -- Invites are insert/delete only: forbid in-place mutation so the row-bound
+        -- AuthorizedInsert signature cannot be sidestepped by updating consent
+        -- parameters (TotalUses/ExpiresAt/...) after a legitimate insert. A bare check
+        -- defaults to insert+update; the checks on insert / on delete above exclude update,
+        -- so this guard is required. Mirrors FormationUsage.InsertOnly.
+        constraint Immutable check on update (false)
+    ) with context (OwnerKey text, Signature text);
+
+    table FormationUsage (
+        Token text not null,            -- the FormationInvite this acceptance redeems. Stated explicitly because
+                                        -- Token is no longer a primary-key prefix; Authorized below would refuse a
+                                        -- null anyway (null = null is never true, so its FormationInvite
+                                        -- exists-clause cannot match), but the column carries the invariant rather
+                                        -- than leaving it to a CHECK.
+        UsageStampId text not null,     -- single-use nonce for THIS redemption, and this table's PRIMARY KEY.
+                                        -- The JOINING peer mints it and sends it in its contact message, having
+                                        -- signed it into its own 'consent' digest (PeerConsented below); the
+                                        -- responder inserts that same value and asks the approver about it, so it
+                                        -- is bound into the 'vouch' digest below too and one sign-off is spendable
+                                        -- exactly once. Neither side can swap it: a substituted nonce fails the
+                                        -- joiner's consent signature.
+                                        -- As the row key, a verbatim replay of an approval collides on the
+                                        -- primary key locally instead of on a column \`unique\`. Unlike every other
+                                        -- StampId in this schema, this table is append-only (InsertOnly below),
+                                        -- so the nonce is never freed by a delete: the key alone makes it
+                                        -- permanent and there is deliberately NO NotRevoked / RevocationRecorded
+                                        -- pair here — do not go looking for the missing one.
+                                        -- NOTE: the key is evaluated against LOCALLY VISIBLE rows, so two nodes
+                                        -- that have not yet converged could each admit the same nonce and both
+                                        -- rows survive the merge. Same class as the NotRevoked convergence notes
+                                        -- on OwnerKey / Strand / ValidationKey; the digest binding still holds on
+                                        -- both nodes, so the outcome is a duplicated audit row, never a join
+                                        -- nobody approved.
+        PeerKey text not null,          -- the joining peer's own ed25519 public key (base64url, 32 bytes), bound
+                                        -- into BOTH the approver's 'vouch' digest and the joiner's 'consent'
+                                        -- digest below, so an approval cannot be re-filed under a different
+                                        -- joiner's name and the named joiner provably agreed (PeerConsented).
+                                        -- The key IS the joiner's identity — its libp2p peer id is derivable
+                                        -- (identity multihash of these bytes), never stored here.
+        PeerSig text not null,          -- the joining peer's signature over the 'consent' digest — see
+                                        -- PeerConsented below for what it proves and why it is stored on the row.
+        Disclosure text,
+        StrandId text,
+        StrandStampId text not null,   -- the Strand.StampId this consent record authorizes. Consent is
+                                       -- bound to ONE strand ROW, not to a strand id forever — see
+                                       -- Strand.AuthorizedInsert's consent branch for why. NOT unique:
+                                       -- in the bound (provision-then-record) path several invitees
+                                       -- each write a usage row against the SAME host strand, so many
+                                       -- usage rows legitimately share one stamp.
+        primary key (UsageStampId),
+        constraint InsertOnly check on update, delete (false),
+        constraint Authorized check on insert (
+            -- Satisfies an invitation
+            exists (
+                select 1 from FormationInvite FI
+                    where FI.Token = new.Token
+                        -- The use cap is COUNTED against the pre-transaction snapshot, never
+                        -- sequenced. This CHECK auto-defers to commit (it has a subquery), by
+                        -- which point the in-flight row is live; committed.* is what excludes
+                        -- it, so a sequentially exhausted invite — every seat already committed
+                        -- on this node — is still refused here. What is deliberately NOT
+                        -- refused: concurrent redeemers on separate nodes (or nodes that have
+                        -- not yet converged) each count the same committed snapshot and both
+                        -- land, over-admitting by at most the number of concurrent redeemers.
+                        -- Both rows survive in this append-only record, so the overage is
+                        -- auditable, and removal is owner-gated (member removal + Revocation).
+                        -- Same class as the convergence note on UsageStampId above.
+                        -- One rule for FUTURE writers: two FormationUsage rows for one token
+                        -- inserted in ONE transaction each read the same committed count, so
+                        -- they can jointly exceed the cap. No writer in this repo does that; it
+                        -- is a constraint on new writers, not a case to engineer for.
+                        -- Do not "fix" this into a per-token sequence number to restore a
+                        -- strict cap — that trade was weighed and rejected (2026-08-04): a
+                        -- fought-over sequence key turns a concurrent redemption into a silent,
+                        -- unrecoverable loss of a consented join, which is strictly worse than
+                        -- a visible, reversible over-admission.
+                        and (FI.TotalUses is null or FI.TotalUses > (select count(1) from committed.FormationUsage U where U.Token = new.Token))
+                        and (FI.ExpiresAt is null or FI.ExpiresAt > context.Now)
+                        -- An invite carrying a ValidationUrl demands a sign-off from a key the party
+                        -- ENROLLED in ValidationKey. The signature is verified against the STORED VK.Key,
+                        -- NOT against context.ValidationKey — that distinction is the whole point:
+                        -- context.ValidationKey is a plain insert parameter, so verifying against it asked
+                        -- only "did the redeemer sign its own disclosure with SOME key it holds?", which any
+                        -- redeemer answers by minting a throwaway keypair. context.ValidationKey survives
+                        -- purely to SELECT which enrolled row is being claimed; naming an enrolled key while
+                        -- signing with a different one fails the verify against VK.Key.
+                        --
+                        -- Deliberate: CHECKs run on write only, so removing a validation key later does NOT
+                        -- re-examine the FormationUsage rows it already approved. The sign-off was valid when
+                        -- given and the strand it authorized stays formed; removal narrows who may approve
+                        -- FUTURE redemptions, it is not a retroactive revocation of past ones.
+                        --
+                        -- What ONE sign-off buys: exactly ONE row. The digest covers
+                        -- (Token, UsageStampId, StrandId, PeerKey, Disclosure), so an approval is NOT
+                        -- transferable across invitations, redemptions, networks, joiners, or disclosure
+                        -- text. Replay is closed twice over, by two independent mechanisms: presenting an
+                        -- approval VERBATIM repeats its UsageStampId and is refused by this table's
+                        -- primary key; presenting it under any OTHER redemption changes a signed field
+                        -- and fails this verify.
+                        -- Every signed field is supplied by the redeeming side — nothing derived from
+                        -- the table's current state is bound — so no concurrent write can invalidate an
+                        -- approval between the sign-off and the row landing.
+                        -- Why StrandStampId is deliberately NOT bound: it names the strand ROW
+                        -- incarnation, which the unbound path (redeemInvitation) mints inside its own
+                        -- transaction, and it adds nothing on top of a strictly single-use approval —
+                        -- StrandId already pins WHICH network the approver approved joining.
+                        and (FI.ValidationUrl is null or exists (
+                            select 1 from ValidationKey VK
+                                where VK.Key = context.ValidationKey
+                                    and verify(digest('CadreControl.FormationUsage', 'vouch', new.Token, new.UsageStampId, new.StrandId, new.PeerKey, new.Disclosure), context.ValidationSignature, VK.Key, 'ed25519')))
+                        -- A bound invite (non-null StrandId) may only ever name its own host strand:
+                        -- without this, any holder of a bound token could record consent against an
+                        -- arbitrary strand id — annotating an unrelated strand, or (before
+                        -- Strand.AuthorizedInsert's consent branch was narrowed to unbound invites)
+                        -- consent-seating that id outright.
+                        -- NOTE: an UNBOUND invite is deliberately left free to name any strand, so a
+                        -- holder can spend a use appending a consent row to an unrelated existing
+                        -- strand. Harmless today (the row grants nothing, it only burns a use and
+                        -- forecloses that id's consent-seating, which is the safe direction); if
+                        -- unlimited-TotalUses invites ever become common, this is an append-only
+                        -- growth surface worth bounding.
+                        and (FI.StrandId is null or FI.StrandId = new.StrandId)
+            )
+        ),
+        -- Matched on the (id, stamp) PAIR, the same key Strand.AuthorizedInsert's consent branch
+        -- reads back: a usage row may only ever name a strand ROW that exists, so a consent record
+        -- can never be filed against a stamp of the writer's choosing and held in reserve to
+        -- re-seat the id after a removal.
+        constraint StrandExists check (exists (select 1 from Strand S where S.Id = new.StrandId and S.StampId = new.StrandStampId)),
+        -- The JOINING peer proves it consented to this redemption: PeerKey is its own ed25519
+        -- public key and PeerSig is its signature over the 'consent'-tagged digest below.
+        -- Unlike the approver's sign-off (context.ValidationSignature, checked against a STORED
+        -- ValidationKey row), the identity here IS the key, so there is no enrolled row to look
+        -- up and nothing for a writer to substitute: a forged joiner would need that joiner's
+        -- private key. Stored rather than passed in context so any later reader can re-check it
+        -- (verifyFormationConsent); the 'consent' action tag keeps this replicated signature
+        -- useless against every other rule in this schema (notably the approver's 'vouch'
+        -- digest over the same table).
+        -- NOTE: StrandId is deliberately NOT in this digest — the joiner cannot know it when it
+        -- signs (a bound invite's host strand arrives only in the result frame; an unbound
+        -- strand is responder-minted). The responder cannot substitute a strand anyway: bound
+        -- invites are pinned by Authorized's FI.StrandId check, unbound invites mint fresh.
+        constraint PeerConsented check on insert (
+            verify(digest('CadreControl.FormationUsage', 'consent',
+                          new.Token, new.UsageStampId, new.PeerKey, new.Disclosure),
+                   new.PeerSig, new.PeerKey, 'ed25519')
+        ),
+    -- Context here is only what the approver-side rules read: Now for expiry, and the
+    -- ValidationKey/ValidationSignature pair for the 'vouch' check in Authorized. The joiner's
+    -- signature is NOT context — it lives on the row (PeerSig, verified by PeerConsented above).
+    ) with context (Now datetime, ValidationKey text null, ValidationSignature text null);
+
+    -- Token is no longer a primary-key prefix (the key is the redemption nonce), so the
+    -- per-token filters — the cap count in Authorized above, and cadre-core's
+    -- countFormationUsage / isTokenUsed / hasOutstandingFormationInvite — get an index
+    -- rather than a table scan.
+    index FormationUsageByToken on FormationUsage (Token);
+
+    -- Append-only retirement record for the one-off StampId nonces of removed OwnerKey /
+    -- CadrePeer / ValidationKey / Strand rows. Without it a removal was undoable: the add
+    -- approval is a signature over
+    -- (row key, stamp) that never expires, and deleting the row freed the stamp, so anyone who
+    -- kept a copy of the approval could resurrect the row.
+    -- Each tombstone also records WHICH row was retired (RowKey below): the consent branch of
+    -- Strand.AuthorizedInsert reads it to refuse consent-seating any strand id that has ever
+    -- been removed, whichever way it was seated.
+    -- NOTE: the guarded tables' NotRevoked CHECK runs against locally visible rows, so a node
+    -- that has not yet converged on a Revocation row can still accept the replayed add, and the
+    -- resurrected row coexists with the tombstone after merge — same class as the MinOneOwner
+    -- note on OwnerKey. The read-side mitigation is ControlDatabase.queryCadrePeers, which
+    -- drops any CadrePeer row whose StampId appears here; every membership reader inherits it.
+    -- NOTE: append-only, so this table only ever grows. Every append is owner-signed
+    -- (Authorized below), so the growth surface is the owner keys, not every writer that can
+    -- reach the control database. Cadres are a handful of peers and owner rotation is rare, so
+    -- unbounded growth is fine today; revisit if either changes.
+    -- A tombstone committed while the node was alone is local-only (never broadcast); the
+    -- ReissuedAt counter below exists so an owner can re-write — and therefore re-broadcast —
+    -- such a tombstone once peers are reachable, without changing what it means.
+    table Revocation (
+        TableName text,             -- 'OwnerKey' | 'CadrePeer' | 'ValidationKey' | 'Strand' | 'DeviceToken' (confined by RowIsGone below)
+        RowKey text not null,       -- primary key of the removed row: OwnerKey.Key / ValidationKey.Key /
+                                    -- CadrePeer.PeerId / DeviceToken.PeerId / Strand.Id
+                                    -- Every guarded table's RevocationRecorded CHECK requires the
+                                    -- accompanying tombstone to carry the removed row's key here, so
+                                    -- a REMOVAL cannot file a misnamed tombstone. A tombstone with no
+                                    -- accompanying delete is not covered by that (see Authorized).
+        StampId text,               -- the retired nonce
+        -- Bumped by an owner-signed re-issue so a tombstone written while the node was alone
+        -- (committed local-only, never broadcast) can be re-written and therefore re-broadcast
+        -- on cohort growth. Carries NO semantics: nothing reads it, and retirement is decided
+        -- by the row's existence, not by this value.
+        ReissuedAt integer not null default 0,
+        -- Keyed on the stamp, not the RowKey: stamps are unique per row incarnation, and one
+        -- name may legitimately carry several tombstones over its life (seat -> delete ->
+        -- owner re-seat -> delete).
+        primary key (TableName, StampId),
+        -- Retirement is permanent: a tombstone may never be withdrawn.
+        constraint NoDelete check on delete (false),
+        -- Pinned at 0 on insert so an owner cannot seat a tombstone at a saturated counter and
+        -- thereby freeze its own later re-issues (ReissueOnly below). Deliberately NOT folded
+        -- into the Authorized digest: the value is fixed by this rule, so signing over it would
+        -- only widen the signed surface for no gain, and would invalidate every existing
+        -- insert-side digest.
+        constraint FreshTombstone check on insert (new.ReissuedAt = 0),
+        -- A re-issue may move NOTHING but the counter, and only upward. Without the identity
+        -- clause an "update" would be a way to re-point a tombstone at a different row,
+        -- restoring exactly the replay this table exists to stop.
+        constraint ReissueOnly check on update (
+            new.TableName = old.TableName and new.RowKey = old.RowKey
+                and new.StampId = old.StampId and new.ReissuedAt > old.ReissuedAt
+        ),
+        -- A stamp may only be retired once its row is actually gone. Deferred (subquery), so a
+        -- delete in the same transaction has already landed. Retiring a stamp that never
+        -- existed is permitted and harmless: a stamp carries 128 bits of CSPRNG output
+        -- (control-database.ts:generateStampId — 16 bytes of sha256(PeerId) followed by 16
+        -- random bytes), so a future legitimate one cannot be guessed and pre-planted.
+        -- Deliberately keyed on the STAMP only, not RowKey: checking "no live row named
+        -- new.RowKey" breaks under out-of-order convergence — a peer removed (tombstone names
+        -- it, stamp1) then re-admitted (stamp2) would leave a node that converges on the
+        -- re-add FIRST rejecting the stamp1 tombstone forever, never learning that stamp is
+        -- retired. The stamp-only form passes there (stamp1 is not live).
+        constraint RowIsGone check on insert (
+            (new.TableName = 'OwnerKey' and not exists (select 1 from OwnerKey K where K.StampId = new.StampId))
+                or (new.TableName = 'CadrePeer' and not exists (select 1 from CadrePeer P where P.StampId = new.StampId))
+                or (new.TableName = 'ValidationKey' and not exists (select 1 from ValidationKey V where V.StampId = new.StampId))
+                or (new.TableName = 'Strand' and not exists (select 1 from Strand S where S.StampId = new.StampId))
+                or (new.TableName = 'DeviceToken' and not exists (select 1 from DeviceToken D where D.StampId = new.StampId))
+        ),
+        -- Appending a tombstone is an OWNER action, like every other write in this schema.
+        -- Ungated, any writer that could reach the control database could retire a stamp:
+        -- filing one against a CadrePeer row not visible locally (RowIsGone reads LOCALLY
+        -- VISIBLE rows — see the convergence note above) evicted that peer party-wide AND
+        -- permanently blocked the owner's own later re-admission of it (NotRevoked), and
+        -- filing arbitrary stamps flooded a table whose rows never go away.
+        -- The digest binds the WHOLE row (TableName, RowKey, StampId); the 'CadreControl.Revocation'
+        -- domain tag keeps it disjoint from every other rule — including the
+        -- 'CadreControl.CadrePeer' 'remove' digest the same owner signs in the SAME
+        -- transaction for the delete this tombstone accompanies.
+        -- RowKey is not cross-checked HERE against the retired row: positively binding it (e.g.
+        -- requiring a committed.Strand row carrying the pair) would reject a tombstone re-issued
+        -- in a LATER transaction — which the delete-while-alone durability path
+        -- (docs/architecture.md) plans to do — and reject it outright on a node that never
+        -- converged on the removed row. The binding lives on the other side instead: each
+        -- guarded table's RevocationRecorded requires the tombstone accompanying a DELETE to
+        -- name that row's key, which the re-issue path never trips (it files no delete).
+        -- Residual: a STANDALONE tombstone — owner-signed, naming a stamp no live row holds —
+        -- is still accepted, so an owner can name an id that never existed and thereby
+        -- permanently foreclose CONSENT-seating of that id (Strand.AuthorizedInsert).
+        -- Owner-only, the owner already controls invite issuance, and unbound ids are 128
+        -- random bytes minted at redemption — no escalation (same reasoning as the pre-plant
+        -- note on RowIsGone).
+        -- Reads LIVE OwnerKey (like ValidationKey / Strand / CadrePeer / DeviceToken), not
+        -- committed.OwnerKey. The one difference that makes: a founding transaction on an
+        -- owner-less database could seat an owner key and file a tombstone in one go. An
+        -- owner-less control database is already a total loss, and a second transaction
+        -- achieves the same thing under committed.*, so consistency with the siblings is
+        -- worth more than the distinction — do not "tighten" this without a reason other
+        -- than that one.
+        -- RowIsGone and NoDelete are unchanged: they guard an owner retiring a stamp early
+        -- or withdrawing one later, which authorization does not cover.
+        constraint Authorized check on insert (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Revocation', 'remove', new.TableName, new.RowKey, new.StampId), context.Signature, A.Key, 'ed25519'))
+        ),
+        -- A re-issue is an OWNER action, like the original append. Distinct 'reissue' action
+        -- tag, so an append approval can never be replayed as a re-issue and vice versa. The
+        -- digest adds ReissuedAt so a captured re-issue signature cannot bump the counter to
+        -- any other value. Reads LIVE OwnerKey, matching Authorized above.
+        constraint AuthorizedReissue check on update (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey
+                and verify(digest('CadreControl.Revocation', 'reissue',
+                                  new.TableName, new.RowKey, new.StampId, cast(new.ReissuedAt as text)),
+                           context.Signature, A.Key, 'ed25519'))
+        )
+    ) with context (OwnerKey text, Signature text);
+}
+
 apply schema CadreControl;`;
 //# sourceMappingURL=control-schema.js.map