Attestation Infrastructure in v0.1

Attestation Infrastructure in v0.1

The named-approver attestation discipline that ships in v0.1 — three typed attestation subclasses (rtm:SatisfactionAttestation, rtm:AdequacyAttestation, rtm:SufficiencyAttestation), each a rdfs:subClassOf rtm:Attestation, each governed by a single SHACL shape that rejects any attestation lacking a named human approver IRI. This is the accountability mechanism that is "by construction" rather than "by policy." Per ADR-032 Methodology Agnosticism as Foundational Axiom, named-signer accountability is part of what flexo-rtm IS — settled engineering independent of any specific downstream-analysis methodology. The ADCS Prototype Lessons regression corpus already depends on adequacy and sufficiency attestations. Normative source: Design Spec §4.3. Acceptance criteria: §9.A.3 I1 (schema-enforced approver) and §9.A.3 I7 (git approver binding under signed-commits profile).

Purpose and scope

flexo-rtm v0.1 ships three kinds of attestation as first-class typed RDF assertions. Each is an independent claim by a named human about a single subject, and each is rejected at write time if no approver is named. This is flexo-rtm's named-signer accountability discipline — narrower in scope than the full topological audit Zargham (2026) describes (no closed-triangle gate, no recursive completeness check on guidance, no V−F invariant computation), and intentionally so. The topological audit belongs to a separate research line (Topological Framework Future Work); if an adopter chooses to run it as a downstream-analysis mode, the data is forward-compatible — but flexo-rtm does not commit to it. The typed attestations are well-defined as individual assertions on their own.

This page specifies what v0.1 ships, the SHACL shape that makes the discipline structural, the composable profiles, and the boundary against the deferred framework. Normative source: Design Spec §4.3. Gap codes: Gap Taxonomy (§4.7). Git side: Approver Binding via Git. Accountability motivation: Human-AI Accountability.

Why this ships in v0.1 (and not in the deferred framework)

Two arguments converge.

Regression need. The ADCS Prototype Lessons corpus — the ground-truth dataset against which flexo-rtm regressions run — already records adequacy and sufficiency attestations as rtm:Attestation instances with earl:result outcomes and prov: provenance. v0.1 has to read and round-trip those graphs without semantic loss; the three subclasses with a named-approver SHACL shape are the minimum satisfying the regression contract.

Independent value. Named-approver accountability is meaningful on its own — flexo-rtm's named-signer discipline, per ADR-032 Methodology Agnosticism as Foundational Axiom — not as preparation for any specific downstream-analysis methodology. A claim that "this artifact satisfies this requirement" is well-typed regardless of whether any closed triangle exists. The adopter who turns on attested-satisfies today gets the "by construction" property — they cannot persist an unsigned attestation. Structural accountability is achieved by making the schema reject the unaccountable case, not by trusting reviewers to enforce a recommendation.

The three attestation subclasses

All three are rdfs:subClassOf rtm:Attestation and share the parent's properties. They differ in what they take as subject and what they assert.

Class	Subject	Asserts
rtm:SatisfactionAttestation	an rtm:satisfies triple (artifact → requirement)	"this artifact satisfies this requirement" — named human approves
rtm:AdequacyAttestation	an artifact + requirement pair (typically tied to coupling via rtm:AdequacyCriteria guidance)	"the model representation is adequate for the kind of claim made about this requirement" — named human approves
rtm:SufficiencyAttestation	an artifact + requirement pair (typically tied to coupling via rtm:SufficiencyCriteria guidance)	"the evidence is sufficient to support the claim about this requirement" — named human approves

A satisfaction attestation answers "did this artifact meet this requirement?" An adequacy attestation answers "is the model we used adequate for the kind of claim being made?" A sufficiency attestation answers "is the evidence enough to support the claim?" The three are separable judgments, potentially made by different approvers under different aspects, each an independent named-approver assertion. The prototype flow at ADCS-lifecycle-demo/traceability/attestation.py already follows this triple split — the CLI presents evidence, the engineer makes adequacy and sufficiency judgments, and the records are written with earl:result outcomes and prov: provenance.

