An SCR is not a CRD, not a capability, and not a source of new binding requirements. It is a companion reference. A constraint that governs a capability must also appear in that capability’s own CRD.
Why it exists
CRDs deliberately hold one capability’s purpose, boundaries, interaction contracts, rules, defaults, and realization information. Product sources also contain context that belongs to no single capability: why the system exists, constraints that span several capabilities, which clients expose what, and when work is intended to happen.
Without a dedicated reference, that context can be silently dropped, forced into one CRD where it does not belong, or left for a reader to reconstruct from many files.
When to create one
Create one Source Context Reference per substantial source—or closely related set of sources—that produces multiple capabilities. Skip it for a small or single-capability extraction when there is no genuine cross-cutting context to preserve.
What it records
| Section | Purpose |
|---|---|
| Source(s) | Title, location, version/date, stated audience, and stated purpose. |
| Product/system intent | Why the whole product or system exists; label it rationale/intent, not capability purpose. |
| Scope | Included and excluded release/version scope that informs the inventory’s boundaries. |
| Cross-cutting constraints | Constraints spanning multiple capabilities, their semantic class, and the capability IDs they affect. |
| Platform/client exposure | Which clients or platforms expose which capabilities. |
| Delivery/build sequencing | The source’s stated order or phases—explicitly non-normative to a capability. |
| Shared verification material | End-to-end tests, acceptance criteria, or success narratives that span several capabilities. |
| Unmapped or deferred material | Substantive source material that did not become a capability or shared context item. |
Keep authority in the right place
If a cross-cutting constraint is a rule/invariant or implementation requirement, verify that it is stated in every affected CRD. The SCR should name a gap rather than quietly letting a binding condition live only in the shared reference.
How it connects
Use the SCR alongside a Capability Inventory and its CRDs. The inventory answers what the system can meaningfully do; each CRD explains one ability; the SCR records the source-level context that should not disappear between them.