dot-iu-cutter v0.2 — BR-7 sandbox_tac Role Clarification

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-7-sandbox-tac-role-clarification-2026-05-15.md
revision: r1
date: 2026-05-15
author: Agent (Claude Code CLI, Opus 4.7 1M)
phase: v0.2 planning — BR-7 read-only discovery
mutation_performed: false

---

§1 — Purpose

Resolve BR-7 (reconciliation report §4): clarify the role of sandbox_tac schema and decide whether v0.2 Phase α should ignore, mirror, or include it.

---

§2 — Read-Only Inspection Results

2.1 Schema contents (8 tables — full TAC mirror)

sandbox_tac tables:
  change_set
  change_set_member
  logical_unit
  publication
  publication_member
  publication_type_vocab
  section_type_vocab
  unit_version

This is a full mirror of the public TAC table family, suggesting an isolated environment for testing TAC pipeline behavior without polluting production.

2.2 sandbox_tac.logical_unit column structure

#	Column	Type	Nullable
1	id	uuid	NO
2	canonical_address	text	NO
3	doc_code	text	NO
4	parent_id	uuid	YES
5	sort_order	integer	NO
6	section_type	text	NO
7	section_code	text	YES
8	owner	text	NO
9	identity_profile	jsonb	YES (differs from public)
10	lifecycle_status	text	NO
11	tier	text	YES
12	created_at	timestamptz	NO
13	updated_at	timestamptz	NO

Compared with public.tac_logical_unit: 12 of 13 columns IDENTICAL; only identity_profile differs (nullable in sandbox; NOT NULL in public).

2.3 Indexes + constraints

logical_unit_pkey                      UNIQUE btree (id)
logical_unit_canonical_address_key     UNIQUE btree (canonical_address)
idx_sbx_lu_doc_code                    btree (doc_code)
idx_sbx_lu_parent                      btree (parent_id)

Mirrors the public counterpart's intent (PK + canonical_address UNIQUE + doc_code btree + parent btree).

2.4 Row statistics

rows:                       76
canonical_address_non_null: 76 (100%)
distinct_values:            76 (100% unique — UNIQUE constraint satisfied)

2.5 Creation timestamps

oldest:  2026-04-27 00:56:46.200585+00
newest:  2026-04-27 00:56:46.200585+00

All 76 rows share the exact same timestamp → single-shot seed/fixture load 18 days before this discovery. No incremental writes since.

2.6 Sample addresses (first 20)

D38-C1A-ROOT, D38-C1A-S1, D38-C1A-S2, D38-C1A-S3,
D38-C1A-S3-P1, D38-C1A-S3-P2, D38-C1A-S3-P3,
D38-C1A-S4, D38-C1A-S4-P1..P7,
D38-C1A-S10..S14

Format pattern: D38-{section_code}-{S{n}|ROOT}[-P{n}] where section_code = C1A (not DIEU28/DIEU32/DIEU35 like public). Same SYNTAX family as public but DIFFERENT document slug.

2.7 Address overlap with public

sandbox_total: 76
public_total:  86
overlap:       0   (no canonical_address value appears in both sandbox and public)

Sandbox and production address namespaces are fully disjoint.

2.8 Helper function

sandbox_tac.fn_sbx_lu_parent_same_doc — sandbox-only guard
role: enforces parent-child rows share the same doc_code; mirrors a similar guard expected in production but materialized as a separate sandbox helper

---

§3 — Classification

sandbox_tac role: STATIC FIXTURE / TEST SCHEMA
basis_for_classification:
  - full mirror of TAC table family (8 tables) — purpose-built, not accidental
  - exclusive helper function namespace (sandbox_tac.fn_sbx_lu_parent_same_doc) — sandboxed governance
  - single-timestamp seed (2026-04-27 00:56:46) — one-shot fixture load
  - no incremental writes since load — not an active sandbox under daily use
  - disjoint address namespace from public — no cross-contamination risk
  - distinct doc convention (C1A vs DIEU{N}) — likely a draft / chapter-style fixture
likelihood_of_active_usage:
  - low at present (no writes since 2026-04-27)
  - could be re-loaded ad hoc when needed for testing
