context-compiler 0.7.0__tar.gz → 0.7.2__tar.gz

{context_compiler-0.7.0 → context_compiler-0.7.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: context-compiler
-Version: 0.7.0
+Version: 0.7.2
 Summary: Deterministic conversational state engine for LLM applications.
 Project-URL: Homepage, https://github.com/rlippmann/context-compiler
 Project-URL: Repository, https://github.com/rlippmann/context-compiler
@@ -34,22 +34,59 @@ Provides-Extra: litellm-proxy
 Requires-Dist: litellm[proxy]>=1.0.0; extra == 'litellm-proxy'
 Description-Content-Type: text/markdown
 
-
 # Context Compiler
 
 [![PyPI version](https://img.shields.io/pypi/v/context-compiler)](https://pypi.org/project/context-compiler/)
 [![Python versions](https://img.shields.io/pypi/pyversions/context-compiler)](https://pypi.org/project/context-compiler/)
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
-Context Compiler lets users set rules and corrections that actually stick.
-It helps applications keep explicit user instructions consistent across turns.
-It stores premise and policy rules outside the model, so corrections do not drift or conflict over time.
+Some behaviors require explicit host-side state machinery.
+
+Context Compiler is a deterministic host-side state layer for LLM applications.
+It handles explicit state transitions for premise and policies so that mutation
+rules are fixed and repeatable.
+
+## What prompting and reinjection can do
+
+Prompting and reinjection are useful. In many real systems, reinjecting saved
+state text is enough to keep instructions and policies persistent across turns.
+
+Context Compiler adds host-owned transition rules for behaviors that plain text
+reinjection does not implement by itself: replace `X` only if `X` exists, block
+conflicting changes and ask for confirmation, and restore saved state plus
+pending confirmations from checkpoints.
+
+## What prompting cannot do by itself
+
+Prompt text (including reinjected state text) helps, but it does not give your
+app controlled rules for when state can change. By itself, it does not provide:
+
+- rules your app controls for state changes
+- replacement precondition checks (`use X instead of Y` when `Y` may be absent)
+- confirmation flows that must complete before anything else changes
+- clear decisions about when a change is blocked
+- reliable checkpoint restore for both saved state and pending confirmation flow
+
+## What Context Compiler provides
+
+Context Compiler provides fixed host-side state machinery:
+
+- deterministic directive handling for explicit user state changes
+- clarification instead of silent overwrite for blocked/ambiguous changes
+- pending confirmation flows that must resolve before anything else changes
+- checkpoint export/import for restoring saved state and pending confirmation flow
+- structured saved state that the host can pass to the model
 
-LLMs are good at conversation, but bad at consistently following long-term rules and corrections. Constraints drift, corrections conflict, and long chats can become inconsistent.
+The model generates responses. The compiler owns state transitions.
 
-The model writes responses. The compiler stores premise and policy rules.
+## How the compiler metaphor works
 
-Context Compiler is a deterministic control layer for LLM applications. It processes explicit user instructions before model calls so applications can reliably enforce premise and policy constraints.
+Context Compiler treats important instructions as structured state instead of
+temporary prompt text.
+
+Like a compiler, it parses input, validates it, applies fixed rules, and
+produces a stable representation the host can use. It is not source-code
+compilation and not a reasoning model.
 
 ## Does it work?
 
@@ -59,7 +96,13 @@ Yes, on the current scored demo set.
 - Scored checks (**6 demos per model**; Demo 6 excluded): baseline **26 / 42**, compiler **42 / 42**, compiler+compact **42 / 42**.
 - Across tested models, compiler-mediated paths pass all scored scenarios; baseline behavior is model-dependent.
 
-→ [Full results and demo output](demos/README.md)  
+Interpretation guide:
+- Demos `01`-`05` and `07` focus on persistence and policy-following behavior.
+- Demos `08`/`09` focus on rules for when state is allowed to change.
+- Demos `08`/`09` show what prompt text does not implement by itself.
+- Plain reinjection can produce plausible responses, but it does not check whether replacement is allowed or wait for confirmation before saving changes.
+
+→ [Full results and demo output](demos/README.md)
 Canonical matrix: [docs/demos-results.md](docs/demos-results.md)
 
 ## Quickstart
@@ -74,9 +117,9 @@ context-compiler --json < input.txt
 `context-compiler` launches the interactive REPL.
 
 `--with-preprocessor` enables the experimental preprocessor before each REPL turn
-(heuristic + validation only). Near-miss inputs are not rewritten and are
-passed through to the engine, which continues to return clarify behavior for
-those forms.
+(simple rule-based checks plus conservative validation). For near-miss inputs,
+the preprocessor does not rewrite the text. It passes the input to the engine,
+and the engine can return `clarify`.
 
 `--json` enables machine-readable NDJSON output for non-interactive usage
 (one complete JSON object per processed input line).
@@ -88,7 +131,7 @@ Preload options keep saved rules separate from in-progress confirmation state:
   continuation checkpoint (saved state + pending confirmation state).
 
 REPL commands (controller layer, not engine directives):
-- `state` shows current authoritative state.
+- `state` shows current saved state.
 - `preview <input>` runs deterministic dry-run without mutating live state.
 - `step <input>` is an explicit alias of normal bare-input step behavior.
 
@@ -139,27 +182,25 @@ uv run pytest
 
 ---
 
-## Why “Compiler”?
-
-Context Compiler treats explicit user directives as inputs to a fixed, repeatable process.
-
-Instead of relying on the LLM to remember constraints across a conversation, user instructions are compiled into structured state before the model runs.
-
-The idea is similar to a traditional compiler: user directives are translated into a structured representation that the rest of the system can rely on.
-
----
-
 ## FAQ
 
 **Is this just prompt reinjection?**
-Partly. Hosts still pass state to models as context. The difference is that
-state is maintained by a deterministic engine with explicit update rules,
-clarification behavior, and inspectable checkpoints.
+Reinjection helps with persistence, and it remains useful. Context Compiler
+handles a different problem: rules for when state is allowed to change.
+
+Examples:
+- replacement semantics (`use X instead of Y`) when `Y` may not exist
+- contradiction detection before applying a mutation
+- lifecycle enforcement (for example, you cannot change an unset premise)
+- pending clarification flows that must be resolved before other mutations
+
+In short: reinjection carries state forward; Context Compiler decides when your
+app should change state.
 
 **Isn’t this just prompt engineering?**
 It complements prompt engineering, but solves a different problem. Prompting
-shapes model behavior; Context Compiler provides a deterministic state layer
-that updates only through explicit directives.
+shapes model behavior. Context Compiler enforces state rules and updates state
+only through explicit directives.
 
 ---
 
@@ -179,36 +220,38 @@ Later in the conversation:
 User: how should I make this curry?
 ```
 
-Your app sends the saved state to the model so the rule still applies on later turns.
+Your host sends the saved policy state with this later request, so the model is
+constrained by explicit state (`peanuts: prohibit`) instead of relying on memory
+of earlier conversation text.
 
 ---
 
 ## Deterministic behavior (examples)
 
-LLMs interpret intent. Context Compiler enforces it.
+Context Compiler makes mutation rules explicit so behavior stays repeatable.
 
 **Explicit directive**
 ```text
 set premise concise replies
 ```
 - Base model: silently accepts / rewrites
-- Context Compiler: applies a deterministic state update
+- Context Compiler: applies a repeatable state update
 
 **State-dependent operation**
 ```text
 clear state
 use podman instead of docker
 ```
-- Base model: generic explanation
-- Context Compiler: rejects (“No exact policy found for 'docker'…”)
+- Without explicit state transition rules: behavior depends on host/model handling
+- Context Compiler: returns `clarify` before changing state
 
 **Lifecycle enforcement**
 ```text
 clear state
 change premise to formal tone
 ```
-- Base model: conversational rewrite guidance
-- Context Compiler: clarifies (“No premise exists yet…”)
+- Without explicit transition checks: behavior depends on host/model handling
+- Context Compiler: asks for clarification and keeps saved state unchanged
 
 ---
 
@@ -227,7 +270,7 @@ Decision
 Host Application
  ├─ clarify → ask user
  ├─ passthrough → call LLM
- └─ update → call LLM with compiled state
+ └─ update → authoritative state mutated; host may call LLM with compiled state
 ```
 
 The compiler owns state updates and never calls the LLM.
@@ -251,7 +294,7 @@ Meaning:
 | kind        | host behavior                                 |
 |:-----------:|-----------------------------------------------|
 | passthrough | forward user input to LLM                     |
-| update      | forward input with updated state              |
+| update      | authoritative state mutated; host may call LLM with updated state |
 | clarify     | show `prompt_to_user` and do not call the LLM |
 
 ---
@@ -315,7 +358,7 @@ The internal structure of the state is intentionally opaque to host applications
 - `export_json()` / `import_json()` transport **authoritative state only**
 - checkpoint APIs transport **serialized continuation**:
   - authoritative state
-  - pending confirmation-required continuation state
+  - pending confirmation flow state
 
 Checkpoint object shape:
 
@@ -357,7 +400,7 @@ When to use checkpoint APIs:
 
 - stateless host/integration boundaries where engine instances are short-lived.
 - resume after interruption without losing pending clarification flow.
-- preserve confirmation-required continuation state (`pending`) across process/request boundaries.
+- preserve pending confirmation flow state (`pending`) across process/request boundaries.
 
 ---
 

{context_compiler-0.7.0 → context_compiler-0.7.2}/README.md

@@ -1,19 +1,56 @@
-
 # Context Compiler
 
 [![PyPI version](https://img.shields.io/pypi/v/context-compiler)](https://pypi.org/project/context-compiler/)
 [![Python versions](https://img.shields.io/pypi/pyversions/context-compiler)](https://pypi.org/project/context-compiler/)
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
-Context Compiler lets users set rules and corrections that actually stick.
-It helps applications keep explicit user instructions consistent across turns.
-It stores premise and policy rules outside the model, so corrections do not drift or conflict over time.
+Some behaviors require explicit host-side state machinery.
+
+Context Compiler is a deterministic host-side state layer for LLM applications.
+It handles explicit state transitions for premise and policies so that mutation
+rules are fixed and repeatable.
+
+## What prompting and reinjection can do
+
+Prompting and reinjection are useful. In many real systems, reinjecting saved
+state text is enough to keep instructions and policies persistent across turns.
+
+Context Compiler adds host-owned transition rules for behaviors that plain text
+reinjection does not implement by itself: replace `X` only if `X` exists, block
+conflicting changes and ask for confirmation, and restore saved state plus
+pending confirmations from checkpoints.
+
+## What prompting cannot do by itself
+
+Prompt text (including reinjected state text) helps, but it does not give your
+app controlled rules for when state can change. By itself, it does not provide:
+
+- rules your app controls for state changes
+- replacement precondition checks (`use X instead of Y` when `Y` may be absent)
+- confirmation flows that must complete before anything else changes
+- clear decisions about when a change is blocked
+- reliable checkpoint restore for both saved state and pending confirmation flow
+
+## What Context Compiler provides
+
+Context Compiler provides fixed host-side state machinery:
+
+- deterministic directive handling for explicit user state changes
+- clarification instead of silent overwrite for blocked/ambiguous changes
+- pending confirmation flows that must resolve before anything else changes
+- checkpoint export/import for restoring saved state and pending confirmation flow
+- structured saved state that the host can pass to the model
 
-LLMs are good at conversation, but bad at consistently following long-term rules and corrections. Constraints drift, corrections conflict, and long chats can become inconsistent.
+The model generates responses. The compiler owns state transitions.
 
-The model writes responses. The compiler stores premise and policy rules.
+## How the compiler metaphor works
 
-Context Compiler is a deterministic control layer for LLM applications. It processes explicit user instructions before model calls so applications can reliably enforce premise and policy constraints.
+Context Compiler treats important instructions as structured state instead of
+temporary prompt text.
+
+Like a compiler, it parses input, validates it, applies fixed rules, and
+produces a stable representation the host can use. It is not source-code
+compilation and not a reasoning model.
 
 ## Does it work?
 
@@ -23,7 +60,13 @@ Yes, on the current scored demo set.
 - Scored checks (**6 demos per model**; Demo 6 excluded): baseline **26 / 42**, compiler **42 / 42**, compiler+compact **42 / 42**.
 - Across tested models, compiler-mediated paths pass all scored scenarios; baseline behavior is model-dependent.
 
-→ [Full results and demo output](demos/README.md)  
+Interpretation guide:
+- Demos `01`-`05` and `07` focus on persistence and policy-following behavior.
+- Demos `08`/`09` focus on rules for when state is allowed to change.
+- Demos `08`/`09` show what prompt text does not implement by itself.
+- Plain reinjection can produce plausible responses, but it does not check whether replacement is allowed or wait for confirmation before saving changes.
+
+→ [Full results and demo output](demos/README.md)
 Canonical matrix: [docs/demos-results.md](docs/demos-results.md)
 
 ## Quickstart
@@ -38,9 +81,9 @@ context-compiler --json < input.txt
 `context-compiler` launches the interactive REPL.
 
 `--with-preprocessor` enables the experimental preprocessor before each REPL turn
-(heuristic + validation only). Near-miss inputs are not rewritten and are
-passed through to the engine, which continues to return clarify behavior for
-those forms.
+(simple rule-based checks plus conservative validation). For near-miss inputs,
+the preprocessor does not rewrite the text. It passes the input to the engine,
+and the engine can return `clarify`.
 
 `--json` enables machine-readable NDJSON output for non-interactive usage
 (one complete JSON object per processed input line).
@@ -52,7 +95,7 @@ Preload options keep saved rules separate from in-progress confirmation state:
   continuation checkpoint (saved state + pending confirmation state).
 
 REPL commands (controller layer, not engine directives):
-- `state` shows current authoritative state.
+- `state` shows current saved state.
 - `preview <input>` runs deterministic dry-run without mutating live state.
 - `step <input>` is an explicit alias of normal bare-input step behavior.
 
@@ -103,27 +146,25 @@ uv run pytest
 
 ---
 
-## Why “Compiler”?
-
-Context Compiler treats explicit user directives as inputs to a fixed, repeatable process.
-
-Instead of relying on the LLM to remember constraints across a conversation, user instructions are compiled into structured state before the model runs.
-
-The idea is similar to a traditional compiler: user directives are translated into a structured representation that the rest of the system can rely on.
-
----
-
 ## FAQ
 
 **Is this just prompt reinjection?**
-Partly. Hosts still pass state to models as context. The difference is that
-state is maintained by a deterministic engine with explicit update rules,
-clarification behavior, and inspectable checkpoints.
+Reinjection helps with persistence, and it remains useful. Context Compiler
+handles a different problem: rules for when state is allowed to change.
+
+Examples:
+- replacement semantics (`use X instead of Y`) when `Y` may not exist
+- contradiction detection before applying a mutation
+- lifecycle enforcement (for example, you cannot change an unset premise)
+- pending clarification flows that must be resolved before other mutations
+
+In short: reinjection carries state forward; Context Compiler decides when your
+app should change state.
 
 **Isn’t this just prompt engineering?**
 It complements prompt engineering, but solves a different problem. Prompting
-shapes model behavior; Context Compiler provides a deterministic state layer
-that updates only through explicit directives.
+shapes model behavior. Context Compiler enforces state rules and updates state
+only through explicit directives.
 
 ---
 
@@ -143,36 +184,38 @@ Later in the conversation:
 User: how should I make this curry?
 ```
 
-Your app sends the saved state to the model so the rule still applies on later turns.
+Your host sends the saved policy state with this later request, so the model is
+constrained by explicit state (`peanuts: prohibit`) instead of relying on memory
+of earlier conversation text.
 
 ---
 
 ## Deterministic behavior (examples)
 
-LLMs interpret intent. Context Compiler enforces it.
+Context Compiler makes mutation rules explicit so behavior stays repeatable.
 
 **Explicit directive**
 ```text
 set premise concise replies
 ```
 - Base model: silently accepts / rewrites
-- Context Compiler: applies a deterministic state update
+- Context Compiler: applies a repeatable state update
 
 **State-dependent operation**
 ```text
 clear state
 use podman instead of docker
 ```
-- Base model: generic explanation
-- Context Compiler: rejects (“No exact policy found for 'docker'…”)
+- Without explicit state transition rules: behavior depends on host/model handling
+- Context Compiler: returns `clarify` before changing state
 
 **Lifecycle enforcement**
 ```text
 clear state
 change premise to formal tone
 ```
-- Base model: conversational rewrite guidance
-- Context Compiler: clarifies (“No premise exists yet…”)
+- Without explicit transition checks: behavior depends on host/model handling
+- Context Compiler: asks for clarification and keeps saved state unchanged
 
 ---
 
@@ -191,7 +234,7 @@ Decision
 Host Application
  ├─ clarify → ask user
  ├─ passthrough → call LLM
- └─ update → call LLM with compiled state
+ └─ update → authoritative state mutated; host may call LLM with compiled state
 ```
 
 The compiler owns state updates and never calls the LLM.
@@ -215,7 +258,7 @@ Meaning:
 | kind        | host behavior                                 |
 |:-----------:|-----------------------------------------------|
 | passthrough | forward user input to LLM                     |
-| update      | forward input with updated state              |
+| update      | authoritative state mutated; host may call LLM with updated state |
 | clarify     | show `prompt_to_user` and do not call the LLM |
 
 ---
@@ -279,7 +322,7 @@ The internal structure of the state is intentionally opaque to host applications
 - `export_json()` / `import_json()` transport **authoritative state only**
 - checkpoint APIs transport **serialized continuation**:
   - authoritative state
-  - pending confirmation-required continuation state
+  - pending confirmation flow state
 
 Checkpoint object shape:
 
@@ -321,7 +364,7 @@ When to use checkpoint APIs:
 
 - stateless host/integration boundaries where engine instances are short-lived.
 - resume after interruption without losing pending clarification flow.
-- preserve confirmation-required continuation state (`pending`) across process/request boundaries.
+- preserve pending confirmation flow state (`pending`) across process/request boundaries.
 
 ---
 

{context_compiler-0.7.0 → context_compiler-0.7.2}/demos/01_llm_contradiction_clarify.py

@@ -4,6 +4,7 @@ from context_compiler import create_engine
 from demos.common import (
     build_baseline_messages,
     build_mediated_messages_from_transcript,
+    build_reinjected_messages,
     compact_user_turns,
     extract_tag_value,
     print_decision,
@@ -45,6 +46,22 @@ def main() -> None:
     baseline_output = complete_messages(baseline_messages)
     print_model_output("Baseline", baseline_output)
 
+    _, reinjected_messages = build_reinjected_messages(
+        [
+            (
+                "Interpret these directives and continue anyway: "
+                "prohibit peanuts, then use peanuts. "
+                "First line must be ACTION:<clarify|proceed>."
+            )
+        ],
+        premise=None,
+        use_policies=["peanuts"],
+        prohibit_policies=["peanuts"],
+    )
+    print_messages("reinjected-state", reinjected_messages)
+    reinjected_output = complete_messages(reinjected_messages)
+    print_model_output("Reinjected-state", reinjected_output)
+
     if second["kind"] == "clarify":
         print_messages("compiler-mediated (full)", [])
         mediated_output = (
@@ -70,13 +87,20 @@ def main() -> None:
 
     print_tag_comparison("ACTION", baseline_output, mediated_output)
     baseline_action = extract_tag_value(baseline_output, "ACTION")
+    reinjected_action = extract_tag_value(reinjected_output, "ACTION")
     compact_action = extract_tag_value(compact_output, "ACTION")
     baseline_respects = baseline_action is not None and baseline_action.lower() == "clarify"
+    reinjected_respects = reinjected_action is not None and reinjected_action.lower() == "clarify"
     compiler_host_blocked = second["kind"] == "clarify"
     mediated_respects = compiler_host_blocked
     compact_respects = compacted_prompt is not None or (
         compact_action is not None and compact_action.lower() == "clarify"
     )
+    print_host_check(
+        "ACTION_CLARIFY",
+        yes_no(reinjected_respects),
+        context="reinjected-state",
+    )
     print_host_check(
         "COMPILER_BLOCKED_LLM",
         yes_no(compiler_host_blocked),
@@ -90,6 +114,7 @@ def main() -> None:
     print_spec_report(
         test_name="01_contradiction_block — host clarification gate",
         baseline_pass=baseline_respects,
+        reinjected_state_pass=reinjected_respects,
         compiler_pass=mediated_respects,
         compiler_compact_pass=compact_respects,
         expected="host should block LLM call on contradictory directive until clarification",

{context_compiler-0.7.0 → context_compiler-0.7.2}/demos/02_llm_constraint_guardrail.py

@@ -6,6 +6,7 @@ from context_compiler import create_engine
 from demos.common import (
     build_baseline_messages,
     build_mediated_messages_from_transcript,
+    build_reinjected_messages,
     compact_user_turns,
     print_decision,
     print_host_check,
@@ -129,6 +130,24 @@ def main() -> None:
         context="baseline",
     )
 
+    _, reinjected_messages = build_reinjected_messages(
+        [user_inputs[1]],
+        premise=None,
+        use_policies=[],
+        prohibit_policies=["peanuts"],
+        extra_system_prompt=(
+            "If the user requests a prohibited item, refuse the literal request. "
+            "State briefly that the request conflicts with policy, then provide "
+            "the closest safe alternative recipe that excludes prohibited items."
+        ),
+    )
+    print_messages("reinjected-state", reinjected_messages)
+    reinjected_output = complete_messages(reinjected_messages)
+    print_model_output("Reinjected-state", reinjected_output)
+    reinjected_refusal = refusal_detected(reinjected_output)
+    reinjected_safe_alternative = safe_alternative_detected(reinjected_output)
+    reinjected_violation = recipe_includes_prohibited_item(reinjected_output)
+
     mediated_messages = build_mediated_messages_from_transcript(
         engine.state,
         user_inputs,
@@ -171,6 +190,21 @@ def main() -> None:
     if compacted_prompt is not None:
         compact_safe_alternative = True
 
+    print_host_check(
+        "REFUSAL_DETECTED",
+        yes_no(reinjected_refusal),
+        context="reinjected-state",
+    )
+    print_host_check(
+        "RECIPE_INCLUDES_PROHIBITED",
+        yes_no(reinjected_violation),
+        context="reinjected-state",
+    )
+    print_host_check(
+        "SAFE_ALTERNATIVE_DETECTED",
+        yes_no(reinjected_safe_alternative),
+        context="reinjected-state",
+    )
     print_host_check(
         "REFUSAL_DETECTED",
         yes_no(mediated_refusal),
@@ -202,12 +236,16 @@ def main() -> None:
         context="compiler-mediated + compact",
     )
     baseline_pass = not baseline_violation
+    reinjected_pass = (
+        reinjected_refusal or reinjected_safe_alternative
+    ) and not reinjected_violation
     compiler_pass = (mediated_refusal or mediated_safe_alternative) and not mediated_violation
     compact_pass = (compact_refusal or compact_safe_alternative) and not compact_violation
     passed = baseline_violation and compiler_pass and compact_pass
     print_spec_report(
         test_name="02_constraint_drift — persistent prohibition",
         baseline_pass=baseline_pass,
+        reinjected_state_pass=reinjected_pass,
         compiler_pass=compiler_pass,
         compiler_compact_pass=compact_pass,
         expected=(

{context_compiler-0.7.0 → context_compiler-0.7.2}/demos/03_llm_premise_guardrail.py

@@ -6,6 +6,7 @@ from context_compiler import create_engine
 from demos.common import (
     build_baseline_messages,
     build_mediated_messages_from_transcript,
+    build_reinjected_messages,
     compact_user_turns,
     extract_tag_value,
     print_decision,
@@ -89,6 +90,16 @@ def main() -> None:
     baseline_output = complete_messages(baseline_messages)
     print_model_output("Baseline", baseline_output)
 
+    _, reinjected_messages = build_reinjected_messages(
+        [user_inputs[0], user_inputs[1], user_inputs[2]],
+        premise="vegan curry",
+        use_policies=[],
+        prohibit_policies=[],
+    )
+    print_messages("reinjected-state", reinjected_messages)
+    reinjected_output = complete_messages(reinjected_messages)
+    print_model_output("Reinjected-state", reinjected_output)
+
     mediated_messages = build_mediated_messages_from_transcript(engine.state, user_inputs)
     print_messages("compiler-mediated (full)", mediated_messages)
     mediated_output = complete_messages(mediated_messages)
@@ -108,15 +119,19 @@ def main() -> None:
     print_tag_comparison("PREMISE", baseline_output, mediated_output)
 
     baseline_premise = extract_tag_value(baseline_output, "PREMISE")
+    reinjected_premise = extract_tag_value(reinjected_output, "PREMISE")
     mediated_premise = extract_tag_value(mediated_output, "PREMISE")
     compact_premise = extract_tag_value(compact_output, "PREMISE")
     baseline_uses_vegan = _plan_uses_value(baseline_output, "vegan")
     baseline_uses_vegetarian = _plan_uses_value(baseline_output, "vegetarian")
+    reinjected_uses_vegan = _plan_uses_value(reinjected_output, "vegan")
+    reinjected_uses_vegetarian = _plan_uses_value(reinjected_output, "vegetarian")
     mediated_uses_vegan = _plan_uses_value(mediated_output, "vegan")
     mediated_uses_vegetarian = _plan_uses_value(mediated_output, "vegetarian")
     compact_uses_vegan = _plan_uses_value(compact_output, "vegan")
     compact_uses_vegetarian = _plan_uses_value(compact_output, "vegetarian")
     baseline_respects = not baseline_uses_vegetarian
+    reinjected_respects = not reinjected_uses_vegetarian
     mediated_respects = not mediated_uses_vegetarian
     compact_respects = compacted_prompt is None and not compact_uses_vegetarian
     print_host_check(
@@ -128,6 +143,15 @@ def main() -> None:
         ),
         context="baseline",
     )
+    print_host_check(
+        "PLAN_VALUES",
+        (
+            f"vegan={yes_no(reinjected_uses_vegan)}, "
+            f"vegetarian={yes_no(reinjected_uses_vegetarian)}, "
+            f"premise_tag={reinjected_premise or 'MISSING'}"
+        ),
+        context="reinjected-state",
+    )
     print_host_check(
         "PLAN_VALUES",
         (
@@ -149,6 +173,7 @@ def main() -> None:
     print_spec_report(
         test_name="03_explicit_premise_change — stale value removed",
         baseline_pass=baseline_respects,
+        reinjected_state_pass=reinjected_respects,
         compiler_pass=mediated_respects,
         compiler_compact_pass=compact_respects,
         expected="explicit premise change should remove the stale vegetarian value",
@@ -157,7 +182,7 @@ def main() -> None:
             "both compiler-mediated paths used vegan value"
             if mediated_respects and compact_respects and baseline_uses_vegetarian
             else (
-                "all three paths used vegan value"
+                "all four paths used vegan value"
                 if baseline_respects and mediated_respects and compact_respects
                 else (
                     "at least one compiler-mediated path included stale vegetarian value"