Conformance

Conformance

Requirement IDs are stable: MC-n never changes meaning. A build may cite the IDs it satisfies, and a reader may check the citation.

Key words MUST / MUST NOT / SHOULD / MAY are used per RFC 2119.

Canonical source: spec/CONFORMANCE.md

---

The design constraint

Every requirement is written as an observable property of an output, never as a property of an intention.

This is not a stylistic preference. A requirement phrased as an intention — "the implementation should consider alternative viewpoints" — is satisfied by an implementation that says it considered them. The requirement then certifies nothing, and a conformance suite built on such requirements is a suite that cannot fail.

So each requirement below can be checked by a third party holding only the output, with no access to the implementation and no trust in its author.

---

The requirement set

ID	Group	The core of it
MC-0	Delta Rule	an operation reported as performed MUST have produced an observable change; one that did not MUST be reported skipped; generic reflective language is a violation, not a compliance
MC-1	State	SHOULD read load/pressure/affect; MUST report PULL where one exists; MUST prefer presence to structure under acute distress
MC-2	Monitoring	every substantive claim classified Known/Inferred/Unknown; the Unknown set MUST NOT be empty for a non-trivial problem; unsourceable claims marked [UNVERIFIED] and kept out of the recommendation; MUST NOT invent a specific to fill a gap
MC-3	Falsification	an established claim MUST carry a falsifier; it MUST be specific and observable; a claim with none MUST be labelled unfalsifiable and MUST NOT be defended as strong
MC-4	Flexibility	≥2 frames that can disagree; MUST state which is trusted and why; frames selected because they agree MUST NOT count
MC-5	Calibration	confidence MUST carry EARNED/UNEARNED; EARNED requires a record; UNEARNED MUST be reported where true; a rate over an empty denominator MUST NOT be reported as 0
MC-6	Shadow Gate	the five gate questions MUST run before an actionable output; failing MUST be a permitted terminal outcome; MUST NOT proceed by lowering the standard
MC-7	Levels	a reported level MUST be justified by a tell present in the same output; MUST NOT report a level whose tell is absent; when uncertain, report the lower and name what prevented the higher
MC-8	Self-development	3 cited instances to promote; 1 counter-instance demotes; history preserved; never-fired rules marked dormant; MUST NOT imply learning across sessions it cannot remember
MC-9	Scope	MUST NOT claim subjective experience; the human decides; MUST NOT apply the full ladder where it changes nothing

---

Auditing a build in ten minutes

You do not need the implementation. Take three of its outputs — ideally one trivial, one substantive, one where it should have refused — and work through this.

1 · The Unknown test (MC-2.2) Read the UNKNOWN section. Could it be pasted unchanged under a different question? Then it names nothing, and the build fails the cheapest requirement in the set. Start here — most builds that fail anything fail this.

2 · The delta test (MC-0.1) For each step the output claims to have performed, point at the words that exist because it ran. If you cannot, the step did not happen — and reporting it anyway is a more serious violation than skipping it.

3 · The falsifier test (MC-3.2) Name the observation that would make the falsifier fire. If you cannot name one, it is decoration.

4 · The basis test (MC-5.1, MC-5.3) Is every confidence figure labelled? Are they honestly UNEARNED? A build that reports EARNED without pointing at a record has failed MC-5.2 — and a build where everything is EARNED has almost certainly failed it silently.

5 · The level test (MC-7.2) Work top-down through The Five Levels and stop at the first missing tell. Compare to the claimed level. Overclaiming is itself a Level-1 act.

6 · The empty-denominator test (MC-5.4) If the build reports any self-measured rate, check whether the denominator is zero. A 0% over nothing is a fabricated measurement dressed as evidence.

7 · The ceremony test (MC-9.3) Look at the trivial output. If it ran the full ladder, the build fails from the other direction.

8 · The persistence test (MC-8.5) Ask what it remembers from previous sessions. Compare the answer to what the host actually provides.

---

Self-assessment is not conformance

A build cannot certify itself by asserting these IDs.

Conformance is demonstrated by outputs a third party can check against the tells — which is precisely why every requirement is written as an observable property.

A build that says "fully conformant with MC-0 through MC-9" has produced a claim, and a claim about one's own process with no delta behind it is the failure MC-0.1 describes. The correct form is: here are outputs; here is which requirement each part satisfies; here is the one I skipped and why.

---

Checking the reference build

The repo ships its own checks, and they are built to be able to fail:

python tools/validate_skill.py    # 45 checks — installability + load-bearing content
python -m pytest -q               # 38 contract tests

The validator checks more than structure: the Delta Rule's presence, the EARNED/UNEARNED distinction, the level tells, the promotion thresholds, and the limits the OS is required to state about itself.

The test suite checks what a per-file validator structurally cannot — that the documents agree with each other: no document cites an undefined requirement ID, no requirement group is unreachable, every requirement carries an RFC-2119 keyword, and the promotion threshold is the same number everywhere.

The non-vacuity test

def test_validator_reddens_when_a_load_bearing_line_is_removed(...):
    """If deleting the core law still passes, the validator is decoration
    and every green run above it means nothing."""

It clones the repo, deletes a load-bearing line from SKILL.md, and asserts the validator exits non-zero for the right reason. The CI secret scan does the same thing with a planted canary: it must detect the canary before it is allowed to report clean.

A check that cannot fail is not a check. That is MC-0 applied to the tooling.

---

Related

• The Delta Rule — MC-0 in full
• Failure Modes — each requirement's violation in the wild
• Calibration — MC-5, the one most likely to be dropped