Purpose
An inventory makes reusable and planned capabilities visible across products, services, agents, and applications. A CRD may be linked from a product or PRD, but it can also stand alone in an open inventory.
Inventory entry
| Field | Meaning |
|---|---|
id | Stable identifier. |
name | Capability MLE name. |
status | planned, draft, active, deprecated, or unknown. |
purpose | One-line general outcome enabled by the capability. |
CRD | Link or reference to the Capability Requirements Document, if available. |
realization status | Available, partial, planned, deprecated, or unknown. |
known realizations | Products, services, or apps already known to realize the capability, linked to their CRD or Operational Capability Documentation where available. |
tags | The CRD's own universal tags plus this row's implementation tags, each prefixed (e.g. impl:inbox) so the two kinds are never mistaken for each other. Optional — omit if it adds nothing beyond purpose. An HTML projection typically renders this as two tabs instead — by universal tag and by implementation tag/domain — with the visual badge convention reserved for implementation tags. |
notes | Important discovery, boundary, or unknown note. |
Illustrative entry
| id | name | status | purpose | CRD | realization | known realizations |
|---|---|---|---|---|---|---|
moving.quote.request | Request a moving quote | draft | Enable a move to be presented to a provider for quote consideration. | Example CRD | illustrative | none yet |
Make reuse checkable
Known realizations keep “reusable” from becoming an unsupported label. For a general capability, list every product, service, or app already known to realize it. If there are none, say so — but say it precisely: zero known realizations does not mean the capability is invalid. It can still be a valid planned requirement. What's unproven is a claim that it's generalized/reusable — and cross-context reuse specifically stays unproven until a second real consumer exists or is imminent. When a general capability is projected from a specific one, that source product is realization #1 and should be listed.
This distinction matters because an inventory is often read by someone deciding whether to build against a capability as a shared abstraction. Conflating "not yet built anywhere" with "not real" discourages legitimate forward planning; conflating "used once" with "proven reusable" invites building against an abstraction that has never actually been shared. Keeping the two claims separate keeps the inventory honest about which risk applies.
A single-service inventory may omit the field when no cross-product reuse question exists.