The hard questions, answered straight.
A careful reader of this site will ask seven things. Is there new AI here, or good engineering? How much of a build is really standard? Do the safety figures hold up? Aligned, or certified? Does the data really stay put? Can one platform carry government? And what does it do to the cost? These are the right questions. Here is each one, with what we claim, what we do not claim and how you check it.
- 1Is this new AI, or well-engineered software?
- 2How much of a build is really standard, and how much is custom?
- 3Do the safety figures hold up?
- 4Aligned, or certified?
- 5Does the data really stay in our jurisdiction?
- 6Twenty-one services on one platform is an enormous claim. Is it real?
- 7How much cheaper or faster is it, really?
Is this new AI, or well-engineered software?
Well-engineered software, on purpose. We have not invented a model and we do not say we have.
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.
What we claim
- A product architecture that makes AI safe to put into operations with legal and financial weight.
- Model neutrality: the rails work across clouds, model providers and self-hosted models, and every agent has a deterministic path that runs without a model.
What we do not claim
- A proprietary model, a research breakthrough or accuracy that other teams using the same models cannot reach.
- That a language model decides anything. It drafts and summarises where it is configured, and every run records which engine ran it.
How you check it
- Ask to see an agent run with the model switched off. The lawful path still completes.
- Read any run transcript: each step names its actor as agent, guardrail or human.
How much of a build is really standard, and how much is custom?
The rails are identical for everyone. The service is a template. What is custom is your law, your delegations and your data, and we report the split on every build.
Three things are the same in every deployment and are never rebuilt: the hold-and-approve engine, the central delegation check and the evidence chain. On the MeshGov platform all twenty-one services run through that one engine, one delegation check and one chain. A new service does not get its own.
Each service then starts from a catalogue template with intake, assessment, decision and record already built. What changes per customer is mostly data, not code: the instruments and provisions, the delegation limits, the thresholds, the statutory clocks, the forms and the notices. What is genuinely coded per customer is integration with the systems you keep and rules that no template has met before. Anything a second customer could use goes back into the template.
The honest edge: the strongest evidence we have today is our own platform, where twenty-one services were built in sequence on the same rails and each reused what the last one left behind. A long run of customer builds is evidence we are still accumulating. So we do not ask you to take the ratio on trust. 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, so you see the custom share of your own build, and whether it fell on your second service.
What we claim
- The rails are not rebuilt or forked per customer. Ever.
- Jurisdiction rules, delegations, thresholds and clocks are configuration that your own officers can change within guardrails after go-live.
- A three-column scope and a three-column build report on every made-to-measure build.
What we do not claim
- That a real government implementation needs no custom engineering. Integration, data migration and unusual legislation are real work and are scoped as such.
- A published percentage. The share depends on the service and on what you are integrating with, and we would rather show you yours than quote an average.
How you check it
- Ask to see the same service loaded with a second jurisdiction's rules as data, without a code change.
- Ask for the three-column scope for your first service before you commit to it.
- Make the second-service comparison a term of the agreement.
Do the safety figures hold up?
They are counts read from the platform, not estimates, and we will produce them in front of you.
The figures on the AI safety page are counted from the MeshGov platform: 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.
What we claim
- Every figure can be regenerated from the platform on request, with the date it was read.
- Each guardrail has a code, a rule in plain words and the code that enforces it.
What we do not claim
- That a test count is a measure of safety by itself. The tests show that named refusals work. Your own assessor should still test the deployment.
- Independent third-party verification of the figures. They are ours until your assessor or auditor has checked them, and we will support that check.
How you check it
- Watch the suite run, including the refusals.
- Pick any guardrail code and ask to see the rule, the enforcing code and the test.
- Ask us to edit a past event and re-run chain verification.
Aligned, or certified?
Aligned. Where we say built to align, we mean the controls are designed to the standard and evidenced in the product. It does not mean a certificate.
Across this site we say built to align with ISO/IEC 42001, ISO/IEC 27001, SOC 2, the Essential Eight, the NIST frameworks and the OWASP LLM Top 10. That wording is chosen with care. Alignment means the controls the standard requires are designed in and can be shown. Certification means an accredited body has audited them. They are different things, and we do not blur them.
We do not claim a certificate we do not hold. Certification and assessment status is stated per product and per deployment, in writing, on request. The cloud regions we deploy into carry their own certifications and government assessments, and those belong to the cloud provider, not to us. For a government deployment the assurance pack supports your authority to operate, and your assessor decides.
What we claim
- Controls designed to the named standards, mapped article by article and guardrail by guardrail, with the evidence in the product.
- A written statement of current certification and assessment status for any product before you buy.
What we do not claim
- ISO/IEC 27001, ISO/IEC 42001 or SOC 2 certification, or an IRAP assessment of our products, unless that written statement says so.
- That a cloud provider's certification transfers to the software running on it.
How you check it
- Ask for the certification and assessment status statement for the product you are buying.
- Ask for the control mapping and walk any control back to where it is enforced.
Does the data really stay in our jurisdiction?
Residency is decided by the deployment architecture and the contract, so we give you both to examine before you buy.
MeshGov deploys into a tenancy you control, in the region you choose. Storage, backups, logs, the agent engine and model inference run in that region. Model calls go to the route you choose: your own agreement with the model provider, or an in-region model service from your cloud provider, pinned to the region. Outbound traffic is limited to that route and to read-only public feeds. Every agent has a deterministic path, so a service keeps running lawfully with no model at all.
A sovereignty claim is only as good as the papers behind it, so these are part of the offer and not an afterthought: a region map for your deployment, a sub-processor list with notice of change, a data processing agreement naming the region and the purposes, a residency clause, a no-training clause that flows down to every model provider, and audit rights.
What we claim
- No offshore leg for storage, processing or inference in a deployment configured for residency.
- Customer data is never used to train external models, by contract on both sides.
- Meshbone records the provider, model and region of every AI call, so residency is observable and not only promised.
What we do not claim
- That every model is available in every region. Where an in-region model route does not exist, we say so, and the deterministic path is the fallback.
- That sovereignty is met by our word. It is met by your review of the architecture, the sub-processors and the contract.
How you check it
- Ask for the region map and the sub-processor list for your deployment before you buy.
- Read the residency, no-training and audit clauses in the draft agreement.
- Inspect the Meshbone call log for provider, model and region.
Twenty-one services on one platform is an enormous claim. Is it real?
The platform and the twenty-one services exist and run on seeded data. Replacing a government's legacy estate is a programme you would run one service at a time, and we say so.
It helps to separate three things. The platform exists: 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 platform, 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.
What we claim
- Twenty-one services built on shared rails, each one inspectable today.
- An adoption path that starts with one service and carries no obligation to migrate the rest.
What we do not claim
- That a whole government has moved onto MeshGov. Where a reference deployment exists we will name it with the customer's permission, and where it does not we will not imply one.
- That legacy retirement is quick. Migration, integration and change management set the pace, as they do in any programme.
How you check it
- Ask to walk any of the twenty-one services end to end, including a refused decision.
- Start with one service, with exit terms that let you keep your data and the evidence chain in open formats.
How much cheaper or faster is it, really?
We will not quote a saving we cannot yet evidence across many customers. We show where the saving comes from, and we agree the measures with you before a build starts.
The mechanism is simple to state. The rails are paid for once and reused by every service, so identity, the evidence trail, the delegation model, integrations and the design system are not bought again for service two. Builds are fixed scope, so overrun is not passed on to you. Rules are configuration, so a change in a threshold or a form is made by your officers and not raised as a change request. And as a legacy system retires, its licence, integration and upgrade costs go with it.
What we do not have yet is a large set of completed customer programmes to average. Publishing a headline percentage without that would be the kind of claim this site argues against. Instead, the business case is built with your numbers: Orbit Roadmaps costs and sequences the work before anything is built, and each build agrees its measures up front, such as time to decision, cost to serve, rework and the run cost of what it replaces, and reports against them.
What we claim
- Fixed-scope builds and a platform subscription, so the cost of a service is known before it starts.
- Measures agreed before the build and reported after it, from the platform's own records.
What we do not claim
- A benchmarked saving against any named alternative.
- That consolidation pays back in the first service. The shared rails are the reason the later services cost less, so the case strengthens as services are added.
How you check it
- Ask for a costed roadmap for your portfolio before any build.
- Write the measures and the second-service comparison into the agreement.
Ask us the eighth question
If your assessor, auditor or board has a harder question than these, we would rather hear it before you buy. We will answer it in writing, and if the answer is no, or not yet, we will say that.