GPT Directive — Opus IU-0 Full Draft

Date: 2026-05-03 Target agent: Opus new session Goal: write IU-0 full draft from OUTLINE-E.1

1. Context snapshot

Track A legacy vector stabilization is DONE. Do not reopen vector firefighting unless a new regression appears.

Completed sequence:

1. P11E-A Checker Proof uploaded.
2. VRC runtime investigation completed.
3. OGV-0 root cause found: soft-delete vector resurrection.
4. OGV-P0 fixed: two-layer defense, orphan 47 -> 0.
5. Track A residual completed: trigger/function persisted, dot-vector-audit report-only fixed, Qdrant backup cron added, full re-audit PASS.
6. IU-0 OUTLINE-E.1 already uploaded and is the baseline for full draft.

Key accepted evidence:

• Orphan bug = 0.
• Ghost bug = 0.
• Correct-behavior ghosts = 6, separated from bugs.
• Legacy search smoke PASS.
• Trigger/function persisted in /opt/incomex/migrations/track-a-residual-kb-vector-sync-trigger.sql.
• dot-vector-audit cron is report-only (--local, no --heal).
• Qdrant backup cron exists at 03:00.

2. Mandatory source documents

Read these first, preferably batch/full:

1. knowledge/dev/laws/dieu44-trien-khai/design/07-iu0-information-unit-minimum-standard-outline.md — IU-0 OUTLINE-E.1 baseline.
2. knowledge/dev/laws/dieu44-trien-khai/reviews/handoff-iu0-full-draft-from-s190-2026-05-03.md — compact handoff.
3. knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md — P38-XC / UMC / capability context.
4. knowledge/dev/laws/dieu44-trien-khai/design/03-profile-registry-design.md — P44-3 Profile Registry.
5. knowledge/dev/laws/dieu38-trien-khai/reports/vector-reality-check-agent-data-qdrant-2026-05-02.md — VRC evidence.
6. knowledge/dev/laws/dieu38-trien-khai/reviews/gpt-review-track-a-residual-complete-2026-05-03.md — Track A accepted complete.

Do not re-search broadly unless a gap appears. The handoff and outline were created to save context and tokens.

3. Decisions already finalized — do not ask again

1. Legacy KB vector remains as-is and stabilized.
2. IU vector is parallel, not a mutation of legacy production_documents.
3. IU vector migration: Phase 0 mapping -> Phase 1 separate IU collection -> Phase 2 search adapter + dedup -> Phase 3 unit-aware chunking.
4. Duplicate KB + IU content is very common. Use collection separation first, then freshness-based dedup.
5. Vector projection must be async delayed outbox, not inline.
6. PG CRUD hot path = local PG only; no OpenAI/Qdrant/remote calls in hot path.
7. Defaults: quiet window 120s, delete delay 30-60s, worker poll 30s, retry 3, dead-letter manual + alert, debounce IU key = unit_version_id, vector freshness states = current/pending/stale/error/retired.
8. Track A is complete; §6 Phase 1+ is no longer blocked by legacy instability, but implementation is still defer.

4. Full draft target

Write full draft document:

IU-0 — Information Unit Minimum Standard & Packaging Plan (FULL DRAFT)

Path proposal remains: knowledge/dev/laws/dieu44-trien-khai/design/07-iu0-information-unit-minimum-standard.md

Do not upload until User/GPT review unless explicitly authorized. Produce full draft artifact/report first.

5. Required sections

Expand OUTLINE-E.1 into full draft with these sections:

§0. Executive summary

• 5-7 clear lines.
• State IU-0 is universal standard for all Incomex information units.
• State Track A legacy vector stabilization is complete and vector assumptions are now evidence-based.

§1. Purpose, scope, and guardrails

• Why IU-0 exists: long docs, slice editing, standard schema, no duplicate schema systems.
• Strict guardrails: no DDL/code, no P44-6 execution, no mutation of legacy vector, no new object family just for subtype.

§2. Strategic decision: one universal information_unit substrate

