dot-iu-cutter v0.5 — Constitution Source Snapshot Options Analysis

Phase: v0_5_constitution_source_snapshot_and_version_policy_design · Date: 2026-05-18 · doc 2 of 5

evaluates: A_KB_revision_snapshot ; B_captured_snapshot_artifact ;
           C_live_page_re_ratification_only ; D_raw_canonical_endpoint
grounding (read-only): Agent Data get_document(knowledge/dev/laws/constitution.md)
  -> exists, revision=44, raw markdown content_length=19132
dml/seed/mutation: none ; decision_authority: GPT / User ONLY ; self_advance: PROHIBITED

0. Shared facts (KB-SSOT, read-only)

sync_architecture (MEMORY/SSOT): knowledge_documents Agent Data -> Directus -> Nuxt render ;
  Agent Data is SSOT for knowledge/*
constitution_source_in_AD: knowledge/dev/laws/constitution.md ; revision=44 ;
  raw_markdown_len=19132 (UPSTREAM of Nuxt render, no render noise)
nuxt_render_of_same_doc: ratified normalized (parser nuxt-incomex-portal-constitution-v1)
  candidate_B = f9d22d05…/17791 (B6 CLOSED for that fixed revision)
codex_fresh (authoritative, 2026-05-18): live normalized 17522 / 17660443… ;
  raw 1205114 / 8d551f47… ; markers 19/1/1/1 ; corresponds to AD revision 44
key_consequence: the previously-ratified 17791 bytes are NOT recoverable — they
  were never persisted verbatim (established in drift triage). Any pin must pin
  CURRENT content, not the lost prior bytes.

---

A. KB revision snapshot (Agent Data revision as immutable identity)

identifier_available: YES — (document_id='knowledge/dev/laws/constitution.md', revision:int)
  revision currently = 44 ; monotone-increment per AD edit ; AD is SSOT
fetch_verify: Agent Data get_document / get_document_for_rewrite returns canonical
  markdown + revision. Pin = (doc_id, revision, checksum_of_normalized_markdown).
  Drift detection = revision int change OR checksum change.
pros:
  - an immutable per-revision identity ALREADY EXISTS; zero new infrastructure
  - UPSTREAM of all Nuxt render noise (markdown, not HTML) -> raw-drift class vanishes
  - SSOT-aligned (AD is the source of truth, Nuxt is a derived view)
  - revision integer gives human-legible lineage
cons / open risks:
  - byte SURFACE changes from Nuxt-HTML(norm 17791) to AD-markdown(raw 19132):
    requires a NEW parser_profile + a fresh B6-style determinism ratification of
    the markdown-normalized checksum. Prior Nuxt ratification work not reusable
    for identity (still reusable for the rendered-view drift detector).
  - MUST verify (read-only, next phase) whether AD API can fetch a SPECIFIC
    HISTORICAL revision (revision N bytes), or only the latest + its number.
    If only latest: revision-int still detects drift, but exact old-byte
    re-fetch unavailable -> pin must also store a captured copy (degrades toward B).
  - revision may bump on non-content metadata edits (title/tags) -> revision
    alone insufficient; MUST pair with content_checksum.
verdict: strongest *durable* identity; needs a new parser ratification + an AD
  historical-fetch capability check before it can be the production pin.

B. Captured snapshot artifact (freeze normalized content as a KB artifact)

mechanism: at a gated capture step, fetch live -> normalize under the ratified
  parser_profile nuxt-incomex-portal-constitution-v1 -> write the exact normalized
  bytes to a WRITE-ONCE, checksum-addressed KB artifact, e.g.
  knowledge/dev/laws/dieu44-trien-khai/snapshots/constitution/icx-const-<sha256>.md
  source_document_version -> points to (artifact_path + content_checksum).
verify_no_mutation_capture_to_seed:
  - artifact filename EMBEDS its sha256 (self-verifying address)
  - seed precheck re-reads artifact, recomputes sha256, asserts == filename == registered
  - mismatch -> STOP (fail-closed). Race window CLOSED: seed/cut bind to artifact, not live.
pros:
  - fullest immutability under OUR control; independent of AD/Nuxt API capabilities
  - REUSES the already-ratified parser_profile + B6 work (artifact = ratified
    normalized bytes) -> no new determinism ratification needed
  - verification is offline (re-hash), no network at seed/cut time
  - directly satisfies GPT primary OPT_2 with minimal new design
cons:
  - content duplication in KB
  - KB docs are themselves revisioned/mutable -> immutability is by CONVENTION
    (checksum-named, never edited, integrity = re-hash). Needs an explicit
    write-once rule + a tamper check at every bind.
  - adds one gated capture action before seed
verdict: simplest SAFE route that unblocks B5 without new ratification; the
  pragmatic OPT_2 implementation.

C. Live page re-ratification only

mechanism: re-run B6-style cross-interval confirmation on the CURRENT live Nuxt
  page, accept the new checksum, seed quickly.
pros: minimal new design ; reuses ratified parser_profile ; fastest nominal unblock
cons / race: reproduces the EXACT race just observed — any KB edit between
  re-ratification and seed re-fails QG1. No immutability. GPT explicitly:
  seed_from_unpinned_live_page = REJECTED_FOR_PRODUCTION_VERSION_IDENTITY.
acceptability: ONLY as a temporary/manual diagnostic path, never production
  identity. Even then it must be paired with an immediate pin (=> collapses
  into B). Not a standalone solution.
verdict: REJECTED as production identity (per GPT); usable only as the
  fetch step *inside* B's capture.

D. Raw canonical endpoint

mechanism: serve/define a stable raw canonical surface (e.g. AD markdown via API,
  or an nginx /raw/constitution.md route) instead of the Nuxt-rendered HTML.
pros:
  - removes the Nuxt render-noise class entirely (deterministic byte stream)
  - simpler parser_profile (markdown, not HTML) -> easier future ratification
  - scales to "Cắt N văn bản" batch factory direction (operating-objectives §5)
cons / needed_later:
  - requires implementation/infra work (endpoint, stability + auth guarantees)
  - a raw endpoint of *latest* is STILL MUTABLE -> D removes render-noise but
    does NOT by itself provide immutability; it must still be paired with a
    pin (A revision or B artifact)
  - needs its own determinism ratification
verdict: a valuable FUTURE ENABLER (logged tech-debt), complements A/B; not an
  immediate unblock and not a substitute for pinning.

5. Comparative summary

immutability:         A=strong(if historical fetch) ; B=strong(by convention) ; C=none ; D=none-alone
new_ratification:     A=REQUIRED ; B=NOT(reuses) ; C=re-ratify(racey) ; D=REQUIRED
new_infra:            A=none ; B=none ; C=none ; D=endpoint build
race_closed:          A=yes ; B=yes ; C=NO ; D=only with A/B
gpt_alignment(OPT_2): A=yes(durable) ; B=yes(pragmatic) ; C=rejected ; D=future-enabler
fastest_safe_unblock: B  (then A as durable upgrade, D as future, C only inside B's fetch)

6. Statement

• All four options evaluated against immutability, ratification cost, infra, race-closure, GPT OPT_2 alignment (QG2). Live drift treated as real; C (live re-ratify) rejected as production identity per GPT (QG1/QG5). Nothing executed or mutated; Agent Data accessed read-only only (QG6).
• doc 2 of 5; STOP after 5 files → route GPT/User. Self-advance PROHIBITED.

Companions: operations-framing, version-policy-design, seed-strategy-update, policy-report.