P3D Birth — B2 Contract Rev3 + B3-F1c-H Wrapper / system_health_checks Integration Design

Doc rev: 2 (dual-trigger patch) Date: 2026-05-14 Mode: DESIGN ONLY — no execution, no mutation, no file change, no DDL, no DML, no cron change, no wrapper creation, no row INSERT, no manual dot-dot-health invocation, no fn_birth_onboarding_full_scan invocation. Author: Claude (Opus 4.7, 1M context) Patch motivation (this rev): knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b2-rev3-b3f1c-h-design-dual-trigger-patch-required-2026-05-14.md — adds the dual-trigger / never-wait operational principle and demotes cron observation from gate to diagnostic. Predecessors (PASS evidence):

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-b3-eld-exec-ddl-execution-report.md

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-b3f1c-g-vps-scheduler-repair-execution-report.md

knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3-eld-exec-and-b3f1c-g-execution-pass-next-steps-2026-05-14.md Lineage:

B2 Rev2: knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b2-contract-design.md

Probe (signature gap proof): knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-probe-report.md

Full-scan SQL Rev3: knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-function.sql.md

0. Hard-boundary attestation (design session)

Boundary	Held
No PG mutation	YES — no SQL run
No DDL	YES
No DML	YES
No file change (other than this design doc + companion report)	YES
No cron change	YES
No wrapper creation (function only sketched, not compiled)	YES
No `system_health_checks` INSERT	YES
No `dot_tools` mutation	YES
No manual `dot-dot-health` trigger	YES
No `fn_birth_onboarding_full_scan` invocation	YES
No Phase 5C2 work	YES
No UI cutover	YES

1. Inputs accepted as ground truth

Fact	Source
`birth_registry.canonical_address text NULL` landed	B3-ELD-EXEC report §5a
`birth_registry.owner text NULL` landed	B3-ELD-EXEC report §5a
`birth_registry.jsonb_profile jsonb NOT NULL DEFAULT '{}'::jsonb` landed	B3-ELD-EXEC report §5a
Row count unchanged 280,854 → 280,854	B3-ELD-EXEC report §5c
All existing rows received `'{}'::jsonb` via DEFAULT; null=0, non-empty=0	B3-ELD-EXEC report §5b
dot-dot-health now accepts `--local	--cloud` as no-op
Safe `BASH_SOURCE[0] == "$0"` source guard installed	B3-F1c-g report §5 (V3)
Cron line unchanged	B3-F1c-g report §7
Function executor signature = `public.<ref>(jsonb) RETURNS boolean`, RW mode, text-cast equality `t/true/f/false`	B3-F1c-e probe §1 / §7
`fn_birth_onboarding_full_scan()` signature = `() RETURNS jsonb`	B3-F1c-e probe §7
`system_health_checks` schema = 13 cols	B3-F1c-e probe §2a
Current function-type checks count = 0	B3-F1c-e probe §3
dot-dot-health jurisdiction hardcoded `NRM-LAW-35-V5P2`; no CLI/env override	B3-F1c-e probe §5
`dot-dot-health` source-time references to `--dry-run` and `--only-check` exist in parse_args	B3-F1c-e probe §5 — but flag-existence ≠ proof of mutation-safety; see §6.3

2. B2 Contract Rev3 — birth metadata contract update

2.1 Delta from Rev2 (2026-05-12)

Rev2 stated: "9/10 supported, owner ABSENT". After B3-ELD-EXEC the storage gap is closed for the placeholder layer. Rev3 ratifies this in the contract.

Field	Rev2 state	Rev3 state
`canonical_address`	Not a column	text NULL — PLACEHOLDER_AT_BIRTH
`owner`	ABSENT (rev2 §2 note)	text NULL — PLACEHOLDER_AT_BIRTH (resolution algorithm from rev2 §3 unchanged; result now materialized on this column)
`jsonb_profile`	Not a column	jsonb NOT NULL DEFAULT `'{}'` — REQUIRED_AT_BIRTH (with empty-object default satisfying NOT NULL at insert time)
`identity_profile`	Per-entity-kind, not central	UNCHANGED — NOT_CENTRAL_BIRTH_REGISTRY
5 coverage statuses (rev2 §6)	unchanged	unchanged
Governance Operating Model (rev2 §7)	unchanged	unchanged
Universal birth address `(collection_name, entity_code)` (rev2 §4)	unchanged	unchanged
8 relation hooks (rev2 §5)	unchanged	unchanged

