Traceability: Making the Invisible Visible

15.1 The five-state coverage classification

Sylang Studio puts every artifact in your project into one of five coverage states. That classification is your principal triage view for review and audit. Here are the five states, what each one means, and the decision each one should trigger.

The five states

1. Isolated. Zero outgoing edges and zero incoming edges: the artifact is structurally disconnected from the rest of the project graph. Often it's a dead artifact left over from removed scope; sometimes it's isolated by design (a standalone reference document, an early-stage placeholder). Triage: remove the artifact if it's dead, or connect it if it belongs in the graph.
2. Orphan. It has outgoing edges (it points to other artifacts) but no incoming edges, so nothing references it. Often this means a missing inverse trace: the upstream artifact that should point at this one lacks its implementedby or enables edge. Sometimes the artifact is intentionally a top-level concern, such as a project-root product line. Triage: add the missing inverse edge, or accept the orphan status as intentional.
3. Sink. It has incoming edges (other artifacts reference it) but no outgoing edges, so it sits at the leaf of a trace chain. That's typical for test cases (no further artifact points at them), and also for certain safety mechanisms and low-level requirements. Sinks are usually intentional and rarely need triage.
4. Broken. It has outgoing edges, but some of them target identifiers that don't resolve to existing artifacts. This is always a bug. Triage: fix the reference by correcting the identifier, or remove it if the target was intentionally removed. The validator's diagnostic points you to the specific broken reference.
5. Connected. It has both outgoing and incoming edges, and every outgoing reference resolves. This is the healthy state, and most artifacts in a mature project are connected. The coverage report's headline metric is the connected fraction; as a rough illustration, a healthy production project might sit somewhere around 85 to 95%.

Triage order: worst first

The coverage report lists artifacts worst first: broken → orphan → sink → connected → isolated. That order reflects review priority. Broken artifacts are bugs that block the build, and orphans point to possibly missing inverse traces that hurt the safety case. Sinks are usually fine, connected artifacts need no triage, and isolated artifacts are typically dead and can be cleaned up at leisure.

In a Sylang project, the reviewer's daily routine is short. Open the coverage report, fix any new broken refs from overnight commits (usually a few minutes' work), look into any newly orphaned artifacts (usually a small architectural decision), and move on. That habit keeps the artifact graph clean as the project evolves. Contrast that with legacy MBSE projects, where graph drift builds up across the development cycle until a heroic late-cycle cleanup.

What follows

Subchapter 15.2 covers the inverse-pairs discipline that the coverage classification depends on. Subchapter 15.3 covers the safety-case coverage queries, 15.4 walks the insulin pump anchor's coverage report, and 15.5 covers per-variant coverage analysis.

15.2 Inverse pairs and the bilateral traceability discipline

The coverage classification of Subchapter 15.1 depends on an artifact graph that is well formed in both directions. Sylang's relationship vocabulary defines inverse pairs such as enables ↔ performs, decomposesto ↔ decomposedfrom and allocatedto ↔ implements (with satisfies on the test side and no inverse on the requirement side). Where a pair exists, authoring both ends keeps the graph navigable in both directions. This subchapter gives you the inverse-pairs catalog and the habits that keep it complete.

The inverse-pairs catalog

Five inverse pairs come up again and again across the engineering spine and the safety chain.

1. enables (function → feature) ↔ performs (feature → function). The feature-function bilateral. Projects with mature PLE practice author both sides, and the coverage analysis warns on single-sided pairs.
2. decomposesto / decomposedfrom (within .fun, .blk, .ifc). The hierarchy bilateral. Both sides are authored; the convention is universal.
3. allocatedto (function → block) ↔ implements (block → function). The function-architecture bilateral. It tends to be authored less consistently than the others, and it's easy to author only the architecture side.
4. derivedfrom (requirement → safetygoal) ↔ leadsto (safetygoal → requirement). The safety-chain bilateral. ISO 26262 explicitly calls for both sides as part of the safety case argument.
5. satisfies (testcase → requirement). Single-sided by design (Chapter 9 Subchapter 1 explains the rationale).

Beyond the five major pairs above, a few more show up in specific contexts, and the full catalog lives in the relationship validator source. Within FMEA there's causedby ↔ effects. For ASPICE there's implements (block → function in .blk) ↔ implementedby (function → requirement in .fun). And mitigates (safetygoal → hazard) has an implicit inverse: the hazard's malfunctionof identifies the function whose malfunction the goal mitigates.

The authoring discipline

Three practices keep bilateral authoring complete in production projects.

Practice 1: agent-authored bilaterals. AI agents working under the RequirementsEngineer, ArchitectureLead and SafetyManager roles author both ends of every relationship by default, and the skill files reinforce the convention. When agents author most of a project, complete bilaterals are the default outcome.

Practice 2: CI-gated bilateral completeness. A CI rule fails the build if any relationship is authored on one side without its inverse. The rule is strict and occasionally pedantic. It earns its keep by stopping single-sided traces from piling up for the coverage analysis to flag later.

