# 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](/build/patterns/batch/) | evaluate many cases with an application loop | `toCaseInput`, `buildCollect`, `buildTruth`, `evaluateCollect`, `evaluateTruth`, `toViewModel` |
| [Offline](/build/patterns/offline/) | install once, then run with no network | `openModel` with `offline: true`, the evaluate calls |
| [Questionnaire](/build/patterns/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:

```text
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](/build/patterns/batch/)