Incomex AI Portal
KB-26D2

Hiến pháp Kiến trúc Hệ thống Incomex v4.7 — DRAFT (Modular Architecture Amendment)

13 min read Revision 1
laws-newconstitutionv4.7draftmodular-architecturemodule-contract-firstfederated-registryblast-radiusnot-enacted

HIẾN PHÁP KIẾN TRÚC HỆ THỐNG INCOMEX — v4.7 DRAFT

STATUS: DRAFT — KHÔNG PHẢI BAN HÀNH / NOT ENACTED. This is the modular-architecture rewrite draft (track knowledge/dev/laws-new/). The enacted baseline remains knowledge/dev/laws/constitution.md v4.6.3 BAN HÀNH until a separate enactment process (Council review per Đ37 + APR per Đ32 + Owner approval) promotes this draft. Nothing in this document authorizes any production mutation, DDL, deploy, approval mutation, or registry mutation. Drafted 2026-06-12 on the v4.6.3 baseline (KB rev 44). Working language of this draft is English; an enactment candidate must be issued in Vietnamese per house style with this draft as source.

PART I — PRESERVED KERNEL (carried from v4.6.3 UNCHANGED IN STRENGTH)

I.1 — 15 Nguyên tắc Nền tảng (NT1–NT15) — PRESERVED

The fifteen foundation principles of v4.6.3 are carried over verbatim and in full force: NT1 LÀM MỘT LẦN DÙNG MÃI (SSOT), NT2 TỰ ĐỘNG 100%, NT3 DOT 100% (với 5 ngoại lệ Đ33 §13), NT4 SẴN SÀNG THAY ĐỔI, NT5 TỰ PHÁT HIỆN TỰ SỬA, NT6 5 TẦNG ĐỒNG BỘ — CẤM CODE NUXT, NT7 DUAL-TRIGGER, NT8 ASSEMBLY FIRST, NT9 KHÔNG CHẮC ĐÚNG = SAI, NT10 QUẢN LÝ BẰNG PG, NT11 KHAI TỐI THIỂU THÔNG TIN TỐI ĐA, NT12 DOT THEO CẶP (2 CHIỀU), NT13 PG FIRST · PG NATIVE · PG DRIVEN, NT14 THỰC THI ĐƯỢC NGAY, NT15 THIẾT KẾ TRƯỚC TRIỂN KHAI.

v4.7 adds one scoping clarification (not a weakening): where NT2/NT3/NT6/NT12/NT13 state obligations over "mọi thao tác / toàn hệ thống", the obligation is satisfied within the declared contract scope of the module that owns the surface (see Part II, Điều M-2). The obligation itself is unchanged; what changes is whose automation, whose DOT pair, whose PG-first design must answer for it: the owning module's, verified at its contract boundary. Kernel surfaces remain system-scoped as today.

I.2 — Data infrastructure architecture — PRESERVED

The 4-database cluster (directus / incomex_metadata / workflow / postgres) and the 3-layer Não–Kho–Cổng architecture, with exclusive legal gateways per database, are preserved exactly as enacted in v4.5.0–v4.6.3. The gateway-per-store rule (Đ33, exception E4 precedent) is elevated to the canonical pattern for module adapters (Part II).

I.3 — Safety kernel — PRESERVED, EXPLICITLY NON-WEAKENABLE

The following are the Core Kernel (Lớp Lõi). No provision of v4.7, and no module contract, lane, or registry federation, may weaken, bypass, or reinterpret them. Any change to them is Class E (Điều M-4) and follows the full pre-v4.7 macro lane unchanged:

  1. Birth authority (Đ0-G, Đ29, QT-001/QT-002): no entity operates without birth registration; species/classification for governed entities; fn_birth_register as the single register path.
  2. Approval law (Đ32 v1.1): quorum thresholds (high = president + 2 AI-council + 0 reject), no self-approve, open reject not overridable, DOT-100% creation path, audit-preserving FK regime. v4.7 may add scope routing to approval (Điều M-4); it may not lower any quorum.
  3. Production gates: Đ20 Tier-3 explicit Owner approval; production SQL Tier-0 environment+ratification guard (db=directus AND os_proposal_approvals>=1); Đ41 deploy corridor (flock, computed FAST/FULL smoke, atomic swap, known-good rollback, vps_deploy_log); separate named Owner grant per production action (REAL_RUN, permit, activation, repoint, cutover — no inherited authority).
  4. Rollback law: no Tier 2+ execution without a concrete rollback path; rollback to known-good only; rollback proven in staging before apply (FIX7 PROVEN_IN_STAGING doctrine); validator-gated (ROLLBACK_APPLY_DID_NOT_MUTATE, ROLLBACK_NOT_RESTORED_TO_PIN).
  5. Evidence & audit: Rule of Evidence (no artifact = FAIL), No Blind PASS, fail-closed validators with bad-input probes (any_fail_open=false), governance_audit_log + system_issues immutability conventions, Đ31 watchdog with independent alert channel.
  6. Legislative integrity (Đ37): enacted law immutable; amendment via Council; every enacted law has an enforcing DOT; one primary law per domain.

