Outward Conformity Registry — When Operating on Host Projects

Canonical registry of the fifteen production mandates. This document carries the full fifteen-mandate registry (M1–M15), the trivial-vs-non-trivial threshold ratification, the M↔CM cross-mapping policy, and the mandate-introduction protocol; the substantive enumerations live here, operationalized by the per-mandate rule files.

When this ecosystem generates, edits, reworks, retrofits, extends, or removes any artifact in a host project (the user's invocation target — git repo, doc tree, research corpus, infrastructure manifest, scratchpad), every produced artifact meets the fifteen-mandate bar (M1–M15) declared below. This is non-negotiable and applies to every ecosystem surface (skill, assistant, command, hook, response, diff, message). Enforcement is the pre-emission gate (see site/content/docs/governance/pre-emission-gate-registry.mdx); mechanical-fraction enforcement lives at src/apothem/conformity/*-grep.py orchestrated by src/apothem/conformity/gate.py.

The fifteen mandates operate alongside the CM-N mandates per the parallel-vocabulary policy (see site/content/docs/governance/cross-cutting-mandates.mdx); M and CM are orthogonal governance dimensions (M is the outward axis — host-project artifacts; CM is the inward axis — ecosystem-internal artifacts). Each rule listed below is the canonical home for its mandate; this registry is the index.

1. Trivial-vs-Non-Trivial Threshold (settled)

The threshold separating trivial from non-trivial work — non-trivial work triggers the M11 + M12 apparatus — is line-count + scope hybrid: a change is trivial when it is a single-file edit of ≤ 5 lines AND introduces no public-API surface change AND no behavioral shift. Anything else is non-trivial. Settled once per the M5 settle-once discipline; the threshold lives here at user scope and is overridden only by an explicit project-scope declaration honoring M1 host-discovery (e.g. a <project>/.claude/CLAUDE.md for Claude Code, or the equivalent per-project surface for another harness).

2. M↔CM Cross-Mapping

Each M-numbered rule body declares its CM-N cross-mapping inline (in its Cross-bound with ↔ binding) using the parallel-vocabulary policy: where an M-mandate has a closest CM-N analog, both rules apply where both apply (no substitution). The mappings are intrinsic to the rule bodies; this registry summarizes the axis policy without duplicating the mapping table.

3. Mandate-Introduction Protocol

Adding a new M-numbered mandate (e.g., a future M16) is a bundled change. The bundle reaches the registry only when every component below is present in the same change-set. Silent additions — a new M-row in the registry table without the supporting bundle — produce mandate-axis drift and are non-conformant per M14 systemic-participation.

Application discipline. A mandate proposal that arrives without the bundle is rejected at review; the proposer either completes the bundle or downgrades the proposal to an extension of an existing mandate. The existing fifteen mandates were adopted together as the spec's outward axis; future additions honor the same all-components-or-no-component adoption cadence rather than landing piecemeal.

Demotion / retirement protocol. When an established M-N is found redundant with an existing CM-N or with another M-N (the cross-mapping coverage map at the materializing-rule's body shows direct adjacency in both directions), the demotion is the symmetric inverse: the registry row is retired, the gate row is retired, the canonical rule is retired (with content folded into the absorbing rule per src/apothem/rules/clean-room-generation.md §3 Re-Writing Protocol), the conformity fixture is retired, the release-proof schema's bars: block drops the row, and the change-set is recorded in the disclosure ledger with the absorbing-rule citation. Demotion preserves the same all-components-or-no-component invariant.