Practice 3: periodic coverage-driven cleanup. Without the strict CI rule, check the coverage report's orphan category periodically (weekly or per sprint) and fix the orphans by adding inverse edges. That catches the drift before it grows beyond practical cleanup.

What follows

Subchapter 15.3 covers the safety-case coverage queries. Subchapter 15.4 walks the insulin pump anchor's coverage report, and 15.5 covers per-variant coverage analysis.

15.3 Safety-case coverage queries

The five-state classification of Subchapter 15.1 is general purpose. A safety case needs additional, more specific queries, derived from the work-product requirements of the regulatory standards. This subchapter covers the dozen most-used queries and the decision each one supports.

The dozen principal queries

1. Requirements with no verifying test. Every def requirement whose identifier appears in no def testcase's satisfies. These requirements are unverified, so the safety case can't claim verification coverage for them. Expect it to be the auditor's first question.
2. Test cases with no satisfied requirement. Every def testcase with no satisfies edge. The test exists, but nothing traces it to the requirement it was written to verify, so its scope rationale is undocumented.
3. Failed tests on safety-critical requirements. Every def testcase with testresult fail whose satisfies ref requirement targets an ASIL-D or SIL-3 requirement. These are open safety issues, and release readiness must address them.
4. Hazards without safety goals. Every def hazard not referenced by any def safetygoal's derivedfrom or mitigates. These hazards lack a defined mitigation strategy, so the HARA-to-goals derivation is incomplete.
5. Safety goals without mechanisms. Every def safetygoal with no satisfying def safetymechanism. These goals lack a concrete realization, so the goal-to-mechanism derivation is incomplete.
6. Functions not allocated to blocks. Every def function with no allocatedto ref block. These are orphan functions, and the function-to-architecture allocation is incomplete.
7. Blocks with no implemented functions. Every def block with no implements ref function. These architectural elements have no functional purpose, which is usually a sign of design churn (blocks added, then abandoned).
8. Features with no realizing functions. Every def feature with no performs ref function. These customer-facing features have no implementation: either an authoring gap or a marketing artifact that should be removed.
9. ASIL inheritance audits. Every def requirement whose safetylevel is lower than the safetylevel of any safety goal in its derivedfrom chain. These are ASIL violations in the derivation chain, and a common authoring error.
10. Single points of failure. Top events in any def faulttree with minimal cut sets of size 1. These are safety architecture deficiencies for ASIL-D / DAL-A items, and mitigation must be added.
11. High-RPN failure modes. Every def failuremode with RPN ≥ 100 or actionpriority high. These failure modes need design optimization under the AIAG-VDA methodology.
12. Stale sprint tasks. Every def task (in .spr) with issuestatus inprogress whose commit history shows no activity for more than 7 days. This is a project-management hygiene issue.

Implementation: the .spec / .dash route

You implement these queries as def table and def metric constructs in .spec and .dash files, with the source, where, groupby and orderby clauses doing the filtering and aggregation. Each query is typically a few lines. The EPB anchor's EpbSpec.spec and EpbDashboard.dash files in the companion repository implement half a dozen of them.

Thanks to the reactive-documentation infrastructure of Chapter 16, the queries re-materialize on every render. The answers reflect the current state of the artifact set, not a snapshot from whenever the report was last generated. The review report the auditor signs off on is the same document the development team reads every day. In conventional MBSE practice, those are two separate artifacts.

What follows

Subchapter 15.4 walks the insulin pump anchor's coverage report in detail. Subchapter 15.5 covers per-variant coverage analysis, which you'll need for any project with non-trivial variant configurations.

15.4 Insulin pump coverage report walkthrough

This subchapter walks the insulin pump anchor's coverage report as a safety reviewer might see it on the morning before a pre-submission audit. The scenario is an illustration, not a measured project, but it exercises the queries from Subchapter 15.3 against a realistic project state. For each issue, you'll see what surfaced and the decision it triggered.

The coverage report's structure

Sylang Studio's coverage report is a hierarchical view. At the top sit the headline metrics (total artifacts; broken, orphan, sink, connected and isolated counts). Below them come per-file-type breakdowns, and below those, per-artifact drill-downs with click-through to the source. You can sort the view and filter it by safety level, status and variant; a safety reviewer will typically filter to safetylevel SIL-3, status approved and sort by coverage state.

The morning's report

The reviewer opens the report. The headline figures: 145 artifacts in total, with 132 connected (91%), 8 sink (5.5%), 3 orphan (2%), 2 broken (1.5%) and 0 isolated. The connected fraction is acceptable, but the orphans and the broken artifacts need attention.

The two broken artifacts top the triage. The first is REQ_INS_007, a requirement whose derivedfrom ref safetygoal SG_NoFalseAlarm points at a safety goal that exists in no .sgl file. It turns out SG_NoFalseAlarm was renamed to SG_NoSpuriousAlarm in last week's sprint, and the requirement's reference was never updated. The fix is a one-line edit to the requirement: five minutes of work.