not_classifiable_as:
  - legacy mirror of production data: NO (no overlap, different doc convention)
  - production data: NO (different schema, isolated)
  - corrupt or abandoned: UNLIKELY (helper function is intentional; full table family suggests purpose)

---

§4 — Should v0.2 Ignore, Mirror, or Include?

Option I — Ignore sandbox_tac in v0.2

description: do nothing to sandbox_tac; Phase α DDL only touches public.tac_logical_unit + new alias table in tac/cutter_governance schema
risks:
  - sandbox tests run against a schema that diverges from production v0.2 shape; any test that exercises authority/format_version paths against sandbox_tac.logical_unit will fail because the columns don't exist there
  - over time, sandbox drift becomes harder to reconcile
  - if sandbox is re-loaded under a future fixture, the load script may need updating anyway
pros:
  - smallest Phase α surface
  - no risk to a static fixture during a production migration
recommendation: NOT_RECOMMENDED if sandbox is intended to remain a reliable test bed

Option II — Mirror sandbox_tac additive columns

description: apply the same ADD COLUMN authority + ADD COLUMN canonical_address_format_version to sandbox_tac.logical_unit; create a sandbox_tac.canonical_address_alias table mirroring the public one
risks:
  - one extra mirror per Phase α additive change — small overhead
  - if sandbox_tac is later refactored or dropped, mirrored changes would also need to be torn down
pros:
  - keeps sandbox shape aligned with production v0.2
  - any test relying on sandbox_tac.logical_unit having the new columns will work
  - mirror is exactly the same DDL applied to a different schema — trivial to dry-run alongside the public DDL
recommendation: RECOMMENDED for Phase α

Option III — Include sandbox_tac in v0.2 backfill

description: Option II + populate authority and canonical_address_format_version on the 76 sandbox rows
risks:
  - sandbox semantics may differ from production (C1A doc convention is not law-text); backfill rule may not apply directly
pros:
  - sandbox rows have the same value semantics as production rows after backfill
recommendation: CONDITIONAL — only AFTER BR-4 (authority backfill rule) is designed, and only if the rule generalizes cleanly to sandbox addresses

---

§5 — Recommendation for Phase α

br_7_blocker_status: RESOLVED (advisory; not blocking)
recommendation_for_v0_2_phase_alpha: Option II — MIRROR additive columns

specifics:
  - apply ADD COLUMN authority text NULL to sandbox_tac.logical_unit (mirror)
  - apply ADD COLUMN canonical_address_format_version text NOT NULL DEFAULT '<TBD>' (mirror)
  - create sandbox_tac.canonical_address_alias table (mirror of the public one, if alias placement is in tac/sandbox_tac)
  - Phase α DDL groups the public + sandbox_tac changes inside the same dry-run scenario set
  - Phase α dry-run env (likely a fresh sibling of pg-dry-run-hb05-2026-05-15) restores BOTH schemas so the dry-run reflects production layout

backfill_for_sandbox:
  - decline backfill until BR-4 authority rule design is done and explicitly applied to sandbox addresses
  - meanwhile sandbox rows have authority=NULL — this is consistent with the v0.1 P0-1 design's "nullable until backfill" pattern

risk_of_ignoring_sandbox:
  - medium — sandbox drift over time will require larger one-shot reconciliation; cheaper to mirror now

---

§6 — Followups Not Resolved Here

unresolved_questions:
  - who owns sandbox_tac and why was it loaded on 2026-04-27?
  - is sandbox_tac referenced by any future test suite plan?
  - is sandbox_tac.logical_unit the only sandbox_tac table that matters, or do change_set / publication etc. also need mirroring?
recommendation: ask sovereign User during Phase α design start; do not block on this — Option II proceeds either way

---

§7 — Hard Boundaries

no_DDL_written: TRUE
no_SQL_mutation: TRUE
no_ALTER_TABLE: TRUE
no_INSERT_UPDATE_DELETE: TRUE
no_migration: TRUE
no_design_authored: TRUE
output_form: br_7_read_only_clarification

End of BR-7 sandbox_tac role clarification.