Parent class rtm:Attestation — shared properties

All three subclasses inherit:

• rtm:approvedBy (IRI) — REQUIRED; points to a foaf:Person or org:Membership. This is the SHACL-enforced field.
• rtm:attests — points to the asserted triple (via RDF-star) or to the reified (artifact, requirement) pair.
• rtm:attestationStatus — REQUIRED; one of rtm:status/pass, rtm:status/fail, rtm:status/deferred, rtm:status/deprecated. See the next section.
• earl:result (optional, retained for EARL-tooling compatibility) — SKOS-aligned to the canonical rtm:attestationStatus; tools may read either property. Adopters using EARL infrastructure can populate both.
• rtm:hasAspect (optional) — aspect tag for per-aspect attestation; used by the aspect-coverage profile.
• prov:wasGeneratedBy, prov:atTime, prov:wasAssociatedWith — full PROV provenance.
• prov:wasInvalidatedBy (optional; required under strict profile when rtm:attestationStatus = rtm:status/deprecated) — points to the activity or commit that invalidated the attestation.

Attestation status — the four-state vocabulary (§ADR-031)

Every rtm:Attestation carries one of four status values. The vocabulary is locked in ADR-031 Attestation Status Pass Fail Deferred Deprecated and replaces the earlier reliance on earl:result alone:

Status IRI	Meaning	EARL analogue
rtm:status/pass	Attestation is valid and the claim holds.	earl:passed (via skos:exactMatch)
rtm:status/fail	Attestation is valid and the claim does not hold.	earl:failed (via skos:exactMatch)
rtm:status/deferred	Engineer surfaced the judgment moment but has not yet resolved it. Subsumes the prior rtm:DeferredJudgment concept.	none
rtm:status/deprecated	Attestation existed and was valid, but is now invalidated by upstream changes; a new attestation is required.	none

The fail status preserves what the earlier earl:result earl:failed channel provided: a recorded "this claim does not hold," with full named-approver discipline. The attestation exists, has an approver, and asserts failure. That is structurally different from $T3$/$T4$/$T5$ which surface as "no attestation present at all (for this claim type, under the active profile)."

The deprecated status is the methodology-neutral regression-handling mechanism introduced in ADR-031 Attestation Status Pass Fail Deferred Deprecated. When upstream changes invalidate a downstream claim, the affected attestation is marked deprecated with prov:wasInvalidatedBy recording the cause. The cert artifact surfaces deprecated attestations as T9 gaps so the team knows what to re-attest. This mechanism replaced an earlier scope-level lifecycle state machine (see the reframed ADR-029 Engineering Lifecycle Stages as Scope Metadata); it is local to the attestation and does not require any privileged lifecycle vocabulary.

A second SHACL shape enforces the status field:

rtm:AttestationStatusShape a sh:NodeShape ;
    sh:targetClass rtm:Attestation ;
    sh:property [
        sh:path rtm:attestationStatus ;
        sh:minCount 1 ;
        sh:in ( rtm:status/pass rtm:status/fail rtm:status/deferred rtm:status/deprecated ) ;
        sh:message "Every attestation requires one of the four status values"
    ] .

Combined with the named-approver shape (next section), the two shapes give every rtm:Attestation the same structural discipline: an accountable human AND a determinate status (or deferred if the human is honest that they have not yet resolved the judgment).

Schema-enforced named-approver requirement (§9.A.3 I1)

The single SHACL shape that gives this discipline its structural character:

rtm:AttestationShape a sh:NodeShape ;
    sh:targetClass rtm:Attestation ;  # applies to parent and all subclasses
    sh:property [
        sh:path rtm:approvedBy ;
        sh:minCount 1 ;
        sh:nodeKind sh:IRI ;
        sh:message "Every attestation requires a named human approver IRI"
    ] .