The second broken artifact is TC_INS_AIR_DETECT, a test case whose satisfies ref requirement REQ_INS_AIR_005 targets a deprecated requirement. The deprecation was correct, so the test case should be deprecated too. The fix: change the test case's status to deprecated and remove the broken satisfies. Two minutes of work.

The three orphans need more thought, starting with REQ_INS_022, which has no inverse trace from any test case through satisfies. The requirement is brand new (committed yesterday), and nobody has authored its test case yet. Decision: file a task in the next sprint for the TestEngineer agent to author the verifying test case. The fix is a one-line task addition to the active sprint.

The second orphan is a hazard, HAZ_INS_SHOCK_DAMAGE (a hardware-shock-induced failure mode). It was added during the recent revisit of the durability analysis, and no safety goal has been authored to mitigate it. Decision: the SafetyManager agent should author the corresponding goal in the next sprint.

The third orphan is a feature, F_INS_CUSTOM_REMINDERS, with no realizing function. It was a marketing addition for the latest variant proposal, and no engineering content has been committed yet. Decision: the FeaturePlatformLead agent should either author the realizing functions or, if the feature is no longer in scope, mark it deprecated. The fix is a task added to the sprint.

The audit-readiness conclusion

In this scenario, the reviewer closes the report after about fifteen minutes of triage. Two broken refs are fixed, and three orphans have follow-up tasks assigned. The connected fraction should be around 93% by tomorrow's morning report, and the pre-submission audit is on schedule.

That's the difference between Sylang's continuous-coverage approach and the conventional MBSE practice of late-cycle artifact reconciliation. In a conventional tool, these issues would pile up through the development cycle and get addressed in the weeks before submission, a substantial and error-prone effort. In Sylang, you address them daily, in fifteen-minute increments. Audit readiness becomes the project's continuous condition, not a one-time push.

What follows

Subchapter 15.5 covers per-variant coverage analysis, the chapter's final coverage topic and one you'll need for any project with non-trivial variant configurations.

15.5 Per-variant coverage and the closing of Part IV

If your project ships multiple variants, you face a coverage problem that single-variant projects never see. The aggregate report mixes active and inactive artifacts across variants, so its numbers don't correspond to any one variant's release readiness. Per-variant coverage solves this by scoping the analysis to the artifacts active in one variant at a time. This subchapter covers the technique and closes Part IV.

The aggregate-coverage problem

Consider the EPB anchor's single-motor and dual-motor variants. The dual-motor variant adds functions (MotorCrosscheck, DualMotorDriver), requirements (REQ_EPB_003, motor cross-check) and tests (TC_EPB_MOTOR_MISMATCH). The single-motor variant has none of these; in that variant, those artifacts are inactive.

The aggregate report includes every artifact and asks: of the 80 requirements in the project, how many are verified? Say the answer is 75 of 80 (94%), and the dual-motor requirement REQ_EPB_003 is among the 5 unverified. In the single-motor variant, REQ_EPB_003 doesn't apply at all. That variant's true coverage might be 100%, or it might be 89% if 4 of its own requirements are unverified, and the aggregate can't tell you which.

Per-variant coverage asks the right question. For the single-motor variant, what is the coverage fraction scoped to the artifacts active in the single-motor variant? And, separately, for the dual-motor variant?

The technique

Per-variant coverage takes three steps. Load the .vcf for the variant you care about. Filter the artifact graph to the artifacts whose when ref config clauses that .vcf satisfies, then run the coverage analysis on the filtered graph. In Sylang Studio, the coverage report's Variant dropdown drives the whole workflow: select a variant and the entire report re-scopes to that variant's active artifacts.

Sylang Studio makes this straightforward, since the variant filter is a UI control over a graph traversal. In a conventional MBSE tool, the same workflow needs substantial custom scripting. That makes it tempting to skip per-variant analysis entirely and live with the imprecision of aggregate-only coverage.

Per-variant release readiness

Each shipping variant has its own release readiness, because the safety case argument is variant-specific. A program with three shipping variants has three safety cases, three audit reviews and three release-readiness decisions. Per-variant coverage is the foundation for each of them.

For a given variant, the program manager's release-readiness review pulls the per-variant coverage report and addresses any orphans, broken refs or sinks specific to that variant. The reviews run in parallel across variants. Many artifacts are shared (the safety chain, the FMEA, the requirements common to all variants), and the variant-specific artifacts are reviewed once per variant.

Closing Chapter 15

You now have the cross-cutting traceability and coverage tooling. We covered the five-state classification (15.1), the inverse-pairs discipline (15.2), the safety-case queries (15.3), the insulin pump walkthrough (15.4) and per-variant coverage (this subchapter). The coverage report is your principal interface for daily review and audit readiness alike. Master it, and Sylang stops being just a tool and becomes the operational substrate for your safety case.

Chapter 16 covers the reactive-documentation file types (.spec and .dash) that produce the safety case and the program-management reports from the underlying artifact set. It is the chapter that makes up Part V.

Exercises (Chapter 15)