Don't take enterprise-grade on trust. Ask to see the record.

The language has moved fast. Eighteen months ago it was vibe coding, a person and a model producing something that worked until it didn’t. Then it was agentic engineering, agents working inside a process, with specs, tests and reviews. Now the thing you buy from is a software factory. A team, a method and a set of agents that turns an approved description of a system into a running system in days.

Two months ago “software factory” was a phrase we used about ourselves. Now it is everyone’s. Kiro, Forge, Factory, Augment, Replit and a dozen agencies have picked it up, and underneath it every one of them makes the same promise. Enterprise-grade.

I don’t doubt they mean it. The trouble is that nobody can check it from a landing page, and a claim nobody can check is worth nothing. The question to ask a factory instead is a short one. Show me the record.

We had to answer that question about ourselves first.

Speed used to carry its own assurance

Eighteen months to build an application was an awful thing to pay for, but it bought something nobody priced separately. Someone had lived with the problem for eighteen months. They had argued over the edge cases, been woken by the first outage, retested after the retest. When a vendor said enterprise-grade, the phrase was never really a description of the software. It was shorthand for everything that time had already caught.

An application can now be built in days. The time is gone, and nothing has replaced it. The factories still say enterprise-grade, but the phrase only ever stood in for something that no longer exists. It is a reference to an assurance that speed has quietly removed.

What should replace it is a record, and a record has a specific shape. It is produced by the build, not written about the build afterwards. The spec the customer approved. The checks each stage of the build was blocked on. The audit trail the platform wrote while it ran. The working behind every action the software took. The test of a real record is that you could not fake it retrospectively, because it was load-bearing at the time.

What we found when we went looking

We rebuilt our own website this month, and the hard part was not the design. It was deciding what we were entitled to say. We wanted the site to explain why we are confident calling what we build enterprise-grade, and we did not want to do it with the same adjectives everyone else uses. So on 7 November we drafted the claims first, then went back through them line by line against our repositories. For every claim we asked the same question. Where is the artefact that backs this up, and when was it written?

Every line found something that already existed. It had been written between August and October, by the build, for the build, not for a website. The design record with its numbered decisions and dated review findings. The checkpoint reports that closed each stage of the build. The adversarial tests that tried to break the system before it shipped. The SOC 2 readiness review, run before any customer data could touch the platform, with a decision recorded by name against every finding. Even the positioning had a dated artefact. We had asked ourselves what our USP was at the end of August, and the answer sits in the design record beside the review findings.

The record was there. We just hadn’t gone looking for it as a record. That is the difference between a factory that can show you the record and one that cannot. Not whether the team is careful, but whether the care left evidence behind as it happened.

What a record is made of

A record is produced in four places, and none of them is a document someone writes at the end.

The spec governs the code. The description the customer approved is not a starting point the agents drift away from. It is the rule they build under. When the code and the spec disagree, the disagreement is reported as a finding and a person decides. It is never quietly worked around, because a workaround is a decision nobody made.

The build is gated. We build in tranches, bounded slices of the system that each take days rather than weeks. A tranche closes against a findings file, a list of what the tests, the reviews and the adversarial checks turned up, and the next tranche cannot start until every finding has a resolution. The tests that define correct behaviour are protected too. Changing what counts as correct is itself a recorded decision with a written reason, so a failing test cannot be edited into passing without leaving a mark.

The platform records what the software did. Every application runs on one shared identity and audit layer. A user’s identity travels with every action an agent takes on their behalf, so the agent acts as them and nothing more. Every read is logged, including the ones that were refused, and the log is written in a way that shows if it is altered afterwards. Anything sensitive is proposed by one person and approved by another, and the platform enforces that, not a convention.

Every action carries its working. When the software does something, the result carries a reference you can open, re-run under your own permissions and drill into. The proof travels with the action, wherever the action lands.

Since the obvious objection is that we are using agents too, we measure our own code the same way. Static analysis on every repository, and an independent model reviewing each change for the mistakes static analysis cannot see, mainly whether one customer’s data could reach another. Those findings go through the same gate as everything else.

Why the record can be trusted

A sceptic will say the same agents that wrote the code could write a plausible findings file afterwards, and the sceptic is right. A document written by the agent that built the software proves nothing on its own.

The answer is that the findings file is not where the proof lives. It is the receipt, not the bank statement. A receipt tells you what to look for. The bank statement is held by someone else, and that is what makes it evidence.

The record is built the same way. The findings file says the tests passed, but the tests ran on a hosted build service that stamped the time and the exact version of the code, and nobody on our side can edit that afterwards. The findings file says the audit trail is complete, but the trail is written so that any row changed, inserted or removed after the fact shows up when the customer checks it, and the customer can check it without asking us. The findings file says a change was approved, but the approval sits in the identity system, not in a document we wrote. Every important claim in the record points at something held outside the conversation that produced it.

That is what makes a record worth asking for. Not that the builder wrote it down, but that the builder wrote down where to look, and the places it points to belong to someone else.

There is a gap. A customer who never opens a repository can’t check a build log. For them, we hand over the record and the evidence it points to at delivery. That is a promise about process rather than a mechanism, and it should be read as one.

The gap nobody owns

Spec-first with human gates is not unique to us. The factories all do it now. Audit trails and access control are not unique either. Every serious platform has them. If the argument were that we do either of those things, it would be a weak argument.

The argument is about where each of them stops. Factories stop at the pull request. They don’t own the platform the software runs on, or what it does once it is live. Platforms start at deployment. They can tell you who did what, but they don’t own the spec or the build, so they can’t tell you whether what the software did was what anyone agreed it should do. Nobody carries one record from the spec a customer approved to the action their software takes, and attaches the proof to whatever the software does, wherever it does it. That is a narrower claim than enterprise-grade. Narrower is fine. It is checkable.

It also happens to be what regulators are asking for. Competitors are already framing the approved spec as the Article 11 documentation artefact under the EU AI Act, and a record produced by the build is exactly the shape that kind of regime wants. We’re not compliance consultants. It is simply a happy accident when doing the work properly and proving you did it turn out to be the same thing.

The record is the maintenance contract

Two objections, briefly. All this record-keeping slows you down. It doesn’t, because the gates are automated, the findings files are generated, and the tranche structure is how the agents work anyway. The record is a side effect of building carefully, not a tax on it. And customers don’t read findings files. True, and not the point. They don’t read their lawyer’s case notes either. The point is that the record exists, someone can read it, and the software can show its working when it matters.

The deeper reason to care is what happens after delivery. Software that is built in days and then has to live for years is only safe if nobody ever loses track of what right was. The approved spec, the gate results, the protected tests and the audit trail are the only honest account of that, and they are what every future change is checked against. Without them, every change is a guess dressed as a fix.

So whoever you are buying from, ask to see the record behind a real build. Not the deck, not the process diagram, the actual artefacts from an actual delivery. Then notice what happens. Some will show you. Most will tell you about their process. The difference is the whole answer.