2.2 Class definitions (Rev3 normative)

Class	Meaning
REQUIRED_AT_BIRTH	Must be present at `INSERT INTO birth_registry`. For NOT NULL columns, the value (including a default like `'{}'`) is contractually present. Reads MUST find a value here.
PLACEHOLDER_AT_BIRTH	Column is nullable; at birth the value MAY be NULL (or a documented sentinel). Downstream resolver fills it. Readers MUST treat NULL as expected-at-birth, not as an anomaly.
ENRICHED_LATER	Not a column on `birth_registry` directly; the enrichment lands in `jsonb_profile.*` keys (or a sibling per-entity-kind table) post-birth.
DERIVED_LATER	Not stored. Computed from other rows in views or queries.
NOT_CENTRAL_BIRTH_REGISTRY	Out of scope for `birth_registry`. Lives in per-entity-kind structures, joined via `(collection_name, entity_code)`.

2.3 Field classification table (Rev3 canonical)

Column	Type	NULL?	Default	Class	Notes
`entity_code`	text	NO	—	REQUIRED_AT_BIRTH	Universal address half.
`collection_name`	text	NO	—	REQUIRED_AT_BIRTH	Universal address half.
`species` / species mapping fields (per existing schema)	per schema	per schema	per schema	REQUIRED_AT_BIRTH	Resolved via `species_collection_map`.
Governance fields (governance_role, coverage status flags, etc.)	per schema	per schema	per schema	REQUIRED_AT_BIRTH	Per Rev2 §7.
Birth timestamps / actor (per existing schema)	per schema	per schema	per schema	REQUIRED_AT_BIRTH	Set by birth gate at INSERT.
`canonical_address`	text	YES	NULL	PLACEHOLDER_AT_BIRTH	New (B3-ELD-EXEC). Resolved later. NULL at birth is contractually expected.
`owner`	text	YES	NULL	PLACEHOLDER_AT_BIRTH	New (B3-ELD-EXEC). Resolution algorithm = Rev2 §3. NULL at birth is contractually expected; may later be filled with `UNKNOWN_OWNER` sentinel rather than NULL once owner-resolution runs.
`jsonb_profile`	jsonb	NO	`'{}'`	REQUIRED_AT_BIRTH	New (B3-ELD-EXEC). Empty object satisfies REQUIRED_AT_BIRTH; keys inside are ENRICHED_LATER.
`identity_profile` (per-entity-kind)	—	—	—	NOT_CENTRAL_BIRTH_REGISTRY	Lives in per-entity-kind collections. NEVER added to `birth_registry`. Bridge: `(collection_name, entity_code)`.

Other existing columns retain their Rev2 classification.

2.4 `jsonb_profile` semantics (Rev3 normative)

Container class: REQUIRED_AT_BIRTH (column NOT NULL, default '{}').
Content class: keys inside the object are ENRICHED_LATER by per-entity-kind enrichment jobs. The contract does NOT mandate any specific key at birth.
Birth gate MUST NOT reject inserts where jsonb_profile = '{}'::jsonb.
Birth gate MUST NOT mandate a minimum key set.
Validators MUST treat jsonb_profile -> 'identity_profile' as NOT_CENTRAL_BIRTH_REGISTRY even if present.
Indexing strategy (GIN, expression) is a separate future workstream.

2.5 `canonical_address` and `owner` semantics (Rev3 normative)

Both are PLACEHOLDER_AT_BIRTH. NULL at birth is the documented contract.
Backfill of 280,854 existing rows is a separate enrichment workstream.
Birth gate MUST NOT reject inserts where these are NULL.
Health-check coverage (§3, §4 below) reports critical gaps elsewhere; missing canonical_address/owner at birth is by-design and MUST NOT raise.

2.6 `identity_profile` decision (Rev3 normative)