• Explain every object is represented through information_unit + unit_kind, not separate incompatible schemas.
• Include illustrative unit_kinds, but mark vocab extension as APR-controlled.

§3. Universal Minimum Core (UMC)

• Inherit P38-XC UMC. Do not redesign.
• Explain U1-U10 and their purpose.
• Emphasize stability and migration requirement for any major UMC change.

§4. Profile and capability extension model

• Inherit P44-3 Profile Registry.
• Profile fields must be registered; Agent must not invent fields.
• Required vs optional fields follow INV-P4.

§5. Packaging model

• Expand 9-layer package: identity, version, content, profile, edges, topic, checker, vector, protection.
• Include who owns each layer, where it is stored logically, and what happens on update.
• Include Minimum Usable Package tiers.

§5.A. IU-PG CRUD Performance Contract

• This is a critical section. Make it practical, not slogan.
• Hot path: local PG only.
• Cold path: outbox worker.
• Include IU-HP rules for create/update/delete unit, version, profile, and edge.
• Include agent workflows: create slice, edit same slice multiple times, read after edit, delete, bulk import.
• Include outbox design: source_kind, source_id/debounce key, operation, content_hash, earliest_run_at, status, retry_count, last_error.
• Explicitly state no embedding/Qdrant/OpenAI in CRUD hot path.

§6. Vector architecture

• Use VRC evidence, not assumptions.
• State legacy vector facts: document-based, production_documents, 1536/Cosine, text-embedding-3-small, payload lacks IU fields, search has no multi-collection/dedup today.
• State Track A completion facts.
• State IU vector target principles IU-VP-1..6.
• Include freshness states current/pending/stale/error/retired.
• Include duplicate KB+IU handling matrix.
• Include migration phases 0-3.
• Include do-not-break legacy guardrails.

§7. Protection / guardrail contract

• Include schema/code guardrails G-1..G-9 and vector guardrails VG-1..VG-9.
• Clarify enacted content immutability and version creation.

§8. Slice-based editing workflow

• This is the practical reason IU-0 exists.
• Define slice = default §Section atom; alternatives: logical atom, composite section.
• Include operations: read, edit draft/new version, append, split, merge, reorder, retire/delete.
• Include canonical address resolution and local-context editing.
• Emphasize edit one slice, not rewrite full file.

§9. Minimum Usable Package (MUP)

• Tier 0, Tier 1, Tier 2+.
• Define what is enough to start dogfooding without waiting for P44-6.

§10. Pilot dogfooding plan

• P0 priority docs: IU-0, P38-XC, P44-3, P11E, selected Đ44 docs.
• Start small: 3-5 docs.
• Success criteria: token reduction, edit reliability, no schema conflicts, vector remains delayed/outbox.

§11. OPEN / TD

• Carry forward OUTLINE-E.1 items.
• Include Track A now DONE, not open.
• Keep implementation details, P44-6, outbox implementation, search adapter, IU collection design as defer/open.

§12. Risk / conflict check

• Include major risks: schema divergence, vector duplicate search, outbox worker stuck, dead-letter accumulation, agent inventing profile fields, legacy vector mutation.
• For each risk, include mitigation.

§13. Review questions / AP-CLOSE

• Ask only meaningful review questions.
• Do not re-ask already settled defaults.
• Recommend next step after review: polish round, then upload.

6. Writing constraints

• Vietnamese by default.
• Evidence-based wording.
• Schema sketches must be labeled NON-NORMATIVE EXAMPLE.
• No SQL DDL, no executable code, no API implementation, no migration script.
• No P44-6 opening.
• Do not claim runtime implementation beyond Track A evidence.
• Do not alter uploaded documents.
• If a design point is uncertain, mark OPEN/TD; do not invent.

7. Expected output from Opus

Return:

1. Concise diff from OUTLINE-E.1 to FULL DRAFT.
2. Full draft content.
3. Self-audit: guardrails, vector safety, PG hot path, duplicate handling, UMC/Profile inheritance.
4. OPEN/TD summary.
5. Clear question: ready for GPT/User polish review or not.

Stop after full draft. Do not upload.