PART II — MODULAR ARCHITECTURE DOCTRINE (NEW IN v4.7)

NT16 — MODULE CONTRACT FIRST (new foundation principle)

# Nguyên tắc Nghĩa Hệ quả
16 MODULE CONTRACT FIRST Every part of the system belongs to exactly one module with a published, versioned, machine-checkable contract (MODULE_CONTRACT.v1 + MODULE_MANIFEST.v1). Work on a module is judged at its contract boundary, not by whole-system review. No contract = no module = surfaces default to kernel scope (heaviest lane). Building against another module's internals = violation. Changing behavior without changing the contract where the contract requires it = violation. A contract that cannot be mechanically checked is not a contract (NT14 applies).

Điều M-1 — Five-layer architecture

The system is governed in five layers: (1) Core Kernel (Part I.3 — identity/birth, canonical/global registry, permission model, production gates, rollback law, global object model UMC/G1–G12, event/audit log); (2) Contract Layer (module contracts, manifests, I/O schemas, authority/mutation/rollback/evidence/compatibility contracts, promotion policy); (3) Module Sandbox (own folder, tests, fixtures, bad-input probes, rollback proof, local registry slice, no production access, Đ41 S-class ceiling S2, O11-style DENY charter fail-closed); (4) Integration Bus (no hidden coupling; adapters with boundary schema validation; version negotiation from compatibility declarations; auth boundary by module identity; declared timeout/failure/fallback; event log with provenance); (5) Promotion Pipeline (Levels 0–4: local test → contract test → integration sandbox → production readiness → production activation). Normative detail: modular-architecture-proposal.md §1, module-contract-standard.md.

Điều M-2 — Declared contract scope

  1. Each module declares its surfaces (tables, DOT pairs, routes, KB paths, stores) in MODULE_MANIFEST.v1. The declaration is diffable and verified mechanically.
  2. Automation/DOT/PG-first obligations (NT2/NT3/NT12/NT13) and sync obligations (NT6) bind per declared scope: the owning module must satisfy them inside its boundary; the contract checker verifies them at the boundary; kernel scanners verify the module's checker is alive (watchdog delegation).
  3. A diff that exits the declared scope is automatically reclassified upward (Điều M-4.3). Undeclared surfaces belong to the kernel by default — fail-closed.

Điều M-3 — Internal change autonomy

  1. An internal-only change (Class A) within a module whose contract is unchanged does not require whole-system review, Council review, president approval, or Context-Graph whole-map reading. It requires: module tests + bad-input probes green, local rollback path, module owner approval, manifest hash update.
  2. A contract-compatible change (Class B) additionally requires automated re-test of consumers' pinned contracts and consumer notification.
  3. This article does not apply to any kernel surface, production surface, or governance surface — those are Class D/E regardless of which module hosts them.
  4. Anti-ceremony clause: the required artifacts for Class A/B lanes are fixed by module-contract-standard.md; expanding them is a Class D change.

Điều M-4 — Promotion by blast radius

  1. Classes: A (internal-only) · B (contract-compatible) · C (contract-breaking) · D (governance-affecting) · E (production/kernel-affecting). Definitions and mechanical tests: modular-architecture-proposal.md §3.
  2. Lanes: A → pipeline Levels 0–1, module owner. B → Levels 0–2, owner + consumer re-test. C → Levels 0–3, owner + affected-consumer sign-offs + APR (risk-routed). D/E → the full pre-v4.7 macro lane unchanged (design → Council → APR quorum → dry-run/rollback-proof → sealed evidence → per-action Owner grants).
  3. Computed, not declared: class is computed by a registered fail-closed classifier from the diff, the manifest, and the contract delta (Đ41 FAST/FULL doctrine). Ambiguity resolves upward. Misclassification discovered later = incident + lane probation for the module.
  4. Đ32 approval routing gains a scope dimension (module/domain) so Class A/B/C approvals route to module owners and risk-appropriate quorums. Quorum thresholds for each risk level are unchanged from v1.1; only routing is added. Until the Đ32 amendment is enacted, Class A/B operate under the existing Đ32 low-risk auto-approve rule with full audit trail.

