This page sets out Clio Care’s note integrity standard. It exists so that independent NDIS support workers, support coordinators, plan managers, educators, and allied health professionals can understand exactly what Clio commits to, and hold us to it.
This is not a marketing document. It is an accountability document. If anything on this page changes, we will say so here, with the date of the change.
What note integrity means
A case note has integrity when it contains only what the support worker observed, did, or was told during a shift. Nothing more. In NDIS contexts, this means the worker remains the sole legally responsible author of every line.
A note does not have integrity when it contains clinical observations the worker did not make, participant states the worker did not describe, goal progress the worker did not report, or any other detail added by software to fill gaps or improve the appearance of the documentation.
The distinction matters because NDIS support workers are legally responsible for the accuracy of every note they sign. The software that assisted in producing the note carries no part of that responsibility. The worker does.
What Clio’s standard requires
Every note generated by Clio must meet the following requirements:
Content accuracy
The generated note must contain only information present in the worker’s input or the participant’s profile. Clio must not add clinical observations, behavioural descriptions, mood assessments, goal alignment statements, or any other participant specific detail that was not provided by the worker.
Gap identification, not gap filling
When a worker’s input is incomplete, Clio must identify what is missing and ask the worker to complete it. Clio must not generate plausible sounding content to fill the gap.
Generation preserved, edits recoverable
When Clio generates a note, the original AI output is preserved unchanged. If the worker edits the note before signing, to refine wording, add detail, or remove content, those edits do not overwrite the generated version. Both versions are kept. The signed note can always be compared against what Clio produced, and every change the worker made is recoverable.
This means an admin or auditor reviewing a signed note can see what Clio prompted the worker to address, what the worker chose to include in the final note, and what they changed between generation and sign-off. Placeholders the worker removed, sections they deleted, content they rewrote, all visible by comparison.
Clio’s commitment is that the record is complete. A worker may sign off a note Clio flagged with gaps, but they cannot do so silently. The original prompt, the edits, and the final signed content all exist in the audit record, available for review.
Worker voice
The note must reflect the worker’s own account of the shift. Clio must not reframe, embellish, or clinically elevate the worker’s language beyond what they described.
Participant specificity
The note must reflect what actually occurred with this participant on this day. Clio must not produce uniform language across sessions regardless of what the worker reported.
Regulatory context recognition
When a worker’s input contains signals that describe one of the six reportable incident categories set out in the NDIS Incident Management and Reportable Incidents Rules 2018, Clio must recognise this, structure the note against the minimum record-keeping fields required by Section 12 of the Rules, and flag the applicable notification timeframe (24 hours for most categories, 5 business days for restrictive practices).
Clio must not silently produce a standard shift note when the worker has described something that carries these obligations. The worker retains the sole responsibility for determining whether an incident is reportable and for making any required notification. Clio’s responsibility is to surface the regulatory context, not to hide it.
This is the mirror of Requirement 2. Where Requirement 2 says Clio identifies gaps in the worker’s input rather than filling them with fabricated content, Requirement 6 says Clio identifies regulatory context the worker’s input triggers rather than omitting it. Both requirements exist so a signed note is a complete record of what the worker described and what that description requires.
How the standard is enforced
Clio maintains a test suite that includes exhaustive anti-fabrication testing across a range of input types, from minimal to detailed.
Every scenario in the test suite must confirm that Clio’s output contains only what the worker provided. Anti-fabrication testing is a condition of every update to how Clio generates notes. If any test fails, the update does not go live.
This means every worker using Clio can be confident that the version of Clio they are using has passed anti-fabrication testing before it reached them.
What this standard does not cover
Clio’s note integrity standard governs the content of AI generated notes. It does not guarantee that a worker’s own input is accurate. A note is only as good as what the worker brings to it. More detail, more context, and more accurate observation always produces better documentation.
The standard also does not cover notes generated by any other product or platform. If you use multiple tools, apply the same scrutiny to each.
How to verify this standard yourself
You do not need to take our word for it. Run this test:
Open Clio. Create a participant. Write the following as your session description:
Generate the note.
If the note adds descriptions of the participant’s mood, engagement, goal progress, or anything else not present in your two sentences, the standard has not been met. Contact us immediately at hello@cliocare.com.au and we will investigate.
If the note identifies what is missing and asks you to complete it before signing, the standard is working as designed.
To verify Requirement 6, run this second test:
Open Clio. Create a participant. Write the following as your session description:
Generate the note.
If Clio produces a standard shift note without recognising this description as a potentially reportable incident, without structuring the note against the incident-format fields, and without flagging the notification timeframe, Requirement 6 has not been met. Contact us immediately at hello@cliocare.com.au and we will investigate.
If Clio recognises the incident signals, restructures the note against the six-category framework, and prompts you to address notification, the requirement is working as designed. It remains your responsibility as the worker to determine whether the incident is reportable in your specific circumstances and to make any required notification.
Our public commitment
Clio is the only NDIS note app with a publicly available note integrity standard and a test suite that enforces it before every update to note generation.
We publish this standard openly because we believe the NDIS sector deserves tools that can be held accountable. Support workers deserve to know exactly what their documentation software will and will not do. Coordinators and plan managers deserve confidence in the notes they receive. Educators and allied health professionals deserve a benchmark they can point to.
If this standard changes for any reason, we will update this page with the date and nature of the change. We will not remove previous versions. The history of this standard will remain visible.
Change history
Requirement 6 added for regulatory context recognition
The standard has been extended with a sixth requirement covering how Clio must respond when a worker’s input describes something that falls within the six reportable incident categories set out in the NDIS Incident Management and Reportable Incidents Rules 2018. This behaviour has always been part of how Clio generates notes. Documenting it here brings it under the same public accountability contract as the other five requirements.
The requirement was added in response to a competitor releasing a paid tier that advertised incident detection as a premium feature. Clio has offered this capability in its single plan from day one. Publishing it as Requirement 6 records the commitment openly and makes it verifiable by any reader.
Requirement 6 is written to sit alongside the existing five, not to change any of them. The anti-fabrication commitments in Requirements 1 through 5 continue to apply without alteration. A verification test for Requirement 6 has been added to the “How to verify this standard yourself” section above.
Requirement 3 reframed from prevention to audit trail
The previous Requirement 3 stated that a note with identified gaps could not be signed off. In practice, Clio surfaces gaps via placeholders and warnings, but it does not prevent a worker from removing those placeholders manually or signing despite a warning. A documentation tool cannot enforce a worker’s judgment in real time.
What Clio does enforce, architecturally, is the preservation of the original AI output. Every note has two stored versions: what Clio generated, and what the worker signed. The two can be compared at any time. Every edit a worker makes is recoverable.
Requirement 3 has been rewritten to reflect this. The protection sits in the audit trail, not in a sign-off block that the product does not deliver. We made this change because the standard is a public accountability commitment, not a marketing document. When we found the previous wording over-promised, we corrected it.
How to cite this standard
For journalists, researchers, educators, and providers
This standard is publicly readable and freely citable. If you are referencing it in an article, training material, audit framework, professional discussion, or compliance document, please use the following format:
Each substantive change to this standard is recorded in the Change history above. The first published version of this standard appeared on 24 May 2026.
Contact
Questions, references, or standard concerns
Questions about this standard, requests to use it as a reference in professional or educational contexts, or reports of standard failures:
hello@cliocare.com.auWe welcome scrutiny. It is how standards improve.