Pillar — Composition

Prefix: COM- Catalog: v1.1 (new pillar). What it measures: how the system is assembled — explicit module boundaries, published contracts, and composition points an agent can reuse instead of copying.

The v1.1 ticket lists this pillar as CMP. The registry code is com and the criterion prefix is COM- so it does not collide with the v1.0 Compliance pillar (cmp / CMP-), which is not renamed. There is no v1.0 Composition catalog; IDs in the COM-1xx band are the first published criteria for this dimension.

Criteria in this pillar

COM-100 — Module boundaries published

Level: 2 · Scope: portfolio · Check: deterministic
The portfolio publishes a map of applications, shared packages, and the allowed edges between them. An agent can read which module owns a path without inferring it from folder folklore. A README list of names without edges does not satisfy this criterion.
Rationale: composition starts with knowing the parts. An agent that cannot see the graph will copy a neighbour or import across a boundary that was never written down.
Evidence expected: a committed map (workspace manifest, architecture document, or machine-readable graph); every in-scope application and shared package appears; allowed edges are named, not implied.

COM-110 — Composition contracts published

Level: 3 · Scope: application · Check: deterministic
Each composition point the application offers — a published package export, an HTTP or RPC API, or an event schema — has a committed contract (types, OpenAPI, JSON Schema, or language-equivalent). Consumers depend on that contract, not on copied internals.
Rationale: a composition point without a contract is an implementation detail an agent will freeze by copying. The contract is what makes reuse cheaper than duplication.
Evidence expected: a contract artifact per published composition point; consumers import the package or call the API rather than vendoring internals; a lint or review gate fails a new public export with no contract.

COM-120 — Shared capability consumed, not copied

Level: 4 · Scope: portfolio · Check: deterministic
A capability that more than one application needs lives in a shared module (or published package) that those applications import. A ratchet or review gate fails wholesale copies of that module into an application tree. Forks are enumerated, owned, and justified.
Rationale: copy-paste is the failure mode this pillar exists to prevent. Agents duplicate whatever is nearest; a shared module plus a copy gate is how the assembly stays one assembly.
Evidence expected: shared packages (or equivalent modules) imported by more than one application; a copy/fork ratchet or CODEOWNERS-equivalent review on duplicated trees; exception list empty or owned with a reason.

COM-130 — Compatible change at composition points

Level: 4 · Scope: application · Check: deterministic
Breaking changes to a published composition contract are versioned, or they fail a consumer-side contract check, before they land. Silent in-place breaks of an exported signature, wire format, or event schema do not satisfy this criterion.
Rationale: reuse dies the first time a shared contract moves under a consumer. Agents "fix" a package in isolation unless compatibility is a required check.
Evidence expected: versioning policy or contract-test job on changes to published exports; the job is required; at least one assertion against a documented export or schema.

COM-140 — Portfolio assembly visible as k/n

Level: 3 · Scope: portfolio · Check: manual
The assembly map reports k/n applications that consume shared composition points versus forking them. A newly added application is on the map within one review cadence or is marked not_applicable with a one-line justification. A diagram that omits a live application does not satisfy this criterion.
Rationale: portfolio scope (CSPC-31) is the scoring unit. One well-factored application next to three vendored copies is not a composed product.
Evidence expected: map or report with per-application consume-versus-fork status plus k/n; cadence stated; not_applicable entries justified.

v1.1 pillars — draft catalog, including these COM-1xx criteria. Registry cmp remains Compliance and is not this page.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 2 · Scope: portfolio · Check: deterministic

The portfolio publishes a map of applications, shared packages, and the allowed edges between them. An agent can read which module owns a path without inferring it from folder folklore. A README list of names without edges does not satisfy this criterion.

Rationale: composition starts with knowing the parts. An agent that cannot see the graph will copy a neighbour or import across a boundary that was never written down.

Evidence expected: a committed map (workspace manifest, architecture document, or machine-readable graph); every in-scope application and shared package appears; allowed edges are named, not implied.

Level: 3 · Scope: application · Check: deterministic

Each composition point the application offers — a published package export, an HTTP or RPC API, or an event schema — has a committed contract (types, OpenAPI, JSON Schema, or language-equivalent). Consumers depend on that contract, not on copied internals.

Rationale: a composition point without a contract is an implementation detail an agent will freeze by copying. The contract is what makes reuse cheaper than duplication.

Evidence expected: a contract artifact per published composition point; consumers import the package or call the API rather than vendoring internals; a lint or review gate fails a new public export with no contract.

Level: 4 · Scope: portfolio · Check: deterministic

A capability that more than one application needs lives in a shared module (or published package) that those applications import. A ratchet or review gate fails wholesale copies of that module into an application tree. Forks are enumerated, owned, and justified.

Rationale: copy-paste is the failure mode this pillar exists to prevent. Agents duplicate whatever is nearest; a shared module plus a copy gate is how the assembly stays one assembly.

Evidence expected: shared packages (or equivalent modules) imported by more than one application; a copy/fork ratchet or CODEOWNERS-equivalent review on duplicated trees; exception list empty or owned with a reason.

Level: 4 · Scope: application · Check: deterministic

Breaking changes to a published composition contract are versioned, or they fail a consumer-side contract check, before they land. Silent in-place breaks of an exported signature, wire format, or event schema do not satisfy this criterion.

Rationale: reuse dies the first time a shared contract moves under a consumer. Agents "fix" a package in isolation unless compatibility is a required check.

Evidence expected: versioning policy or contract-test job on changes to published exports; the job is required; at least one assertion against a documented export or schema.

Level: 3 · Scope: portfolio · Check: manual

The assembly map reports k/n applications that consume shared composition points versus forking them. A newly added application is on the map within one review cadence or is marked not_applicable with a one-line justification. A diagram that omits a live application does not satisfy this criterion.

Rationale: portfolio scope (CSPC-31) is the scoring unit. One well-factored application next to three vendored copies is not a composed product.

Evidence expected: map or report with per-application consume-versus-fork status plus k/n; cadence stated; not_applicable entries justified.