identity_profile is NOT_CENTRAL_BIRTH_REGISTRY by design.
Rationale: birth_registry is a universal coverage row; identity profiles have entity-kind-specific schemas.
Storage: each entity-kind keeps its own identity_profile via its own collection.
Bridge: (collection_name, entity_code) join.
Adding an identity_profile column to birth_registry is explicitly out of contract.

2.7 Birth gate / trigger implications

Contract invariants after Rev3:

MUST accept inserts where canonical_address IS NULL.
MUST accept inserts where owner IS NULL.
MUST accept inserts where jsonb_profile = '{}'::jsonb.
MUST NOT auto-populate canonical_address or owner from heuristics at INSERT time.
MAY allow jsonb_profile to be passed in explicitly; MUST default to '{}' if absent.

Verification against trigger behavior is part of B3-MAINLINE-RESUME or focused delta check — out of scope here.

2.8 Out of scope for Rev3

Backfill of 280,854 existing rows.
Index strategy on jsonb_profile.
Per-entity-kind identity_profile schemas.
DROP COLUMN / rollback.
Phase 5C2 resume.

3. B3-F1c-H Wrapper Function design

3.1 Contract gap recap

Surface	What it expects	What we have	Gap
`dot-dot-health` `dispatch_function` (lines 382–404)	`public.<executor_ref>(jsonb) RETURNS boolean`, text-cast `t/true/f/false`	`public.fn_birth_onboarding_full_scan() RETURNS jsonb`	Arity 0 vs 1 AND return type jsonb vs boolean

3.2 Proposed wrapper

Name: public.fn_birth_onboarding_full_scan_hc Signature: (cfg jsonb DEFAULT '{}'::jsonb) RETURNS boolean

Sketch (compile-only — NOT executed in this session):

-- SKETCH ONLY. NOT EXECUTED. NOT COMPILED.
CREATE OR REPLACE FUNCTION public.fn_birth_onboarding_full_scan_hc(cfg jsonb DEFAULT '{}'::jsonb)
RETURNS boolean
LANGUAGE plpgsql
SECURITY INVOKER
AS $$
DECLARE
  v_result          jsonb;
  v_critical_count  bigint;
  v_threshold       bigint;
BEGIN
  v_result := public.fn_birth_onboarding_full_scan();

  IF v_result IS NULL THEN
    RETURN false;
  END IF;

  v_critical_count := COALESCE((v_result ->> 'critical_count')::bigint, 0);
  v_threshold      := COALESCE((cfg     ->> 'critical_threshold')::bigint, 0);

  RETURN v_critical_count <= v_threshold;
END;
$$;

COMMENT ON FUNCTION public.fn_birth_onboarding_full_scan_hc(jsonb) IS
'B3-F1c-H wrapper. Calls fn_birth_onboarding_full_scan() and folds critical_count <= cfg.critical_threshold (default 0) to a boolean for dot-dot-health.dispatch_function.';

3.3 Design principles honored

Principle	How
Thin	~10 lines of plpgsql
PG-first / PG-native / PG-driven	All logic in PG
No hardcoded collection lists	Enumeration in scanner only
Threshold from cfg	`critical_threshold` honoured (default 0)
Safe NULL	NULL output → false; missing keys → 0
Error visibility	No `EXCEPTION WHEN OTHERS`
RW consistency	Scanner writes `system_issues`; executor uses `run_pg_rw`

3.4 Why `critical_count` only

GPT-locked gap counter per scanner Rev3. Alternatives rejected (status string brittle; multi-counter reads violate "thin").

3.5 Wrapper non-goals

Does not enumerate collections; does not write system_issues directly; does not bypass scanner; does not interpret severity beyond critical_count.

wrapper_recommended = true — compile + INSERT NOT authorized in this session.

4. `system_health_checks` row design (one row)

4.1 Proposed row

