Skip to content

Conformance

Conformance is a claim about a named implementation boundary at a named revision. It is not a brand label.

TM-CON-001 — Complete core assessment. A core conformance claim MUST assess every applicable normative requirement in specification 0.1.0.

TM-CON-002 — Exact target. The claim MUST identify the implementation, version or revision, coherence boundary, specification version, assessor, and assessment date.

TM-CON-003 — Evidence per requirement. Each requirement disposition MUST be one of:

  • satisfied — concrete evidence demonstrates the behavior;
  • not_satisfied — evidence demonstrates a gap;
  • not_applicable — the conditional capability is outside the assessed boundary, with a reason; or
  • unknown — available evidence cannot support a conclusion.

TM-CON-004 — No unresolved conformant claim. A claim MUST NOT use the word conformant while any applicable requirement is not_satisfied or unknown.

TM-CON-005 — Exact evidence. Supporting evidence MUST cite stable tests, records, source revisions, observations, or other inspectable mechanisms. A policy statement that depends on careful memory is not sufficient evidence of structural enforcement.

TM-CON-006 — Scoped publicity. A public conformance report MUST state which evidence is publicly auditable, privately attested, or withheld under a declared boundary.

Publication requirements TM-PUB-* apply only when publication or outside encounters are included in the assessed boundary. Live-observation requirements TM-OBS-005 through TM-OBS-009 apply only when the system claims declared-versus-observed comparison.

Declaring a capability outside the boundary is valid. Hiding an implemented but nonconforming path by omitting it is not.

Profiles add requirements to a core claim. Version 0.1 provides informative Git-native and AI-Peer profiles; they do not yet define separate normative conformance marks.

Patterns describe useful optional shapes. Using or not using the Facets pattern has no effect on core conformance.

The repository’s reference instance demonstrates one implementation and provides fixtures for validators. It is not automatically conformant because it hosts this specification. Its conformance report must pass the same exact assessment and publication rules as any other implementation.

A complete report contains:

implementation identity
assessed coherence boundary
specification version
assessor and date
requirement -> disposition -> evidence
optional profiles claimed
public/private evidence boundary
known limitations

The structured report schema is published under /schemas/.