Circe's thesis is sound.
The implementation has not proved it.

Reviewed 22 September 2026 at commit 68927499f971d9a6302d1cbe2dd98c39a46184d0. The local checkout exactly matched that commit and was clean. This is a review of the whole implementation at that point, not just the final commit's diff. No Circe source files were changed.

I inspected every implementation module in core, context, perception and resolvers-deterministic, the inspector's entry point, the scenario/replay/fuzz infrastructure, the semantic fixtures and tests, and the relevant architecture documents. I ran pnpm test and pnpm typecheck. Both passed. The test result was 126 passing tests, including tests that require the 18 semantic RED cases to remain unsuccessful. Three of those cases return unsupported without interpretation. There are also two successful structural anchors.

I wrote and ran 25 additional counterexamples against this exact code. All reproduced the behavior described in their names. These checks deliberately assert the observed defects; their green result is reproduction evidence, not a safety endorsement. See the downloadable reproduction suite and results attached to this report. Findings explicitly described as static analysis or design gaps have not been presented as dynamic reproductions.

A. Executive assessment

The product thesis is sound. This implementation does not yet establish it.

Circe has useful pieces of a semantic runtime: an authority-aware entity model, explicit observations and beliefs, reference and transaction state, graph retrieval, and a model-independent decision interface. These are worth keeping. Context storage can exist independently of a conversation parser, so it is more than a cache of parser results.

But the running system is still a deterministic utterance interpreter and an in-memory transaction engine. Alongside it sit an in-memory context store and a perception workflow engine. There is no implemented path joining those pieces into the proposed semantic runtime. SemanticTurn is a type with no producer or consumer. Perception can choose a capability, but the kernel independently chooses a capability from words in the original utterance.

More seriously, the kernel is not a dependable consequence boundary yet. I reproduced execution without authority preconditions, duplicate execution from overlapping confirmations, cancellation being overwritten during validation, and lost-response failures that remain RUNNING. These are violations of the core thesis even if the semantic model were perfect.

The current complexity is partly justified and partly ahead of its evidence. The expensive mistake would be to interpret the package diagram and 126 green tests as proof that the foundation is finished, then build Jev integration on top. Several interfaces currently describe guarantees that no component enforces across the boundary.

My recommendation is to keep the architecture's central separation, repair the actual execution and evidence boundaries, and prove one difficult interaction end to end. Do not add more English rules. Do not undertake a wholesale rewrite either.

B. Architecture blockers

B1. Capability selection is still owned by raw language inside the kernel

Architectural flaw. Fix before integrating semantic interpretation.

Paths: RuntimeDeps and SemanticRuntime, compileIntent, request handling, SemanticTurn.

ingest() requires an EventClassifier. For an ordinary request it tokenizes observation.text, and compileIntent() picks the first capability whose lexicon contains any token. The unresolved-reference branch repeats the same routing. A semantic capability placed in classification.frame is ignored. Registration order decides between multiple lexical matches.

I supplied a custom classifier selecting task.resume, with a resolved target, for “continue the other one.” The kernel produced no intent and asked a question because “continue” was not in the descriptor's lexicon. Replacing the classifier with Jev does not solve this.

The smallest principled fix is a typed kernel command entry point. Commands should express new intent, revision, confirmation, cancellation and execution resumption without carrying raw language as routing input. A proposed intent must include the chosen capability ID, named slot bindings, arguments, constraints, supporting decisions and expected versions. The kernel validates those fields against its registered descriptors. Keep the legacy classifier as an adapter for existing fixtures. It must call the same typed entry point.

SemanticProposition currently lacks named slot assignments, arguments, an explicit target transaction/revision and inter-proposition relations. A list of propositions is useful, but not yet an executable contract. Also distinguish “resume this domain entity” from “resume scheduling this existing transaction”; the current request handler treats the resume operation as the latter and bypasses capability compilation.

B2. Confirmation, cancellation and dispatch are not an atomic transition

Implementation bug with an architectural concurrency gap. Blocks effects.