Column	Value	Rationale
`code`	`DOT-BIRTH-ONBOARD-FULLSCAN-HC`	Distinct from raw-scanner DOT in `dot_tools`.
`name`	`Birth/Onboarding Full Scan — Critical Gaps`	Human-readable.
`jurisdiction`	`NRM-LAW-35-V5P2`	Required for dot-dot-health precheck. See §4.3.
`check_kind`	TBD	Confirm pre-INSERT against existing taxonomy.
`executor_type`	`function`	First function-type row (B3-F1c-e §3).
`executor_ref`	`fn_birth_onboarding_full_scan_hc`	Wrapper. `public` schema implied.
`threshold_config`	`{"critical_threshold": 0}`	Strict.
`severity_on_fail`	`critical`	Confirm enum pre-INSERT.
`auto_fix_action`	NULL	No safe auto-fix.
`is_active`	`true`	Active for next dispatch.
`order_index`	TBD = `max(order_index)+1` within jurisdiction	Compute pre-INSERT (read-only).
`description`	Self-contained — wraps `fn_birth_onboarding_full_scan()`, fails when `critical_count` exceeds threshold.	—
`_dot_origin`	`dot-dot-health`	Confirm convention pre-INSERT.

4.2 Mandatory read-only preflight (future INSERT session)

Wrapper function exists with (jsonb) RETURNS boolean.
check_kind enum lookup.
severity_on_fail enum lookup.
_dot_origin convention lookup.
UNIQUE(code) check.
max(order_index) within jurisdiction.
normative_registry membership of NRM-LAW-35-V5P2.

4.3 Jurisdiction debt analysis — `NRM-LAW-35-V5P2`

Question	Answer
Acceptable to hardcode?	YES, as temporary debt.
Why	dot-dot-health precheck hard-fails if its hardcoded `JURISDICTION` is not in `normative_registry`; parse_args has no `--jurisdiction`; no env override. Anything else is invisible to the scheduler. Script edit is wider blast radius than this row.
Debt symbol	`B3-F1c-jurisdiction-decoupling-debt`
Debt trigger	Next `dot-dot-health` patch cycle OR second non-NRM-LAW-35-V5P2 birth check.

jurisdiction_debt_accepted = true

4.4 Row recommendation

system_health_checks_row_recommended = true — INSERT NOT authorized in this session.

5. Dual-trigger model (NEW — patch-driven)

5.1 Operating principle

NT7 dual-trigger / never-wait: a critical health check MUST be reachable via two independent triggers — a scheduled background trigger AND a controlled on-demand trigger. The system must not depend on cron alone to prove operational readiness.

Cron observation is retained as a diagnostic (§8) but is no longer a gate: wait_for_cron_required = false.

5.2 Trigger A — Scheduled (background assurance)

Aspect	Value
Schedule	`0 3 * * * ... /opt/incomex/dot/bin/dot-dot-health --local ... >> /var/log/incomex/dot-health.log 2>&1`
Path	root cron → dot-dot-health → dispatch_function → wrapper → scanner
Purpose	Continuous background assurance; daily coverage.
Mutation mode	INTENTIONAL_WRITE (scanner writes `system_issues`).
Changes	NONE — cron line unchanged by B3-F1c-g.
Defined	`scheduled_trigger_defined = true`

5.3 Trigger B — Controlled on-demand (Council-invoked)

Two operational variants, each with its own pre-conditions and mutation class. Both are explicit operator-invoked paths; neither requires waiting for 03:00 UTC.

B1 — pre-wrapper scheduler-health validation (§6 below).
B2 — post-wrapper birth full-scan invocation (§7 below).

on_demand_trigger_defined = true

6. Trigger B1 — Pre-wrapper scheduler-health validation (NEW)

6.1 Purpose

Prove that dot-dot-health --local parser + precheck + generic executor can run after the B3-F1c-g patch without waiting for the 03:00 cron tick, and without invoking the not-yet-existing wrapper.

6.2 Candidate paths (NOT existing-truth)

Per GPT guidance, the following candidates are listed as flags to be discovered, not assumed truth. Source-time presence of a flag in parse_args does NOT prove its mutation-safety at runtime.

Candidate	Form	Status
C1 — full dry-run	`/opt/incomex/dot/bin/dot-dot-health --local --dry-run --verbose`	Candidate — flag-safety unverified.
C2 — narrowed dry-run	`/opt/incomex/dot/bin/dot-dot-health --local --dry-run --only-check=<SAFE_EXISTING_CHECK_CODE> --verbose`	Candidate — flag-safety AND check-safety unverified.

