Incomex AI Portal
KB-59EC

GPT Directive — Description Policy Tiering for IU / Pack 2B Gate

8 min read Revision 1
gpt-directivedescription-governanceiu-0pack-2bdieu3dieu4dieu43law-amendmentopus

GPT Directive — Description Policy Tiering for IU / Pack 2B Gate

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Trigger: User identified foundational mismatch: detailed Description governance cannot scale to hundreds of thousands of Information Units.

Evidence checked

  • knowledge/dev/laws/law-03-metadata.md rev 6 — Đ3 Metadata / Description Governance
  • knowledge/dev/laws/law-04-birth-process.md rev 5 — Đ4 Birth / Description Guard
  • knowledge/dev/laws/dieu43-system-context-law.md rev 51 — Đ43 System Context / H11 checks
  • knowledge/current-state/queries/h11a-description-basic-missing
  • knowledge/current-state/queries/h11b-description-detail-missing
  • knowledge/dev/guides/description-enrichment-guide.md rev 2
  • knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md rev 2
  • knowledge/dev/laws/dieu44-trien-khai/design/12a-iu0-pack2a-description-birth-contract-decision-note.md

Finding

User's concern is valid and should be treated as a Pack 2B blocker.

Current Description Governance was built mainly for architectural/governance objects: DOT, collection, species, config, module, page, workflow step, task, governance entities. For those, detailed description is valuable because it allows graph/context/agents to understand function without reading code.

But Information Units may scale to hundreds of thousands of slices. Requiring agent-authored/enriched description for every IU row is not feasible and likely not necessary. IU rows already have structured fields such as canonical address, kind, content, profile/identity fields, parent/child relations, source doc, version, etc. Their semantic description should often be derived from structure/content, not manually authored.

There is already a seed of this distinction in description-enrichment-guide.md:

  • WRITE for architectural fixed entities: DOT, collection, species, module, config, domain, agent, page, workflow step, task, governance entity.
  • DO NOT WRITE for operational/runtime records; machine-generated basic description is enough.

However, this principle is not yet sufficiently encoded in Đ3/Đ4/Đ43 health checks so that the system can know when missing detailed description is an error vs normal.

Required design direction

Introduce a formal tiered Description Policy.

Proposed model:

Tier A — Architectural / Governance entities

Examples: DOT, collection, species, script, config, domain, page, workflow, task, law/process/design artifacts.

Requirement:

  • Detailed description required.
  • Agent/Human enrichment expected.
  • H11b missing detail may be WARNING/CRITICAL depending entity class.
  • Provenance matters: PROV-AI / PROV-HUMAN / PROV-DOT.

Tier B — Runtime / High-volume atomic entities

Examples: information_unit rows, unit_version rows, labels, fields, logs, generated operational records, simple atoms.

Requirement:

  • Detailed description not required by default.
  • Basic machine-generated description OR structured semantic fields are enough.
  • Health checks must not flag missing detailed description as error if entity class is exempt or uses structured profile.
  • Graph should derive meaning from canonical_address, unit_kind, source, parent/child links, relation edges, content hash, profile JSONB, etc.

Tier C — Transitional / Unknown entities

Requirement:

  • If policy unknown, do not guess.
  • Classify via Context Graph + Process Gate and runtime evidence.
  • Default to WARNING/discovery, not automatic write.

Key technical requirement

The system needs a machine-checkable classification, not just prose.

Possible mechanisms to investigate:

  • description_policy enum: required_detailed, basic_only, structured_exempt, unknown.
  • requires_description_detail boolean at species/collection/entity-type level.
  • description_strategy: agent_enriched, auto_basic, derived_from_profile, none_for_runtime.
  • registry/config mapping table or dot_config keys for H11 exclusions.
  • update h11b_exclude_species or replace with stronger policy table.
  • update H11a/H11b queries to distinguish missing basic description vs exempt detailed description.

IU-specific direction

For IU rows:

  • Do not require agent-authored detailed description for every information_unit row.
  • Use structured IU profile/canonical graph as the semantic source.
  • A derived/basic summary may be allowed, but not mandatory for every row.
  • For Pack 2B, birth path must create/validate required structural metadata, not force manual/enriched description per row.
  • The parent collection information_unit already has collection-level description (COL-176). Individual IU rows need a different rule.

Impact on F6 / Pack 2B

F6 must include Description Policy Tiering before opening CRUD.

Pack 2B cannot assume current H11/Description rules apply uniformly to IU data rows. It must first define:

  1. Which IU-level objects require detailed description.
  2. Which are exempt and why.
  3. What structured fields replace description for graph understanding.
  4. How Đ43/H11 health checks recognize the exemption.
  5. How birth guard behaves for exempt entity classes.

Directive to Opus/Ocus

Do not open Pack 2B CRUD.

Prepare one consolidated investigation/design package:

knowledge/dev/laws/dieu44-trien-khai/design/13-iu0-description-policy-tiering-and-pack2b-f6-preflight.md

Purpose: adjust Description Governance for scalable IU usage while preserving strict description for architecture/governance objects.

Required content:

  1. Context Graph + Process Gate evidence.
  2. Documents to read:
    • knowledge/dev/laws/law-03-metadata.md
    • knowledge/dev/laws/dieu3-phu-luc-description-templates.md
    • knowledge/dev/laws/law-04-birth-process.md
    • knowledge/dev/laws/dieu43-system-context-law.md
    • knowledge/current-state/queries/h11a-description-basic-missing
    • knowledge/current-state/queries/h11b-description-detail-missing
    • knowledge/dev/guides/description-enrichment-guide.md
    • knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md
    • knowledge/dev/laws/dieu44-trien-khai/design/12a-iu0-pack2a-description-birth-contract-decision-note.md
    • relevant Opus chat/history from S178/S190/S193 if available.
  3. Current law/process summary: what Đ3/Đ4/Đ43/H11 currently enforce.
  4. Runtime investigation proposal or evidence:
    • actual H11a/H11b queries;
    • dot_config.h11b_exclude_species;
    • description triggers/functions if needed;
    • species/collection classification fields available.
  5. Proposed tiered policy: required detailed vs basic-only vs structured-exempt vs unknown.
  6. IU-specific rule: Information Unit rows should be structured-exempt/basic-only unless a subtype explicitly requires enriched description.
  7. Proposed changes to laws/docs:
    • Đ3 amendment wording;
    • Đ4 birth guard wording;
    • Đ43/H11 query logic direction;
    • description-enrichment-guide update;
    • Đ44/F6 Pack 2B birth path implications.
  8. Risks and alternatives.
  9. Clear recommendation and next gate.

Do not patch laws yet unless explicitly instructed after review. This is design/investigation first.

Immediate answer to User's point

Yes: description should be governed by entity class/tier. Detailed agent-written description remains mandatory for complex architectural/governance objects, but should not be mandatory for high-volume IU rows. The system must encode this distinction in machine-checkable policy so missing description is an error for DOT/script/collection where applicable, but normal for exempt IU atoms that are semantically represented by structured profile and graph edges.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-directive-description-policy-tiering-for-iu-2026-05-04.md