Patterns

This section collects three patterns that sit on top of the deadline example: evaluating many cases, running with no network, and collecting facts through questions. Each pattern reuses the application’s modules unchanged and adds a small, named procedure around them.

When to use which

• Batch when cases arrive together: a file of forms, a nightly queue, a backlog to clear. The loop keeps per-case errors apart so one bad form does not sink the rest.
• Offline when the machine that evaluates has no network, or when the run must show it used no network. The pattern splits install from run and shows how to confirm the split.
• Questionnaire when the user supplies facts step by step instead of all at once. The pattern maps fields to facts by hand and derives the follow-up questions from whyNot instead of guessing.

Pattern map

Pattern	It shows	Modules it reuses
Batch	evaluate many cases with an application loop	toCaseInput, buildCollect, buildTruth, evaluateCollect, evaluateTruth, toViewModel
Offline	install once, then run with no network	openModel with offline: true, the evaluate calls
Questionnaire	map form fields to facts and ask for what is missing	validateFormInput, toFacts, missingFacts, questions()

Each pattern page follows the same shape: when to use it, the procedure step by step, the exact functions and files involved, what to expect on the worked case, and the limits that bound it.

What each pattern assumes

The application under all three patterns is:

Output

docs/build/examples/deadline-app

All three patterns assume the running setup from the application section: the pinned packages (@arxo/law 0.3.3, @arxo/canon-bgb-fristen 0.1.5, arxo 0.2.0), the model de.bgb.fristen@0.1.0 opened with offline: true, the time zone Europe/Berlin, and the policy urn:de:corpus:clir:bgb-fristen#BGB_FRISTEN_TAG. The worked case stays the same throughout: event 2026-03-06, length 14 days, candidate 2026-03-20, legal time 2026-09-17.

The engine facts the patterns rely on are local execution (via is local), the collect value 2026-03-20 with COMPUTED, the truth status TRUE_ONLY on the candidate, NEITHER on a wrong date or a partial case, two whyNot blockers on the partial case, empty sources in this canon build, and the program, semantic, and result hashes with canonical document bytes on every answer.

Conventions the procedures share

• Fresh inputs per case: every case builds its own FormInput and case input through validateFormInput and toCaseInput. Cases never share mutable state.
• Named failures: a case that fails records its error next to its id; the run continues, and the report lists results and errors side by side.
• Same-SDK replay: any capture a pattern stores is replayed by the SDK that saved it.
• The worked case first: each pattern page shows the procedure on the running example before generalizing.

Shared limits

• One engine call answers one case: batching is an application loop, not an engine call.
• Local open and evaluate need no network after install; explain() needs an MCP host and therefore the network.
• Python has no questions, no unfold, and no focused_truth: the questionnaire pattern reads the TypeScript manifest on the Python path.
• Captures replay within the SDK that saved them; statuses and values match across SDKs, bytes do not.

What the patterns do not cover

The patterns add no new modules and change no contract: the adapter, the queries, the reader, and the capture format stay exactly as the architecture page describes them. Anything that changes those — a new canon, a new question, a new capture layout — belongs to the application section, not to a pattern.

How to read these pages

Read the application section first — the architecture page names every module the patterns reuse. Then read the pattern you need; the three are independent of each other. Fenced blocks carry the procedures and the transcripts; the prose says what each step establishes and where it can fail.

Next

• Batch: many cases, one loop