Paths: commit, authority await, affirm and cancel.

ingest() has no serialization or observation deduplication. commit() checks some conditions, awaits authority validation, and then freezes and dispatches without rechecking transaction state or revision. Two confirmations can both enter validation while the transaction is awaiting confirmation. Both subsequently invoke. A cancellation delivered during validation sets CANCELLED; the resumed commit overwrites it and executes anyway. I reproduced both.

I also delivered the same low-risk utterance twice with the same observation ID. It produced two effects with different idempotency keys. The use of an effect ID as an idempotency key does not deduplicate the original command.

Use a per-interaction command sequencer and a persisted command identity. For authority calls outside the state transaction, compare the expected intent revision and transaction state again before committing. A pending validation must not acquire authority to execute a revised or cancelled command. Atomically record the transition and dispatch intent once. Define whether cancellation interrupts a pending validation or queues behind an already committed command; either is implementable, but the observable state must respect that choice.

B3. Authority validation can succeed without validating the target

Implementation bug. Blocks effects.

Paths: snapshots and makeSlotBinding, validation loop.

makeSlotBinding() simply omits preconditions for refs absent from the kernel's views. commit() groups the preconditions it happens to have and accepts the absence of any negative result. An unobserved but resolved ref therefore invokes with no adapter validation. An adapter returning an empty results array for one requested precondition is also treated as success. Both reproduced.

There is a second observation problem: snapshots() takes the first matching entity in insertion-ordered views. After observing version 1 and then version 2, a new intent still binds version 1. This reproduced too. A correct adapter rejects valid new work as stale. The kernel and context store already disagree about which observation is current.

Require complete evidence coverage for every entity binding that needs conditional execution, validate the authority/token/ref relationship, and require one recognized validation result per requested condition. Reject absent or malformed results. Bind the exact observation versions that supported the accepted interpretation, and reject them if they became stale. Do not substitute an arbitrary older view or silently refresh the interpretation's meaning. Entity creation and other operations without an existing target need explicit descriptor semantics, not a blanket “some binding exists” check.

B4. The failure and persistence model is not durable

Missing implementation and unsafe failure behavior. Blocks a durable runtime and effects.

Paths: runtime initialization, executor invocation, InteractionLogEntry, test-only replay.

Core state is held in Maps in a closure. The context implementation is explicitly in-memory. No production journal, recovery entry point, persisted counter namespace or atomic write-before-dispatch mechanism exists. InteractionLogEntry is a declared union that the runtime does not emit. Transaction history is initialized but not populated for the subsequent transitions. The inspector runs scenario fixtures.

An in-memory reference implementation is acceptable deferred work. Calling the durable kernel “proven” is not. Plain serializable records alone do not solve the crash window between external execution and local outcome recording.

I simulated an executor applying a change and throwing because the response was lost. ingest() rejected; the effect stayed RUNNING and the transaction stayed COMMITTED. The runtime never calls reconcile(). Existing UNKNOWN tests inject UNKNOWN as an observation; they do not demonstrate that uncertain dispatch produces it.

Add an injected journal/state transaction port with one minimal persistent implementation. Record accepted commands, frozen effects and pending dispatch durably before invoking. Distinguish known rejection from unknown execution after a transport failure. Persist receipts and reconciliation results. Recover using the same command/effect identities, and never blindly retry an uncertain non-idempotent operation. Pure core code can remain dependency-free by injecting the storage and execution ports.

The replay tests do prove repeatability of selected deterministic scenarios against recorded adapter responses. They re-run the old classifier and consume responses by call kind/order. They do not prove semantic decision replay, crash recovery or recovery without reinvoking a nondeterministic model.

B5. Unaccepted decisions are available as accepted inputs to later stages

Implementation and contract flaw. Fix before Jev.

Paths: answer accessors, dependency check, state reduction.

The orchestrator stores every syntactically valid answer in state.answers, whether policy says auto-bind, clarify, escalate or block. choiceOf() returns it unconditionally. Dependencies require only answer presence. Reducers receive all answers.

