Early access · all three products

Requirements in.
Evidence out.

Fara is three engineering tools that share one trace spine. FaraSYS holds the requirements. FaraEDA designs the board. FaraSW writes the firmware. Nothing in the chain gets called verified because an AI said so — a check ran, or it isn't.

Request early access → Meet the family
One trace spine  ·  system requirements → board + firmware  ·  evidence at every tier
FaraSYS requirements · baselines baselines ↓ baselines ↓ ↑ evidence · CRs FaraEDA the board · schematic · layout FaraSW the firmware · code · tests same system requirements · the traces meet at the top
one versioned contract · no shared database · every artifact schema-checked
A real screenshot

This is the actual product, mid-design.

Not a concept render. FaraEDA working the TC5 tool-carousel controller: twenty function blocks, the block diagram half-wired, and the header telling the truth about it.

TC5 carousel · block diagram · FaraSYS baseline v1 pinned real screenshot
FaraEDA screenshot: block diagram of the TC5 carousel controller with 20 function blocks, a header reading 405 blocking cards and 17/44 verified, and the Synthesis Coach explaining a duplicate-block merge card.

Look at the header. 405 blocking · 17/44 verified · synthesis incomplete. The engine knows this design isn't done, says so, and lists exactly what stands in the way. On the right, the Synthesis Coach is talking an engineer out of blanket-merging three transceivers that only share a name. We think a design tool that refuses to pretend is worth more than one that always says yes.

The family

Three tools. One spine.

Each one stands on its own. Together they cover the V: intent at the top, a board and firmware below, and evidence flowing back up to the requirements that asked for it.

FaraSYS

early access

The system tier. Feed it a specification and it builds the requirement set: audited for holes and ambiguity, quantified with typed parameters instead of prose numbers, allocated to hardware and software, and published as versioned baselines the design tools consume. When it finds a gap it asks you a question. It does not fill the gap with a guess.

Explore FaraSYS →
FaraSYSTC5 carousel baseline v3 37/44 verified 2 MIRs open
Project
Specs
Requirements
Allocation
Baselines
Audit
Documents
TC5-SYS-REQ-005Tool presence shall be sensed on all 7 pocketsverified
TC5-HW-REQ-12Sensor input divider, 24 V domainHW24 V nomverified
TC5-SW-REQ-1Poll all 7 channels at 100 Hz, debounce 3 samplesSW100 Hz minTest
TC5-SYS-REQ-011Carousel shall index within [TBD] secondsMIR-31 open
Missing information request · MIR-31
What is the maximum allowed index-to-index time? The spec gives a spindle dwell but no carousel figure. Used by 2 downstream requirements.
Answer… (a human answers — the tool never invents this number)

FaraEDA

early access

The board. It takes the hardware baseline and works like an engineer: partition into functions, define each circuit in words before wires, select real parts from a grounded catalog, wire the connective tissue, and run ERC as it goes. Every move lands as a reviewable card with a reason. You approve; it never just does.

Explore FaraEDA →
FaraEDA block-diagram canvas, cropped view

FaraSW

early access

The firmware. It decomposes the software baseline into low-level requirements, drafts the design description, and then writes code where your engineers already work — in the IDE, with an AI pane beside the editor. The trace rides in the source. Tests run before merges. A requirement counts as verified when its tests executed and passed at the coverage your assurance level demands, measured by tooling. Not before.

Explore FaraSW →
tool_presence.c — tc5-carousel-fw
implements TC5-SW-LLR-3 host ✓ · MC/DC 87%
/* @implements TC5-SW-LLR-3 */
void debounce_update(uint8_t ch, bool raw) {
  shift_reg[ch] = ((shift_reg[ch] << 1) | raw) & 0x07;
}
static void motor_tune_experiment(void) { … }
untraced function — no requirement asks for this. It can't merge.
FaraSW panel
TC5-SW-LLR-3

Maintain a 3-deep sample register per channel; report a change only on 3 identical samples.

Derived LLR (proposed)

Sampling task priority above RS-485 service, to hold the 100 Hz deadline.

ApproveEdit
How they talk

A contract, not a shared database.

The products exchange versioned, schema-checked artifacts. That's the whole interface. It means each tool stands alone, and it means a requirement change upstream marks exactly the affected work stale downstream — not the whole project.

Down: what design consumes

baselineRequirements with typed parameters — values, units, bounds, and where each number came from.
change docDeltas between baselines, so a re-run touches only what changed.
dispositionsAnswers to every change request the design tools filed.
baselines ↓evidence ↑

Up: what design owes back

