For hardware test & systems teams
Requirements and test data, linked at agent speed.
Tensol ties each requirement to the test case, run, and channel that verifies it - and when anything changes, traces what it broke: stale evidence flagged, coverage recomputed, re-runs queued. No status fields. No spreadsheet before the review.
Every requirement in Project Kestrel, rolled up by the subsystem it constrains — computed from 61 runs across 4 benches, not from a field anyone maintains by hand.
Built by founders & operators from
1 week
before every gate
The week before every design review: rebuilding the “which requirements did we actually verify” spreadsheet by hand.
1 day
per failed run
A test fails Friday. Monday is spent digging through logs on three rig PCs to find when it started.
3 formats
before you can start
NI on one bench, UEI DAQ on another, .csv from a third — every debug starts with format archaeology.
Requirements in from your ALM. Traces in from your benches. Coverage out, by subsystem.
- 01
Requirements, with their hierarchy intact
Import from Polarion, DOORS, Jama, ReqIF, or CSV. The hierarchy comes with them, so a requirement still knows which subsystem it constrains and which parent it decomposes from.
- 02
Tests and traces, from any bench
Whatever your benches already write —
.mf4,.tdms, ROS bags,.csv, ULog — or live CAN. Each run is matched to the test case it executed and the requirement that case verifies, down to the channel. - 03
Coverage by subsystem, kept current
Every run re-checks the limits and the rollup moves with it — per requirement, per component, per program. A failure stands on its own; a pass queues for sign-off, and the approver's name travels with the evidence. Change a requirement and the affected sign-offs flag stale.
Follow one requirement all the way to the channel.
The chain at the foot of the board, expanded. Subsystem, requirement, the boundary it is tested within, test case, the run and the rig level it was entitled to use, channel, cause — every coverage figure on this site resolves to one of these, and nothing is asserted that you cannot open.
Every change, traced to what it touches.
Precharge shall complete within 250 ms → 200 ms of power-on.
m.reyes · 2026-08-24 09:14
1 line changed · no other edits
Nobody filed a ticket. Nobody told the test team. The requirement simply says something different now.
One line changes
A limit tightens by 50 ms in the requirements tool. On its own, that edit tells no one anything.
The limit moved down. Every child that inherits it is unproven again, and any case asserting 250 is now asserting the wrong thing.
Five of six children inherit the tightened limit. Two cases assert the old value and must be re-authored.
The agent walks what it touches
Down the decomposition, across the test cases, back through every run already on disk, re-scored against the value that just changed.
Sub-components affected
The blast radius, itemised
What lost its evidence, which sign-offs went stale, which sub-components are in scope - and, just as usefully, which are not.