00 — Human Ratification Handoff: Overview & State Recovery

Package: one-roof-human-ratification-handoff-2026-06-02 Mission: PREPARE_HUMAN_RATIFICATION_HANDOFF_AND_POST_RATIFY_BUILD_GATE Mode: human handoff + post-human verification design. NO BUILD. NO PG COMMIT. NO LIVE MUTATION. Date: 2026-06-02 This package is text, not an act. Nothing here has been executed. The human ratification has NOT happened.

---

0.1 Why this package exists

The auth-model ratification intake is published and verified in KB and accepted by GPT council. Status is READY_FOR_HUMAN; persistent BUILD: NO-GO. The only remaining blocker is a human-only constitutional act — it cannot be performed, recorded, or simulated by any Agent.

GPT's accepted next macro (verbatim intent): "Prepare and route the human ratification packet: extract the exact human actions, produce a one-page checklist, prepare verification queries for after the human act, and define the next build macro that may run only after the human ratification exists." This package is that deliverable.

0.2 The remaining blocker (the one gate, B-RATIFY)

ID	Decision	Plain meaning
D-BOOT-1	Redefine M-1 from "any os_proposal_approvals row exists" to per-step SB-0 technical build authorization (governance_build_authorization, L3 grant recomputed from L2 quorum).	The build "go" key stops being a single sales e-sign row and becomes one explicit grant per build step.
D-BOOT-2	Adopt SB-0 governance_build_authorization as the L3 technical build gate, and reserve os_proposal_approvals for L4 sovereign e-sign only.	Technical build permission (L3) and sovereign sign-off (L4) become two distinct surfaces; the sales e-sign table is no longer the build key.

Enacting D-BOOT-1 + D-BOOT-2 requires one-time L2 council quorum + L4 sovereign e-sign — both human/sovereign, out-of-band, in Directus. (R-REQ; intake doc 01 §1.5.) No Agent-recordable path exists (enactment = forgery; intake-request blocked by no governance action-type + constitutional origination must be human + no-mutation scope; D-PATH, intake doc 03.)

0.3 Live state recovery (read-only, 2026-06-02, this run)

Re-verified live this run via read-only SELECT against PostgreSQL (directus DB):

os_proposal_approvals          = 0        ← L4 sovereign e-sign gate UNSATISFIED
approval_requests              = 211
apr_approvals                  = 42
apr_action_types               = 6        ← add_field, amend_law, create_item, enact_nrm,
                                            patch_ops_code, update_item
                                            (NO governance build-auth type → SB-1 unbuilt)
governance_build_authorization = ABSENT   ← SB-0 not built
axis_registry / axis_assignment = ABSENT  ← axis substrate not built
APR-BOOT-AUTHMODEL-1 in approval_requests = 0  ← the ratification request has NOT been filed
idle_in_transaction (workflow_admin)      = 0  ← no leaked/open transactions

This reading is identical to the published intake/verification run. The authorization gate is unchanged and UNSATISFIED. The human act has not occurred.

0.4 Schema facts that shape the human steps and the verification queries

Verified live this run (column inventories):

• approval_requests has NO quorum_passed column. Earlier intake prose referenced approval_requests.quorum_passed; that is not a stored column. Quorum is enforced by the trigger fn_apr_quorum_check (returns trigger, fires on apr_approvals writes), which moves approval_requests.status pending → approved. Verification therefore checks status='approved' + the underlying votes — it must NOT call the function standalone and must NOT hand-edit status.
• apr_approvals columns: id, apr_id, approver, approver_type, decision, rationale, created_at. Quorum rule (high-risk): ≥1 president-human (approver ILIKE '%president%' and a human approver — F-AUTH-LIVE-1: identified by name+human, not by approver_type='president'), ≥2 ai_council, 0 rejects, proposer excluded.
• os_proposal_approvals columns include signature_text, signature_image, first_name, last_name, email, esignature_agreement, proposal, ip_address, metadata. This is the interim L4 surface; the genuine signer is the President, out-of-band.
• approval_requests has code, action, proposed_action_code, status, proposed_action, title, evidence, source, priority, request_type — the fields the human author fills (doc 02/03).

0.5 What this package contains

Doc	Purpose
00 (this)	Overview + live state recovery
01-one-page-human-checklist.md	One-page, non-technical ratification checklist
02-l2-council-and-l4-sovereign-wording.md	Copy-paste approval / e-sign wording for D-BOOT-1/D-BOOT-2; L2 vs L4 explicit
03-directus-manual-action-guide.md	Exact Directus/manual action list for L2 + L4
04-post-human-verification-checklist.md	Exact read-only verification queries to run after the human act
05-next-build-gate-and-prompt.md	Exact GO condition + a next-build prompt that hard-stops unless ratification is verified
06-self-review.md	Self-review + forbidden-compliance
07-closing-pointer.md	One-line routing pointer

0.6 Status line

READY_FOR_HUMAN. Persistent BUILD: NO-GO until the human L2 + L4 act is performed and later verified live. No claim is made that ratification has happened — it has not.

0.7 Cross-links

• routes [[one-roof-auth-model-ratification-intake-2026-06-02]] doc 04 (human packet) to execution.
• sustained by [[auth-model-ratification-intake-publication-verification-and-final-routing-2026-06-02]].
• accepted-next-macro from [[gpt-review-ratification-intake-published-ready-for-human-no-build-2026-06-02]].
• build sequence in [[one-roof-auth-axis-bootstrap-ratification-rehearsal-go-nogo-2026-06-02]] doc 07/08 and [[one-roof-axis-auth-proposal-operational-hardening-build-ready-design-2026-06-02]] doc 02/12.