6.3 Mandatory static-proof prerequisite (READ-ONLY)

Before invoking C1 or C2, the agent MUST statically prove (in a separate session) that:

DRY_RUN=1 short-circuits every write path inside dot-dot-health, including:
- fn_log_issue calls.
- direct INSERT INTO system_issues.
- any run_pg_rw invocation whose body contains DML.
The --verbose flag does not enable an alternative write path.
For C2, the chosen <SAFE_EXISTING_CHECK_CODE> has no side-effect under DRY_RUN=1 — verified by reading its executor_type/executor_ref and the corresponding dispatcher branch.
The patched file's behavior (post-B3-F1c-g) matches the static read — i.e. the read is against the live sha256 = 28bc0b8e1ad93d380045e5e3cff6a6934d67c4b9bfffdd51ac5caaa1630a6bf2 file.

If any of steps 1–4 fail to prove safety, B1 is BLOCKED-pending-discovery. The design does NOT invent flags. Static proof is a separate session deliverable; this design defines the requirement.

6.4 Operational rules for B1

MUST NOT source the script.
MUST NOT run bare normal mode.
MUST capture stdout + log tail and emit a KB execution report.
MUST NOT precede the static-proof artifact.
MAY be re-run safely (read-only by proof).
Classification when proof passes: READ_ONLY.
Classification while proof pending: UNKNOWN — treated as if mutating; do NOT invoke.

on_demand_pre_wrapper_validation_defined = true (plan defined; execution gated on static-proof artifact).

6.5 Why no PG path for B1

B1 validates the SCRIPT (parse_args + precheck + generic executor reach), not a function. There is no PG-side analog for "does dot-dot-health's parser still work." A PG SELECT cannot exercise the dispatch chain. The script is the only valid surface for B1.

6.6 Future CLI enhancement (out of current scope)

If static proof of --dry-run / --only-check safety is not achievable on the current file, the correct response is a future dot-dot-health enhancement — explicitly add a --dry-run-safe-mode that is provably non-mutating — and not to invent assumptions in this design. Classify as DOT enhancement / future work, not current path.

7. Trigger B2 — Post-wrapper on-demand birth full-scan (NEW)

7.1 Purpose

After wrapper + system_health_checks row are installed, the Council can invoke the birth full-scan immediately without waiting for 03:00 UTC.

7.2 Current (recommended) path — PG SELECT

-- INTENTIONAL_WRITE. Authorization required. NOT for this session.
SELECT public.fn_birth_onboarding_full_scan_hc('{}'::jsonb);

Or directly exercise the scanner:

-- INTENTIONAL_WRITE. Authorization required. NOT for this session.
SELECT public.fn_birth_onboarding_full_scan();

current_on_demand_trigger_path = PG_SELECT

7.3 Mutation classification (NORMATIVE)

Aspect	Value
Class	INTENTIONAL_WRITE
Reason	`fn_birth_onboarding_full_scan()` is a scanner: it writes to `system_issues` by design. The wrapper inherits this.
Implication	Trigger B2 is NOT read-only and MUST NOT be confused with dry-run validation.

on_demand_pg_trigger_considered = true on_demand_pg_trigger_classification = INTENTIONAL_WRITE manual_trigger_mutation_mode = INTENTIONAL_WRITE

7.4 Operational rules for B2

Authorization required: explicit GPT + user authorization per invocation, until standing authorization is granted.
Execution report required: every invocation MUST upload a KB execution report capturing:
- timestamp, invoker, jurisdiction (NRM-LAW-35-V5P2).
- exact statement run.
- critical_count and other rollup fields from the returned JSONB.
- delta in system_issues row count (before/after).
- any new severities surfaced.
MUST be run via the approved PG path (docker exec postgres psql -U directus -d directus ...).
MUST NOT be wrapped inside a script that obscures the SQL text.
MUST NOT be batched with unrelated SQL.
Failure handling: if the statement errors, capture exit code + stderr in the report; do NOT auto-retry.
Rollback: no rollback. Scanner writes are append-only by design; treat as audit trail.

