ADR —
- Status: proposed | accepted | informational | superseded by ADR-XXXX | rejected
- Date: YYYY-MM-DD
- Spec target: XTL 0.x
- Affects: language.md | evaluation.md | new section | impl-only
Context
What problem motivates this decision? What constraint is currently under-specified, ambiguous, or in conflict?
Considered Options
Brief comparison of the realistic alternatives. List each, with the strongest argument for and against.
Decision
The chosen option, stated in normative language. Quote the exact spec text that should change, where possible.
Consequences
What does this commit the spec to? What follow-up work does it imply (impl changes, fixtures, deprecations)? What does it explicitly not commit to?
References
Links to related ADRs, issues, or external precedent.
Status values
- proposed — under discussion; impl MAY anticipate but spec is not yet binding.
- accepted — normative; impl and conformance corpus reflect it.
- process-normative — accepted, but binds only the ADR pipeline
and authoring discipline (not runtime impl). Future ADR authors
MUST honor it; impl authors need not. ADR-0043 and ADR-0048 take
this status. (Added 2026-05-18 to replace the earlier compound
accepted (informational + process-level normative)phrasing.) - informational — non-normative documentation, audit, or process. Does not bind impl behavior or future ADR authors.
- superseded by ADR-NNNN — replaced (in whole or part) by a later decision. Both ADRs remain in the corpus for traceability.
- rejected — considered and explicitly NOT adopted; kept for the historical record so the option does not get reproposed without new context.