CRD

Working form

Capability Requirements Document (CRD) Template

The minimal human-readable form for a reusable CRD. Remove optional sections that add no contextual meaning; do not replace unknown information with invention.

View Markdown source ↗

Identity

NameStable concise capability name.
DefinitionWhat the ability is, without implementation detail.
Statusdraft · active · deprecated · unknown

Core meaning

Capability purposeThe general outcome this ability exists to enable.
Meaningful outcomeThe result that makes the ability complete.
Boundaries — includesWhat belongs inside the capability.
Boundaries — excludesWhat explicitly does not belong inside the capability.
Terms and conceptsShared definitions needed to understand the capability.
Tags (optional)Universal only — a dimension not already derivable from another field. Pick the tag whose dimension the statement is actually about, not the nearest-sounding one (see the Specification's disambiguation table — e.g. a notification side effect is notification-triggering, not network-touching). In a rendered projection this typically becomes a grouping/section key or plain text, not a badge — the badge convention is reserved for implementation tags below.

Interaction Contract MLEs

Add one or more contracts. Use an explicit unknown only when no contract can yet be established.

[Contract name]

ActorWho or what initiates the behaviour.
Command / intentThe requested action.
Current stateThe required starting state or context.
Policies / invariantsConditions governing validity.
TransitionThe state change, or an explicit no-change statement.
ResultThe direct outcome delivered to the actor or caller.
Events / effectsMaterial emitted events or side effects; use none known when appropriate.
UnknownsIntentionally unresolved contract details.

Rules and defaults

Rules / invariants

Binding statements, or an explicit statement that none are known.

Recommended defaults

Normal behaviour unless deliberately overridden, or an explicit statement that none are known.

Unknown / unresolved

Record deliberately unspecified, uncertain, or pending questions. Unknown is valid documentation; assumed detail is not.

Optional: operational realization

Realization name and statusSpecific implementation identity and availability.
Implementation/business rationaleWhy a particular organization chose this realization.
Owner / operating contextOptional operational ownership and context.
Operational constraintsRestrictions imposed by this realization, not the reusable capability.
ExposureUI · API · MCP · tool · event · workflow · internal.
Implementation tags (optional)Product-specific groupings meaningful only to this realization, e.g. impl:inbox — never the CRD's own universal tags. In a rendered projection, this is the only kind of tag shown as a visual badge.
Implementation referencesCode, data, configuration, or dependency references.
Verification and operationsTests, telemetry, audit trail, authority, grounding, and approval gates where relevant.
ProvenanceSources and evidence status for extracted material.

Draft 0.4 extensions

Decision precedenceRule / invariant → explicit implementation requirement → explicit owner or user choice → recommended default → agent judgment.
Execution modesoftware-primary | agent-primary-using-software | software-primary-calling-agents | unknown.
Shared reuseFor shared elements, record created-for capability and approved-reuse capability references when known.
Agentic mappingsMap skills and tools to the capability or interaction contracts they realize or support.
Audience projectionsLink business, UX, frontend, backend, API/MCP/tools, agent, or operations views that trace to this CRD.

Optional: Related MLEs by Dimension

Traceability only — omit any dimension with no genuine content; do not fill every dimension to appear complete.

DimensionRelationshipRelated MLENotes
[Business/Domain · UX/Experience · Communication · Interaction/Behaviour · Frontend/Interface · Backend/Execution · Data/Information · API/Interoperability · Agentic · Verification · Operations]defines · implements · supports · constrains · verifies · exposes · reused_by[reference]

Communication MLEs (if any)

Include only when this capability genuinely triggers a communication. Every Communication MLE requires representative example text: preserve authoritative wording when sourced; otherwise label the text illustrative so it is never mistaken for shipped or binding copy.

PurposeWhat understanding or commitment this communication establishes.
TriggerThe event or state that causes it.
AudienceWho receives it.
Required meaningThe meaning that must survive regardless of channel or language — not the wording.
Terminology, tone/style, rules, recommended default (optional)Same semantic classes as §6 — an example wording is example; a promise is a rule/invariant only if the realization actually guarantees it.
Possible realizationsInline UI, toast, email, push, SMS, agent response, etc.
Representative example textRequired. Semantic class: example. Use sourced wording where available; otherwise explicitly label illustrative wording, never binding copy.

Statement provenance

For extracted or generated material, label statements so readers can distinguish facts, inferences, defaults, and uncertainty.

StatementSemantic classEvidence statusSource / note
[statement]explicit factsourced[source]