context-compiler 0.9.0.dev12__tar.gz → 0.9.0.dev13__tar.gz

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: context-compiler
-Version: 0.9.0.dev12
+Version: 0.9.0.dev13
 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
@@ -27,9 +27,8 @@ Description-Content-Type: text/markdown
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
 Context Compiler is a deterministic conversational state authority for LLM applications.
-It handles canonical directive execution, semantic validation, deterministic
-error decisions, runtime semantic continuation boundaries, and structured authoritative state for
-the host.
+It handles canonical directive execution, semantic validation, terminal error
+decisions, advisory repairs, and structured authoritative state for the host.
 
 ## What Context Compiler provides
 
@@ -37,7 +36,7 @@ Context Compiler gives hosts fixed state rules:
 
 - handle canonical explicit state changes with deterministic rules
 - error instead of silent overwrite for blocked/ambiguous changes
-- preserve supported pending continuation when explicit confirmation is required
+- return structured terminal errors with explicitly selectable advisory repairs
 - export and import authoritative state for host-managed persistence
 - produce structured authoritative state for downstream host decisions
 
@@ -84,8 +83,8 @@ The architecture has three layers:
   directive-shaped syntax, or ordinary no_directive
 - semantic evaluation decides whether a canonical directive updates state,
   clarifies, or no-ops
-- semantic continuation optionally preserves a deterministic blocked transition
-  that needs explicit `yes` / `no`
+- semantic evaluation returns an update or a terminal error with structured
+  advisory repairs when a canonical directive conflicts with state
 
 ### Explicit directive
 
@@ -103,7 +102,7 @@ use docker and prohibit peanuts
 ```
 
 - Without an authority layer: host/model behavior varies
-- Context Compiler: treats this as invalid directive-shaped syntax, keeps authoritative state unchanged, and does not create pending continuation
+- Context Compiler: treats this as invalid directive-shaped syntax and keeps authoritative state unchanged
 
 ### State-dependent operation
 
@@ -159,8 +158,9 @@ Use Context Compiler in your host application first:
 ```python
 from context_compiler import (
     Engine,
-    is_error,
-    is_update,
+    NoDirectiveDecision,
+    SemanticErrorDecision,
+    UpdateDecision,
 )
 
 engine = Engine()
@@ -168,16 +168,16 @@ engine = Engine()
 user_input = "set premise current project uses uv"
 decision = engine.step(user_input)
 
-if is_error(decision):
-    show_to_user(decision["message"])
-elif is_update(decision):
+if isinstance(decision, SemanticErrorDecision):
+    show_to_user(decision.message)
+elif isinstance(decision, UpdateDecision):
     messages = build_messages(
         premise=engine.premise,
         policies=engine.policies,
         user_input=user_input,
     )
     render(call_llm(messages))
-else:
+elif isinstance(decision, NoDirectiveDecision):
     render(call_llm(user_input))
 ```
 
@@ -188,7 +188,7 @@ For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 That companion repository shows enforcement points built on compiler state,
 including retrieval filtering, schema selection, tool gating, execution
-authorization, gateway middleware, runtime continuation handling, and prompt
+authorization, gateway middleware, runtime state handling, and prompt
 construction.
 
 ## Does it Work?
@@ -235,6 +235,12 @@ for non-interactive usage.
 context-compiler --json < input.txt
 ```
 
+The JSON output uses `output_version: 2`. Decision payloads expose structured
+fields: updates include `changed`; semantic errors include `failure`, the
+failed canonical `directive`, ordered advisory `repairs`, and `message`.
+These fields are a CLI projection of ephemeral Decisions, not Decision object
+serialization. Repairs are never applied automatically.
+
 Preload options load authoritative state:
 
 - `--initial-state-json` / `--initial-state-file` load saved state
@@ -268,7 +274,9 @@ uv run pytest
 
 ## Decision API
 