disclosureThe design itself — board elements or the software design description — traced to the requirements it refines.
CRsDiscovered requirements, infeasible asks, and honest questions, routed upstream as first-class objects.
evidenceCheck and test results, stamped with the environment they ran in. Host, simulated, and on-target are different things and stay that way.
Engineering posture

Rules the tools can't break.

These aren't values statements. Each one is enforced in the architecture, and we've bled for every one of them.

No model ever sets “verified.”

In every Fara product, verified status is written by a deterministic gate fed by checks that ran — electrical rules, computed conformance, executed tests with measured coverage. An AI can propose all day. It cannot certify anything, including its own work. Neither can a human's say-so, for that matter.

The calculator outranks the model.

Any value derivable by formula is computed by code — divider ratios, regulator headroom, trace widths, coverage percentages. A model's arithmetic lands as unverified until a real computation passes it. We built this rule after watching a language model pick a 20 V regulator for a 24 V rail. Twice.

Empty is an answer.

When a generator has nothing grounded to say, it returns nothing and raises its hand — a missing-information request, a library gap, an honest open question. A tool that fills silence with invented content is worse than no tool.

Every change has an author and a reason.

Agent or human, every mutation is a typed, attributed entry in an immutable history. For regulated work that trail is your configuration-management evidence. For everyone else it's the answer to “wait, why is R7 different?”

Your designs are not our training data.

Schematics, netlists, requirements, firmware — never used to train any model. Stated plainly here, in the contract, and on the security page.

One project, the whole V

We build with our own tools first.

Every Fara product is built and tested against the same golden project: TC5, a seven-pocket tool-carousel controller for a CNC machine. It isn't a toy. It has 44 hardware requirements, a stepper axis, RS-485 comms, 24 V sensing into a 3.3 V microcontroller, and firmware with real deadlines.

FaraSYS turned its specification into audited, quantified requirements and asked the questions the spec forgot to answer. FaraEDA is designing the board from the hardware baseline. FaraSW implements the firmware from the software baseline — and the firmware's 100 Hz debounce requirement literally cites the board's input-divider design in its rationale, because the two sides of the V share one spine.

When a competitor shows you a demo, ask them to show you the trace from a line of firmware to the system requirement that justifies it, through the board that carries it. That picture is the product.

TC5 carousel · the project every Fara release has to survive
For regulated teams

Certifiable, not certified.

Fara ships evidence-shaped artifacts from day one: trace matrices, verification records, coverage reports, documents your auditor recognizes. You own certification and decide when to pursue it — there's no qualification bill hiding in the price. And if you're building a robotics prototype, all of this stays out of your way until you want it.

DO-254 · airborne hardware DO-178C · airborne software ISO 26262 · automotive IEC 60601 / 62304 · medical

How the trace spine maps to design assurance →

Early access

We're onboarding design partners.

All three products are in early access, running real projects. Partners get the products free during the program, a direct line to the engineers building them, and a real say in what gets built next. In exchange we want your hard problems and your honest complaints. The pricing page shows what we plan to charge at launch, so there are no surprises later.

Request early access → Email the team
FAQ

Questions engineers actually ask.

Do I need all three products?+
No. Each stands alone — the interface between them is a versioned contract, not a shared database, so you can run FaraEDA without FaraSYS, or FaraSYS with your existing design flow. The spine pays off most when requirements and at least one design tool are both on it.
Does FaraEDA replace KiCad or Altium?+
No. You design in FaraEDA, then export clean projects to KiCad, Altium, or Cadence, plus Gerber, ODB++, and IPC-2581. Same posture for FaraSW: it works inside VS Code with your own toolchain, not instead of it.
Can the AI change my design without my approval?+
No. Every proposed change arrives as a reviewable card with a reason, and you accept, reject, or edit it. Deeper than that: no model can set verified status on anything, anywhere in the family. That gate is deterministic and it's fed only by checks that actually ran.
Is my design data used to train models?+
Never. Requirements, schematics, netlists, BOMs, and firmware are never used to train any model. Details on the security page.
What does “early access” actually mean?+
The products run and are used on real projects daily, including our own. You should expect rough edges, fast fixes, and engineers answering your tickets personally. Early-access partners use Fara free during the program.
Are the products certified for DO-254 / DO-178C work?+
Fara's posture is certifiable, not certified: the outputs are evidence-shaped from day one, and the architecture keeps AI out of the verification chain so there's a clean story for tool qualification — which you own, when and if a program needs it. We'll help; we don't pretend it's already done.

Put your next project on the spine.

Requirements, board, and firmware — with the receipts to prove they agree.

Request early access → Start with the requirements