RELAY spec v1.10 (release) adds §20 Continuous Conformance, making the CI process normative: conformance must be continuously proven, not just declared.
§20 requires, on every change, that CI gates on:
relay conform --strict against the built CLI (fail on FAIL or WARN).- The full gofusa lifecycle — not a subset:
check (gate on ERROR), 100% requirement traceability (traced and tested), cybersecurity analysis, dependency vulnerability scan, and the tool qualification suite.
relay interop behavioural conformance (once convert exists) — EQUIVALENT for every golden vector.- Evidence (§20.4): a traced+tested requirements registry, a HARA, a dFMEA, and a TARA where untrusted input is processed.
- Supply-chain (§20.5): SBOM + build provenance (SLSA), releases tagged from green CI.
RELAY itself is the reference exemplar — its CI now runs the full go-FuSa lifecycle and passes every gate.
What go-LIN needs
No relay conform CI gate yet (see #30) — add it (--strict). Expand to the full go-FuSa lifecycle (vuln, qualify, 100% trace). Add relay interop, TARA, dFMEA, SBOM/provenance.
This builds on the §13.7 architecture + spec-uplift issue already open. No changes are requested to RELAY. Verify with relay conform --strict + the full gofusa lifecycle locally.
Definition of done — the entire current spec (v1.10)
This issue lists the §20 deltas, but the bar is the whole current RELAY spec — v1.10 (the latest release), not only §20, and not the "1.9" mentioned in the earlier §13.7 issue (now superseded). The implementation is conformant when:
version --format json reports spec_version 1.10 (track spec/version.json in SoundMatt/RELAY);relay conform --strict <binary> passes — the full §12 / §17 document and behaviour surface;relay interop reports the implementation EQUIVALENT for every golden vector (§20.2), once convert is conformant;- the full x-FuSa lifecycle passes (§20.1.2);
- all normative sections are satisfied — §13.7 architecture, §15 canonical types (including CAN XL / ESI where applicable), §5 sentinels, §6 lifecycle, etc. — not just the sections cited above.
Re-verify against spec/version.json after each RELAY MINOR release.
RELAY spec v1.10 (release) adds §20 Continuous Conformance, making the CI process normative: conformance must be continuously proven, not just declared.
§20 requires, on every change, that CI gates on:
relay conform --strictagainst the built CLI (fail on FAIL or WARN).check(gate on ERROR), 100% requirement traceability (traced and tested), cybersecurity analysis, dependency vulnerability scan, and the tool qualification suite.relay interopbehavioural conformance (onceconvertexists) — EQUIVALENT for every golden vector.RELAY itself is the reference exemplar — its CI now runs the full go-FuSa lifecycle and passes every gate.
What go-LIN needs
No
relay conformCI gate yet (see #30) — add it (--strict). Expand to the full go-FuSa lifecycle (vuln, qualify, 100% trace). Addrelay interop, TARA, dFMEA, SBOM/provenance.This builds on the §13.7 architecture + spec-uplift issue already open. No changes are requested to RELAY. Verify with
relay conform --strict+ the full gofusa lifecycle locally.Definition of done — the entire current spec (v1.10)
This issue lists the §20 deltas, but the bar is the whole current RELAY spec — v1.10 (the latest release), not only §20, and not the "1.9" mentioned in the earlier §13.7 issue (now superseded). The implementation is conformant when:
version --format jsonreportsspec_version1.10 (trackspec/version.jsonin SoundMatt/RELAY);relay conform --strict <binary>passes — the full §12 / §17 document and behaviour surface;relay interopreports the implementation EQUIVALENT for every golden vector (§20.2), onceconvertis conformant;Re-verify against
spec/version.jsonafter each RELAY MINOR release.