Agents prepare. People decide. Every time.
Every Arrochar Labs product is built around one rule: no AI agent takes a decision with legal effect on a person. Agents classify, assemble the history, draft, check and recommend. A named person with the authority to decide takes the decision, and the record shows who, under what delegation, with what reasons.
That rule is not a policy document. It is enforced in code on every product in the suite, tested on every build, and evidenced on a tamper-evident chain. We adopted the strictest applicable standards in the world as our bar and built the stack to meet them everywhere it runs.
Figures from the MeshGov platform as at September 2026, read from the platform itself. Ask and we will run the suite in front of you.
Nine safety mechanisms, and the code they live in
Each mechanism is shared across the suite. The examples are from products running today, most of them from MeshGov, where the platform runs the operations of government and the stakes are highest.
Human authority by construction
Every agent runs through one engine. When an agent reaches a decision with legal effect it holds, names the guardrail, the risk and the role that must decide, and stops. A person approving that hold is the only path that executes the effect. There is no code path from an agent to a determination, a payment, a licence, a warning, a resolution or a signature.
- MeshGov: a ministerial reply drafted by the correspondence agent cannot be sent until the minister or chief of staff signs; a licensing officer who tries is refused in code.
- MeshGov: the recruitment agent ranks candidates on merit; only the delegated manager can appoint, and not until a flagged panel conflict is recorded as managed.
- AIG Sentinel: approval gates on every AI use case; nothing moves from assessed to approved without a named approver.
Delegations as data, enforced at every decision
Who may decide what, and up to what amount, is loaded from the instrument of delegation as data. One central check runs before any decision takes effect, with monetary limits, and logs every attempt, allowed or refused. An officer without the delegation cannot take the decision, and the attempt is on the record.
- MeshGov: general counsel can settle a claim to $250,000; a $300,000 settlement is refused with the limit named.
- MeshGov: a manual journal at or above the threshold holds for the CFO delegate, and the preparer cannot approve their own.
- MeshGov: the audit agent reads the delegation attempt log as evidence, so the control is tested by the platform itself.
A tamper-evident evidence chain
Every audit event is hash-linked to the one before it, across every product and service on the platform. Verification runs on every overview, every audit and every legal file. Change a historical record and verification breaks from that point, which is what an auditor, an ombudsman or a court needs to rely on the record.
- MeshGov: the internal audit agent cites the chain in every engagement, with population, sample and exceptions.
- MeshGov: the legal agent puts the chain's verification status on every matter file so the record can be produced for discovery.
- AIG Sentinel: the audit-ready evidence trail that boards, auditors and regulators read on demand.
Guardrails as code, not as prose
Each service carries named guardrails: a code, a rule in plain words, and the line of code that enforces it. Agents stop at them. The guardrail register is public on every service's governance page, and the automated tests prove each one refuses what it should.
- No spend without appropriation: a purchase order beyond the available budget line is refused before it exists.
- Nothing publishes with an accessibility blocker: missing alt text, a skipped heading level or a link that does not say where it goes stops publication.
- Regulator first: the officer under the WHS Act cannot record a response to a notifiable incident until the regulator notification and site preservation are on the record.
Deterministic by default; a model only where it drafts
Rules, thresholds, deadlines and eligibility are evaluated deterministically, so the same inputs give the same result every time and the result can be re-run and explained. A language model is used only for drafting and summarising where it is configured, never to decide, and every run records which engine ran it. Where a live feed is unavailable the platform falls back to sample data and labels it as sample.
- MeshGov: PAYG withholding, the superannuation guarantee, notice periods, statutory clocks and three-way invoice matching are rules, not model outputs.
- MeshGov: every agent run records its engine (deterministic or model-assisted) beside its steps, so an auditor can see which was which.
- MeshGov: alert feeds, gazettes and news feeds that cannot be reached are shown as sample, never passed off as live.
Every run explained, step by step
An agent's reasoning is recorded as numbered steps with the actor (agent, guardrail or human), what it did and why, and the records it read. A person deciding a held matter sees the steps, the evidence and the options before deciding, and their decision joins the run.
- MeshGov: a planning assessment shows each control tested, each referral answered and each submission addressed before the delegate sees the recommendation.
- MeshGov: the financial statements list the journals behind every figure; the performance report lists the source and time of every number.
- Execdive: a written synopsis with its charts and sources, so an executive can see where an answer came from.
Transparency generated from the register
The AI register is built from the platform itself: every agent module, its purpose, the data it reads, the guardrails that hold its work for a person and live counts of runs, holds and human decisions. The public AI transparency statement is generated from that register, regenerated when the register changes, and published by an accountable officer.
- MeshGov: the transparency agent builds the register and drafts the statement; the accountable officer publishes it; an unchanged register never produces a new version.
- MeshGov: the compliance agent reads the published statement as live evidence for the obligation that requires it.
- Meshbone: what runs, who owns it, what it costs and whether it still meets policy, from first request to retirement.
Privacy, minimisation and segregation of duties
Personal information is redacted before anything is published, financial identifiers are stored masked and hashed, records are visible only to the people who need them, and the person who prepares a thing cannot be the person who approves it. Data stays in the customer's region and is never used to train external models.
- MeshGov: emails, phone numbers, addresses and identifiers are removed from consultation submissions before publication, and quotes are used only with consent.
- MeshGov: the officer who raised an order cannot resolve its invoice exception; the reviewer of a decision is never the original decider; the certifier of the statements is not the signer.
- Databallast: a governed glossary, metadata and lineage so the data an agent reads is classified and traceable.
Fairness, vulnerability and contestability
Intake stops when a person may be vulnerable and routes to a support officer before anything else happens. Reviews are decided by a different officer, with a bias check on the record. Every decision notice names the decider and the review rights, and an overturned decision feeds a lesson back into the rules.
- MeshGov: a case with vulnerability indicators halts at intake and holds for a support officer.
- MeshGov: an internal review cannot be decided by the officer who made the original decision, and an overturn requires a lesson that opens a rules feedback item.
- MeshGov: a conduct outcome cannot be decided until seven procedural fairness requirements are met, and HR must concur on the same outcome the manager reached.
MeshGov is held up by the rest of the suite
The government platform is not a product with safety added. It runs on the same rails as everything else we make, and each product in the Accountable AI Framework carries part of the load.
Assesses every MeshGov service and every other AI use against the frameworks that apply to the customer, holds approval gates, and keeps the audit-ready evidence trail the regulator, the auditor-general and the parliament read.
Runs every agent and service on one control plane: what runs, who owns it, what it costs, whether it still meets policy, and retirement when it should stop. The kill switch lives here.
The service templates MeshGov is built from, with the guardrails and the hold-and-approve engine inside the template, so a made-to-measure build starts safe rather than having safety added later.
The governed glossary, metadata and lineage that tell an agent what a field means, where it came from and whether it may be used, before the agent reads it.
Plain-language questions answered with a written synopsis, charts and sources, so executives see the evidence behind a number, not just the number.
Every AI opportunity carries a risk profile before it is built, so safety obligations are known at discovery, not discovered at audit.
Standard rails. Made-to-measure services. No made-to-measure build without the platform underneath it.
Your data stays in your jurisdiction, under your law, in your control
Data sovereignty is a legal obligation for most of the organisations we serve, and a design rule for us. Every Arrochar Labs product is deployed in the region the customer chooses, and every stage of processing stays there: storage, backups, the deterministic engine and model inference. Nothing is routed through another jurisdiction to reach a model. Customer data is never used to train external models, and the customer can export the whole record, evidence chain included, at any time.
Hosting, databases, backups, logs, the agent engine and model calls all run in the customer's chosen region. There is no offshore leg, not even for inference.
Customer data is never used to train or improve an external model. That bar is in our contracts with model providers and in our contract with the customer.
Each customer runs in its own tenancy with encryption at rest and in transit, and customer-managed encryption keys where the platform supports them. Support access is consent-based and logged on the evidence chain.
Records, the evidence chain and every agent run are exportable in open formats. At exit the data is returned and then deleted on a certified schedule.
How we secure it with our partners
| Role | Partner | How the data stays sovereign |
|---|---|---|
| Cloud hosting | AWS, Google Cloud and Microsoft Azure | Deployed in the region you choose, in Australian, US, EU, UK and Singapore regions today, on infrastructure the partner holds to ISO/IEC 27001 and SOC 2, with government-assessed regions available where the customer needs them (IRAP in Australia, FedRAMP in the United States, the NCSC Cyber Assessment Framework in the United Kingdom, MTCS in Singapore). Backups and logs stay in the same region. |
| Model inference | Anthropic Claude, direct or through AWS Bedrock and Google Cloud Vertex AI | Claude is used only for drafting and summarising; the rules that decide are deterministic and never leave the platform. Under the commercial terms we hold, inputs and outputs are not used to train models, and zero-data-retention arrangements are available. Where a region offers Claude through AWS Bedrock or Google Cloud Vertex AI, inference runs in that region and the data never reaches the model provider's infrastructure. Meshbone records the provider, model and region of every call. |
| Supporting services | Identity, email and code hosting | Held to the same bar as the platform: phishing-resistant MFA on every administrative account, no customer records in transactional email beyond what a message needs, code and configuration separated from customer data. A sub-processor list is published per deployment and changes are notified before they take effect. |
| Made-to-measure builds | The customer's own team after go-live | Configuration changes within guardrails are made by the customer's officers on the platform, in region. Nothing is copied out to be worked on elsewhere. |
What the contract says
- A data processing agreement naming the region, the sub-processors and the purposes.
- A residency clause: storage, processing and inference in the named region, with change only by written agreement.
- A no-training clause that flows down to every model provider.
- Breach notification within the statutory period of each jurisdiction, and never longer than 72 hours.
- Audit and inspection rights, including the right to verify the evidence chain independently.
- Return and certified deletion at exit, in open formats, within an agreed period.
How you verify it
You can see it, not just read it. Meshbone shows the provider, model, region and cost of every AI call. AIG Sentinel assesses each AI use against the residency rule that applies to you. The MeshGov AI register lists the data every agent reads. Ask for the sub-processor list and the region map for your deployment before you buy.
The security baseline underneath residency, including phishing-resistant MFA and the Essential Eight, is on the Security page.
The standards we adopted as the bar, everywhere
We do not build to the lowest requirement of the market we are selling into. We build to the strictest applicable standard globally, once, and read it back in each regulator's language.
The bar we adopted
| Standard | What it requires | Where it shows up in the stack |
|---|---|---|
| ISO/IEC 42001:2023 AI management system | An organisation-wide management system for AI: policy, roles, risk, impact, lifecycle controls, monitoring and improvement. | The structure of every product: roles with decision rights, guardrails as controls, agent runs as records, the AI register as the inventory, quarterly review of the register. |
| EU AI Act, Regulation (EU) 2024/1689, high-risk obligations | Risk management, data governance, technical documentation, record keeping, transparency, human oversight, accuracy and robustness, and a fundamental rights impact assessment for public bodies. | We build to the high-risk bar everywhere, not only in Europe: articles 9 to 15 and 26 to 27 are mapped below to the mechanisms that meet them. |
| NIST AI Risk Management Framework 1.0 and the Generative AI Profile (AI 600-1) | Govern, map, measure and manage AI risk, with the generative-AI risks named and controlled. | Risk registers with live signals, deterministic evaluation of rules, models limited to drafting, sample data labelled, red-team and evaluation before go-live. |
| Australia's Voluntary AI Safety Standard (2024), ten guardrails | Ten practical guardrails from accountability to stakeholder engagement, aligned to ISO/IEC 42001 and the NIST framework. | Adopted as the operating checklist for every deployment; each guardrail is mapped below to the mechanism and the example that meets it. |
Risk, impact and lifecycle
| Standard | What it requires | Where it shows up in the stack |
|---|---|---|
| ISO/IEC 23894:2023 AI risk management | How to identify, assess and treat AI risk through the lifecycle. | Risk categories, appetite, live signals and escalation in the governance service; risk profiles on every Orbit roadmap item. |
| ISO/IEC 42005:2025 AI system impact assessment | Assess the impact of an AI system on people and society before and during use. | Impact runs test a proposed rule on the live caseload before adoption; vulnerability screening at intake; fairness checks before outcomes. |
| ISO/IEC 5338 AI lifecycle and ISO/IEC TR 24028 trustworthiness | Lifecycle process and the properties of trustworthy AI: explainability, robustness, controllability. | Every run explained step by step; deterministic rules; the person can override any recommendation and the override is recorded. |
| OWASP Top 10 for LLM Applications (2025) and MITRE ATLAS | The attack surface specific to language-model systems: prompt injection, data poisoning, excessive agency, sensitive information disclosure. | Models never hold authority (no excessive agency by construction), inputs validated, outputs held for a person, content from feeds treated as data not instructions, red-team before go-live. |
Law and policy by jurisdiction
| Standard | What it requires | Where it shows up in the stack |
|---|---|---|
| Australia: AI Ethics Principles; DTA Policy for the responsible use of AI in government (2024); Privacy Act automated decision-making transparency (from December 2026); Commonwealth Ombudsman automated decision-making better practice guide; the Robodebt Royal Commission's recommendations | Transparency statements, accountable officials, human review of automated decisions, and lawful data-matching with response periods. | The transparency statement generated from the register; a named decider on every notice; the 28-day response period enforced on every overpayment notice; the data-matching safeguards tested by the audit agent. |
| United Kingdom: Algorithmic Transparency Recording Standard; the Data (Use and Access) Act 2025 automated decision-making provisions; the AI regulation principles | Public records of algorithmic tools; safeguards and human review for significant automated decisions. | The AI register maps to the ATRS fields; every significant decision is human by construction. |
| United States: NIST AI RMF; OMB memorandum M-25-21 on federal use of AI (high-impact AI minimum practices); state laws including the Colorado Artificial Intelligence Act | Inventories, impact assessments, human oversight and notice for high-impact and consequential decisions. | The inventory is the register; oversight is the engine; notices name the decider and the review path. |
| European Union and Council of Europe: the AI Act; the Framework Convention on AI, Human Rights, Democracy and the Rule of Law (2024); GDPR Article 22 | Human-rights based obligations for public-sector AI and the right not to be subject to a solely automated decision. | No decision is solely automated; contestability and review are built into every notice. |
| Canada: Directive on Automated Decision-Making and the Algorithmic Impact Assessment | Impact levels with matching requirements for notice, human intervention and testing. | Risk tiers on every agent in the register; human intervention at every held decision. |
| Singapore: IMDA Model AI Governance Framework, including the Generative AI framework (2024), and AI Verify | Internal governance, human involvement, operations management and stakeholder communication, with a testing framework. | The same mechanisms, plus AI Verify style test reports available on request. |
| New Zealand: Algorithm Charter for Aotearoa | Transparency, partnership, people focus, data, privacy and human oversight for government algorithms. | Plain-language explanations of each agent, human oversight, and the evidence chain. |
| OECD AI Principles (2024 update), UNESCO Recommendation on the Ethics of AI, G7 Hiroshima Process code of conduct | The international consensus on trustworthy AI: human-centred values, transparency, robustness, accountability. | The throughline of the Accountable AI Framework. |
Security and records underneath
| Standard | What it requires | Where it shows up in the stack |
|---|---|---|
| ISO/IEC 27001, SOC 2, the ACSC Essential Eight and the Information Security Manual | The security baseline every AI control depends on. | See the Security page: phishing-resistant MFA, application control, patching, least privilege, backups, data residency. |
| ISO 15489 records management and the evidence rules | Records that can be produced and relied on: who did what, when, on what basis. | The evidence chain, agent runs, human decisions and every notice as sent. |
| WCAG 2.2 AA and plain-language standards (ISO 24495-1) | What the platform publishes is readable and accessible. | The publishing agent blocks accessibility failures; reading grade measured on every piece. |
The ten guardrails, mapped
Australia's Voluntary AI Safety Standard sets ten guardrails aligned to ISO/IEC 42001 and the NIST framework. We use them as the operating checklist for every deployment, in every country.
| 1 | Accountability processes: ownership, governance, training and regulatory compliance Named roles with stated decision rights on every service; the AI assurance officer reviews the register; the accountable officer publishes the transparency statement. |
| 2 | A risk management process to identify and mitigate risks The governance service's risk register with appetite by category and thirteen live signals read from the other services; escalation beyond appetite to the audit and risk committee. |
| 3 | Data governance measures for data quality and provenance Databallast lineage and classification; every posting carries its source record; every figure lists its source and time; sample data labelled as sample. |
| 4 | Testing before deployment and monitoring after More than 130 automated tests on every build, most of them refusals; live monitoring of every run; audit tests read the platform's own trail. |
| 5 | Human control or intervention The hold-and-approve engine: every decision with legal effect is taken by a person with the delegation; the kill switch on Meshbone. |
| 6 | Inform end users about AI-enabled decisions and AI-generated content Every notice names the decider and the review rights; the public AI transparency statement and register; sample and model-assisted content labelled. |
| 7 | Processes for people to challenge use or outcomes Review rights on every notice; internal review by a different officer; feedback loop from overturned decisions to the rules. |
| 8 | Transparency across the AI supply chain The engine and model recorded on every run; the register lists data used and the frameworks applied; contractual disclosure of model providers. |
| 9 | Records that allow third parties to assess compliance The hash-linked evidence chain, agent run transcripts, the guardrail register and the delegation attempt log, exportable for auditors and courts. |
| 10 | Engage stakeholders and evaluate needs, with a focus on safety, diversity, inclusion and fairness Consultation with every submission registered and redacted, reports that count every voice, vulnerability screening at intake, fairness checks before outcomes. |
EU AI Act high-risk obligations, mapped
Public services are listed in Annex III. We meet the high-risk articles as the design bar for every product, whether or not the customer is in Europe.
| Art. 9 Risk management system | Live risk register with appetite, signals and escalation; ISO/IEC 23894 aligned. |
| Art. 10 Data and data governance | Lineage and classification through Databallast; PII redaction; data stays in region. |
| Art. 11 Technical documentation | Each service's standards, governance and guardrail pages are the documentation, generated from the same data the product runs on. |
| Art. 12 Record keeping | Every agent run, step, hold and decision recorded on the hash-linked evidence chain. |
| Art. 13 Transparency to deployers | Every run explained step by step; the engine recorded; the register and statement public. |
| Art. 14 Human oversight | The engine holds every decision with legal effect for a named person; overrides recorded; delegations enforced. |
| Art. 15 Accuracy, robustness and cybersecurity | Deterministic rules, automated tests on every build, OWASP LLM Top 10 controls, the security baseline on the Security page. |
| Art. 26 Deployer obligations | Delegations and roles configured per customer; logs kept; human oversight assigned to named people. |
| Art. 27 Fundamental rights impact assessment (public bodies) | Impact runs on the live caseload before a rule changes; vulnerability and fairness checks; the assessment on the record. |
What we will show you
Safety claims should be checkable. Before you buy, ask for any of these and we will show you the platform, not a slide.
- The automated test suite, run in front of you, including the refusals.
- The guardrail register for every service, with the code behind each rule.
- The delegation attempt log: every allowed and refused decision.
- Verification of the evidence chain, and what happens when a record is altered.
- Agent run transcripts for any matter, with the engine that ran them.
- The AI register and the transparency statement generated from it.
- Where your data is hosted and the contractual bar on training external models.
What we do not claim
A gold standard includes saying plainly where the edges are.
- We say built to align, evidenced in the product. Certification status against ISO/IEC 42001, ISO/IEC 27001 and SOC 2 is stated per product and per deployment on request, and we do not claim a certificate we do not hold.
- A guardrail stops an agent; it does not replace a lawful decision-maker. Where a decision needs a delegate, the platform waits for one.
- Live feeds fail. When they do the platform says so and shows sample data as sample.
- The standards move. The register, the statement and this page are reviewed quarterly and when a new agent is added.
See it refuse the wrong thing
The fastest way to judge AI safety is to watch the platform say no: to the wrong role, the wrong amount, the wrong order of steps. We will run it in front of you.