Two built-in attributes control how requirements behave in trace coverage and how deferred work is tracked.

Status lifecycle#

Every requirement has a status — either draft or approved (default when omitted). Only approved requirements count as upstream coverage providers.

## REQ-001: System boot
```attr
status: approved
trace: [STK-001]
```

A draft requirement can be referenced by a trace but does not satisfy a requires-trace-from: expectation. This lets you stage work-in-progress without breaking coverage checks.

Try it: in Step 2, the SYS-001 requirement shows:

⚠  SYS-001  no upstream trace: no approved requirement from "software" traces to this item (1 draft downstreams ignored)

The (1 draft downstreams ignored) message means SW-001 traces to SYS-001 but SW-001 is still draft — so the coverage chain is incomplete.

Disposition workflow#

When a requirement can’t be immediately implemented, use disposition + disposition-reason instead of leaving silent gaps:

Disposition	What it signals	Rationale needed?
`implemented`	Actively developed	No
`deferred`	Accepted, postponed	Yes
`rejected`	Not accepted	Yes

## STAKE-007
```attr
status: approved
disposition: deferred
disposition-reason: "Deferred to Phase 2 per steering committee 2025-03-14"
```
The system shall support over-the-air firmware updates for all ECUs.

Disposition is orthogonal to trace coverage. Use requires-trace-from: [] to explicitly state that no downstream coverage is expected.

Extending the status enum#

When draft/approved is too narrow, add custom values:

x-reqmd:
  additional-status-values: [review, in-progress]

Opting out of the lifecycle#

For legacy imports or generated specs:

x-reqmd:
  ignore-status: true

All requirements count as coverage providers; the status filter is hidden in HTML export.

What’s next#

Now export your spec tree — go to Step 3.