I returned A with probability .55 and B with .45. Policy required clarification, but the next stage received A and asked whether to act on it. The dependent trace was RESOLVED. The overall run correctly remained AMBIGUOUS, so this is not evidence of a presently wired effect bypass. It is evidence that the proposed decision graph already propagates an unaccepted binding and creates individually misleading traces. Backend-level AMBIGUOUS with a high-confidence answer likewise produces a RESOLVED trace.

Separate raw answers from accepted values. Normal dependency access must require both successful backend status and an accepted policy outcome. Represent explicit conditional exploration separately if a workflow needs to investigate alternatives. Emit a kernel proposal only when all supporting dependencies are accepted and current. Do not make every workflow author remember an extra outcomes lookup.

B6. Pinned context can be lost, and completeness can lie

Implementation bugs in a safety-relevant retrieval contract. Fix before Jev.

Paths: provider order, seed cap, provider-local limits, materialization caps, completeness.

The candidate-budget stage preserves pins, but pins can disappear before that stage. Sixty-four soft active-scope seeds fill maxSeeds; a later explicit selection is dropped. The frame reports generic seed truncation but has no record that the required pin was lost. The existing pin test uses 30 refs, exercising the 24-candidate budget while staying below the 64-seed cap.

The provider interface returns only an array. Recent activity silently returns its first 16 results, history silently slices bindings, and type retrieval may stop at a limit. The collector cannot report what a provider already discarded. With 17 recent entities, I got 16 candidates and every incompleteness flag false. An exhaustive high-confidence decision was allowed to auto-bind.

Relation and event materialization discard evidence separately from candidate retrieval. I gave two candidates 13 incident relation records, with the warning last. The frame contained the first 12 and no warning, while every incompleteness flag was false. Hop limits and temporal windows also do not state whether the relevant search universe is closed. A singular phrase such as “the risky one” needs enough evidence to disambiguate too; exhaustive alone cannot express all coverage requirements.

Merge and retain pins independently of soft caps. If a backend cannot accept required context, fail explicitly or use a defined partitioning strategy. Give each provider a bounded result containing coverage, truncation and continuation information. Report evidence truncation per candidate as well as candidate truncation. Distinguish “complete within this explicit scope” from “no known truncation in a heuristic search.” Policy should require the coverage appropriate to the question.

B7. Invalidation covers existing dependency edges, not changing knowledge

Architectural gap plus implementation bugs. Fix before reusable semantic beliefs.

Paths: recordObservation, relations and derived records, invalidation closure.

The transitive closure is useful and works for registered assertion/annotation dependencies. But four reproduced cases expose its limits:

• A model reads observation O1. O2 arrives while the model runs. The O1-based annotation is inserted afterward and remains active forever unless another relevant change occurs. Invalidation happened before the dependent existed.
• Re-ingesting the identical observation produces a new record ID and invalidates beliefs despite unchanged version and data.
• Adding a new blockedBy relation does not invalidate an earlier “safe” belief based on the old neighborhood. Depending on existing record IDs cannot represent absence of an edge or completeness of a set.
• A deterministic relation derived from O1 survives O2. Relations can contain deterministic evidence but have no registered dependency list, and automatic dependent invalidation only marks assertions/annotations.

Explicitly invalidating an existing relation can invalidate registered dependents, but ingestion does not identify replacement/retraction of source relations. ingestRelationObservations() only appends. Likewise, recording entity removal as an event is not a tombstone or automatic belief invalidation.

Introduce explicit dependency semantics for immutable historical records versus mutable current state. Add current-observation generations, relation-set generations, and scope/temporal dependencies where the question needs them. On publishing a decision or annotation, verify that the read dependencies still match. Give source observations and relations stable ingestion identities and defined replace/retract semantics. Keep invalidated history, but reject or mark stale a late result at insertion time. A multi-entity tuple is indexed correctly today; freshness across all its subjects still depends on callers manually declaring every dependency.

B8. Decision provenance is neither uniquely addressed nor reliably stored

