Case-Note Impact Synthesiser
Reads a de-identified case note against your own outcomes framework and drafts the structured entry — Star scores, goal progress, risk flags — with every value traced to its source, so a program manager reviews in an hour instead of retyping notes into report fields for days.
It parses each session note against your Outcomes Star domains and goal plan, drafts the outcomes entry with a source cited for every value, and flags wellbeing declines for a person to check before anything reaches a funder.
Where this works well
The slow, invisible problem this makes visible is the gap between the work a community-services team actually does and the evidence that survives into a funder report. A support worker captures a rich session note — an independent bus trip against Goal 2, two new social connections, a money worry and a missed Centrelink appointment — and most of that nuance dies when someone later retypes a handful of figures into an Outcomes Star entry or a DFFH service-agreement acquittal. This pattern reads the note against the participant's own support plan and Star baseline and drafts the structured entry while the detail is still there, with a source cited for every value.
It earns its keep where you already run a recognised outcomes framework — the Outcomes Star with its ten domains scored on the 1–10 Ladder of Change, or an NDIS plan with stated goals and baselines — and where your notes reference those goals and domains. The role it helps most is the program manager or outcomes lead assembling quarterly reporting across a caseload: the person currently reading dozens of unstructured notes and copying figures into a master document over days. At that scale, a draft-per-note that arrives pre-mapped to your metrics is the difference between reporting being a fortnight of dread and an hour of review.
Where it works badly
It works badly when there is no framework to read against. If your team writes free-text notes with no goal references, no domain language, and no Star or baseline to compare to, the tool has nothing to map progress onto — it will surface a few facts and mark most of the entry as a gap to verify, and you will have bought a slower way to do what you already do by hand.
It is also confidently unhelpful on stale inputs. If a participant's plan was reviewed or a goal closed after the support plan it reads, it will score progress against a target that no longer applies — flagging a "win" on a goal you have already retired. And it cannot read tone or safeguarding nuance the way a worker can: a note that says "more settled" gets logged as an improvement even if the worker meant it warily. The honest test: pull five of your own recent notes and ask whether a colleague who had never met the participant could tell, from the note alone, which goal moved and in which direction. If they can't, neither can this.
What it doesn't do — and shouldn't
It drafts; it does not decide. It surfaces extracted goal progress, proposed Star scores, and risk flags — it does not finalise an outcomes entry, does not lodge anything to a funder, and does not judge whether a participant is genuinely doing better. Those are the program manager's calls, and the human-in-the-loop step is deliberate. A wellbeing decline feeding a DFFH acquittal, or a goal marked achieved on a thin note, has real consequences for the participant and for the organisation's funding — so the draft waits in the client record for someone to approve, edit, or reject it.
It also will not invent statistics to make a report look complete, and it shouldn't. Where the note doesn't state something, it marks a gap rather than estimating a number. A thin draft with visible gaps is the truthful signal; a tidy fabricated one would quietly corrupt the evidence base the whole sector is trying to build.
What your data has to look like for this to work
Concretely: your notes need to distinguish a goal from an observation, and ideally reference the goal by name or number the way the support plan states it ("Goal 2: build travel confidence"). You need a current support plan and a recent Outcomes Star baseline per participant for the tool to compare against — without a baseline, "progressed" and "declined" have nothing to mean. Notes should name a domain or a measurable change where one happened, not just narrate the visit. And identifiers need to be stripped before synthesis, consistently, so the pattern runs on de-identified text.
Most organisations have some of this in good shape and some not — a solid Star process but inconsistent notes, or careful notes but baselines that live in three different systems. Fixing that is usually the real first job, and it is rarely about buying a tool: it is about how information gets captured at the point of the session. That capture work is what we help with, and it is typically bigger and more valuable than the AI layer sitting on top of it.
Could it score a domain wrong and quietly push a bad number into our funder report?
It can mis-read a note — that is exactly why nothing it drafts is final. Every Star score and goal-progress line carries the source it came from (the case note, the support plan, or the Star baseline), and the draft sits in a review queue until a program manager approves, edits, or rejects it. It also flags a sharp domain drop — like a Money score falling 5 to 3 with a missed Centrelink appointment — for supervisor sign-off rather than letting a wellbeing decline slide into an acquittal unseen. The number a funder sees is one a human approved, not one the tool decided.
Our case notes are inconsistent — some are two lines, some ramble, some mix observations with plans. Will this still work?
Partly, and honestly that is the real test. If a note distinguishes a goal from an observation and names a domain or a measurable change, it extracts cleanly. If notes are a wall of prose with no goal reference and no baseline to compare against, it will surface less and mark more as a gap to verify. Most organisations have a mix, and tidying how notes get captured is usually the first piece of work — often more valuable than the AI layer itself.
Does this replace our program managers or our outcomes/data team?
No. It drafts the entry; the program manager still owns the judgment — whether a goal genuinely progressed, whether a flagged decline needs a different response, what story the quarter actually tells a funder. The time it gives back is retyping and cross-checking, which gets redirected to reviewing more cases and the harder interpretive calls. We accelerate the thinking; the thinker stays in charge.
How current does the data have to be for the draft to be right?
It reflects the session note and the support plan and Star baseline as they stood when it ran. If a participant's plan was updated, a goal closed, or a fresh Star was completed after those documents, the draft will read against stale targets and may flag progress against a goal that no longer applies. It works best run close to when the note is written, against the current support plan and the most recent Star.
Where does the participant data go, and is it safe given how sensitive case notes are?
The pattern is built to run on de-identified notes — names, addresses and other identifiers removed before synthesis, consistent with the Australian Privacy Principles and your APP 11 security obligations — and it outputs no client names or locations. Where it runs and what it retains is part of the build, scoped to your privacy and data-handling rules; this is sensitive information and the design treats it that way. Nothing is shared externally; the draft stays in your client record until a person approves it.
Will it invent statistics to fill out a report that looks complete?
No — that is a deliberate boundary. It only records what the note and attached documents actually state, and marks anything not stated as a gap to verify rather than estimating it. A thin note produces a thin draft with visible gaps, which is the honest signal a program manager needs, not a fabricated full page.
Estimated build: 4 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.