ISO/IEC 29148 — Trace Matrix

Purpose: verifiable conformance of a conformance claim to ISO/IEC/IEEE 29148:2018 (standard/14 §14.4.2). Normative field definitions are in standard/06, standard/08, standard/09, 02-schemas.md.

RENAR simplifies the set of mandatory 29148 attributes (18 → 7–8 per artifact) and adds TC as a first-class artifact, ADAPT, and the SPEC axis. The table below is the complete trace for a conformance assessor and for populating external-claims[] in the manifest.

---

1. Requirement classes (29148 §5)

ISO/IEC 29148 class	RENAR artifact	Normative source
Stakeholder requirement	BR	§6.5
System requirement	SR (level: system / subsystem / module)	§6.6
Software requirement (implementation unit)	TR	§6.7
Interface / design specification	SPEC-* (9 types)	§8
Verification item	TC	§9
Requirements validation (client interpretation)	ADAPT	§7

---

2. Requirement attributes (29148 Table B.1 → RENAR)

#	ISO/IEC 29148 attribute	RENAR field / mechanism	Mandatoriness	Note
1	Unique ID	id (immutable)	mandatory	V1; see §3.3.1
2	Requirement statement	body (Need / Behavior / …)	mandatory	EARS template for SR: §6.6.3
3	Rationale	body "Context" + source.adapt-section	mandatory (BR/SR)	Traceability to ADAPT
4	Source	source.adapt, source.tz-section, source.document-ref	mandatory	V5 pinning via document-ref
5	Fit criterion	body "Success criteria" (BR) / Pass criteria of TC	mandatory	Measurability via 25022/25023: §14.4.4
6	Priority	priority (MoSCoW)	mandatory	WSJF — informative in the SAFe mapping
7	Owner	owner (BR/SR) / business-context.stakeholder	mandatory	§6.5.2
8	Status	status (lifecycle enum)	mandatory	State machines: §10
9	Verification method	verified-by[] → TC + tc-type	mandatory for verify	TC as a first-class artifact — an extension of 29148
10	Parent / child	parent.id, auto children[]	mandatory (SR/TR)	Hierarchy BR→SR→TR
11	Traceability (derived)	verified-by, constrained-by[], implements-spec[], KG edges	derived	reference/05 §4
12	Version	substrate-native version + requirement-version in TC	mandatory (V5)	§3.3.5
13	Author	V6 author + ai-provenance	mandatory (RENAR-4+ AI)	§4.10.1
14	Date created / modified	substrate change-record timestamps	derived (V6)	Audit log: §10.13
15	Risk	compliance[], AIR register link	optional / domain	03-ai-risk-register.md
16	Assumption	ADAPT backward findings type: assumption	via ADAPT	§7.4.4
17	Dependency	depends-on[] (SPEC), constrained-by[] (SR)	mandatory where applicable	DAG invariant: 02 §9
18	Approval authority	QG-0 / QG-2 + ADAPT dual signature	mandatory	Replacement for the formal walkthrough: §14.4.2

Not adopted from 29148: review meetings and inspection-only verification without TC evidence — see §14.7.

---

3. Verification methods (29148 §6.4)

29148 method	RENAR implementation
Test	TC with tc-type: system \| acceptance \| contract \| …
Demonstration	tc-type: acceptance + client sign-off (QG-4 optional)
Inspection	[test-spec-change] workflow + adversarial review (§9.13)
Analysis	SR with quality-characteristic + eval-TC (tc-type: eval) for SPEC-AI

---

4. Lifecycle processes (29148 §6)

29148 process	RENAR chapter	Gate
Requirements elicitation	ADAPT backward + TZ	QG-0 (ADAPT approve)
Requirements analysis	BR/SR decomposition	QG-0 (BR/SR approve)
Requirements specification	SPEC axis	QG-3 Architecture (optional/required)
Requirements verification	TC + QG-2	QG-2 Verification
Requirements validation	ADAPT client signature + QG-4	QG-4 Acceptance (optional)
Requirements management	lifecycle §10 + substrate V1–V6	Continuous

---

5. Use in conformance assessment

1. For each ISO/IEC/IEEE 29148:2018 claim in the manifest — walk through the rows of §2–§5.
2. By spot-check (≥10% of artifacts, or all system-level BR/SR) verify the presence of mandatory fields and the source.adapt trace.
3. Non-conformance of any mandatory row of §14 — a partial claim is not permitted (§14.6.2).

---

Reference RENAR 1.0-draft — renar.tech