Ask a language model the same question twice

For a concrete check on the design basis, read scalable units and fabric evidence.

Ask a language model the same low level design question twice and you get two architectures. Ask a different model and you get a third. Ask again next month, after the weights have moved under you, and you get a fourth.

Every one of them will be fluent. Every one will name real products, get the rack arithmetic close, and format itself like something a senior architect spent a fortnight on.

That is the problem. Not that the answer is wrong. That you cannot tell which one is.

The question everybody asks in the first ten minutes

Every conversation about this software arrives at the same place, usually before the coffee is cold:

Why would I buy this? I can just ask a model.

You can. We are not going to pretend otherwise, and anyone who tells you different is selling you something. A frontier model will produce an AI factory design that reads extremely well.

Then you submit it, and it stops being a document and starts being a commitment.

What a bid has to survive

An AI factory RFP is not a request for a diagram. It is a test of whether your organisation can hold hundreds of requirements in one place, design an architecture that satisfies them, produce a bill of materials that reconciles with that architecture, build a delivery plan that reconciles with both, and then defend every decision to a reviewer whose entire job is to find the seam.

There are four ways that ends badly, and only one of them looks like failure at the time.

One missed requirement. You are disqualified, and nobody tells you which one it was.

An unbuildable promise. You win. The win is the disaster, and it is a disaster you are now contractually inside.

Documents that do not reconcile. The diagram says one thing, the bill of materials says another, the proposal says a third. The reviewer notices, because noticing is the job.

An architecture that looks unready. Not wrong. Unready. The customer quietly concludes you are not who they thought you were, and you never learn that either.

A model that is confident and inconsistent is well suited to producing exactly these four outcomes, and poorly suited to telling you it has.

Use the NCP requirements self audit to check which published requirements you can evidence before choosing an architecture.

What a compiler does differently

The same inputs produce the same design. Every time. That single property is the whole argument, and everything else follows from it.

You can compare options honestly. Swap the storage vendor, the storage fabric or the compute fabric and get another aligned design, with a different bill of materials and a different cost. The difference between the two is a real difference, not the model having a different morning.

You can separate maker and checker. An immutable candidate, a decision log, an evidence package. When somebody asks how you arrived at this, there is an answer that is not "the model suggested it".

Alignment protects your support entitlement. Deviate on Spectrum-X, on InfiniBand, on certified storage, and when the GPUs underperform the answer you get back is that you used the wrong kit. That is a reason to stay aligned to the reference architectures that has nothing to do with winning the bid, and it survives long after the bid is won.

The knowledge stops leaving with your architect. It is in the system. Your senior architect going on holiday stops being a scheduling risk.

The Neon public release briefing describes which parts of the architecture and delivery package the compiler brings together.

Where the model is genuinely good

We use language models. They are excellent at reading an RFP and pulling out what it actually asks for, at drafting prose around a structure that already exists, and at explaining a decision to somebody who was not in the room.

What they are not good at is being the authority on the infrastructure design. Those are different jobs, and the second one is where the fifty million dollars is.

The rule we build to: the model reads and writes, the compiler decides, and the human signs.

The last mile is judgement

The software gets you most of the way. It does not get you all the way, and we would rather say so.

Which requirements are load bearing for your workload and which are not is a judgement call. NVIDIA diverges from its own reference architecture on frontier builds, so that call cannot be compiled by anybody, by us least of all. That is what our consulting is for, and it is why we do not hand you a box and walk away.

Requirements in. Architecture out. Risks exposed while they are still cheap. Decisions stay human.

The cost of waiting for that judgement appears in Six months to the first requirement.

For the work we deliver alongside the compiler, see the Bid Clock delivery plan.

The brief

How Neon fits your AI factory delivery pipeline

Nine pages for the people who sign: where Neon sits in an enterprise AI factory delivery pipeline, what it owns, what it never touches, and the three questions executives ask. Sent as a PDF.

The Neon briefings explain the design and delivery choices behind the package.