---
schema_version: 1
id: RAC-KV4134WW3ZT3
type: roadmap
tags: [standards, requirements, prompts, enforcement]
---
# v0.17.1 — Per-Type Standards Enforcement

## Status

Planned

## Context

Releases A–C made RAC validate a repository deterministically: the OKF-superset
core, an OKF conformance gate, severity overrides + SARIF, and the Layer-3
relationship graph (range, acyclicity, all-type status-consistency). What RAC
does *not* yet check is whether each artifact meets the external *per-type*
standards it claims to align to — the strongest of which back requirements.

This milestone encodes the **checkable** parts of those standards as
deterministic per-type checks (no LLM, no prose judgement): ISO/IEC/IEEE 29148
well-formedness and BCP-14 normative-keyword discipline for requirements, EARS
syntax as advisory warnings, a horizon/outcome/linkage check for roadmaps, and
MADR-4.0 field presence for decisions. Prompt↔dotprompt interop is recorded
separately (ADR-057) and delivered as a derived export, not a source change.

## Outcomes

- Requirement artifacts are linted against 29148 well-formedness and BCP-14
  keyword discipline (errors), and EARS pattern/cardinality/clause-order
  (warnings) — so legacy requirements are guided, not broken.
- Roadmap artifacts are checked for a horizon, an outcome/metric, and at least
  one link into the graph; decisions gain optional MADR-4.0 field recognition.
- Every check is deterministic and decidable by parsing — the no-AI-in-core
  invariant holds — and ships with golden + adversarial fixtures.

## Initiatives

### Initiative 1 — Requirements: 29148 + BCP-14 (errors)

Lint requirement lines for 29148 well-formedness (singular, verifiable,
unambiguous — the structurally checkable subset, extending the existing
ambiguous-verb heuristic) and BCP-14 keyword discipline: lowercase
`shall`/`must` inside a requirement body is flagged as ambiguous; only uppercase
`MUST`/`SHOULD`/`MAY` carry normative weight. Errors inside `requirement`
artifacts (ADR-056).

### Initiative 2 — Requirements: EARS (warnings)

Detect EARS patterns by keyword (`When`, `While`, `If … then`, `Where`,
ubiquitous), and check clause cardinality (0..* preconditions, 0..1 trigger,
exactly one system name, 1..* responses) and temporal clause order. Warnings,
since legacy requirements will not comply (ADR-056).

### Initiative 3 — Roadmaps and decisions

Roadmaps: check that each declares a horizon (now/next/later or a quarter), an
outcome/metric, and at least one relationship into the graph. Decisions: recognise
optional MADR-4.0 fields (decision drivers, considered options, confirmation,
consulted/informed) without requiring them — the Nygard floor and the status
lifecycle (ADR-051) already ship.

### Initiative 4 — Coverage and docs

Golden (compliant) and adversarial (failing) fixtures per check with precise,
standard-citing diagnostics; severities respected and overridable (ADR-053);
docs and CHANGELOG.

## Success Measures

- A requirement with a lowercase normative `shall` fails; one using uppercase
  `MUST` passes; a non-EARS requirement warns but does not fail.
- A roadmap with no horizon, no outcome, or no graph link is flagged.
- `rac validate rac/` stays green after the corpus is brought into line, and the
  new checks are deterministic across runs.

## Assumptions

- The external standards (29148, EARS, BCP-14, MADR) remain as cited; checks
  encode only their decidable parts.
- Severity defaults (errors vs warnings) are overridable per the v0.15.2 model.

## Risks

- Over-firing on legacy requirements. Mitigated: EARS is warning-level and the
  whole pass is downgradable via `.rac/config.yaml` (ADR-053), warnings-first.
- Standard drift. Mitigated: diagnostics cite the standard; checks are the
  decidable subset only.

## Related Decisions

- adr-056
- adr-057
- adr-049
- adr-053

## Related Requirements

- rac-cross-artifact-enforcement

## Related Designs

- per-type-standards-checks

## Related Roadmaps

- v0.14.0-enforcement-foundation
- v0.17.0-single-document-import-skill
