Care Policy Concierge
Answer staff "what does our policy say?" questions from your approved document library — with the clause cited, and a refusal when the answer isn't there.
It searches only your approved policies and procedures, answers with the document, version and clause it relied on, and refuses rather than guess when the corpus doesn't cover the question.
Where this works well
The invisible problem this surfaces is the lookup tax. In an aged-care provider, the same handful of questions — how long do we keep incident records, what's the medication-error escalation, which form for a reportable incident under SIRS — get asked dozens of times a week, and they land on whoever is seen as the policy authority: the clinical lead, the quality and compliance officer, the People & Culture team. Each answer is a small interruption to higher-value work, and worse, the answer often comes from memory rather than the current document.
This pattern earns its keep when you have a genuine, approved document library — Clinical Care Policy, Records & Information Management Policy, incident-management SOPs, the medication-management procedure, the staff handbook — and a workforce that needs to consult it but doesn't read it cover to cover. It answers from those documents and cites the version and clause it used (the demo lights up Records & Information Mgmt Policy v4, §6.3), so the staff member is reading the actual policy, not a paraphrase. Best fit: a multi-site provider where staff can't walk to the compliance officer's desk, and where "what does our policy say" should always resolve to the current approved document.
Where it works badly
It is only ever as right as the corpus you give it. If your policies live in several versions across shared drives, or two documents quietly contradict each other, the tool will retrieve and cite one of them with the same confidence it shows for a clean answer — it has no way to know which is authoritative. It would happily quote a superseded medication procedure if that's the version indexed.
It also can't reason across documents or interpret a grey case. "Does this resident's fall meet the SIRS reportable threshold" is a judgement that depends on facts the policy doesn't contain; the tool can show you the threshold text but not apply it to the situation. The honest test: pick five questions your staff actually ask and check whether each has a single, current, approved document that answers it in writing. If most don't, the document work comes first — the retrieval layer can't manufacture an answer that isn't written down.
What it doesn't do — and shouldn't
It surfaces what the approved document says; it does not decide what the policy should be, and it does not certify that following the document satisfies the Act. When a question falls outside the corpus — the demo's "staff cryptocurrency trading" — it refuses, returns zero sources, and escalates to a person rather than inventing a plausible-sounding rule. That refusal is the most important thing it does.
The human-in-the-loop boundary is deliberate. A grounded answer carries Helpful and Flag controls, and a flag routes to the document owner so a wrong or stale answer becomes a correction to the source, not just a one-off. In a sector regulated by the Aged Care Quality and Safety Commission, where a confidently wrong answer about reportable incidents or medication management has real consequences for an older person, the tool's job is to make the right document fast and visible — and to hand back to a person the moment it can't.
What your data has to look like for this to work
You need one current, approved version of each policy and procedure, with a clear owner and a visible version and date — the demo's documents carry v-numbers and update months (v4, updated Feb 2026) for exactly this reason. The corpus has to be the authoritative set, not a shared-drive dump; every document in it should be one you'd be comfortable a staff member acting on. Superseded versions need to be retired, not just renamed, or the tool will retrieve them.
Most providers have the documents but not the discipline around them: three versions of the incident SOP, a handbook that hasn't tracked the November 2025 standards, no single owner for "what's current". Fixing that — establishing document control so there is exactly one live version of each policy — is usually a larger and more valuable piece of work than the retrieval layer on top, and it's a matter of how you capture and approve documents, not a tool you buy. It's the part we help with first, because the concierge is only as trustworthy as the library beneath it.
Could it give a confidently wrong answer and push a staff member to do the wrong thing under SIRS or the strengthened Quality Standards?
It only answers from chunks that clear a similarity threshold, and it shows you the document, version and clause it relied on plus the verbatim quote — so the staff member checks the source, not just the summary. When nothing in the corpus matches (the demo's cryptocurrency-policy question), it refuses and escalates to a person rather than inventing a rule. The safeguard against a wrong answer is that the answer is never separated from its source, and a person stays on anything consequential.
Our policies are a mess — old versions in shared drives, three documents that contradict each other. Will this work?
Not well, and it will make the mess visible fast. The tool answers from whatever you index, so if two policies disagree it can cite the wrong one or surface a superseded version with confidence. Sorting out which document is current and authoritative — one version of each, clearly owned — is usually the real first job, and it's work we help with before the AI layer earns its keep.
Does this replace our policy and compliance officer, or the People & Culture team?
No. It answers the high-volume "where is it written" questions so your policy and compliance people aren't the lookup desk, which recaptures their time for the judgement work — interpreting an ambiguous case, drafting a new procedure, handling an exception. It cannot decide what the policy should be, only repeat what the approved document says, and it routes anything it can't answer to a person.
How current does the document library have to be? Policies change, and the Act changed in November 2025.
As current as your approved documents are — the tool is only ever as right as the version you've indexed. It shows the version and update date on every citation (the demo cites Records & Information Mgmt Policy v4), so a stale answer is visible rather than hidden, but it has no way to know a policy is out of date. Re-indexing when a document is approved, and retiring superseded versions, has to be part of your document-control process.
Where does our policy content go, and who can see staff questions?
The corpus is your approved documents only — the demo states answers come from those five documents and nothing else. A production build runs against a private retrieval index you control, not a public model's training data, and staff questions are operational records you'd treat under your own Records & Information Management Policy. We scope data residency and access with you up front, because policy content and the questions staff ask about it are sensitive.
Estimated build: 3–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.