two-canon-protocol.md

Two Co-Governing Canons — ADID Framework 15.3 and reasoning_kernel_next

Status: reference design note Created: 2026-09-06 Subjects: ADID_Framework_15_3.md (untracked, package-rendered) · reasoning_kernel_next (G1–G9) · prompt_kernel/README.md

Why this note exists

Answers the recurring question: why does docs/ADID_Framework_15_3.md exist at all, why is it gitignored, and why does the reasoning kernel not replace it? Without it, agents re-derive (or mis-derive, e.g. inverting the succession direction) the relationship from scratch each session.

1. The canons (quoted from the 15.3 header)

Two co-governing canons — do not merge them:

• ADID Framework 15.3 governs the development protocol: communication rules, operating protocol, artifact generation (ADM XML), web search specs.
• reasoning_kernel_next (G1–G9 control graph) governs transformer-based agents: reasoning and authorization.

The header states the succession direction explicitly:

15.3's dual-mode decomposition and semantic-vector narrative do not map onto transformer attention; attempts to extend 15.3 in that direction produced the kernel as a separate, self-contained canon.

So: the kernel is 15.3's successor. 15.3 is frozen — it will not change; the current generation is rendered by the external ADID package. The canons coexist on purpose.

Transformation chain (author, 2026-09-11)

An MLA-class model cannot lift 15.3 at all — so the document was not extended, it was transformed, in three steps:

