The hard questions, answered straight.

We use the best available language models and we do not train our own. What we build is the part the models do not give you: an engine that holds every decision with legal effect for a named person, delegations enforced as data, guardrails as code, deterministic rules for anything that must be repeatable, and a tamper-evident record of all of it.

That is a deliberate position. The reason AI stalls in government and regulated industry is not model quality. It is that nobody can show who decided, under what authority, on what evidence. That is an engineering and governance problem, and it is the one we solve. A model upgrade should make our products better without changing how accountable they are.

The figures on the AI safety page are counted from MeshGov itself: the services running on the engine, the automated tests in the suite and the guardrail codes in the register. Most of the tests are refusals: the wrong role, the wrong amount, the wrong order of steps, each proven to stop. The evidence chain is verified by recomputing every hash from the first event.

A number on a web page proves little, which is why the offer on that page stands: we run the suite with you watching, open the guardrail register with the code behind each rule, and alter a historical record so you can see verification break.

The controls every service shares are the same in every deployment: identity, the hold-and-approve engine, the delegation check, the evidence chain and the run-time controls agentVIKING™ enforces. An assessor who has assessed those once need not assess them again for the next service, and the evidence for them is produced once and reused. That is the whole of the claim, and the right name for it is reusable assurance.

It is not a claim that a service inherits approval. Each service has its own purpose, its own data, its own risks, integrations, business rules, permissions, model usage, threat surface and consequences of failure, and each of those is assessed for that service. What the rails change is the size of the job: the shared controls are already evidenced, so the service assessment is about the service. It is smaller and faster for that, and it is still your assessor's decision, including which controls they accept as reusable.

It helps to separate three things. The rails exist: one engine, one delegation model and one evidence chain, with all twenty-one catalogue services built on it as working software, each with its guardrails, tests, standards mapping and public-facing pages. The demonstrations on this site are walkthroughs, and they are labelled as such. The running services operate on seeded, invented data, not on a live government's records.

What the vision describes, a government retiring its legacy platforms onto one governed suite of agents, is a multi-year programme and not a product you switch on. Nobody should buy it as a single leap, and we do not sell it as one. The design is to start with the one service under the most pressure, run it alongside what you have, prove it, then add the next. Each service must earn its place before the next begins, and you can stop at any point and keep what is running.

The wide claim would be that one piece of software solves government's AI problem. We make the narrow one. AIG Sentinel defines policy. Meshbone enforces it at run time. Nanolitte carries the controls into service templates. Databallast controls what data an agent may read. agentVIKING™ runs across all of it, and one evidence chain records what happened. That is the infrastructure, and it is identical for every customer. A government service is then configured onto it: the legislation, the delegations, the thresholds, the clocks, the forms and the notices, mostly as data. The service is built to measure. The rails underneath it are not rebuilt, ever. An outside reviewer's phrase for this is reusable, governed agent infrastructure with services configured on top, repeatedly. Ours is standard rails, made-to-measure services. They describe the same thing.

What makes it more than a pile of agents is that each part hands the next something it can check. A policy written in AIG Sentinel is the rule Meshbone enforces. A delegation is data the engine reads at every decision. A guardrail is code the test suite exercises. The record an auditor reads was written by the same chain the agent ran on. Agents prepare and people decide, and the record shows who, under what delegation, with what reasons.

The economics are unproven in the way that matters, and we say so. The strongest evidence we have today is our own estate, where twenty-one services were built in sequence on the same rails and each one reused the engine, the delegation check, the evidence chain, the identity model and the design system of the one before. That is evidence the model works for us. It is not yet evidence that it works across many customers, with their legislation, their exceptions and the legacy systems they keep, and that is where the custom share lives. A long run of customer builds is evidence we are still accumulating, and until it exists we will not quote a headline saving.

So we do not ask anyone to take the model on trust. The proof of reusable infrastructure is one measurable thing: whether the second service is substantially easier than the first. Every fixed-scope build is scoped in three columns before it starts (standard, configured, coded) and reported in the same three columns when it ends. The second-service comparison goes into the agreement. The measures that matter to you, such as time to decision, cost to serve, rework and the run cost of what is replaced, are agreed before the build and reported from the agents' own records after it. If the coded column does not fall on the second service, the model has failed your test, and the report will say so.

An enterprise buyer cannot accept an AI service that is right half the time this week and three quarters of the time next week, and the fair question is how we know ours is consistent. The first part of the answer is architectural. Rules, thresholds, deadlines and eligibility are evaluated deterministically, so the same inputs give the same result every time, the result can be re-run, and every run records which engine produced each step. A language model is used only where it drafts or summarises, never to decide, and every decision with legal effect is held for a named person.

The second part is about the drafted text, and here we say what exists and what does not. Each service is red-teamed and evaluated before go-live, and the model, provider and version of every call are on the evidence chain, so a change in behaviour can be traced to a change in model. What does not yet exist is a published, repeatable evaluation set for each service that re-runs on every release and on every model change and reports its pass rate over time. That is being built, and until it runs we show you the go-live evaluation and the call log rather than a consistency figure.