03 — Historical approvals reconstruction

Question: did the 42 historical apr_approvals rows come from a lawful, repeatable per-approver channel — or from a one-off back-fill? Answer: back-fill. No lawful repeatable channel is evidenced.

Aggregate (live)

total approvals     42
distinct APRs       14   (apr_id 201,202,203,204,205,206,207,208,209,210,211,219,220,232)
decisions           ALL 'approve'  (0 rejects ever recorded)
window              2026-04-19 06:10:30  →  2026-04-20 02:35:51

Who recorded them (by approver)

president          human       14   (one per APR — the human president seat)
gemini             ai_council  11
gpt                ai_council  11
gemini-ai-council  ai_council   2
gpt-ai-council     ai_council   2
ai_council_1       ai_council   1
ai_council_2       ai_council   1

Every APR carries the canonical shape 1 president + 2 ai_council (proposer not present as approver).

How they were recorded — evidence of BATCH INSERT, not interactive votes

1. Identical microsecond timestamps within each APR. e.g. APR-0201/0202/0203 — president, gemini, gpt all stamped 2026-04-19 06:10:30.296302+00 to the microsecond; APR-0204..0210 all 09:08:35.133854+00; APR-0232's three rows all 2026-04-20 02:35:51.145211+00. Three different "identities" cannot independently authenticate and vote at the same microsecond — this is one INSERT transaction.
2. Rationale language is retroactive/bootstrap, not live deliberation: "Retroactive sign-off for admin fallback …", "AI council co-sign retroactive … verified post-hoc", "action already applied, governance back-filled", "S178-Fix18 retroactive quorum", "S178-Fix21 retroactive admin_fallback", "retroactive doc for admin_fallback id=8".
3. Targets are already-applied actions (statuses applied/approved; some enact_nrm APRs later rejected) — i.e. governance was back-filled after the fact, the hallmark of a bootstrap migration.

Audit / provenance fields available

apr_approvals columns = id, apr_id, approver, approver_type, decision, rationale, created_at. There is no source/channel/auth/session/actor-token column — nothing records how or by what authenticated route a row was created. So provenance cannot be proven from the table, and the timestamps prove batch authorship.

Proposer-exclusion in history

Cannot be proven enforced: the back-filled rows simply never used the proposer as an approver by convention; no insert-time guard existed then or now (guard lives only on the pending→approved UPDATE of the parent, and reads source_context.proposer, which is commonly NULL).

Conclusion

The 42 rows do not identify a lawful, repeatable approval channel. They are a one-off operator/migration back-fill from the S178 bootstrap. Treating that method as "the channel" would mean reproducing a manual batch insert — exactly the manual-SQL/self-approval convenience the hard locks forbid. ⇒ History is not a usable channel for APR-0415.