# 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.