Because sh:targetClass rtm:Attestation matches the parent, RDFS subclass entailment ensures the shape also targets all three subclasses. SHACL rejects any attestation instance of any kind that lacks an approver IRI at write time. This is what Design Spec §9.A.3 I1 specifies as the acceptance criterion: every rtm:Attestation instance MUST have rtm:approvedBy <IRI> with sh:minCount 1 and sh:nodeKind sh:IRI; writes without this fail at the SHACL gate. The test is tests/conformance/test_attestation_shape.py. Gap code $T7.unapproved-attestation$ is listed in Gap Taxonomy as cannot exist — the schema does not admit such triples.

This is the "by construction" mechanism. The conventional approach asks reviewers to enter their name into a field; flexo-rtm's approach makes the absence of that name a write-time validation failure. The two look similar in policy text; they differ enormously in the data that ends up in the graph.

Composable optional profiles

The named-approver shape is on by default and unconditional. Four additional profiles are off by default and composable — adopters opt in as their workflow matures:

• attested-satisfies — every rtm:satisfies triple in the graph requires a corresponding rtm:SatisfactionAttestation whose subject is that triple. When this profile is off, satisfaction triples can exist without attestations; gap code $T3.unattested-satisfaction$ only surfaces when the profile is on.
• attested-adequacy — every rtm:satisfies triple requires a corresponding rtm:AdequacyAttestation for the artifact. Surfaces gap $T4.unattested-adequacy$.
• attested-sufficiency — every rtm:satisfies triple requires a corresponding rtm:SufficiencyAttestation for the artifact. Surfaces gap $T5.unattested-sufficiency$.
• aspect-coverage — for multi-aspect requirements, each declared aspect requires its own attestation per claim type. Surfaces gap $T8.aspect-uncovered$.

An adopter typically starts with just the unconditional named-approver shape, then enables attested-satisfies, then layers attested-adequacy and attested-sufficiency as practice matures, and finally aspect-coverage for programs with multi-aspect requirements (safety, security, performance, dependability). Composability is the point: the discipline scales to the rigor the program is ready for, and audit reports show exactly where the gaps are at each stage. See Aspect Coverage with Adequacy and Sufficiency for the per-aspect rollup and Quantitative Outcomes for reporting.

Per-aspect attestation

A multi-aspect requirement (one that declares aspects like rtm:safety, rtm:security, rtm:performance) can have its claims attested per-aspect: an attestation carries rtm:hasAspect <aspect-iri> to mark which aspect it covers. When aspect-coverage is on, the audit checks that each declared aspect has the required attestations per claim type. This composes with attested-adequacy and attested-sufficiency — a safety-aspect requirement may need adequacy and sufficiency attestations for the safety aspect in addition to (or in lieu of) program-wide ones. The per-aspect rollup is described in Aspect Coverage with Adequacy and Sufficiency.

Git binding chain (§9.A.3 I7)

The named-approver IRI is enforced at the SHACL gate; the binding between that IRI and a real human action is enforced at the git layer. The full chain is documented in Approver Binding via Git. The relevant guarantee here is §9.A.3 I7: when the signed-commits profile is active, any git commit that introduces an attestation triple MUST be GPG- or SSH-signed by a key whose fingerprint matches the rtm:approvedBy IRI's published key. A pre-commit hook and a GitHub Actions check both verify this, applied uniformly to all three subclasses. The test is tests/integration/git/test_approver_binding.py. Together, I1 (SHACL-enforced approver IRI) and I7 (cryptographic binding from IRI to commit signer) compose into the end-to-end guarantee: an attestation exists in the graph only if a named approver signed for it, and a signed commit introducing one only verifies if the signer matches the named approver.

Why per-claim attestations are part of what flexo-rtm IS

An attestation is an independent assertion by a named human about a single claim. Its semantics do not depend on whether any surrounding assurance triangle is closed, whether the guidance it implicitly invokes has itself been attested, or whether some V−F invariant balances. Those are properties of an aggregation of attestations, not of any individual one. Per ADR-032 Methodology Agnosticism as Foundational Axiom, named-signer attestation is part of what flexo-rtm IS — settled engineering composed of W3C VC Data Integrity, SLSA in-toto, Sigstore + Fulcio, git GPG/SSH signing, NIST SP 800-63, and W3C SHACL — independent of any specific downstream-analysis methodology. Adequacy and sufficiency, as individual judgments, are well-defined; the ADCS Prototype Lessons corpus demonstrates them in operation.