Implementation and persistence contract flaw. Fix before Jev.

Paths: trace ID, recordDecision, trace contents, frame hash.

The ID is decision:<frame.id>:<spec.id>. It has no workflow run, attempt or stage identity. Frame IDs themselves repeat when the same interaction/observation/expansion is assembled again. I ran two different workflows against the same frame and spec ID, stored both traces, and obtained one record containing the second result. The comment claiming repeated runs never overwrite is false.

runPerceptionWorkflow() merely returns traces. No application code records them, and no frame storage operation exists. Backend failures produce errors without attempt traces. A hash and a frame ID are not enough to recover what was sent.

Hashing also uses a different representation from the backend input. Capabilities are sorted in the hash but retain caller order in frame.capabilities. Reversing their order produced distinct backend inputs with the same hash. Generated metadata, full derived evidence and binary decision criteria are other examples of information not fully captured by the proposed provenance path. Whether each field should influence semantic caching is a separate question from whether the exact request is auditable.

Use an explicit persisted run/attempt identity and unique stage/spec identities. Reject accidental duplicate trace IDs. Persist immutable input frames and complete decision specifications, backend output, applied policy and failure records. Define a canonical backend request representation and hash those exact bytes. A separate normalized semantic cache key is fine, provided it is not presented as the exact request fingerprint.

B9. Backend validation assumes the shape it claims to validate

Implementation bug and underspecified score semantics. Fix before Jev.

Paths: validation, score validation, score policy.

Validation starts by iterating result.answers, accessing answer fields and enumerating probabilities. It takes a PerceptionResult, not unknown data, and is called outside the try/catch surrounding the backend call. Returning null reproduced an uncaught TypeError instead of a structured ERROR result. Missing arrays, null entries and malformed distributions have analogous unchecked shape accesses. The status discriminator is not validated either.

Score answers need only a finite score, a normalized distribution of the right length, and confidence in [0,1]. A score of -999 against three named risk levels, with uniform probabilities and confidence .99, passed validation and auto-bound at high risk. There is no defined numeric mapping from levels to score, no support/range check and no contract relating reported confidence to the distribution. If confidence is a separately calibrated quantity, that relationship must be specified and established with data; the current adapter contract accepts an unsupported assertion of certainty.

Validate unknown data in a total decoder, including the outer envelope and discriminated branches. Define whether score means a selected level, an expected numeric value or something else. Derive or validate it against declared support. Keep backend scores separate from calibrated probability of a correct decision. Require explicit abstention coverage and validate decision specifications, including duplicate IDs, before calling the backend.

B10. Materialization loses knowledge needed to judge evidence

Architectural boundary gap. Fix the minimum frame contract before Jev.

Paths: ContextCandidate and materialized evidence types, candidate construction, history seeding.

The store can persist deterministic assertions, but assembly never calls assertionsFor(). Candidate derived consists solely of freshly generated counts, membership flags and age values. I persisted a must-not-run assertion and confirmed it was absent from the frame.

Attributes lose their observation ID, version and evidence class in the model-facing candidate. Relation and event projections retain only an evidence-class label, not the authority or semantic confidence. Because RelationRecord accepts semantic evidence, a .51-confidence semantic relation and a .99-confidence semantic relation can present the same materialized evidential strength. Generic temporal events also lose their full participating ref tuple. History providers retrieve entities, but do not supply the recorded binding phrase, polarity or discourse role as frame history.

The model therefore sees more than IDs, which is progress, but cannot always distinguish a trusted fact, a weak relationship belief and a remembered mention well enough for the requested judgments. Merely retrieving an entity mentioned earlier is insufficient to explain what “earlier” meant when there are several prior discussions.

Materialize a bounded evidence view with versioned observations, relevant stored assertions, complete relation/event participants and evidence strength. Include relevant interaction bindings with their interaction identity and phrase/role. Carry only what the decision needs, not the whole database, and report omissions. Bind downstream preconditions to that evidence view. Keep user/domain policy explicit: “needs me,” “safe to do” and admissible action targets require information about the actor, obligation and contemplated action that the present generic frame does not guarantee.

