Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions python/examples/schema_selection/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,14 +8,20 @@ They demonstrate observable runtime behavior changes rather than model complianc

### `refund_intake`

Routes requests to a refund workflow when state contains:
Shows two generic schema-selection mechanisms in the same customer
order/support intake domain.

Policy-driven selection can route requests when state contains:

```text
use refund_intake
```

The test verifies that the refund handler runs and the technical-support
handler does not.
Premise-driven selection can also change schema choice for the same ambiguous
request when saved factual order context changes.

This example keeps premise factual. It does not treat premise as a disguised
workflow command.

### `ollama_structured_output`

Expand Down
71 changes: 58 additions & 13 deletions python/examples/schema_selection/refund_intake/README.md
Original file line number Diff line number Diff line change
@@ -1,50 +1,95 @@
# Refund intake

This example routes a request to the refund workflow.
This example shows two host-side schema-selection mechanisms in the same
customer order/support intake domain.

The host reads Context Compiler authoritative state and chooses the workflow.

In this example, the host routes the request to the refund workflow because the
authoritative state contains:
The enforcement point stays the same:

```text
use refund_intake
```

The technical-support workflow is available, but it is not used.
- same user request
- different authoritative state
- different host-selected schema

Context Compiler does not choose the workflow by prompt wording. The host reads
the saved authoritative state and selects the workflow/schema from that state.
For premise-driven selection, the host applies a small deterministic
order-intake rule:

`saved order facts -> intake category -> selected schema`

In this example, the host checks for a few explicit order facts in the saved
premise, such as `delivered physical item` plus `damaged on arrival`, or
`digital subscription` plus `login failure`.

## Enforcement point

Schema selection

## State mechanism
## State mechanisms

`use`
- policy-driven schema selection via `use ...`
- premise-driven schema selection via factual order context

## What changes

Without matching state, no workflow is selected.
Without matching authoritative state, no workflow is selected.

With:
With policy state:

```text
use refund_intake
```

the refund workflow runs.

With a factual premise:

```text
set premise order A-100 is a delivered physical item reported as damaged on arrival
```

the same ambiguous user request, `I need help with order A-100.`, selects the
`refund_intake` schema.

In the host rule layer, that saved premise maps to the
`damaged_physical_delivery` intake category, which then maps to
`refund_intake`.

With a different factual premise:

```text
set premise order A-100 is a digital subscription with an active login failure after purchase
```

the same ambiguous user request selects the `technical_support` schema.

In the host rule layer, that saved premise maps to the
`digital_subscription_login_failure` intake category, which then maps to
`technical_support`.

The premise is factual context about the order. It is not a workflow command
and it is not rewritten as `use refund_intake` or `use technical_support`.
This mapping is host-owned business logic, not model inference.

## Proof

The test verifies:
The tests verify:

```python
assert refund_handler.called is True
assert technical_support_handler.called is False
```

They also verify:

- `use refund_intake` selects `refund_intake`
- `use technical_support` selects `technical_support`
- saved premise facts map to a named intake category before schema selection
- the same request plus different saved premise selects different schemas
- unrelated premise selects no schema
- adversarial user text does not override saved policy or saved premise

## Test

```shell
Expand Down
65 changes: 63 additions & 2 deletions python/examples/schema_selection/refund_intake/example.py
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,20 @@
from dataclasses import dataclass
from typing import Literal, TypedDict

from context_compiler import POLICY_USE, State, create_engine, get_policy_items
from context_compiler import (
POLICY_USE,
State,
create_engine,
get_policy_items,
get_premise_value,
)

DAMAGED_ORDER_PREMISE = (
"order A-100 is a delivered physical item reported as damaged on arrival"
)
DIGITAL_LOGIN_FAILURE_PREMISE = (
"order A-100 is a digital subscription with an active login failure after purchase"
)


class IntakeRequest(TypedDict):
Expand All @@ -23,13 +36,24 @@ class TechnicalSupportResult(TypedDict):
issue: str


OrderIntakeContext = Literal[
"damaged_physical_delivery", "digital_subscription_login_failure"
]


class IntakeRunResult(TypedDict):
selected_schema: str | None
refund_handler_called: bool
technical_support_handler_called: bool
result: RefundIntakeResult | TechnicalSupportResult | None


_SCHEMA_BY_ORDER_INTAKE_CONTEXT: dict[OrderIntakeContext, str] = {
"damaged_physical_delivery": "refund_intake",
"digital_subscription_login_failure": "technical_support",
}


@dataclass
class IntakeHandler:
name: str
Expand Down Expand Up @@ -57,18 +81,55 @@ def handle(
raise ValueError(f"unknown handler: {self.name}")


def classify_premise_as_order_intake_context(
premise: str | None,
) -> OrderIntakeContext | None:
"""Map saved order facts to a host-owned intake context."""

if premise is None:
return None

normalized_premise = premise.casefold()
if (
"delivered physical item" in normalized_premise
and "damaged on arrival" in normalized_premise
):
return "damaged_physical_delivery"

if (
"digital subscription" in normalized_premise
and "login failure" in normalized_premise
):
return "digital_subscription_login_failure"

return None


def select_schema_from_order_intake_context(
context: OrderIntakeContext | None,
) -> str | None:
"""Map a host-owned intake context to the selected schema."""

if context is None:
return None

return _SCHEMA_BY_ORDER_INTAKE_CONTEXT[context]


def select_schema_from_state(state: State) -> str | None:
"""Select a host-side workflow from authoritative state."""

use_items = set(get_policy_items(state, POLICY_USE))
premise = get_premise_value(state)

if "refund_intake" in use_items:
return "refund_intake"

if "technical_support" in use_items:
return "technical_support"

return None
intake_context = classify_premise_as_order_intake_context(premise)
return select_schema_from_order_intake_context(intake_context)


def run_intake(
Expand Down
Loading