Điều M-5 — Federated registry doctrine

  1. Global registry = envelopes only. The global registry (Đ44 Family Registry + SCMR + Profile Registry stack over today's collection/dot/normative registries) stores one envelope per module: module_id, version, status, owner, contract pointer + hash, module-registry pointer + hash, envelope tree hash, promotion state, compatibility state, published aggregates.
  2. Module registry = internal objects. Module-internal objects, configs, runs, and intra-module edges live in the module's registry slice under the module's namespace prefix (module_id-prefixed IDs; no arbitrary global ID minting).
  3. Globalization test: an object is registered globally only if it is cross-module, authority-bearing, production-bearing, or kernel-bearing. Everything else stays in the module slice.
  4. Edges: cross-module relations go through universal_edges with provenance; intra-module internal edges may live locally (enactment prerequisite: P44-2-δ resolution).
  5. Drift control: every module has a paired drift-checker DOT recomputing slice and contract hashes; mismatch ⇒ compatibility_state degraded + system_issues (jurisdiction = module_id). Envelope/slice divergence is detected mechanically, fail-closed.
  6. Global visibility is preserved: modules publish standard aggregates (counts per kind/status) and a classification section row (Đ43 dispatcher mechanism) so pivots (Đ26), the context pack (Đ43), and orphan/phantom scanning (Đ29/Đ31) keep total-system coverage at envelope granularity, with delegated module-local detail under watchdogged liveness.

Điều M-6 — Module sandbox law

  1. Every module develops in an isolated sandbox: own folder/ledger, own tests/fixtures, mandatory bad-input probes (fail-closed, any_fail_open=false, detector-correctness, no PASS-token leakage), own staged rollback proof, own registry slice, no production access.
  2. DB access ceiling inside module lanes is Đ41 class S2 (real-PG sandbox with sanitized snapshot, run-scoped tagging, verified one-command cleanup). S3–S5 exist only in trusted/kernel lanes.
  3. Sandboxes operate under a fail-closed DENY charter (O11 pattern). Sandbox output is information (patch + metadata + evidence), never an applied change.
  4. No lane may open before its enforcing checker exists and runs in block mode. A paper lane is no lane (lesson: fn_birth_gate warning-mode, Đ41 unbuilt tooling).

PART III — CONSEQUENTIAL NOTES

  1. What v4.7 does NOT do: it does not lower any quorum, gate, or evidence requirement; does not deprecate the macro lane (reserved as the Class D/E lane); does not move production authority anywhere; does not replace PG as SSOT; does not create a parallel ontology or a second edge store; does not enact Đ44 (it depends on Đ44's promotion as a prerequisite — see migration-map.md).
  2. Law catalog: the v4.6.3 catalog (Đ0–Đ44) remains the catalog of record. Laws amended by this track keep their numbers and filenames in laws-new/ (Đ32 scope routing, Đ36 envelope tier, Đ20 class-aware tiering, Đ35 jurisdictional DOT registration, Đ44 promotion). See migration-map.md for the full provision-level mapping.
  3. Precedence during the draft period: v4.6.3 governs. Where this draft conflicts with enacted law, enacted law wins until enactment of v4.7.

CHANGELOG (draft lineage)

Version Content
v4.6.3 Baseline BAN HÀNH (S178 Fix 15): 15 NT, 4-DB + 3 layers, ops-code positioning, Đ22/32/33/35/41 amendments, Đ43 v1.2 FINAL.
v4.7 DRAFT +NT16 Module Contract First. +Part II Modular Architecture Doctrine (Điều M-1..M-6): five layers, declared contract scope for NT2/3/6/12/13, internal-change autonomy, promotion by blast radius A–E with computed classification, federated registry (envelope/slice), module sandbox law. Part I kernel carried unchanged in strength; Class D/E lane = pre-v4.7 macro lane verbatim. NOT ENACTED.