C. Important but non-blocking issues

These can be deferred behind a deliberately small, single-process trial, provided the limitations are explicit.

The “indexes” are scans. typeIndexSeedProvider() scans store.entities(). Recent activity scans then sorts; term retrieval scans entities, obtains latest observations and retokenizes attributes every turn; history scans all bindings. latestObservation() walks the full observation history, and eventsFor() gathers and sorts before applying its limit. Materialization and salience repeat these operations. There is no demonstrated scale boundary here. Add store query methods and maintained indexes when moving beyond tiny worlds; the provider contract should expose bounded queries now so a persistent implementation need not emulate full scans. Do not add synonyms as a substitute for retrieval.

Frame size is not bounded by candidate count. Attributes can contain arbitrarily long text; annotations and some dependency arrays are uncapped. Thirty pinned documents can exceed the backend budget even when candidate handling is correct. Define a byte/token/evidence budget with explicit omission metadata and a policy for required material.

Interaction isolation is a host assumption. historySeedProvider() does not filter binding.interactionId. A shared store pulls recent history from another conversation; I reproduced this. Use an explicit history scope and visibility query. Separate stores per interaction avoid that specific exposure but make shared world knowledge and continuity a different host responsibility.

Identity encoding is ambiguous. Authority is now included, which is correct, but delimiters are not escaped or constrained. Namespace x:y, type z collides with namespace x, type y:z. I reproduced the equal keys. Encode the identity tuple unambiguously or validate an explicit character grammar. Several eval helpers still use authority-free shorthand, so kernel-level cross-authority testing remains weak.

The generic capability contract exceeds implemented behavior. Compilation hardcodes a targets slot; slot filling hardcodes content; arity and argumentsSchema are not enforced. Effect freezing splits every binding/ref into its own effect, then unlimited dispatch recombines all bindings into one invocation with the first effect ID and one result applied to every effect. This is not a general implementation of a two-entity operation such as move(source, destination), and the logical effect boundary changes with concurrency configuration. Before enabling such capabilities, define effect units explicitly and preserve all required bindings for each invocation.

Scope and external observation handling are incomplete. UI/world observations are ignored by core ingest(). Several lifetime forms exist as types without expiry enforcement; maps and scope stacks grow. state() returns the live mutable object behind a shallow readonly type, so host code can alter kernel state. The context store does snapshot ordinary record data, but core needs an equally clear mutation boundary.

Policy numbers are not calibrated. The chosen-option probability check is correct. Binary certainty uses P(true) and its complement correctly, provided a confident false answer is kept false. But per-risk overlays can lower a kind-specific bar, and capability overlays can lower high-risk settings. That may be intentional policy configuration, but there is no validated risk floor. Per-decision thresholds also do not establish the correctness probability of a conjunction of decisions. Use held-out outcome calibration and risk coverage tests; do not multiply correlated probabilities or call arbitrary constants calibrated.

D. What is worth keeping

• Authority participates in entity identity and versions are represented separately from semantic beliefs. That is the right basis for the product.
• Observations, deterministic assertions, semantic annotations and interaction bindings are distinct records. The context store copies and freezes ordinary nested data, and invalidation preserves history instead of deleting it.
• The reverse dependency graph handles already-registered transitive assertion/annotation dependencies. Its late-historical-observation test addresses a real ordering problem.
• Relations have a dedicated ingestion channel and adjacency indexes. Multi-entity annotations retain their ref tuple during materialization. These model real semantic-state problems.
• Candidate generation and semantic acceptance are separate functions. Lexical matching used only to propose candidates is a reasonable retrieval technique. A graph neighborhood containing evidence for an answer is desirable; it is not inherently answer leakage.
• Choice acceptance evaluates the selected option, its runner-up margin and declared NONE probability. Semantic binding policy is explicitly separate from execution authorization.
• Perception's SDK boundary is clean today. No Jev import or legacy coding-control-plane domain is required in core. The anti-corruption tests support that narrower claim, although deletion/typecheck cannot prove behavioral replaceability.
• The existing scenario and metamorphic tests cover useful reference, revision and gating behavior. The RED corpus honestly resists extending the bootstrap parser to make semantic examples pass. These tests are a foundation, not proof of the entire runtime.