-Each user message produces a `Decision`.
+Each user message produces one immutable `Decision` variant. Use concrete
+variants with `isinstance` or pattern matching; use `kind` when generic code
+needs the stable discriminator.
 
 ```python
 class DecisionKind(StrEnum):
@@ -276,26 +284,72 @@ class DecisionKind(StrEnum):
     UPDATE = "update"
     ERROR = "error"
 
-class Decision(TypedDict):
-    kind: DecisionKind
-    message: str | None
+Decision = NoDirectiveDecision | UpdateDecision | SemanticErrorDecision
+
+@dataclass(frozen=True, slots=True)
+class NoDirectiveDecision:
+    kind = DecisionKind.NO_DIRECTIVE
+
+@dataclass(frozen=True, slots=True)
+class UpdateDecision:
+    kind = DecisionKind.UPDATE
+    changed: bool
+
+@dataclass(frozen=True, slots=True)
+class SemanticErrorDecision:
+    kind = DecisionKind.ERROR
+    failure: SemanticFailure
+    directive: CanonicalDirective
+    repairs: tuple[CanonicalDirective, ...]
+    message: str
 ```
 
-`message` is structurally present on every `Decision`, but it is semantically
-meaningful only for `error`. For `no_directive` and `update`, `message` is
-`None`.
+`UpdateDecision.changed` reports whether authoritative state actually changed.
+An accepted idempotent directive is still an `update` with
+`changed=False`.
+
+`SemanticErrorDecision.message` is derived human-readable text. Callers should
+use `failure` for machine decisions rather than parsing the message.
+
+`directive` is the canonical directive that failed semantic evaluation.
+`repairs` is an ordered tuple of advisory canonical directives. Repairs are
+never applied automatically; a host must explicitly submit a selected repair
+through `engine.apply_directive(...)`.
+
+The normative repair mapping is:
+
+| Failure | Ordered advisory repairs |
+| --- | --- |
+| `PREMISE_ALREADY_SET` | `change premise to <requested value>` |
+| `PREMISE_NOT_SET` | `set premise <requested value>` |
+| `ITEM_PROHIBITED` | `remove policy <item>`; `use <item>` |
+| `ITEM_ALREADY_IN_USE` | `remove policy <item>`; `prohibit <item>` |
+| `REPLACEMENT_TARGET_PROHIBITED` | `remove policy <target>`; retry the original replacement directive |
+| `REPLACEMENT_SOURCE_PROHIBITED` | no repair (`()`) |
+| `REPLACEMENT_SOURCE_MISSING` | no repair (`()`) |
+
+Repairs are canonical, ordered, and advisory only. The engine never applies
+them automatically; hosts explicitly select and submit any repair they want to
+use. `message` is presentation data, so control flow must use `failure` and
+the structured directives rather than parse message text.
 
 Meaning:
 
 | kind | host behavior |
 | --- | --- |
 | no_directive | no canonical directive recognized; no authoritative state change; host decides what to do next |
-| update | authoritative state mutated; host may use updated state downstream |
-| error | show `message` and do not continue normal downstream processing yet |
+| update | canonical directive was accepted; inspect `changed` and use updated state downstream |
+| error | canonical directive was rejected semantically; inspect `failure`, show `message`, and optionally offer `repairs` |
+
+`engine.step(...)` is the raw input boundary: it parses user input, may return
+`NoDirectiveDecision` when no canonical directive is produced, and performs
+semantic evaluation only after canonical parsing succeeds. The canonical
+execution boundary is `engine.apply_directive(...)`, which accepts only a
+`CanonicalDirective` and returns only `UpdateDecision` or
+`SemanticErrorDecision`.
 
-For normal app code, prefer the exported decision helpers (`is_error`,
-`is_update`, `is_no_directive`, `get_error_message`)
-instead of direct key traversal.
+Grammar failures do not produce semantic errors. A semantic error is possible
+only after a canonical directive has parsed successfully.
 
 See [docs/api-reference.md](docs/api-reference.md) for the full public API
 reference.
@@ -305,8 +359,8 @@ Common API entry points:
 - engine lifecycle: `Engine()`, `engine.step(...)`,
   `engine.premise`, `engine.policies`, `engine.export_json(...)`,
   `engine.import_json(...)`
