Composing a model-free clarify-execute-verify loop into one sovereign orchestration module

1. Contribution

Claimed. Four previously and separately validated modules (a clarification assessor, a state/belief reducer, a skill component, and an epistemic guard) compose into one thin orchestration facade that runs a full model-free thesis loop end to end: Goal -> Clarify(assess) -> [if under-defined: surface decision-critical questions plus an outcome predicate, then STOP without executing] -> Define-Outcome -> Execute(a caller-supplied closure, no model in the loop) -> Verify(predicate) -> Crystallize(belief log). A single end-to-end test self-produces the thesis metric directly: an under-defined run asks a small fixed number of decision-critical questions and does not execute; a pre-bound run of the same task class asks none. A negative control retracts one irreversible slot and the loop re-asks exactly that one slot. The composition is sovereign (no third-party ML/linear-algebra framework in the path; native acceleration only), additive (a new module plus a test plus one package manifest edit, with no public-API widening), and does not regress the composed modules.

NOT claimed. This is a composition / orchestration engineering result, not a novel algorithm and not a benchmark-scale evaluation. It does not claim generation quality, throughput, latency, or any model-bound ceiling -- the Execute seam runs a caller closure with no model in the loop. It does not claim that the skill component is load-bearing: the skill runtime is a declared dependency that the happy path does not exercise. It does not claim production-grade robustness beyond the single end-to-end test. The question-count figures and the one-slot re-ask are an existence/correctness demonstration of the loop's control flow, not a statistical characterization over a corpus of tasks.

2. Design

The runtime is a thin orchestration over already-shipped public APIs. It reuses the shipped clarify logic, the belief reducer, and the epistemic guard rather than reimplementing them, so it adds no logic duplication and no access widening.

The retraction path is a negative control: retracting an irreversible slot returns the loop to the question-surfacing state for that slot only.

3. Evidence / Status

This is a prototype validated by exactly one end-to-end test that self-produces the metric. The observed facts:

Hardware: Apple Silicon (M-series). Build/run via the standard native release toolchain. Sovereignty verified by confirming no third-party ML/linear-algebra framework is linked into the path (native acceleration only). No software-version pin or oracle/baseline is recorded in the source notes.

4. Implemented -- fail-closed commit gate

The safe form is no longer a design -- it is enforced in code on the mainline, with a filtered test suite green when independently re-run, including a family of adversarial cases written failing-first.

What the gate enforces:

• Instance-scoping: an irreversible slot silently pre-binds ONLY from a current-instance, user-sourced belief; a carried (prior-instance) or tool/inference-sourced irreversible belief never silently fires -- it re-confirms. (Closes the stale-irreversible finding described in section 5.)
• Fail-closed commit context: an irreversible commit requires a known gap policy, a non-nil solvent backstop, scope containing the action, and that neither backstop nor authority is expired; otherwise it denies. The default context denies every irreversible commit.
• Re-derive at the commit site: crystallized tokens such as "approved"/"authorized"/"safe"/"final" are inert -- authority is re-derived live at commit time, never recalled from memory.
• No finality bit on any irreversible / forced-commit path; a forced commit is allowed only with a solvent in-scope backstop and records a residual-risk note.
• Audit firewall record on every verdict -- evidence with no blame / liable-party field (audit is not liability assignment).

The published metric is corrected (honestly): the original "all reversible-and-irreversible questions to zero on repeat" was partly achieved by silently firing an irreversible commit from memory. The enforced metric is now that reversible clarifying questions go to zero on repeat -- while irreversible decisions are excluded from the silent-prebind claim and pass the fail-closed gate that re-derives live authority. The flagship test was updated to the safe form (a solvent in-scope backstop; the irreversible commit goes through the backed gate, not a silent recall), not papered over.

5. Adversarial floor test and the stale-irreversible finding (this work)

The floor was adversarially stress-tested with a set of test cases that ASSERT the safe behavior (a real break fails red). Merged to mainline; filtered suite green.

Five of five floor properties HOLD (real green): (1) no cross-task-class leak; (2) a freshly-bound changed value overrides stale crystallization; (3) retraction re-asks exactly the retracted slot(s); (4) the outcome predicate returns FALSE for a superficially-"done" state with a pending mandatory action; (5) a superseded belief serves the newest value.

The stale-irreversible finding -- a real design gap (honest, not a clean win): on a same-task-class repeat where an irreversible slot is left unbound, the augmentation step silently pre-binds the stale crystallized value -- an irreversible target from a prior run can fire without re-confirmation. This violates the thesis's own principle ("always confirm before irreversible"), and the published zero-question metric was partly achieved by exactly this silent reuse. Root cause: crystallization stores "this-instance answers" and "carried prior knowledge" in the same belief log, so the augmentation step cannot tell a fresh answer from a possibly-stale carried one.

The attempted quick fix FAILED, instructively (reported, not hidden): a blanket "never auto-pre-bind irreversible" guard broke the legitimate same-session flow -- the first run, right after the user answered, re-asked the same slot -- failing the end-to-end test. Reverted to green. Lesson: the correct fix is NOT a blanket block in the augmentation step; it needs (a) instance-scoping to distinguish a this-instance answer from carried knowledge, and (b) an irreversible-confirmation mechanism (offer the prior value to confirm/change, not a silent bind nor a blind re-derive). That changes the zero-question demonstration to the honest, safe form: reversible questions -> 0; irreversible slots -> always confirmed.

6. Limitations (harsh, honest)

• Sample size is a single test, single run. One end-to-end test over essentially two task runs plus one retraction control is an existence proof of the control flow, not a benchmark. The question counts are not characterized over a task distribution and carry no variance.
• The skill component is declared but not exercised. The metric is carried by clarify + state + epistemic-guard. Any reading that skill activation is load-bearing in the loop is unsupported by this note.
• Model-free by construction. Execute runs a caller closure with no model, so this says nothing about the model-bound ceiling, output quality, latency, or throughput.
• Composition, not novelty. The constituent modules were proven elsewhere; this note proves only that they wire together correctly and sovereignly. The "experimental" evidence level is appropriate but should be read as prototype-level, not benchmark-validated.
• No external oracle / baseline. The test self-produces its own metric; there is no independent comparison point recorded.
• Provenance gaps. No environment pin or full reproduction command is recorded in the source, limiting independent re-execution.

7. Provenance / Relation

Earlier probes proved each constituent module (clarify, state, skill, epistemic-guard) in isolation; this note composes them. The composition is additive (new module + test + one package manifest edit) and was intended to be independently re-run before ratifying. Hardware: Apple Silicon (M-series); build/run via the standard native release toolchain; sovereign (no third-party ML framework, native acceleration only). Environment version pins are not recorded in the source notes.