E. Actual trace of the difficult utterance

Consider “Leave the sketchy auth one alone and continue the other one.” Assume a displayed scope [A, B], where B is the risky authentication task and A is the intended continuation target. Compare the current paths rather than the diagram in the docs.

1. The existing runtime receives the utterance. createRuntime().ingest() calls the deterministic classifier. It does not call assembleFrame() or runPerceptionWorkflow().
2. The classifier recognizes “the other one.” parseReferences() calls resolveOtherOne(), which subtracts pending intent targets from the active scope. It does not first resolve “the sketchy auth one.” With no pending target, it returns both A and B. With B already the pending target, it returns A because of existing transaction state, not because it understood this sentence. With A pending, it returns B.
3. A successful structural match suppresses lexical reference fallback. The auth/risk phrase is not semantically assessed. The first token “Leave” can trigger the generic request fallback, with frame.verb = "leave". No prohibition proposition or exclusion constraint is produced.
4. The kernel scans all raw tokens against capability lexicons. With the current task fake descriptors, neither “leave” nor “continue” selects a capability, so the runtime asks a question and creates no intent. If a caller registers a capability matching a word in the negative clause, that capability can be selected instead. I reproduced a descriptor matching “leave” executing against the set-difference result. compileIntent() also flattens references without preserving include/exclude polarity.
5. The new context path can assemble evidence if a caller invokes it separately. Given stored observations, relationships and events, it can supply attributes and a bounded neighborhood for A and B. It still needs an appropriate caller-supplied FrameInteraction; there is no implemented runtime coordinator keeping that projection synchronized with core.
6. The workflow engine can ask questions if a caller supplies stages. It could ask which candidate is risky, what “leave alone” means and which capability corresponds to continuation. No production interpretation workflow implements that sequence. The checked-in stages are scripted tests. No current component produces a SemanticTurn from the results.
7. Even a perfect semantic answer stops at the next boundary. There is no consumer turning { capability: "task.resume", refs: [A] } into a kernel intent. Supplying it through EventClassifier.frame does not bypass lexical selection.

The intended path should persist an accepted exclusion/constraint for B, determine the intended remainder within a known scope, bind A to task.resume, then ask the kernel to enforce capability policy and authority versions. “The other one” is structurally resolvable only once the excluded entity, intended scope and required cardinality are established. In the docs' three-item example, subtracting one yields two; silently calling that singular reference resolved is another assumption the eval must challenge.

F. Jev integration readiness

Do not start by plugging Jev into the current runtime. It would generate credible-looking decisions while the old token router still governs capability choice, and it would encounter unsafe evidence and trace contracts immediately.

The minimum prerequisite is a small, executable contract trial: a scripted backend produces a typed semantic proposal, the kernel consumes the chosen capability without lexical help, unsafe or stale decisions cannot produce proposals, and the complete decision/command/effect chain is recorded and replayed. Correct pins, coverage reporting, output decoding and attempt identities before spending time adapting a probabilistic backend to those interfaces.

An isolated read-only Jev experiment can be useful sooner to test whether the proposed decision decomposition works. Treat that as model evaluation with captured inputs and outputs, not completion of production integration. It cannot establish kernel safety.

The safe adapter boundary remains PerceptionBackend.decide(canonicalFrame, decisionSpecs). The adapter translates those requests, decodes SDK responses and returns bounded data. It has no authority to mutate stores, select executors, grant confirmation, retry effects or reinterpret rejected results through a lexical fallback. Pin the request serialization, backend/model version and calibration identity. The package should be removable without losing persisted context or requiring a model call to replay a committed interpretation.

G. Parser-debt verdict

The current implementation has not escaped the parser. It has built promising context and perception modules alongside it.

