Close the loop

Traceability

One dashboard that answers the question every test-engineering review circles around: does the whole chain still agree? Requirement to test, test to board net, net to routed copper, program limit to the limit each lot actually ran — every hop joined deterministically, every disagreement attributed to the pillar that owns it.

01

Overview

The traceability dashboard is the one surface where all four pillars of a test project meet. It is not a report generator — it recomputes its verdicts from the live artefacts on every load, so it is incapable of showing a stale green.

Traceability dashboard header and closed-loop chain
Fig. 1 — The TMP126 project: 4 joins · 4 pass, 34/34 tests traced end to end, one production-marginal test surfaced with its Cpk.

No LLM sits anywhere in this pipeline. Each join is a pure function over the stored artefacts — the same engines the chat assistant calls when asked to review compliance, so the dashboard and the conversation can never disagree with each other.

02

The joins

Four deterministic joins, each with a named key. Names are allowed to drift between artefacts; the keys are not.

JoinKeyWhat it catches
Spec ↔ Program test_number Coverage gaps (a requirement no test implements) and limit drift — a program limit looser than the datasheet is a compliance error, attributed to the pillar that owns each number.
Program ↔ Board pin / channel A program that drives a pin the board does not route, a board pin no test uses, a power rail mapped to a digital channel.
Schematic ↔ Copper net names The layout binding ties each schematic net to its routed traces — so a requirement can be followed onto physical copper, including tester-side series-termination and Kelvin nets, disclosed as such.
Program ↔ Production PTR test number The limits a lot actually ran versus the limits the program has now — historical drift is reported as drift, never mislabelled as a spec violation.
REQ-011 T1203 tfSioVoh SIO + SIO_T · 33R 6 traces routed copper Cpk 1.66 lot TMP126-L04 test_number pin attribution layout binding PTR join one chain row — the dashboard renders one of these for every test in the program
Fig. 2 — A single closed-loop chain row: requirement REQ-011 (SIO output high) followed to its lot statistics.
03

How it works

  1. Assemble the pillars.

    Requirements come from the ingested spec; program limits from the workbook's Limits sheet (the live open copy when one is connected, and the dashboard labels which copy it reviewed); board nets from the canonical circuit model; lot limits from parsed STDF. All values normalise to SI before comparison, so 65 uA and 65e-6 A reconcile as equal.

  2. Reconcile every hop.

    Limits, forced conditions, pin/channel bindings and net coverage each get their own reconcile engine. Attribution is the point: on real customer data the three limit sources legitimately differ, and the difference between "the lot ran at a recorded limit" and "the program violates the spec" is the difference between a finding and a false alarm.

  3. Build the chain.

    Coverage, board-sync, drift and layout joins compose into one row per test: spec → program → nets → copper trace count → lot Cpk, with debug suspects ranked for any marginal test.

  4. Degrade honestly.

    A pillar that is missing does not fail silently — the join renders as awaiting data with the action that unlocks it (sync a repo, save a channel plan, ingest a lot). An empty chart is never dressed up as a passing one.

Traceability dashboard with the closed-loop chain rows
Fig. 3 — Detail from the same dashboard (Fig. 1): each test's hops render as linked pills; the production hop carries the lot's Cpk and this board's likely debug suspects.
04

Requirement → copper

The chain does not stop at the netlist. Select a requirement in the PCB Designer and its nets — including the tester-side series-termination and Kelvin force/sense extensions, disclosed as such — light up on the routed board inside the same render pass, so the highlight is exactly aligned with the copper by construction.

Requirement dropdown with REQ-014 selected and its traces highlighted amber on the routed board
Fig. 4 — The Highlight-requirement dropdown with REQ-014 (Device ID read) selected: the chip below it names the requirement's 11 nets, and their 36 routed traces render as an amber overlay on the TMP126 load board.
05

On the TMP126 demo

The demo project closes the loop completely: 34 of 34 tests trace spec → program → copper → production, all four joins pass, and the dashboard surfaces two things worth pausing on in a customer conversation:

A real marginal test. Final-test lot TMP126-L04 shows test 1100 (active supply current) at Cpk 0.27 — drifting across four lots while wafer sort stays healthy. The production hop names the likely board-side suspects (U1, R2, R9) from the test-impact analysis, which is exactly the first question a product engineer asks.

A documented divergence, not a hidden one. The SIO output-high and output-low tests measure at the tester, behind a 33 Ω series termination carrying 3 mA — a 99 mV drop. The program limits are compensated accordingly and the requirement's test method documents the arithmetic, so the reconcile reports an info-class documented measurement-path compensation rather than a compliance error. An undocumented looser-than-spec limit still reports as the error it is.

Honest boundary Offline verdicts are labelled offline. The dashboard's reconciles prove consistency between the artefacts; final compile authority for the program remains the IG-XL toolchain, and the platform never reports offline-green as tool-verified.