Case studyIn use with Australian NDIS providers

CareOps

A compliance, claim assurance and evidence platform for Australian NDIS and aged care providers — designed, built and run by All-in AI.

It is also the clearest example of how we build AI for a regulated industry: the rules are versioned data, the validation is deterministic, the agents explain rather than decide, and a named human signs anything a regulator will ever read.

careops · claim assurance

412

Lines checked

Blocked

$18.4k

At risk

Findings

rules v2025-26.0.1

Block
NO_EVIDENCE01_011_0107_1_1
Shift delivered, no evidence recorded
Participant A
Block
PRICE_OVER_LIMIT01_015_0107_1_1
$4.10/hr above the weekday evening limit
Participant B
Warn
BUDGET_LOW04_104_0125_6_1
Core budget 92% consumed, plan ends in 26 days
Participant C
Warn
QTY_EXCEEDS_SHIFT01_011_0107_1_1
Claimed 8.0h against a 6.5h rostered shift
Participant D
Pass
PASSED01_013_0107_1_1
Matched to roster, evidence attached
Participant E

Corrected batch held as a draft artefact until a named person signs it off.

Sign

Illustrative view. No participant or provider data shown.

The problem

The standards are public and structured. The evidence isn't.

Australian NDIS and aged care providers face mandatory registration and expanded evidence obligations on a legislated timetable, with unregistered SIL providers required to apply from 1 October 2026 and broader personal care and daily living settings following from 1 July 2027.

Compliance work at most providers is a person with a spreadsheet and a shared drive. The standards are public and structured; the evidence is scattered and unstructured. That gap is where audits are failed and money is lost.

Claims fail for mundane, checkable reasons — a price above the published limit, a quantity beyond the rostered shift, a support with no evidence behind it, a worker whose screening lapsed. Each one is knowable before submission, and almost nobody checks before submission.

What we built

Three modules, one evidence-to-cash spine.

CareOps sits across the provider's care system, roster and payment files. Each module is useful on its own; together they close the loop from a support being delivered to the money for it arriving, with the paperwork already done.

Module 01

Registration & audit readiness

A provider uploads the policies and procedures they already have. CareOps extracts the text, maps it against the NDIS Practice Standards outcome by outcome, and reports where the evidence is thin — with a citation back to the indicator it was judged against. Where something is missing, it drafts the remediation and puts it in front of a person to approve, rather than filing it silently.

What it checks

→Gap report by module, outcome and quality indicator
→Expected-evidence types resolved per indicator
→Remediation drafts raised as artefacts, never auto-published
→Audit pack export with version footers

Module 02

Claim assurance

Drop in a roster export and a payment file. Every claim line is checked against the participant's plan dates and budget, the published price limits, the shift that was actually rostered and delivered, the worker's screening status, and whether any evidence exists for the support at all. Findings come back in plain English with a suggested fix. A blocked line can be corrected, removed, or overridden with a recorded reason — then re-checked.

What it checks

→Plan dates, budget headroom and category funding
→Price limits by item, rate type and time of day
→Roster reconciliation: quantity, delivery and duplicates
→Worker screening currency and evidence presence

Module 03

Shift evidence capture

The evidence problem is upstream of the claim: a support was delivered, but nobody wrote down what happened. CareOps lets a support worker record a short note in whatever language they speak, attach a photo, and be done. That becomes timestamped, structured evidence bound to the shift — and the claim that depended on it stops being blocked.

What it checks

→Multilingual capture on a phone, built for frontline use
→Structured against the support item being claimed
→Timestamped and bound to a specific shift
→Incident language triggers deterministic reporting deadlines

How it's engineered

Six decisions that make it defensible.

None of these are specific to disability care. They are what we think any AI system has to do before it is allowed near a regulator, an auditor or a payment run.

Regulatory logic is data, not code

Every standard, price limit and timeframe lives in versioned, schema-checked YAML with its source and effective date recorded. Nothing regulatory is hard-coded in application logic or buried in a prompt — which is what makes it reviewable by a compliance person rather than only by an engineer.

Deterministic before the model

Validation is ordinary code with tests. The model's job is to explain a finding, draft a document, or map a policy to an indicator — never to decide whether a claim is valid. If a rule changes, a test catches it; you don't re-tune a prompt and hope.

Human sign-off is a first-class object

Anything that could reach a regulator, an auditor or a payment system exists as a draft artefact until a named person signs it. We record who signed, when, and which rule and prompt versions produced it. The trail is the product as much as the analysis is.

Append-only audit trail

Every mutation of regulated data is written to an append-only log, and every finding carries the rules version it was assessed under. A decision made eight months ago can still be explained against the rules as they stood that day.

Tenant isolation enforced at the database

Row-level security is forced on every tenant table and the API connects as a non-superuser role that cannot bypass it. Isolation does not depend on an application developer remembering a WHERE clause.

Australian data residency, minimised PII

Data stays in Australian regions. Personal information is redacted before anything reaches a language model, and text extracted from uploaded documents has instruction-like content neutralised so a hostile file cannot steer an agent.

What we hold it to

The measures we agreed before we started.

Hours, not weeks

to a first complete gap report

Audit preparation that normally means a consultant reading a shared drive becomes an upload and a review queue.

Blocked, not rejected

claim lines caught pre-submission

The measure that matters is the ratio: lines stopped before they were submitted versus lines rejected weeks after the support was delivered.

Defensible by default

every finding version-stamped

Signed artefacts, rule versions and an append-only log mean the answer to "why did you do that" is already recorded.

We publish the measures rather than a headline number, because a provider's result depends on the state of their records when they start. Happy to walk through what we are seeing in practice on a call.

Why this matters to you

If your industry has an auditor, this pattern is yours.

CareOps is a disability and aged care product, but the hard parts were not about care. They were about operating an AI system inside a rulebook: keeping regulatory logic separate from application code, proving which version of a rule produced a decision, stopping a language model from being the thing that makes the call, and making a human signature a structural requirement rather than a policy someone might follow.

Those are the same problems facing a bank's obligations register, a utility's safety-case evidence, a contractor's delay claim, and a government agency's decision record. We built the pattern once, under real regulatory pressure, on our own money.

If you are carrying a compliance, claiming or evidence problem that everybody has agreed to live with, that is the conversation we want to have.

CareOps is a product of All-in AI. Screens shown on this page are illustrative and contain no participant, worker or provider data. CareOps supports a provider's own compliance decisions — it is not legal advice and does not replace an approved quality auditor or the provider's obligations under the NDIS Act and the NDIS Practice Standards.