-- decision helpers: `is_error(...)`, `is_update(...)`, `is_no_directive(...)`,
-  `get_error_message(...)`
+- decision variants: `NoDirectiveDecision`, `UpdateDecision`,
+  `SemanticErrorDecision`, `SemanticFailure`
 - state transport: `engine.export_json(...)`, `engine.import_json(...)`
 
 ---
@@ -387,8 +441,8 @@ the compiler.
 
 - They transport **authoritative state only**
 - Hosts own any broader interaction or session workflow around that state
-- Pending continuation, if supported by the active engine contract, remains a
-  runtime semantic concept rather than a documented persisted artifact
+- Decision objects and advisory repairs are not persisted; persistence carries
+  authoritative state only
 
 ---
 
@@ -431,11 +485,14 @@ Directive-shaped invalid input is outside the canonical language, and
 `error` is reserved for canonical directives that later fail semantic
 evaluation against authoritative state.
 
-Pending continuation is a separate runtime layer. It may exist only after a
-canonical directive reaches a supported semantic `error` case. It never
-repairs malformed syntax or reinterprets non-canonical input as a directive.
-An absent source item in a canonical replacement directive is itself a
-semantic `error` case and does not authorize degradation to plain `use`.
+A semantic error is a terminal result for the current input. It leaves
+authoritative state unchanged and returns the failure classification, failed
+canonical directive, ordered advisory repairs, and presentation message.
+Repairs are canonical directives. They are advisory only, are never applied
+automatically, and require explicit host selection and submission through
+`engine.apply_directive(...)`. An absent source item in a canonical replacement
+directive is a semantic `error` and does not authorize degradation to plain
+`use`.
 
 Examples:
 
@@ -483,8 +540,8 @@ boundary, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
 **Isn't this just prompt reinjection?**
 No. Prompt construction is one downstream use of authoritative state.
 Context Compiler is the authority layer that decides when state changes are
-allowed, when error is required, and how continuation state is
-restored. For runnable application-layer examples, see
+allowed, when a terminal error is required, and which advisory repairs are
+available. For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 
 Human-facing interpretation is a separate concern. If you want to recognize
@@ -505,8 +562,8 @@ User: prohibit python_script
 ```
 
 Without an authority layer, the application must invent conflict-resolution and
-continuation rules itself. Context Compiler applies deterministic
-state-transition rules and can return error instead of silently
+repair rules itself. Context Compiler applies deterministic state-transition
+rules and can return a terminal error instead of silently
 overwriting state.
 
 ---
@@ -515,11 +572,11 @@ overwriting state.
 
 ### Guarantees
 
-- State changes only through explicit user directives or confirmation.
+- State changes only through canonical directives that pass semantic evaluation.
 - Identical input sequences produce identical compiler state.
 - Model responses never modify compiler state.
 - Ambiguous directives trigger error instead of changing state.
-- Syntax errors never create pending continuation.
+- Syntax errors never produce semantic errors or state changes.
 
 Behavioral tests and Hypothesis-based property tests verify these invariants.
 

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/README.md

@@ -5,9 +5,8 @@
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
 Context Compiler is a deterministic conversational state authority for LLM applications.
-It handles canonical directive execution, semantic validation, deterministic
-error decisions, runtime semantic continuation boundaries, and structured authoritative state for
-the host.
+It handles canonical directive execution, semantic validation, terminal error
+decisions, advisory repairs, and structured authoritative state for the host.
 
 ## What Context Compiler provides
 
@@ -15,7 +14,7 @@ Context Compiler gives hosts fixed state rules:
 
 - handle canonical explicit state changes with deterministic rules
 - error instead of silent overwrite for blocked/ambiguous changes
-- preserve supported pending continuation when explicit confirmation is required
+- return structured terminal errors with explicitly selectable advisory repairs
 - export and import authoritative state for host-managed persistence
 - produce structured authoritative state for downstream host decisions
 
@@ -62,8 +61,8 @@ The architecture has three layers:
   directive-shaped syntax, or ordinary no_directive
 - semantic evaluation decides whether a canonical directive updates state,
   clarifies, or no-ops
-- semantic continuation optionally preserves a deterministic blocked transition
-  that needs explicit `yes` / `no`
+- semantic evaluation returns an update or a terminal error with structured
+  advisory repairs when a canonical directive conflicts with state
 
 ### Explicit directive
 
@@ -81,7 +80,7 @@ use docker and prohibit peanuts
 ```
 
 - Without an authority layer: host/model behavior varies
