GPT Review — P10A-1 D35 Segmentation Candidate

Date: 2026-04-29

Reviewed input

• Agent report: knowledge/dev/laws/dieu38-trien-khai/reports/p10a-d35-segmentation-candidate-2026-04-29.md.
• Opus assessment and GPT review request.

Verdict

P10A-1 discovery PASS accepted.

Segmentation candidate: APPROVE WITH PATCH — not ready for P10A-2 insert/render yet.

The Agent completed the read-only discovery correctly. However, the candidate segmentation needs one more read-only refinement pass before any production insert is planned.

PASS accepted for P10A-1 discovery

Accepted evidence:

• Source snapshot complete: knowledge/dev/laws/dieu35-dot-governance-law.md, revision 13, SHA256 4353ec6d453411a7c8e207658bbc4457d00f99747cba90551c8a4926894d2e5c.
• Schema discovery complete for 14 TAC tables.
• Detailed discovery done for core/member and relevant vocab tables.
• Triggers cataloged as enabled; no trigger firing attempted.
• Batch marker candidate identified: tac_publication.id.
• Vocab values verified.
• Report uploaded.
• Zero mutation confirmed.

Required segmentation patches before P10A-2

Patch 1 — Synthetic root: keep, but do not duplicate full document body

Decision D1: KEEP synthetic root as the article-level parent.

But current root has body_bytes=39938, i.e. full document body. This would duplicate the entire document alongside child sections and distort render/diff/vector behavior.

Patch:

• keep dieu35.root with section_type='article';
• root body should be empty if allowed, or a short article summary/description if body_required=true;
• full document body must not be stored as the root body if child units also store section bodies;
• dieu35.preamble should be child of dieu35.root, not parentless.

Patch 2 — Split §4 SCHEMA before P10A-2

Decision D2: SPLIT before insert.

The current §4 is 11KB and is too large for a single pilot information unit. Split into sub-units according to its headings:

• dieu35.s4 as heading/section parent if needed;
• dieu35.s4.1, dieu35.s4.1.1, dieu35.s4.2, dieu35.s4.3, dieu35.s4.4 or exact heading-derived units from source;
• use technical_spec for SQL/schema-heavy sub-units;
• keep parent/child order deterministic.

Patch 3 — Split §6 if source headings support it

§6 is also large. Split if actual source contains subheadings 6.1–6.7 as noted by Agent.

Recommended mapping:

• section parent: heading/process depending body;
• lifecycle procedure sub-units: governance_process / process;
• checklist-like sub-units: checklist;
• principle-like sub-unit: principle;
• plain explanatory sub-unit: paragraph if available/valid.

Patch 4 — Improve section_type diversity using active vocab

Current candidate uses process for 11/17 units. That is acceptable as a fallback but weak for the pilot.

Recommended initial mapping:

• §1 Mục tiêu → rationale or principle depending actual text;
• §2 Phạm vi → principle or process depending actual text;
• §3 DOT 2 cấp → definition;
• §4 Schema → technical_spec / child technical specs;
• §5 Quy trình tạo DOT → process;
• §6 Vòng đời DOT → split into governance_process, process, checklist, principle as appropriate;
• §7 Đo lường → checklist or rationale if metric-oriented;
• §8 DOT tự quản trị → governance_process;
• §9 Bootstrap → process;
• §10 Success metrics → checklist;
• §11 Retrofit clause → governance_process or process;
• §12 tombstone → paragraph if valid, otherwise keep process with tombstone note;
• Appendix → appendix;
• Changelog → changelog;
• Post-merge TODO → checklist.

Patch 5 — Heading-only units policy

Decision D3: heading-only units are allowed only as structural parents when they have no standalone body.

For parent units created only to group sub-units, use heading only if vocab permits body_required=false. Otherwise provide a short non-duplicative body/description.

Patch 6 — Description backfill required

Decision D4: YES, description must be generated where required.

For every unit_version whose section_type requires description, generate description from first paragraph or a concise one-sentence summary. Record it in the candidate artifact for GPT review before insert.

Patch 7 — Tombstone §12

Decision D5: keep §12 for traceability, but avoid over-labeling as process if a better active type exists.

Preferred: paragraph if active and semantically acceptable; otherwise process with explicit tombstone description.

Patch 8 — Batch marker acceptable with caveat

tac_publication.id is acceptable as batch marker for P10A pilot if P10A-2 also records exact inserted LU/UV/PM IDs in the action log. Because LU/UV do not directly carry publication_id, rollback must use publication_member plus inserted ID lists.

Patch 9 — P10A-2 trigger concerns remain open

Do not proceed to P10A-2 until the patched candidate includes:

• actual length estimates/word counts per unit;
• length_flag expectations;
• description fields;
• planned lifecycle states staying mutable (proposed/draft);
• preflight inspection of tac_birth_gate_config and function source/behavior.

Directive to Opus 4.6

Do not dispatch P10A-2 yet.

Proceed with P10A-1B — Segmentation Candidate Patch, read-only.

Scope:

• Use existing source snapshot and schema discovery.
• Regenerate a revised segmentation candidate for Điều 35.
• Keep synthetic root but remove full-body duplication.
• Make preamble child of root.
• Split §4 before insert.
• Split §6 if source headings support it.
• Improve section_type mapping using active vocab.
• Add generated description field for each unit where required.
• Add word counts/length expectations.
• Keep no full body in report; use excerpt + hash + optional separate local/KB artifact if needed.
• Produce revised candidate report.
• Zero mutation.
• STOP for GPT review.

Expected output path:

knowledge/dev/laws/dieu38-trien-khai/reports/p10a-d35-segmentation-candidate-v2-YYYY-MM-DD.md

After GPT approves revised candidate, Opus may draft P10A-2 insert/render prompt. No production insert before that.

Current state

• P10A-1 discovery: PASS.
• D35 segmentation candidate v1: needs patch.
• P10A-2 insert/render: not authorized.