You do not adopt the whole framework at once — you define one capability well. This page is that walk-through: the file every capability carries, the test that decides its boundaries, and a worked example you can copy.
A capability file is not a paragraph of description. It is a structured bundle that forces the questions of mandate, competition, regulation, and rationale to be answered before a line is built.
The statutes, regulations, policies, charters, or strategic decisions that explain why the organisation holds this capability. At least one source, always.
Where the organisation sits relative to others offering the same capability: table stakes, differentiators, disruptors, unbundling, rebundling, switching drivers.
What is currently in force, what is coming in the next two to three years, and which enforcement signals matter.
Which elements must be built in-house and which should be bought from vendors — an explicit position, not an accident of tooling.
The bounded areas of responsibility that compose the capability, each carrying its own promotion test.
Architectural choices with rationale, alternatives considered, and why those alternatives were rejected. No silent deviation.
Revenue model is intentionally not part of the bundle. The capability file describes what the capability is; commercial analysis is a separate concern.
For every sub-capability you listed, run four boolean criteria. The count of trues decides whether it stays inside the capability or becomes one of its own.
Does it involve actors absent from the parent's other sub-capabilities?
Is it governed by a materially distinct body of rules?
Does it have phases of operation that appear nowhere else?
Do its demand drivers vary independently of the parent?
The prima facie rule. Each criterion is a boolean; criteria_met is the count of trues. If three or more are true, promote the sub-capability to a standalone capability. If fewer, retain it.
Overrides are permitted — a 3-of-4 may be retained, a 2-of-4 may be promoted — but the parent capability's design decisions must record the reasoning. No silent deviation.
This is a real capability from a worked commercial-banking pack — Payment Operations — with two of its sub-capabilities scored against the promotion test, and the design decision that records the harder call.
That is one capability. Repeat for each mandate-backed function until the list is stable, then read how they all fit together.
Read the framework — the invariants every capability obeys →