-- Context Compiler: treats this as invalid directive-shaped syntax, keeps authoritative state unchanged, and does not create pending continuation
+- Context Compiler: treats this as invalid directive-shaped syntax and keeps authoritative state unchanged
 
 ### State-dependent operation
 
@@ -137,8 +136,9 @@ Use Context Compiler in your host application first:
 ```python
 from context_compiler import (
     Engine,
-    is_error,
-    is_update,
+    NoDirectiveDecision,
+    SemanticErrorDecision,
+    UpdateDecision,
 )
 
 engine = Engine()
@@ -146,16 +146,16 @@ engine = Engine()
 user_input = "set premise current project uses uv"
 decision = engine.step(user_input)
 
-if is_error(decision):
-    show_to_user(decision["message"])
-elif is_update(decision):
+if isinstance(decision, SemanticErrorDecision):
+    show_to_user(decision.message)
+elif isinstance(decision, UpdateDecision):
     messages = build_messages(
         premise=engine.premise,
         policies=engine.policies,
         user_input=user_input,
     )
     render(call_llm(messages))
-else:
+elif isinstance(decision, NoDirectiveDecision):
     render(call_llm(user_input))
 ```
 
@@ -166,7 +166,7 @@ For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 That companion repository shows enforcement points built on compiler state,
 including retrieval filtering, schema selection, tool gating, execution
-authorization, gateway middleware, runtime continuation handling, and prompt
+authorization, gateway middleware, runtime state handling, and prompt
 construction.
 
 ## Does it Work?
@@ -213,6 +213,12 @@ for non-interactive usage.
 context-compiler --json < input.txt
 ```
 
+The JSON output uses `output_version: 2`. Decision payloads expose structured
+fields: updates include `changed`; semantic errors include `failure`, the
+failed canonical `directive`, ordered advisory `repairs`, and `message`.
+These fields are a CLI projection of ephemeral Decisions, not Decision object
+serialization. Repairs are never applied automatically.
+
 Preload options load authoritative state:
 
 - `--initial-state-json` / `--initial-state-file` load saved state
@@ -246,7 +252,9 @@ uv run pytest
 
 ## Decision API
 
-Each user message produces a `Decision`.
+Each user message produces one immutable `Decision` variant. Use concrete
+variants with `isinstance` or pattern matching; use `kind` when generic code
+needs the stable discriminator.
 
 ```python
 class DecisionKind(StrEnum):
@@ -254,26 +262,72 @@ class DecisionKind(StrEnum):
     UPDATE = "update"
     ERROR = "error"
 