1. Markdown/ADM canon → Python. 15.3's prose-and-XML canon was re-expressed as declarative Python data — machine-checkable, symbol-collision-proof.
2. Ordered by BGE. Kernel symbols were arranged and integrity-checked with BAAI/bge-base cosine similarity (plus schema-density gradients and a # Semantic Vector assembly-point H1).
3. Simplified into the gate protocol. The ordered kernel was cut down to the G0–G9 control graph now in prompt_kernel/source.py.

So the gate protocol is not a parallel invention: it is 15.3 pythonized, ordered and then simplified until MLA-class attention could carry it. Step 2 was scaffolding for step 3 — the BGE ordering, the density gradient and the assembly-point-as-first-H1 rule were retired on 2026-09-11 (docs/reasoning-framework.md, docs/kernel-stability-principles.md and kernel_semantic_map.json deleted; the live kernel is map-first, its first heading is ## 0. WORKFLOW). Reviving those rules now would break the kernel they were used to build.

2. One protocol, two compilers (parity)

"По сути одно и то же" — the gated workflow is 15.3's ADM system re-expressed for transformer agents:

ADID 15.3 (ADM-XML)	reasoning_kernel_next (G1–G9)
Composite XML Descriptor — the full state canvas (updates.xml)	G3 MASTER_PLAN — full plan artifact: premises, claim ledger, risks, smoke contract
Synthesizer → "executable, atomic XML update plan descriptor"; tools/adm --apply	G7 IMPLEMENT — "smallest cohesive change for the selected task", one bounded task per step
md5/size integrity attributes per descriptor	Claim ledger digest + falsifier; @SV_FORMAT md5/prev-md5/parent-goal-md5
Backup pipeline → rollback	Fossil snapshots per bounded task + git + edit .bak
Roles (Synthesizer/Executor), audited CLI flow a human would follow	@AUTHORITY_SEPARATION — planner/authorizer/implementer/oracle/closure
#information_mark epistemic hierarchy (Popper)	@INFORMATION_STATUS Exact → Inferred → Hypothetical → Guess → Unknown

Direct lineage marker: 15.3's change summary introduced canonical SV hashing (md5_sv_tag) and Prev_MD5s as semantic anchor links — exactly the kernel's SV prev-md5 chaining.

3. Attention economics — why two compilers

• 15.3 executes by generating the complete ADM-based XML state in one shot, then applying single atomic updates per task; rollback lives in ADM. The single-canvas mode rewards MHA-class attention — exact token-level recall across one large structured document at once (GPT/Gemini class).
• This is not a capability ceiling for MLA-class (DeepSeek) models: they enter the state smoothly, over iterations. The kernel's loop reaches the same state in 1–2 passes (ground → draft plan → bounded delta → oracle → revise) because each iteration re-attends only small handles — never the whole canvas. Byte-stable prefix + externalized state (git/fossil/plans/DBs) is what makes iterative entry cheap.
• DeepSeek's fast-answer bias (temperament, not capability) is compensated structurally by kernel guardrails — oracle-before-claim, plan binding, free-first model defaults — so the same state is reached with more Unknowns on the first pass and hard corrections after.

Origin: the gated workflow is itself the product of this constraint analysis. Deep research across GPT and DeepSeek returned the verdict: 15.3 cannot be used on MLA directly — but nothing prevents a Gated Workflow, and everything will work. The kernel is that verdict realized in production.

4. Turn economics — why 15.3 survives

• GPT-class guardrails tax every model turn. Editing files one-by-one multiplies the taxed surface N times.
• 15.3 minimizes turns: one canvas generation + one deterministic tools/adm --apply. Verification is moved out of the model into the CLI: md5/size attributes, auto-repair with telemetry in logs/descriptor_auto_fixes.log, --verify-all / --fix-xml.
• The kernel optimizes the opposite axis: cheap turns, verification granularity per gate.
• Both implement the same principle — a deterministic shell around a stochastic core — tuned for different turn/attention cost models. Merging breaks both: the iterative loop multiplies guardrail tax on GPT-class models; the single-canvas mode outstrips MLA recall.

Why the tax is also cheaper per turn (author, 2026-09-11). GPT-class models visibly relax on 15.3, and the reason is structural rather than rhetorical: the unit of work is a descriptor, not a mutation. The model emits an XML canvas; a deterministic CLI applies it with md5/size verification and a backup pipeline, and the rollback lives in ADM rather than in the model's judgement. Guardrails price irreversibility and blast radius — once both are carried by the tool, there is nothing left to hedge against, so the refusal/hedging surface collapses and the work goes fast. This is not policy evasion: the risk genuinely is lower, and the models are reading that correctly.

Load-bearing condition: the rollback must be real. Backup pipeline, md5/size attributes, fossil snapshots and git are what make the lowered caution honest. The same framing without a working revert path is a trick — the model behaves as if the action were reversible while it is not.

5. Storage decision (2026-09-06)

• docs/ADID_Framework_15_3.md is rendered by the external ADID package → untracked and gitignored (docs/ADID_Framework_*.md wildcard, commit 079f4a213f). The file stays on disk; the package re-renders it.
• Frozen by design: the kernel is the successor; 15.3.1 / 15.4.3 were already retired to git history (per the doc header's installer-asset policy decision D1).
• Fresh clone: the file — and links to it in DOCINDEX.md, docs/README.md, docs/agentic-reasoning-runtime.md — resolve only after the ADID package regenerates the doc. Same receiver model as .cursor/ / .opencode/ assets and docs/examples/.

6. Alignment decision (owner, 2026-09-28)

Aligned, not merged — and the kernel must stand alone. Three findings changed this note's practical reading, so they are recorded here rather than left to the next cycle to re-derive:

1. ADID 15.3 now informs the kernel's protocol directly. The medoid/cluster selection (@MANHATTAN_L1, @ONE_STEP_AHEAD, the degenerate-simplex clause), the bounded-stop conditions at G9 and the five-step bug-fix discipline came from 15.3 and were retained, not reverted. This supersedes the older reading that a 15.3 mechanism present in the kernel is a defect.
2. The single ADM/XML canvas is still not transplanted. 15.3 executes by generating the whole state document once; the transformer kernel reaches the same state iteratively over small handles (§3, §4). Alignment means shared protocol decisions, not one runtime replacing the other, and authority and rollout stay separate: 15.3 is rendered by the external ADID package, the kernel by prompt_kernel (source.py → --install).
3. The kernel is followable without opening 15.3. ADID citations in source.py are provenance, never required reading. A rule must not be phrased through a role the kernel does not define — Analyst1/Analyst2/Oracle2/Mode 2 Fractal Generation were all removed from the runtime text for exactly that reason, with every stop case and both self-trigger conditions preserved. The invariant is pinned by test_runtime_is_followable_without_opening_the_adid_document in prompt_kernel/tests/test_render.py; a rule that reintroduces an undefined role turns it red.

Why the third point is a rule and not a preference: an undefined role is a hole, not a shortcut. It costs the reader a lookup outside the prefix it was given, and the kernel's whole argument is that a transformer attends over what it carries — so anything it does not carry has to be gone, not cited.

Provenance

• Exact (from the 15.3 doc header and §V): canon separation, succession direction, ADM CLI mechanics, SV-hashing lineage.
• Author rationale (session 2026-09-06, framework author): MHA/MLA state-entry styles, guardrail turn economics, and the parity claim ("gated workflow is essentially the same system"). Recorded here so the rationale survives the session.
• Transformation chain (author, session 2026-09-11): 15.3 → Python → BGE-ordered → simplified to the gate protocol; 15.3 stays the reference standard for kernel design, realizable only on MHA-class attention.
• Origin story (author, session 2026-09-06): the kernel came out of deep research in GPT + DeepSeek — DeepSeek's verdict was that 15.3 could not be used on MLA directly, but a Gated Workflow would work. The prediction was confirmed: the MLA-class models the verdict was about run the kernel daily.