7.5 Future CLI path (not current)

# Future — pending --only-check static safety proof per §6.3.
/opt/incomex/dot/bin/dot-dot-health --local --only-check=DOT-BIRTH-ONBOARD-FULLSCAN-HC --verbose

Classification: DOT enhancement / future work. NOT the current path. Conditions to promote it to current:

Static proof of --only-check flag safety (per §6.3 step 3, applied to the new HC code).
Wrapper exists and has been called once via PG path.
Cron observation (§8) has been recorded once.

dot_dot_health_dry_run_supported = unknown dot_dot_health_only_check_supported = unknown post_wrapper_on_demand_trigger_defined = true (PG SELECT path; CLI path future).

7.6 What B2 does NOT do

Does not bypass authorization.
Does not run in this design session.
Does not assume CLI flags.
Does not produce read-only output — system_issues will receive rows.

8. Cron observation — diagnostic-only role (renamed)

8.1 New role

Cron observation is retained as a diagnostic for Trigger A integrity. It is no longer a gate. Trigger B (B1 and/or B2) is the immediate proof path; cron is the background-assurance proof path.

cron_observation_still_supported = true wait_for_cron_required = false

8.2 Diagnostic observation sequence (read-only)

Executed via SSH on VPS 38.242.240.89 — NOT in this session:

# 1. Tail recent log
tail -n 400 /var/log/incomex/dot-health.log

# 2. Confirm post-patch run produces no "Unknown option: --local"
awk '/^=== / { ts=$0 } /Unknown option: --local/ { print ts; print }' /var/log/incomex/dot-health.log | tail -n 50

# 3. Confirm parser reached generic executor
grep -E "precheck|env_load|run_check|dispatch_(builtin|sql|function)|JURISDICTION" /var/log/incomex/dot-health.log | tail -n 80

# 4. Per-check rollup lines
grep -E "code=|active=|ran=|severity=" /var/log/incomex/dot-health.log | tail -n 50

# 5. journalctl cross-check
journalctl --since "2026-05-15 02:55" --until "2026-05-15 03:30" 2>/dev/null | grep -i -E "dot-health|CRON" | tail -n 80 || true

# 6. Cron line integrity
crontab -l | grep -E "dot-dot-health"

# 7. File integrity vs B3-F1c-g hash
sha256sum /opt/incomex/dot/bin/dot-dot-health
# Expected: 28bc0b8e1ad93d380045e5e3cff6a6934d67c4b9bfffdd51ac5caaa1630a6bf2

8.3 Diagnostic PASS criteria

Criterion	Condition
No parse error	Zero `Unknown option: --local` post-2026-05-15 03:00 UTC
Parser reached precheck	`precheck`/`env_load` evidence present
Generic executor reached	At least one `dispatch_*` evidence line
Cron exit	0 (or warn-only)
File integrity	sha256 matches
Cron line	unchanged

8.4 What cron observation does NOT prove

Does not prove dispatch_function end-to-end — that requires Trigger B2 (PG path) OR the future CLI path.
Does not prove wrapper correctness — that requires B2.
Proves only: parse fix + executor scaffolding + cron integrity.

8.5 Observation is not the gate

B3-F1c-H can begin before cron observation has happened, via Trigger B (B1 once proof artifact lands, B2 once wrapper+row exist).
Cron observation remains a hygiene check that closes the loop on Trigger A.

9. Constitutional compliance (NEW — patch-driven)

Tenet	Satisfied by	How
NT7 — Dual-Trigger	Trigger A (cron) + Trigger B (on-demand)	§5.2 + §6 + §7. The system has both scheduled and operator-invoked reach to the same health check.
NT2 — Self-Automation	DOT-runner dispatch + KB execution reports	Trigger A is fully automated by cron; Trigger B's PG path is invoked through the approved runner with mandatory KB report (§7.4). Human grep is diagnostic only (§8), not the final mechanism.
NT5 — Self-Detection	`system_health_checks` + `dot-dot-health` + scanner-side `system_issues` writes	The scanner detects gaps and records them in `system_issues`; the health-check row + executor surface them; manual observation only confirms — not a substitute for the detection chain.
NT12 — DOT Pair	Primary scheduled engine (cron) + secondary on-demand engine (PG SELECT now, CLI `--only-check` future)	The same wrapper is reachable from two engines. Neither engine alone is the source of truth; the wrapper + scanner are.