-class Decision(TypedDict):
-    kind: DecisionKind
-    message: str | None
+Decision = NoDirectiveDecision | UpdateDecision | SemanticErrorDecision
+
+@dataclass(frozen=True, slots=True)
+class NoDirectiveDecision:
+    kind = DecisionKind.NO_DIRECTIVE
+
+@dataclass(frozen=True, slots=True)
+class UpdateDecision:
+    kind = DecisionKind.UPDATE
+    changed: bool
+
+@dataclass(frozen=True, slots=True)
+class SemanticErrorDecision:
+    kind = DecisionKind.ERROR
+    failure: SemanticFailure
+    directive: CanonicalDirective
+    repairs: tuple[CanonicalDirective, ...]
+    message: str
 ```
 
-`message` is structurally present on every `Decision`, but it is semantically
-meaningful only for `error`. For `no_directive` and `update`, `message` is
-`None`.
+`UpdateDecision.changed` reports whether authoritative state actually changed.
+An accepted idempotent directive is still an `update` with
+`changed=False`.
+
+`SemanticErrorDecision.message` is derived human-readable text. Callers should
+use `failure` for machine decisions rather than parsing the message.
+
+`directive` is the canonical directive that failed semantic evaluation.
+`repairs` is an ordered tuple of advisory canonical directives. Repairs are
+never applied automatically; a host must explicitly submit a selected repair
+through `engine.apply_directive(...)`.
+
+The normative repair mapping is:
+
+| Failure | Ordered advisory repairs |
+| --- | --- |
+| `PREMISE_ALREADY_SET` | `change premise to <requested value>` |
+| `PREMISE_NOT_SET` | `set premise <requested value>` |
+| `ITEM_PROHIBITED` | `remove policy <item>`; `use <item>` |
+| `ITEM_ALREADY_IN_USE` | `remove policy <item>`; `prohibit <item>` |
+| `REPLACEMENT_TARGET_PROHIBITED` | `remove policy <target>`; retry the original replacement directive |
+| `REPLACEMENT_SOURCE_PROHIBITED` | no repair (`()`) |
+| `REPLACEMENT_SOURCE_MISSING` | no repair (`()`) |
+
+Repairs are canonical, ordered, and advisory only. The engine never applies
+them automatically; hosts explicitly select and submit any repair they want to
+use. `message` is presentation data, so control flow must use `failure` and
+the structured directives rather than parse message text.
 
 Meaning:
 
 | kind | host behavior |
 | --- | --- |
 | no_directive | no canonical directive recognized; no authoritative state change; host decides what to do next |
-| update | authoritative state mutated; host may use updated state downstream |
-| error | show `message` and do not continue normal downstream processing yet |
+| update | canonical directive was accepted; inspect `changed` and use updated state downstream |
+| error | canonical directive was rejected semantically; inspect `failure`, show `message`, and optionally offer `repairs` |
+
+`engine.step(...)` is the raw input boundary: it parses user input, may return
+`NoDirectiveDecision` when no canonical directive is produced, and performs
+semantic evaluation only after canonical parsing succeeds. The canonical
+execution boundary is `engine.apply_directive(...)`, which accepts only a
+`CanonicalDirective` and returns only `UpdateDecision` or
+`SemanticErrorDecision`.
 
-For normal app code, prefer the exported decision helpers (`is_error`,
-`is_update`, `is_no_directive`, `get_error_message`)
-instead of direct key traversal.
+Grammar failures do not produce semantic errors. A semantic error is possible
+only after a canonical directive has parsed successfully.
 
 See [docs/api-reference.md](docs/api-reference.md) for the full public API
 reference.
@@ -283,8 +337,8 @@ Common API entry points:
 - engine lifecycle: `Engine()`, `engine.step(...)`,
   `engine.premise`, `engine.policies`, `engine.export_json(...)`,
   `engine.import_json(...)`
-- decision helpers: `is_error(...)`, `is_update(...)`, `is_no_directive(...)`,
-  `get_error_message(...)`
+- decision variants: `NoDirectiveDecision`, `UpdateDecision`,
+  `SemanticErrorDecision`, `SemanticFailure`
 - state transport: `engine.export_json(...)`, `engine.import_json(...)`
 
 ---
@@ -365,8 +419,8 @@ the compiler.
 
 - They transport **authoritative state only**
 - Hosts own any broader interaction or session workflow around that state
-- Pending continuation, if supported by the active engine contract, remains a
-  runtime semantic concept rather than a documented persisted artifact
+- Decision objects and advisory repairs are not persisted; persistence carries
+  authoritative state only
 
 ---
 
@@ -409,11 +463,14 @@ Directive-shaped invalid input is outside the canonical language, and
 `error` is reserved for canonical directives that later fail semantic
 evaluation against authoritative state.
 
-Pending continuation is a separate runtime layer. It may exist only after a
-canonical directive reaches a supported semantic `error` case. It never
-repairs malformed syntax or reinterprets non-canonical input as a directive.
-An absent source item in a canonical replacement directive is itself a
-semantic `error` case and does not authorize degradation to plain `use`.
+A semantic error is a terminal result for the current input. It leaves
+authoritative state unchanged and returns the failure classification, failed
+canonical directive, ordered advisory repairs, and presentation message.
+Repairs are canonical directives. They are advisory only, are never applied
+automatically, and require explicit host selection and submission through
+`engine.apply_directive(...)`. An absent source item in a canonical replacement
+directive is a semantic `error` and does not authorize degradation to plain
+`use`.
 
 Examples:
 
@@ -461,8 +518,8 @@ boundary, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
 **Isn't this just prompt reinjection?**
 No. Prompt construction is one downstream use of authoritative state.
 Context Compiler is the authority layer that decides when state changes are
-allowed, when error is required, and how continuation state is
-restored. For runnable application-layer examples, see
+allowed, when a terminal error is required, and which advisory repairs are
+available. For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 
 Human-facing interpretation is a separate concern. If you want to recognize
@@ -483,8 +540,8 @@ User: prohibit python_script
 ```
 
 Without an authority layer, the application must invent conflict-resolution and