Dependency direction makes replacement possible, but control flow has not achieved it. Lexicon routing lives in core, not just in the frozen bootstrap classifier. A Jev-backed EventClassifier would still hit that code. This is fixable with a typed kernel input; it is not evidence that semantic state itself is a dead end.

Keep structural evaluation of explicit selections, ordinals and already-established sets. Remove language-derived routing from the consequence boundary. A structural substring found inside a mixed utterance must not authorize treating the whole utterance as structurally understood.

H. Overengineering audit

The entity/version model, evidence classes, transaction revisions, explicit confirmation, dependency graph and bounded context projection earn their existence through identifiable failure modes. Simplifying them into transcript memory would sacrifice the product.

The generic workflow framework has much less evidence. Its tests show that stages run in order and scripted answers become traces; they do not show that a fixed act → referent → operation → capability → risk decomposition is accurate, efficient or sufficient for real language. Per-candidate role fan-out and typed multi-proposition decoding are plausible alternatives to test. Neither requires an English clause parser. Compare them on meaning preservation, abstention, latency and cost before declaring one the permanent architecture.

There are also structures with no effective consumer yet: SemanticTurn, the layer-2 deliberation interface, persisted custom assertions in frame assembly, stored salience records, several lifecycle declarations, and the journal union. Small future-facing types are cheap. Building more generic infrastructure around them before a vertical path works is where the design becomes a house of cards.

The biggest hidden coupling is between an apparently generic kernel and the fixture model: one active transaction selected by iteration order, targets and content slots, English tokens, and effect splitting that assumes independently acted-on refs. The appropriate simplification is to remove those accidental assumptions while making the actual command contract smaller and explicit.

I. Missing tests and eval weaknesses

The corpus is a useful adversarial seed, not an adequate semantic evaluation. The lexical traps can disprove simple keyword matching, and the current dumb parser fails. That does not prove another dumb heuristic could not pass: a completed-task filter plus a few status/relationship rules could exploit much of this small published set.

Most corpus retrieval fixtures set activeScope.refs directly from the hand-authored c.candidates. The 100% metric measures expansion from these supplied seeds, as its test name correctly states. It does not measure open-world discovery. The cold-start positive test uses an exact “login” overlap. The empty cold-start test checks an empty candidate list but does not require an explicit retrieval failure status.

The selection probe checks selected refs and polarity. It does not enforce gold.requires, validate a claimed semantic annotation, or assert a required capability for selection-kind cases. For example S14 declares message.reply, but that capability is not checked in its selection probe. Annotation/composition cases return unsupported before trying any interpretation. Workflow tests ignore the frame and return scripted answers. This is orchestration coverage, not semantic accuracy.

Some gold answers need correction before calibrating a model. S12 uses Dana versus Dan to decide “she” without a pronoun binding or explicit pronoun information; those names do not establish the required identity. S08 says “don't touch anything involving auth” but excludes a completed auth task from the exclusion set without an explicit actionable-target scope. The intended answer may be reasonable under an unstated policy, but the fixture should state that policy or accept ambiguity. The worked “other one” example likewise needs a cardinality check.

Add tests that can falsify the architecture:

1. A backend-selected capability with no lexical overlap reaches exactly the intended executor. Reverse capability registration order and add dangerous words in quoted or negated text; behavior must remain stable.
2. Two opposite propositions, different capabilities or different slots in one utterance. Preserve their scope, polarity and dependency relation. Include “don't do X unless Y” and singular “other one” with multiple possible remainders.
3. Blocked/ambiguous/error decisions never enter accepted dependency values or kernel proposals. Exercise independently valid branches without allowing partial execution that drops a prohibition.
4. Every malformed outer/backend shape returns a recorded structured failure. Exercise duplicate spec IDs, sparse/missing distributions and inconsistent score support/confidence.
5. Repeated same-frame runs, retries, multiple workflows and different model outputs all remain uniquely retrievable. Replay uses recorded decisions and never calls the backend.
6. Hash/request round trips preserve actual ordering and all model-visible fields. Change evidence strength, binary criteria and capability order independently.
7. Pins at 63, 64, 65 and far above the provider/candidate budgets. Fill soft seeds before adding explicit/pending-obligation pins. Verify mandatory context or an explicit failure.
8. Retrieval with thousands of decoys, rare old relevant entities, no lexical overlap, dense hubs and relations just beyond hop/evidence caps. Measure cold-start recall and coverage truthfulness separately from semantic precision.
9. Invalidation during an in-flight decision; late insertion after dependency changes; relation additions/retractions; historical-versus-current dependencies; entity tombstones; multi-subject beliefs and duplicate event delivery.
10. A journaled restart at each boundary: before freeze, after freeze, after external application, before receipt, after receipt and during reconciliation. Recover the same logical operation and never fabricate a known result.
11. Parallel confirm/cancel/revise/effect-observation schedules, not just sequential utterance permutations. Check transaction/revision compare-and-set behavior.
12. Partial, empty, malformed and cross-authority validation responses; missing observations; observed version updates; atomic rejection by the executor after a validation/application race.
13. Multi-slot, zero-existing-target and arity-one capabilities. Ensure the effect represents the complete invocation, and receipts/outcomes correspond to actual dispatch units.
14. Separate interactions in a shared store, actor-specific obligations, and unsupported assumptions about identity or pronouns. Names alone must not establish a referent.
15. Held-out paraphrases and counterfactual pairs. Keep wording fixed while changing the relevant evidence; keep evidence fixed while changing names/order/irrelevant titles. Evaluate retrieval failure, semantic ambiguity and invalid gold separately. Report false actions, abstention, calibration, cost and latency, not just total passes.

Use the 25 attached reproductions as starting failures after flipping their assertions to the required behavior. Keep the existing 126-test baseline, but add a separate real semantic suite whose passing condition is semantic success rather than continued parser failure.

J. Next three implementation milestones

1. Prove the consequence boundary with typed commands

Add the typed kernel entry point and adapt the old fixture classifier to it. Eliminate raw-token capability routing from core. Enforce slot schemas, expected versions and accepted command identities. Fix duplicate delivery, concurrent confirmation, cancellation during validation and unknown invocation outcomes. Decide and test effect units and complete bindings. Use one scripted two-proposition example to prove that task.resume reaches the executor solely because the semantic proposal chose it.

Exit criteria: no lexicon required for semantic commands; no execution without complete validated evidence; repeat/concurrent commands cannot duplicate an effect; cancellation/revision has defined atomic behavior; uncertain invocation is recoverably UNKNOWN.

2. Make semantic evidence and replay trustworthy

Separate accepted workflow values from raw answers. Add total result decoding, explicit run identities, immutable stored frames/specs/traces and a minimal persistent command/effect journal. Validate dependencies when committing model results. Repair pin collection and provider/evidence coverage. Materialize the stored assertions and discourse/evidence needed by the chosen example. Keep retrieval query contracts ready for indexes without building a large search platform first.

Exit criteria: every effect is traceable to an accepted, current proposal and its exact model input; no missing mandatory context is disguised as completeness; restart and replay perform no new interpretation; the in-flight-invalidation cases fail safely.

3. Add Jev and measure the semantic thesis

Implement the isolated adapter against those working contracts. Add a real semantic workflow and first run it with effect execution disabled. Correct ambiguous gold, add held-out cases, test candidate generation without supplied gold neighborhoods, and compare reasonable bounded decomposition strategies. Calibrate risk-aware acceptance from observed outcomes. Enable a limited set of reversible capabilities only after the consequence and evidence gates pass.

Exit criteria: the difficult mixed utterance completes end to end with the intended constraint and capability; deleting the lexical bootstrap path does not change semantic execution; backend removal leaves durable state/replay intact and causes explicit semantic unavailability.

The next proof should be one hard utterance choosing the right meaning, producing exactly the intended effect, and surviving a crash. More architecture vocabulary or more tests over the existing parser will not establish that.