Every requirement resolves to reuse, extend or create — in that order.

Requirements are matched by behaviour

The index is built from what a capability declares — entity shapes, workflow steps, the policies attached and the contract it publishes — and matching runs over that, never over identifiers, folder names or file paths. A requirement that matches two capabilities closely is not settled by taking the higher score: both candidates go to the person who owns the requirement, with what each would cover and what each would leave behind. A requirement that matches nothing is a gap, and it is stated as one.

Three answers, never just one

Reuse, extend or create — every requirement lands in one of those, and extensions are versioned against the capability they extend. A second consumer's needs widen the existing capability rather than forking a copy that drifts for two years.

Duplicates surface as decisions

When several products implement the same behaviour separately, composition raises it with the affected products named and a promotion proposal attached. It does not promote anything itself. A person decides whether the behaviour becomes a shared capability and what the migration looks like.

The reuse ratio is the output

The ratio counts requirements resolved to an existing published version against every requirement in the composition, and an extension counts as reuse only for the part the existing contract already covered. It is computed from the plan rather than from finished code, so it can be read while the composition is still a proposal, and it moves when the plan moves. Read on its own it says little: a high ratio can also mean a capability was stretched to fit, which is why it is shown next to how often a shared capability had to change for a single consumer.