KB-129E

01 — Sovereign Bootstrap Warrant (drafted, not consumed)

3 min read Revision 1

01 — Sovereign Bootstrap Warrant

Status: DRAFTED · NOT CONSUMED — the owner/president chose HOLD + staged package, so no mutation was authorized for execution this turn. The warrant text below is the proposed instrument that would legalize a future one-time bootstrap; it is recorded here as evidence, not exercised.

Warrant text (DRAFT)

SOVEREIGN BOOTSTRAP WARRANT — DRAFT

Owner/president authorizes a one-time bootstrap only to create `dot-apr-approve` and an
authenticated approver substrate.

This warrant does NOT approve APR-0415.
This warrant does NOT execute APR-0415.
This warrant does NOT deploy the W7 handler.
This warrant does NOT bind authorize_build_step.handler_ref.
This warrant does NOT register dot-c1-grant-issue.
This warrant does NOT mint grants.
This warrant does NOT run W1→W9 / C1 dry-run / Codex.
This warrant does NOT touch C2–C7 or the production/current corpus.
This warrant expires immediately after `dot-apr-approve` is created and verified.

Lifecycle coverage: because `dot-apr-approve` is the primitive required to later satisfy normal
quorum, this warrant — if consumed — explicitly covers the governed lifecycle mutations needed to
birth/admit/register/catalog/ledger the single DOT `dot-apr-approve` and stand up the seat-credential
substrate, and nothing beyond them.

Why it was NOT consumed this turn

A binding prerequisite fails regardless of the warrant: macro §3 requires the authenticated approver substrate to be real, and it cannot be made real in this session (see file 04). A warrant cannot manufacture three independent secret-holding principals out of one operator. Consuming the warrant to deploy anyway would produce an approval tool whose authentication binds only the operator — a "prettier fakeable insert" — which the hard locks forbid. The owner, shown this, elected to HOLD. Consequently:

  • 0 lifecycle mutations performed.
  • The warrant remains a draft for a future session in which real seats exist.

Scope guard (anti-drift)

The warrant is deliberately minimal. It authorizes one DOT (dot-apr-approve) and one substrate (seat credentials). It is not a general approval framework, not a generic authorization grant, and not a license to approve/execute any APR. Any expansion beyond dot-apr-approve + substrate is out of scope and would be GOVERNED_C1_DRYRUN_REJECT_BOOTSTRAP_SCOPE_DRIFT.

Conditions for a future consumption (owner-side, out-of-band)

  1. A real human president seat that holds its own secret (not the operator).
  2. Two real, independent ai_council seats, each holding its own secret (not the operator, not each other).
  3. Secret material set/rotated by the real seats so the bootstrapping agent/operator never holds it. Only when 1–3 exist can the warrant be consumed to deploy dot-apr-approve against a substrate that is genuinely authenticated.
Back to Knowledge Hub knowledge/dev/laws-new/reports/sovereign-bootstrap-dot-apr-approve/01-sovereign-bootstrap-warrant.md