-continuation rules itself. Context Compiler applies deterministic
-state-transition rules and can return error instead of silently
+repair rules itself. Context Compiler applies deterministic state-transition
+rules and can return a terminal error instead of silently
 overwriting state.
 
 ---
@@ -493,11 +550,11 @@ overwriting state.
 
 ### Guarantees
 
-- State changes only through explicit user directives or confirmation.
+- State changes only through canonical directives that pass semantic evaluation.
 - Identical input sequences produce identical compiler state.
 - Model responses never modify compiler state.
 - Ambiguous directives trigger error instead of changing state.
-- Syntax errors never create pending continuation.
+- Syntax errors never produce semantic errors or state changes.
 
 Behavioral tests and Hypothesis-based property tests verify these invariants.
 

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/demos/01_llm_contradiction_error.py

@@ -2,7 +2,7 @@
 
 from context_compiler import (
     Engine,
-    is_error,
+    SemanticErrorDecision,
 )
 from demos.common import (
     build_baseline_messages,
@@ -69,9 +69,9 @@ def main() -> None:
     reinjected_output = complete_messages(reinjected_messages)
     print_model_output("Reinjected-state", reinjected_output)
 
-    if is_error(second):
+    if isinstance(second, SemanticErrorDecision):
         print_messages("compiler-mediated (full)", [])
-        mediated_output = f"[no call] error required: {second['message']}\nACTION:error"
+        mediated_output = f"[no call] error required: {second.message}\nACTION:error"
         print_model_output("Compiler-mediated (full)", mediated_output)
     else:
         premise, policies = observe_engine(engine)
@@ -106,7 +106,7 @@ def main() -> None:
     compact_action = extract_tag_value(compact_output, "ACTION")
     baseline_respects = baseline_action is not None and baseline_action.lower() == "error"
     reinjected_respects = reinjected_action is not None and reinjected_action.lower() == "error"
-    compiler_host_blocked = is_error(second)
+    compiler_host_blocked = isinstance(second, SemanticErrorDecision)
     mediated_respects = compiler_host_blocked
     compact_respects = compacted_prompt is not None or (
         compact_action is not None and compact_action.lower() == "error"

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/demos/06_llm_context_compaction.py

@@ -1,8 +1,8 @@
 """Demo 6: host-side prompt replacement from authoritative step-derived state."""
 
 from context_compiler import (
-    DECISION_UPDATE,
     Engine,
+    UpdateDecision,
 )
 from demos.common import compact_user_turns, is_verbose, print_info_report, state_observations
 
@@ -46,7 +46,7 @@ def _compile_premise(turns: list[str]) -> str:
     engine = Engine()
     for turn in turns:
         decision = engine.step(turn)
-        assert decision["kind"] == DECISION_UPDATE
+        assert isinstance(decision, UpdateDecision)
     compiled_premise = engine.premise
     assert compiled_premise is not None
     return compiled_premise

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/demos/08_llm_replacement_precondition.py

@@ -4,7 +4,7 @@ from collections.abc import Mapping
 
 from context_compiler import (
     Engine,
-    is_error,
+    SemanticErrorDecision,
 )
 from demos.common import (
     build_baseline_messages,
@@ -69,7 +69,7 @@ def main() -> None:
     reinjected_output = complete_messages(reinjected_messages)
     print_model_output("Reinjected-state", reinjected_output)
 
-    if is_error(decision):
+    if isinstance(decision, SemanticErrorDecision):
         print_messages("compiler-mediated (full)", [])
         mediated_output = "[no call] authoritative state blocked replacement without source use"
         print_model_output("Compiler-mediated (full)", mediated_output)
@@ -99,7 +99,7 @@ def main() -> None:
 
     baseline_has_authoritative_precondition = False
     reinjected_has_authoritative_precondition = False
-    compiler_pass = is_error(decision) and state_preserved
+    compiler_pass = isinstance(decision, SemanticErrorDecision) and state_preserved
     compact_pass = compact_error_preserved and compact_state_preserved
 
     print_host_check(
@@ -114,7 +114,7 @@ def main() -> None:
     )
     print_host_check(
         "COMPILER_BLOCKED_INVALID_REPLACEMENT",
-        yes_no(is_error(decision)),
+        yes_no(isinstance(decision, SemanticErrorDecision)),
         context="compiler-mediated",
     )
     print_host_check(

{context_compiler-0.9.0.dev12 → context_compiler-0.9.0.dev13}/demos/README.md

@@ -35,8 +35,7 @@ Runnable application-layer enforcement-point integrations live in
 | [05](./05_llm_prompt_drift_vs_state.py) | Prompt drift | long transcript failure | weaker long-context models ([see Demo 05 example](#demo-05-example-prompt-drift-under-longer-context)) |
 | [06](./06_llm_context_compaction.py) | Context compaction | saved compiler state replacing transcript context | small or local models |
 | [07](./07_llm_prompt_vs_state.py) | Prompt engineering comparison | prompting vs saved compiler state | any model with long transcript sensitivity |
-| [08](./08_llm_replacement_precondition.py) | Replacement precondition | missing-source replacement applies deterministically from authoritative state | any model |
-| [09](./09_llm_confirmation_no_directive.py) | Confirmation no_directive | invalid replacement does not create an engine-owned confirmation state; later confirmation-style input remains ordinary no_directive | any model |
+| [08](./08_llm_replacement_precondition.py) | Replacement precondition | missing-source replacement is terminal; state remains unchanged | any model |
 
 Stronger frontier models may show these behaviors less often, but the same
 patterns still appear in real applications.
@@ -167,18 +166,18 @@ includes:
 
 Notes:
 
-- There are **8 scored demos** (`01`–`05`, `07`, `08`, `09`). `06_context_compaction` is informational and excluded from PASS/FAIL totals.
+- There are **7 scored demos** (`01`–`05`, `07`, `08`). `06_context_compaction` is informational and excluded from PASS/FAIL totals.
 - Anthropic runs in this repo are executed through the `openai_compatible` provider path.
 - `PASS` means the demo-specific expected-behavior check for that path succeeded; `FAIL` means it did not.
 - `reinjected-state` can be enough for some persistence cases; in this demo set it is intentionally used as a prompt-only comparison baseline.
-- Scored checks focus on app-side authority rules (for example blocked mutation and non-pending invalid replacement handling), not model prose quality. `reinjected-state` remains plain text injection only.
+- Scored checks focus on app-side authority rules (for example blocked mutation and terminal invalid replacement handling), not model prose quality. `reinjected-state` remains plain text injection only.
 - Interpretation:
 
 - Demos `01`-`05` and `07` mostly test persistence and policy-following behavior across turns.
-- Demos `08`/`09` test rules for when state is allowed to change.
-- Demos `08` and `09` cover authority semantics prompt text does not implement by itself, such as replacement preconditions, blocked mutations, and waiting for confirmation before saving changes.
+- Demo `08` tests rules for when state is allowed to change.
+- Demo `08` covers authority semantics prompt text does not implement by itself, such as replacement preconditions, blocked mutations, and terminal semantic errors before saving changes.
 - Plain prompt reinjection can produce reasonable answers, but it does not run these authority checks by itself and is not the only or preferred production integration pattern.
-- Similar outcomes across models in `08`/`09` reflect app behavior limits, not model leaderboard ranking.
+- Similar outcomes across models in `08` reflect app behavior limits, not model leaderboard ranking.
 
 ### Demo 05 example (prompt drift under longer context)