Conformance Self-Assessment¶

Purpose: a practical kit for the Tech Lead / Architect before releasing RENAR-CONFORMANCE.yaml. The normative basis is standard/13. This document is informative; on conflict, standard/13 wins.

1. MVR ↔ mandatory clauses §13.3 bijection¶

MVR (§0.5)	§13.3 clause	`mandatory-clauses-confirmed` field
MVR-1 Source-of-Truth inversion	§13.3.1	`sot-inversion: true`
MVR-2 V1–V6	§13.3.2	`substrate-v1-v6: { v1..v6: true }`
MVR-3 ADAPT per TZ	§13.3.3	`adapt-per-tz: true`
MVR-4 11 SPEC types	§13.3.4	`spec-types-closed-list: true`
MVR-5 TC pos/neg	§13.3.5	`tc-pos-neg-pairing: true`
MVR-6 QG — closed list	§13.3.6	`quality-gates-closed-list: true`
MVR-7 conformance manifest	§13.4 (artifact)	manifest exists + signed
— (closed-list policy)	§13.3.7	`closed-lists-backward-findings: true`

All seven MVR + §13.3.7 are mandatory for any RENAR-1..5 level.

2. Self-assessment checklist (mandatory clauses)¶

Check off after verifying the evidence in the substrate:

§13.3.1 Source-of-Truth inversion¶

The BR/SR/SPEC/TC hierarchy is the authoritative source of behavior
No SR reconstructed from code without a defect-fix justification
Drift-hooks / review policy block silent SR←code adaptation

§13.3.2 V1–V6 capabilities (substrate)¶

V1 immutable history — enabled
V2 atomic change unit — enabled
V3 diff & review — enabled
V4 branching / change-set — enabled
V5 end-to-end version pinning across substrates — enabled (verifies[].requirement-version)
V6 author + timestamp — enabled

§13.3.3 Reactive ADAPT¶

Every TZ has passed the adversarial review; the outcome is issued as an AR in status issued
On a "findings present" verdict: the ADAPT is in status approved with the Architect's signature
On a "no findings" verdict: no ADAPT is created; BR/SR/SPEC carry source.tz-section + source.adversarial-review-ref
Every finding in resolved carries decided-in on a clause of a signed ACTZ
Signed ACTZ carry the dual signature (client + contractor)
A client signature on an ADAPT is not declared mandatory (admissible only as declared-stricter)
delta-TZ: the delta-ADAPT is created on the fact of findings from the delta-TZ review, not automatically
Superseded ADAPT are retained in the terminal superseded; no dangling source.adapt remain

§13.3.4 SPEC types¶

All SPEC ∈ {ARCH, API, DATA, INT, PROC, UI, AI, SEC, OPS, TEST, DOC} — the closed list of 11 types
No local SPEC-CUSTOM-*
Test benches and data are described as SPEC-TEST, not as a section of SPEC-OPS
Delivered documentation is described as SPEC-DOC; the internal runbook stays in SPEC-OPS
Every SPEC-TEST in which at least one dataset carries real or personal client data has a client-signature

§13.3.5 TC pos/neg¶

Every verifiable assertion has a pos + neg TC (or a negative-invariant exception)
QG-2 blocks verified on violation
Every TC with automation.kind: dynamic carries an environment-ref to an existing SPEC-TEST (a missing field is fatal; static checks require no bench)
Every SPEC-DOC is covered by the doc-lint (a TC with automation.kind: static); without it the SPEC-DOC does not pass QG-2

§13.3.6 Quality Gates¶

QG-0, QG-1, QG-2 implemented as required
QG-3, QG-4 declared required | declared | absent in the manifest
No local custom gates

§13.3.7 Closed lists¶

Backward finding types — closed list §7.4.4 only
SPEC decomposition types — closed list §8 only

Rule: if at least one is unchecked → do not release the manifest (§13.5.1).

3. Level checklist (choose the target RENAR-N)¶

The minimum for claiming a level is standard/11 §§11.4–11.8. Brief summary:

Level	Key additional criteria
RENAR-1	Mandatory clauses only; frontmatter minimal
RENAR-2	Basic frontmatter (no strict schema validation); TZ and delta-TZ as explicit immutable artifacts; lifecycle statuses not yet mandatory
RENAR-3	Full frontmatter schema + lifecycle statuses; hooks enforce QG-0 and QG-1, QG-2 — partially
RENAR-4	ai-provenance mandatory; pos/neg pairing for every normative assertion; QG-2 enforced natively
RENAR-5	Adversarial review as a gate; multi-model consensus for `priority: must`; knowledge graph as primary lookup; continuous evaluation of SPEC-AI

The chosen level in the manifest is no higher than the checklist actually passed
declared-stricter (if present) is documented separately

4. Manifest template (minimal)¶

Save as RENAR-CONFORMANCE.yaml at the root of the requirements substrate:

manifest-version: 1
manifest-id: "CFM-YYYY-NNN"
renar-version: "1.0"
senar-version: "1.0"
level: RENAR-2
assessment-date: "2026-05-22"
assessment-mode: self          # self | third-party (§13.4.2)
next-assessment-due: "2026-08-22"

mandatory-clauses-confirmed:
  sot-inversion: true
  substrate-v1-v6: { v1: true, v2: true, v3: true, v4: true, v5: true, v6: true }
  adapt-per-tz: true
  spec-types-closed-list: true
  tc-pos-neg-pairing: true
  quality-gates-closed-list: true
  closed-lists-backward-findings: true

quality-gates:
  qg-0: required
  qg-1: required
  qg-2: required
  qg-3: declared
  qg-4: absent

external-claims:
  - standard: "ISO/IEC/IEEE 29148:2018"
    clause-ref: "§14.4.2"
    claim: "partial"           # full | partial | aligned

substrate-capabilities:
  v1-immutable-history: declared
  v2-atomic-change-unit: declared
  v3-diff-review: declared
  v4-branching: declared
  v5-version-pin: declared
  v6-author-timestamp: declared
  substrate-id: "<substrate-native pointer>"

spec-types-supported: ["SPEC-ARCH", "SPEC-API", "SPEC-DATA", "SPEC-INT",
                       "SPEC-PROC", "SPEC-UI", "SPEC-AI", "SPEC-SEC", "SPEC-OPS",
                       "SPEC-TEST", "SPEC-DOC"]

assessor:
  id: "<V6 author identifier>"
  role: architect              # architect | authorized-role-holder | external-assessor
  signature-ref: "<substrate-native pointer to the signature event>"

The full field list is §13.4.2.

5. Cadence¶

Self-assessment: quarterly (default)
After a delta-TZ that affects mandatory clauses — out of cycle
Conformance-loss triggers — §13.8

Reference RENAR 1.0 — renar.tech