Capability is abundant. Trust is scarce.
Two years ago, the open question in engineering organizations was whether AI could do the work at all — draft a requirement, trace an implementation to its specification, summarise a design review. That question is settled. A capable model does all three in seconds, and the next model does them better. Capability has stopped being the scarce resource.
Trust has not. In consumer software, an AI that is occasionally wrong is an inconvenience; you regenerate and move on. In the domains we serve — aerospace, automotive, medical devices, industrial systems — engineering output must be defended: in a design review, in front of a certification authority, sometimes in court. In that setting, an answer nobody can reproduce is not an asset regardless of its quality. And a fluent, confident, unverifiable answer is something worse than useless: a liability with good grammar.
This is the actual bottleneck for AI-assisted engineering in critical domains. Organizations want the speed; they cannot accept opinions in their evidence chain. Most tools offering the speed have not noticed the difference.
Three collisions
The failure modes are structural, not incidental. Three properties of generative systems collide head-on with three requirements of regulated engineering.
Regulated engineering requires reproducibility — the same question must return the same answer twice, because an assessor will ask twice. Generative output varies between runs by design.
It requires provenance — every claim must trace to the artifacts and rules that produced it. A model can assert, fluently; it cannot cite what it computed from, because it did not compute.
And it requires accountability — a named human answers for every engineering decision. Autonomy diffuses responsibility at exactly the point where certification concentrates it.
None of this indicts the models. These are inherent properties of statistical generation — and they are precisely the properties an audit exists to refuse. Which means the fix is not a better model, a longer context window, or a stricter prompt. The fix is an architecture around the model.
The harness
Engineering already has the right word for this situation. A safety harness does not keep the climber off the tower — it is the reason work at height is possible at all. A wiring harness does not reduce electrical capability — it is what turns a drawer of loose wires into a system that can be installed, tested and certified. A horse in harness is not a diminished horse; it is the only configuration in which that power moves a load in a chosen direction.
In every case the harness is the difference between capability and chaos: power made usable, without surrendering control. That is the operating model we believe AI-assisted engineering needs, and it is what we mean by the Engineering AI Harness — a set of structural controls under which AI participates in engineering work while the properties that make output defensible are preserved by the architecture itself, not by a policy document asking everyone to be careful.
Six principles, each with a mechanism
A harness that lives in a slide deck is not a harness. Each principle has to be enforced by something that runs. AI proposes, humans decide: anything a model produces is marked as a candidate, and a human act — not a timeout, not a default — turns a candidate into engineering fact. Trust requires evidence: any conclusion offered for an audit must regenerate byte-identically from a named repository state; if it cannot, it is an opinion. Governance over autonomy: changes enter engineering memory through reviewed, gated steps, never through an autonomous write. Explainability by construction: every finding cites the artifacts, the rule and the commit behind it, so "why does it say that?" has a mechanical answer. Safety is contextual: the rigour applied to an item scales with its criticality, and a check that stands down at a lower band is shown as stood down, never silently dropped. And decisions must be reproducible: evidence is computed from a pinned state of the repository, not assembled by hand and defended from memory.
Notice what these principles have in common: none of them can be retrofitted. A product built generation-first can add disclaimers; it cannot add provenance, because provenance is a property of how answers are produced, decided at the first line of code.
What this looks like built
Sanad, our requirements and engineering governance platform, is built on these principles — and we have been deliberate about the order of construction.
What exists today is the deterministic foundation: a compiler that turns requirements in Git into a typed traceability graph; analysis engines that answer the same question the same way on any machine; findings that cite their rule, their artifacts and their commit; criticality bands that scale rigour to risk; compiled rule packs; human approval gates; an EARS pattern engine; guided setup; and — the piece certification programmes ask for first — an audit-ready traceability report, generated in Markdown, HTML and CSV, carrying its own configuration identity and regenerating byte-identically from the commit it names.
Note what is absent from that list: generative AI. That is deliberate. The harness exists and is load-bearing before AI is invited into it.
The honest roadmap
AI participation capabilities are under development within the Engineering AI Harness architecture: an assistant that turns an engineer's question into governed queries over the compiled graph, so facts come from the graph and reasoning from the model — never the reverse; implementation mapping that proposes ranked, rationale-carrying links between requirements and code, which become facts only when an engineer confirms them; pattern assistance that suggests the best-fitting requirement pattern and shows every rewrite as a diff the author accepts. Each arrives inside the controls described above: marked as proposals, excluded from evidence, closed by a human decision.
We could have shipped the generative features first — the market rewards it, for a while. We built the governance foundation first, because in our domains the second question after "can it do this?" is "can you prove it?" — and that question is unanswerable retroactively.
AI will enter engineering either governed or ungoverned; there is no third option, because it is already entering. The harness is how it enters governed — with its capability intact, and with the engineer still the author of record.