If any tenet is later judged unmet, the design must be re-patched before execution; tenet compliance is not optional.

10. Sequence to declare B3-F complete (updated)

Sequencing only. Each step requires its own authorization. Cron-tick observation no longer blocks earlier steps.

GPT review of this dual-trigger-patched design.
Static-proof artifact for B1 (dot-dot-health --dry-run / --only-check mutation-safety). If proof passes → B1 unblocked; if not → B1 deferred, proceed directly to wrapper.
Wrapper SQL compile artifact + GPT review.
Wrapper DDL execution (CREATE FUNCTION).
system_health_checks INSERT (per §4.1, after preflight in §4.2).
Trigger B2 invocation #1 — PG SELECT, with KB execution report. INTENTIONAL_WRITE acknowledged.
Cron observation #1 — diagnostic confirmation of Trigger A.
B3-F1c-H complete. Birth complete additionally requires post-ELD live verification or B3-MAINLINE-RESUME rerun.

Either step 6 OR step 7 can come first depending on operational need; the dual-trigger model permits both orderings.

Phase 5C2 resume and UI cutover remain out of scope until both branches complete.

11. Open items / explicit non-decisions

Static-proof artifact for --dry-run / --only-check — separate session.
Backfill of 280,854 rows.
Index strategy on jsonb_profile.
Jurisdiction decoupling for dot-dot-health (debt §4.3).
dot_tools registry drift cleanup.
Duplicate DOT_BIRTH_* legacy codes.
EXCEPTION WHEN OTHERS in wrapper — explicitly rejected.
API endpoint for Trigger B — NOT introduced. PG path covers the requirement without crossing into another law/domain.

12. Hard-boundary attestation (re-stated)

Boundary	Held
No PG mutation	YES
No DDL	YES
No DML	YES
No file change (except this design doc + companion report)	YES
No cron change	YES
No wrapper creation (sketch only)	YES
No `system_health_checks` INSERT	YES
No `dot_tools` mutation	YES
No manual `dot-dot-health` trigger	YES
No `fn_birth_onboarding_full_scan` invocation	YES
No Phase 5C2 work	YES
No UI cutover	YES
Secrets disclosed	NONE

13. Final fields

b2_contract_rev3_design_status=PASS
b3f1c_h_wrapper_design_status=PASS
wrapper_recommended=true
system_health_checks_row_recommended=true
jurisdiction_debt_accepted=true

b2_b3f1c_h_dual_trigger_patch_status=PASS
dual_trigger_required=true
scheduled_trigger_defined=true
on_demand_trigger_defined=true
on_demand_pre_wrapper_validation_defined=true
on_demand_post_wrapper_validation_defined=true
wait_for_cron_required=false
cron_observation_still_supported=true
pre_wrapper_nonmutating_validation_defined=true
post_wrapper_on_demand_trigger_defined=true
manual_trigger_mutation_mode=INTENTIONAL_WRITE

dot_dot_health_dry_run_supported=unknown
dot_dot_health_only_check_supported=unknown
on_demand_pg_trigger_considered=true
on_demand_pg_trigger_classification=INTENTIONAL_WRITE
current_on_demand_trigger_path=PG_SELECT

nt7_dual_trigger_satisfied=true
nt2_self_automation_satisfied=true
nt5_self_detection_satisfied=true
nt12_dot_pair_satisfied=true

execution_allowed=false
phase5c2_resume_allowed=false
ui_cutover_allowed=false
next_recommended_action=GPT_REVIEW_DUAL_TRIGGER_PATCH

P3D Birth — B2 Contract Rev3 + B3-F1c-H Wrapper / system_health_checks Integration Design (Rev2 — Dual-Trigger Patched) | 2026-05-14 | DESIGN ONLY