Feed FaraSYS a specification. It builds the requirement set a program can actually stand on: audited for holes, quantified with typed parameters, allocated across disciplines, and published as versioned baselines the design tools consume. Everything downstream traces back here.
Hierarchy on the left, requirements as rows, status you can see from across the room. If you've used a modern issue tracker, you already know how to drive it.
Representative UI — the shipping product shares its shell with FaraEDA, shown in a real screenshot here.
Every spec has holes. Most tools paper over them; most AIs invent something plausible to fill them. FaraSYS raises a Missing-Information Request: a specific question, tied to the requirements that need the answer, waiting for a human. The answer gets recorded with its provenance and flows to everything downstream.
“About 24 volts” is not a requirement. Every quantity in a FaraSYS baseline is a typed parameter: value, unit, bound, tolerance, and — the part auditors love — where the number came from. Spec, human answer, or documented default. Open values are explicit TBDs the tools treat as data, so nothing downstream has to parse a sentence to find a voltage.
FaraSYS publishes numbered, immutable baselines, and every downstream tool pins the version it built against. When the design side hits something the requirements didn't anticipate — a discovered requirement, an infeasible ask, a plain question — it files a change request upstream. A human dispositions it. The decision ships in the next baseline, on the record.
Requirement quality is checked in rings: deterministic lint first (the INCOSE-style rules a machine can enforce), computed checks over the typed parameters second, and only then model judgment — per item, against named rules, never as a rubber stamp. The verified flag itself is written by a deterministic gate. No model touches it. No exceptions.
Requirement specs, trace matrices, and verification reports aren't documents someone maintains — they're views generated from the same data the tools work on. Standards-grade structure, docx and ReqIF out, always current because there's nothing to keep in sync.
FaraSYS publishes the hardware baseline to FaraEDA and the software baseline to FaraSW through the same versioned contract. Design disclosures, change requests, and test evidence flow back up, and FaraSYS renders the whole picture: one trace from a system requirement to the board that carries it and the firmware that runs on it.