Sovereign silicon · Chip design and EDA
The AI layer across your design flow should not live in someone else's cloud.
A requirement change in silicon pulls on four things at once: the requirement, the IP record, the generated RTL and the results. Each holds one kind of truth, and together they are the most sensitive material a chip company owns. NGARi runs the agent layer that keeps that thread linked — on hardware you own, with no outbound calls.
What actually crosses the wire
An orchestration layer that reads across a design flow has to read the flow. When that layer is a hosted service, the requirement text, the IP dependency records, the RTL and the commit history all travel to somebody else's infrastructure and sit under somebody else's terms. For most industries that is a policy question. For silicon it is the asset.
The requirement
What you are building and why, in the customer's own words — including the constraints that were negotiated rather than written down.
The IP record
Which block contains what, and what depends on it. This is the map of everything the company has spent years building.
The source and the results
The RTL, the constraints, and the power, performance and area reports that prove a change was actually met.
If your AI layer reads it, your AI layer holds it. The only version of this that a security review can approve without an argument is the one that never leaves the building.
Where the layer sits
NGARi does not replace a single tool in your flow. It is the layer above them: agents that call tools you authorize, on a machine you own, and a record of everything they did.
| Stage of the thread | What you already run | What NGARi adds |
|---|---|---|
| Requirement | Your requirements and traceability system | An agent that reads the current revision through a tool you authorize |
| Impact | Your IP and dependency records | A written plan laid out before it acts — and a log of every read |
| Design generation | Your generators, scripts and models | Generation driven from your own machine, inside a sandbox |
| Verification | Your sign-off flows and golden models | Results linked back to the requirement they are meant to satisfy |
| Evidence | Tickets, mail threads and slides | One hash-chained ledger: requirement to change to block to commit to result |
The thread is the product. Any tool can pass its own checks while the program still carries risk that no single tool was asked to look for.
What runs today, and what a pilot adds
This is the honest split, because a chip program cannot afford to discover it during an evaluation.
| Capability | Where it stands |
|---|---|
| On-premises inference and agent runtime, Apache 2.0 | Runs today |
| Sandboxed tool execution against an allow-list | Runs today |
| Hash-chained audit of every agent action | Runs today |
| Bring your own model and weights | Runs today |
| Read connectors into a named requirements or IP system | Pilot scope — scoped and tested with you |
| Driving a named EDA flow end to end | Pilot scope — your CAD team stays in charge |
| Physical design, place and route, sign-off | Not our job — we do not replace it |
| Frontier-scale model quality on the appliance | Not claimed — local models are smaller |
We would rather show you this table than a logo wall. The left column is what we can demonstrate this week; the pilot column is what we build with you against your own flow.
The evidence chain is the product
A change that cannot be reconstructed a year later is a change nobody can defend. Every action the layer takes is written to a hash-chained ledger that stays on your premises, so the answer to "how did this requirement get met?" is a query, not a meeting.
- Requirementthe revision that started the change, with its version difference
- Changewhat was asked for, by whom, and when it was accepted
- Blockwhich IP records the change touches, and what depended on them
- Committhe exact source revision that carries the new behaviour
- Resultthe evidence that the requirement was met, linked to all of the above
Each run is pinned by a run index as well as a chain, so a record cannot be quietly rewritten after the fact: editing an entry breaks the chain at that point, and rewriting the whole chain breaks the index that recorded its fingerprint. The ledger is a property of the deployment, not a promise from a vendor — it survives the people who were in the room.
How it runs
Free kernel, or a flashed appliance
The NS-BOS Kernel is Apache 2.0 and free: it orchestrates inference, runs the agent lifecycle, encrypts data at rest, keeps the hash-chained audit trail, and sandboxes agent actions. It is Linux, Python 3.10+, and you supply the model. If you would rather not run a Python environment, NGARi+ is the same stack pre-flashed and verified on NVIDIA Jetson.
Power, not connectivity
The appliance is designed to run with no path to the internet, and the kernel sends no telemetry and makes no outbound calls. That is what makes it usable for design data: it can sit in the room where the work already happens, next to the compute you already own.
| NGARi+ Nano | $999 · Jetson Orin Nano Super, 8 GB |
| NGARi+ Orin | $4,999 · AGX Orin 64 GB, 275 TOPS |
| NGARi+ Thor | $8,999 · AGX Thor 128 GB, 2,070 TFLOPS |
What we will not claim
- We do not connect to a system we have not scoped and tested. If a connector does not exist yet, we say so and it becomes pilot work.
- We do not replace your EDA tools or your CAD team. The flow stays yours; the layer around it is ours.
- We do not claim parity with frontier hosted models. A local model is smaller. For orchestrating a flow and linking evidence, it is enough — and we will show you where it is not.
- We do not hold certifications we have not stated. SOC 2 Type I readiness is in progress; we show the current state rather than a report we do not have.
- We do not touch export-controlled or classified technical data until the facility and personnel clearances are in place.
- We do not ask you to send us your design data to evaluate this. The evaluation happens on your premises, or it does not happen.
Questions from this room
Do you integrate with OpenROAD?
No, and you do not need us to. OpenROAD is a flow you run; NGARi is the agent and evidence layer around it. A pilot can drive a real OpenROAD step from a tool you authorize — Tcl generation, log triage, iteration — without changing OpenROAD itself. The step records whether the engine actually ran: if there is no OpenROAD on the machine, we say so rather than showing you a result.
Do you connect to requirements or IP tools like Jama or Glide today?
Not out of the box, and we will not pretend otherwise. The kernel supports sandboxed tool execution and agent workflows today; a named connector into your requirements or IP system is scoped, built and tested with you as part of a pilot.
Does anything leave the machine?
No outbound calls, no telemetry, no licence check. You can verify that by reading the kernel or by running it with the network down. There is no account to create.
Can it run with no network at all?
That is the intended deployment. The kernel is built to work air-gapped, and the appliance needs power, not connectivity.
Is a local model good enough for this work?
For orchestration, tool calling, log analysis and keeping the evidence linked: yes. For matching a frontier hosted model on open-ended design judgement: no, and we will say so in the room. The point of sovereignty is that the trade is yours to make, not that it does not exist.
What does a pilot look like?
Four to six weeks, one flow, one realistic requirement change, on your premises or a machine we leave with you. You get the working loop, the ledger for it, and a written account of what the layer did and did not catch.
Start with one requirement change.
Bring us a change your team has already handled by hand. We will run it through the sovereign layer, on your premises, and show you the ledger — or tell you plainly that it is not a fit yet.