Requirement Traceability Scope for Bridge 0.3

Bridge 0.3 does not maintain a traceability matrix, completeness ledger, coverage artifact, omission record, or per-requirement verification state. Those former artifact workflows were removed. Requirement traceability remains project-owned documentation unless executable project policy requires evidence that checks it.

What Bridge supports

A project profile may register structured requirement sources:

requirement_sources:
- kind: acai-feature-yaml
  globs:
  - features/**/*.feature.yaml
  id_scheme: acid

For the supported ACID feature-YAML shape, Bridge can discover local source files and parse stable requirement identifiers, text, notes, deprecation data, and replacements. A matching requirement-source file is classified as a docs change. The profile summary also reports the number of configured requirement sources.

This ingestion is descriptive. It does not establish that a requirement is implemented, tested, linked to a subsystem, covered by evidence, or complete. Bridge's canonical JSON status does not expose a requirement-coverage result.

How to enforce a project trace rule

Keep the mapping and its rationale in the project's normal source or design documents. If the rule can be checked, register a non-mutating canonical command and require its evidence kind through verification-policy. Bridge then coordinates the command and tracks its fresh evidence-run receipt; the project command remains responsible for defining and checking trace semantics.

For example, a repository may register a docs-or-nl-spec or custom command that validates its own requirement-to-test index. A passed receipt proves only that the configured command passed for the receipt's fresh subject and selected candidate context. It does not create a general Bridge coverage claim.

Deliberate non-goals for 0.3

• no Bridge-authored trace, coverage, completeness, or omission artifacts;
• no inferred links from prose mentions or citations;
• no automatic subsystem ownership for requirement IDs;
• no mtime-based freshness or portable attestation layer; and
• no new trace-specific CLI surface.

Add more structure only when a real consumer needs a specific machine-readable contract that cannot be expressed by ordinary documentation plus a configured evidence command. Such a change should define the consumer, semantics, failure behavior, and compatibility cost before expanding Bridge's public surface.

See README, library API, and the 0.3 changelog for the current contract.