The corollary is forward-compatible interop. The triples written under v0.1 carry the fields any downstream-analysis path needs: named approver, typed subject, aspect tag, EARL result, PROV provenance. Adopters who choose to run topological analysis as a downstream-analysis mode read them as named-approver-bearing inputs to closed-triangle audits; adopters running SLSA, GSN, ARP4754A, or in-house analyses read them equally.

What flexo-rtm does NOT do

The boundary between flexo-rtm and downstream-analysis paths (topological, SLSA, GSN, ARP4754A, in-house) — per ADR-032 Methodology Agnosticism as Foundational Axiom:

• Does not enforce closed assurance triangles. The 2-simplex closure (verification + validation + spec/guidance coupling all present) is a topological-audit gate from the research line (Topological Framework Future Work); flexo-rtm does not check it and does not commit to it.
• Does not check "is this guidance itself fit-for-purpose?" Recursive completeness is an open problem in the topological research line, requiring a community-curated registry; it is not a flexo-rtm feature.
• Does not run recursive completeness audits. Reaching guidance-of-guidance-of-guidance until a self-attesting base case is found belongs to the topological research line.
• Does not compute V−F invariants. The Euler-style invariant is a property of the closed complex an adopter would construct in a topological downstream audit; flexo-rtm has no such complex.
• Does not verify aspect coverage as a closure property. The aspect-coverage profile checks declared aspects, not topologically derived ones.

All of these live in the topological research line or other downstream-analysis paths adopters may choose to run; see Topological Framework Future Work for the canonical reference to the topological line.

Coverage and audit reporting

v0.1 audit reports include, per Quantitative Outcomes and Gap Taxonomy:

• Coverage statistics per attestation subclass — satisfaction %, adequacy %, sufficiency %.
• Per-aspect breakdown when multi-aspect requirements are present.
• Gap-code enumeration: $T3.unattested-satisfaction$, $T4.unattested-adequacy$, $T5.unattested-sufficiency$, $T6.failed-attestation$, $T8.aspect-uncovered$. ($T7.unapproved-attestation$ is structurally absent.)
• A reproducibility manifest enumerating every external URI (approver identity provider, signed-commit reference, evidence URI) the cert depends on.

Audit failure is decoupled from gap presence — a report can succeed at the predicate level while still listing gaps in $T3$–$T8$, depending on which profiles are active and what the certification predicate requires.

Relationship to traditional V&V analysis

The three subclasses map cleanly to the forward/backward primitives in Traditional Forward and Backward Analysis. Forward analysis (requirement → artifact) corresponds to satisfaction attestation; backward analysis ("is the model adequate / is the evidence sufficient?") corresponds to adequacy and sufficiency attestations. The novelty in v0.1 is not the analysis taxonomy — it is schema enforcement of named approvers on the resulting assertions.

Cross-references

• Design Spec §4.3 — normative source for the three subclasses and the SHACL shape; §4.7 — gap taxonomy ($T3$, $T4$, $T5$, $T6$, $T7$, $T8$); §9.A.3 — acceptance criteria I1 and I7.
• Approver Binding via Git — the git-side of the binding chain that satisfies I7.
• Traditional Forward and Backward Analysis — V&V analysis primitives mapped onto the three subclasses.
• Aspect Coverage with Adequacy and Sufficiency — per-aspect attestation rollup and the aspect-coverage profile.
• Gap Taxonomy — full enumeration of T-codes the audit surfaces.
• Quantitative Outcomes — how coverage % and gap counts appear in audit reports.
• Topological Framework Future Work — the topological research line as one possible downstream-analysis path; not flexo-rtm's destination.
• ADR-032 Methodology Agnosticism as Foundational Axiom — names named-signer accountability as part of what flexo-rtm IS, independent of any specific downstream-analysis methodology.
• Human-AI Accountability — why named-approver accountability matters in the LLM-assisted authoring era.
• ADCS Prototype Lessons — the regression corpus that exercises the three subclasses today.