notarius/docs/adr/0010-workload-oriented-llm-profile-defaults.md

ADR-0010: Use workload-oriented LLM profile defaults

Status: Accepted Date: 2026-08-03

Context

LLM-backed D&D operations share an execution-policy choice, but repeating a provider or model-named profile on every module binding ties pipeline structure to a deployment decision. Different environments may require different model, backend, timeout, or reasoning settings while retaining the same workload.

Notarius also needs a usable default for maintained D&D prompts without making an operator profile mandatory. That default must remain owned by the D&D family, while generic LLM infrastructure stays unaware of domain-specific policy.

Decision

Pipelines may name one workload-oriented default profile, inherited only by selected LLM-backed bindings and validators. Binding-level profile IDs remain intentional exceptions, and the run-wide CLI profile override has highest precedence.

The D&D family owns an embedded fallback profile named dnd-extraction. Operators may provide a complete profile with the same ID through a PromptKit filesystem source. PromptKit selects the higher-precedence matching definition; Notarius does not merge profile documents. Production, development, and local deployments can therefore use different execution policy behind one unchanged pipeline ID.

Alternatives considered

• Repeat a model-named profile on every binding. This makes routine deployment policy changes noisy and obscures the shared workload intent.
• Require every deployment to install a profile file. This adds configuration friction and leaves maintained D&D prompts without an application-owned fallback.
• Put D&D profile policy in generic LLM infrastructure. This breaks domain ownership and makes generic code depend on one workload.

Consequences

Pipeline configuration expresses workload intent rather than a specific provider or model. Operators can replace the complete execution policy without editing bindings, while binding-level and run-wide exceptions remain available. Profile changes affect resolved pipeline and checkpoint identity, so they may intentionally cause work to be recomputed. The D&D fallback becomes a maintained application execution-policy asset.