KB-5BBF

P3D — B3-ELD Entity Living DB Placeholder Design Report

7 min read Revision 1
p3dbirth-systemb3-eldentity-living-dbreport2026-05-14

P3D — B3-ELD Entity Living DB Placeholder Design Report

Date: 2026-05-14 Author: Opus (Claude Code) — DESIGN ONLY Mode: read-only PG; only writes are the two Agent Data docs. Companion design: knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-entity-living-db-placeholder-design.md Secrets redacted: true


1. Executive summary

The Entity Living DB (ELD) placeholder layer on birth_registry can be completed with a 3-column, zero-trigger-patch, fast-path DDL when execution is authorized. Live PG inspection confirms an existing column convention to align with (canonical_address text, identity_profile jsonb, owner text/varchar) and confirms there is no existing jsonb_profile column anywhere in public (it is a category name, not a column).

Recommendation: Option A — Add 3 nullable/defaulted columns to birth_registry (canonical_address text NULL, owner text NULL, jsonb_profile jsonb NOT NULL DEFAULT '{}'::jsonb). Skip identity_profile on birth_registry because it already lives correctly per-entity-kind (information_unit, tac_logical_unit) and would duplicate jsonb_profile semantics.

fn_birth_registry_auto does NOT need patching — adding nullable/defaulted columns is transparent to the trigger. B2 contract requires rev3. B3-F gates do not require updates (optional hardening only). Phase 5C2 remains gated; ELD enrichment for owner and canonical_address can run parallel in B6.


2. Live PG findings (key)

  • canonical_address: lives on 6 tables as text, including information_unit, tac_logical_unit, event_outbox, event_pending, iu_notification_event, unit_edit_draft. Sample looks like slug paths.
  • identity_profile: lives on 2 tables (information_unit, tac_logical_unit) as jsonb NOT NULL DEFAULT '{}'.
  • owner: lives on 13 tables, varied shape (varchar/text/character); owner_ref is a separate, distinct pattern on information_unit.
  • jsonb_profile: NEVER appears as a column. Variants: identity_profile, content_profile, publication_profile.
  • birth_registry: 19 columns; only governance_role of the 6 ELD targets is present. 292,599+ rows (live id value at probe time).
  • fn_birth_registry_auto: inserts only 8 named columns — adding more nullable/defaulted columns is invisible to it.
  • description_policy: fully populated on collection_registry (NULL/empty=0).

3. Key design decisions

# Decision
1 canonical_address text NULL on birth_registry (placeholder); physical-table copies remain authoritative where they exist (6 tables).
2 owner text NULL on birth_registry — stores the resolved owner per B2 §3 (e.g., agent:*, user:*, UNKNOWN_OWNER).
3 jsonb_profile jsonb NOT NULL DEFAULT '{}'::jsonb on birth_registry — generic catch-all for hook snapshots, description_policy mirror, owner-resolution trace.
4 identity_profile NOT added to birth_registry. Remains per-entity-kind on physical tables. Would duplicate jsonb_profile.
5 Birth trigger functions UNCHANGED.
6 B2 contract → rev3 required.
7 B3-F gates: no required change; optional hardening to add NULL-rate audit.
8 Backfill: jsonb_profile auto-defaults on ADD COLUMN (PG ≥11 fast-path); canonical_address and owner start NULL and are enriched in B6.
9 Self-expanding: new collections inherit placeholders the moment their first row fires birth — no allowlist anywhere.
10 DDL execution NOT authorized in this pack.

4. Why not the alternatives

  • Option B (new ELD table) — requires trigger patch + FK + 292k-row backfill + JOIN every read. Violates "birth is dumb/fast". Rejected.
  • Option C (hybrid with entity_living_db_profiles) — collides with existing per-entity-kind JSONB columns. Risks loopback/sync issues. Rejected.
  • Option D (derived-only views) — cannot persist owner resolution; soft gate has nothing to check; multi-table JOINs across 100+ tables. Rejected.

5. Relation hook + enrichment alignment (compressed)

  • IDENTITY anchor: canonical_address + (collection_name, entity_code) universal address.
  • BELONGS_TO: owner (direct) + jsonb_profile.belongs_to_ref (snapshot).
  • CONTAINS / DEPENDS_ON / USED_BY / TRANSITIVE / PEERS / SIMILAR: all snapshot-keyed inside jsonb_profile.* — no per-hook column.
  • description_policy / canonical address / owner resolution / vector seed / pivot result: all live inside jsonb_profile as JSONB keys, no DDL per enrichment kind.

This is what makes the design self-expanding without DDL for downstream enrichment.


6. Risks & open questions

  • Storage overhead on 292k+ rows: minor; jsonb_profile = '{}' is ~2 bytes per row inline.
  • GIN index on jsonb_profile: defer to exec.
  • owner NULL vs 'UNKNOWN_OWNER' sentinel: defer to exec; recommend NULL pre-enrichment.
  • Logical snapshot before exec: recommended.
  • _history shadow tables on birth_registry: not verified; check at exec time.

Full list of 9 open questions: see design doc §13.


7. Pointer to design doc

Full design (per-field placement rationale, full options comparison tables, relation/enrichment matrices, contract revision detail, self-expanding pattern, open questions):

knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-entity-living-db-placeholder-design.md


8. Machine-parseable final fields

b3_eld_design_status=PASS
recommended_option=ADD_BIRTH_REGISTRY_COLUMNS
canonical_address_decision=placeholder_at_birth on birth_registry.text NULL; derived later from physical-table mirror or enrichment
owner_decision=placeholder_at_birth on birth_registry.text NULL; enriched_later via B2 §3 owner-resolution chain
jsonb_profile_decision=required_at_birth on birth_registry.jsonb NOT NULL DEFAULT '{}'; catch-all for hook snapshots and policy mirrors
identity_profile_decision=not_birth_responsibility; remain per-entity-kind on physical tables (information_unit, tac_logical_unit); not added centrally
birth_function_patch_required=false
b2_contract_rev3_required=true
b3f_gate_update_required=false
backfill_required=partial
ddl_execution_allowed=false
phase5c2_resume_allowed=false
next_recommended_action=GPT_REVIEW_B3_ELD_DESIGN
secrets_redacted=true
design_doc_id=knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-entity-living-db-placeholder-design.md
report_doc_id=knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-entity-living-db-placeholder-design-report.md

B3-ELD Entity Living DB Placeholder Design Report | DESIGN ONLY | Opus | 2026-05-14

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-entity-living-db-placeholder-design-report.md