02 — PIV-311 / PIV-313 Add Report (Workstream A)

Decision

Both pivots were READY_TO_ADD (rehearsed clean in the prior macro) and this macro carries explicit owner authorization (§4, §10: "commit PIV-311/PIV-313 if safe"). They count real, single-relation tables — legitimately FINAL, not candidate concepts. Live checks still passed, so they were committed.

Exact definitions committed

INSERT INTO pivot_definitions (code, name, source_object, registry_group, composition_level, species, display_order, filter_spec)
VALUES
 ('PIV-311','Information Units — Total','information_unit','dữ_liệu','atom',NULL,311,'{"filters":[]}'::jsonb),
 ('PIV-313','System Issues (open) — Total','system_issues','giám_sát','atom',NULL,313,
    '{"filters":[{"field":"status","op":"=","value":"open"}]}'::jsonb);

field	PIV-311	PIV-313
source_object	information_unit	system_issues
filter	none	status = 'open'
parent_code	NULL (L1 root)	NULL (L1 root)
registry_group	dữ_liệu	giám_sát
composition_level	atom	atom
expected count	219	207,940
birth	1 row each, collection_name='pivot_definitions'	same

Inserted in one statement → the STATEMENT-level refresh trigger fires once, the ROW birth trigger fires twice (one birth per pivot). Not row-by-row.

Rehearsal (BEGIN..ROLLBACK, net-0)

ENTRY      pivots=37  births=1,132,011  graph_hash=91576fb6…
after_insert pivots=39 births=1,132,013   (+2)
PIV-311 metric_values={"count":219}   needs_refresh=f
PIV-313 metric_values={"count":207940} needs_refresh=f
node_contract: PIV-311 count=219 pivot_backed is_root=t ; PIV-313 count=207940 pivot_backed is_root=t
births: PIV-311→pivot_definitions/born ; PIV-313→pivot_definitions/born   (no composite collision)
ROLLBACK → pivots=37 births=1,132,011 graph_hash=91576fb6…  (entry == exit)

Commit (live)

PRE_COMMIT  pivots=37  births=1,132,011
INSERT 0 2
PIV-311={"count":219}  PIV-313={"count":207940}
COMMIT
POST_COMMIT pivots=39 active=37 roots=26 births=1,132,013 graph_hash=8c5d25a8…
births: PIV-311 born, PIV-313 born

Roots 24 → 26 (the two new L1 totals). Active 35 → 37.

Side-effects (disclosed, designed)

• 2 birth_registry rows added (designed fn_birth_registry_auto). There is no birth-retire mechanism, so the rollback that deletes the pivot rows leaves 2 birth rows as registered-but-absent unless the optional birth-cleanup line is run (see doc 08).
• One STATEMENT-level cache refresh (designed; recomputes pivot_results/meta_catalog). No business/registry source mutation.

Completion

PIV-311 and PIV-313 are LIVE and pivot_backed. ✅