FaraSW takes the software baseline and produces what a serious program actually needs: low-level requirements, a design description, code that carries its own trace, and tests whose executed results back every claim. Your engineers keep their editor. The evidence takes care of itself.
No new editor to adopt. FaraSW ships as an extension beside an AI coding pane in VS Code (Eclipse next): the requirement follows your cursor, the trace state sits above every function, and approvals happen in a panel — not in a chat scrollback.
Wrote the test first (@verifies TC5-SW-LLR-3), then the debounce. Preflight passes on host.
One flag: holding the 100 Hz deadline needs this task above the RS-485 service task. That's a derived requirement — it's not in the baseline. Draft it?
3-deep sample register per channel; report a change only on 3 identical consecutive samples.
Sampling task priority above RS-485 service. Files a CR upstream.
The AI drafts. The panel decides. The test runner proves. Three different jobs, deliberately kept apart.
A requirement is verified when its traced tests actually executed and passed, with the structural coverage your assurance level demands — MC/DC for the highest — measured by tooling. Not when a model says the code looks right. Not when an engineer says they tested it. The gate is deterministic and nobody, carbon or silicon, gets to talk it into anything.
| DAL A | MC/DC coverage, measured | |
| DAL B | decision coverage, measured | |
| DAL C | statement coverage, measured | |
| a coverage claim above the toolchain's measured capability is refused, not estimated | ||
Every function carries a trace anchor to the low-level requirement it implements, and the merge gate refuses untraced code outright. An engineer with a better idea doesn't lose the idea — they route it: a derived requirement, reviewed and filed upstream as a change request, then the code. How to implement stays the engineer's call. What the software does belongs to the requirements.
Passing on your laptop is not passing on the processor. Every piece of evidence is stamped with the rung it ran on — host, simulated (QEMU or VxSim class), or the real target — and the rungs never substitute for each other. Your release gate decides which rung each branch must clear. For TC5, the target rung is the very board FaraEDA designed.
The trace matrix — system requirement to software requirement to low-level requirement to code to test to coverage — is generated, not maintained. Derived requirements route to your safety process the way the standard expects. And because no model ever sets a verification status, the tool-qualification story stays clean: the deterministic verification chain is what a program qualifies, and already-qualified coverage tools can slot in as the measuring oracle. Certifiable, not certified — you own the certificate, we make the evidence cheap.
FaraSW builds against the software baseline FaraSYS publishes, and discloses its design description, code manifest, and test evidence back up the same contract. On the golden project, the firmware's timing requirements cite the input stage of the board FaraEDA designed — one spine, both legs, traces meeting at the system requirements.