Aged Care Module · what to build, from what, in how long

150 developer-years
of work, already done

The twenty open-source projects mapped in this document carry 122,529 commits from more than a thousand contributors across fifteen years. At a conservative two hours per commit that is roughly 245,000 developer hours — about 150 developer-years — of hospital systems, national health-insurance platforms, financial ledgers and compliance engines written, reviewed, tested and run in production by other people.

All of it is licensed for reuse. The quoted proposal prices this module at USD 30k–50k over 8–14 weeks as though it were new construction. It is not. Roughly 85% of the 32 quoted feature lines already exist as working, tested code. What remains is Australian rule content, integration, and proof — and that is a 4–8 week job, not fourteen.

The inheritance

What we are standing on

122,529Commits across the 20 mapped repositories

1,000+Contributors (ten repos exceed the API's 100 cap)

~150Developer-years of prior work

85%Of quoted scope already written

Project	Commits	Contributors	Started	Licence	What we take
surveyjs/survey-library	16,753	100+	2015	MIT	Assessment form runtime
calcom/cal.com	16,494	100+	2021	MIT	Scheduling primitives
openemr/openemr	13,508	100+	2010	GPL-3.0	Clinical + claims reference
medic/cht-core	12,530	100+	2013	AGPL-3.0	Offline sync + rules patterns
paperless-ngx/paperless-ngx	12,086	100+	2022	GPL-3.0	Document store
TimefoldAI/timefold-solver	10,586	100+	2023	Apache-2.0	Roster optimisation (optional)
intuitem/ciso-assistant	7,777	100+	2023	AGPL + EE	Standards & evidence engine
medplum/medplum	6,877	100+	2021	Apache-2.0	FHIR fallback
getprobo/probo	6,552	39	2025	MIT	Compliance alternative
synthetichealth/synthea	4,997	100+	2016	Apache-2.0	Synthetic test fixtures
documenso/documenso	4,162	100+	2023	AGPL-3.0	E-signature (optional)
Grashjs/cmms	2,327	14	2025	AGPL-3.0	Request → work order → vendor
openfga/openfga	2,051	100+	2022	Apache-2.0	Relationship authorisation
neighborhood-lab/folk-care	1,880	5	2025	AGPL-3.0	Care verticals + mobile app
gotenberg/gotenberg	1,364	84	2018	MIT	PDF conversion
formancehq/ledger	1,139	25	2021	MIT	Programmable ledger
openimis/…-claim_py	656	24	2019	AGPL-3.0	Claim lifecycle
gorules/zen	599	12	2023	MIT	Rules as decision tables
smsabeidi/careOS	113	1	2025	MIT	Governance spine (850 KB SQL)
openimis/…-ledger_py	78	2	2024	GPL-3.0	Accounting periods + triggers

Commit counts are exact, read from the GitHub API on 10 September 2026. Contributor counts marked 100+ are floored by the API's page limit — the true totals are higher. Effort is estimated at 2 hours per commit, which is conservative for reviewed work in mature projects.

Provenance

Where this source map came from

These twenty repositories were not found by searching GitHub on the day. They were selected from an indexed corpus SISO maintains and queries as standing infrastructure.

The SISO Repo Bank — the funnel behind this document

1.36MRepository identity databasecontinuously harvested

210,991Distinct repos placed into a taxonomy226,968 placements

32,137Ranked by liftabilityunit class · fame gap

23,778Best-in-category, one row per reporeuse value · licence

3,010Qualified product bases on the capability shelfclient-shaped

8,538UI components indexed separatelywith curated picks

A frozen 264-category taxonomy keys everything, with 105 normalised capability tags. Each row carries reuse value, licence, language, real dependency reach (not stars), and a one-line summary written for an app builder. The bank is derived from a 1.36M-repo identity database and a star-tiered URL farm of 56,675 repositories.

For this engagement the shelf was queried by capability family — healthcare practice management, scheduling, accounting and general ledger, forms and intake, document generation, e-signature, HRIS, workflow engines, identity and authorization — then every candidate was read at source: LICENSE file, recursive file tree, migration names, SQL bodies and test counts. Six rounds. Roughly forty repositories opened; twenty selected.

Corpus counts read from the local bank on 10 September 2026. The bank is SISO-internal; the repositories it points at are public.

Why this beats searching

Two of this document's biggest findings would have been missed by keyword search. openIMIS — 40+ modules covering claims, ledgers and contribution plans — was invisible to every "aged care" query because it is health-financing software. careOS has zero stars and would never surface in a popularity-ranked search, yet it carries the strongest governance schema found anywhere.

Ranking by real dependency reach and capability rather than stars is what surfaced them.

UI is indexed too

A separate bank holds 8,538 catalogued UI components with curated picks carrying written design notes. Screens in this build — participant record, visit detail, funding ledger, evidence register, standards dashboard — are assembled from that bank rather than designed from a blank canvas.

That is what makes the six-week timeline credible: neither the backend logic nor the interface starts from zero.

Is old code a risk?

Age is track record, not decay

Several of these projects started in 2010–2016. That is the founding year, not the age of the code. What matters is whether they are actively maintained now — so here is the last 90 days, measured on 10 September 2026.

Project	Started	Last push	Commits in last 90 days	Latest release	Health
openemr/openemr	2010	2026-09-09	100+	v8.3.0 · 18 Aug 2026	Active
medic/cht-core	2013	2026-09-09	100+	5.3.0 · 31 Aug 2026	Active
surveyjs/survey-library	2015	2026-09-09	100+	v3.0.3 · 3 Sep 2026	Active
synthetichealth/synthea	2016	2026-08-18	19	18 Aug 2026	Active
gotenberg/gotenberg	2018	2026-09-09	100+	v8.36.0 · 14 Aug 2026	Active
calcom/cal.com	2021	2026-09-09	42	v6.2.0 · 1 Mar 2026	Active
medplum/medplum	2021	2026-09-10	100+	—	Active
paperless-ngx	2022	2026-09-10	100+	—	Active
openfga/openfga	2022	2026-09-09	54	—	Active
intuitem/ciso-assistant	2023	2026-09-09	100+	—	Active
gorules/zen	2023	2026-08-25	63	—	Active
formancehq/ledger	2021	2026-09-09	31	—	Active
smsabeidi/careOS	2025	2026-08-31	100+	—	Active
neighborhood-lab/folk-care	2025	2026-03-14	0	—	Dormant

The old projects are the safest ones

OpenEMR has been shipping since 2010 and cut release v8.3.0 three weeks ago. CHT Core has run in national health programmes since 2013 and released 5.3.0 on 31 August. SurveyJS shipped v3.0.3 last week.

Fifteen years of continuous maintenance means fifteen years of security patches, edge cases found in production, and migration paths that actually work. A 2010 project still releasing in 2026 has survived every framework fashion cycle since — that is the opposite of risk.

What we actually take from the old ones

None of the pre-2020 projects are proposed as the running chassis. OpenEMR is a claims and clinical reference — read its X12/837 logic, do not deploy 1.1 GB of PHP. CHT Core is a pattern donor for offline replication and config-driven rules. Synthea generates test data and never ships. SurveyJS and gotenberg are libraries, versioned and pinned like any dependency.

The code that actually runs the product — careOS, ZEN, Formance, OpenFGA, ciso-assistant — is 2021 or later.

The one that should worry you

Not the 2010 project. folk-care — started 2025, and the only repo on this list with zero commits in 90 days. Last push 14 March 2026, 102 open issues, 5 contributors, and a README that contradicts its own LICENSE file.

That is a genuine maintenance risk and it is why folk-care is a transplant source, not the base. We lift its mobile package and selected verticals into a maintained spine and take ownership of that code. New and dormant beats old and shipping.

Commit counts marked 100+ are capped by the API page size — the true 90-day figures are higher. Everything above was read from the GitHub API on 10 September 2026 and should be re-checked before adoption.

Architecture

Seven layers, each with a named donor

1 · Care spinecareOS · MIT

smsabeidi/careOS — 62 SQL migrations, 850 KB. Audit chain, consent, legal authority, domain event outbox, forms engine, evidence, privilege lockdown. Standard PostgreSQL; Supabase-specific calls run to single digits per migration, so lifting it off Supabase is bounded work.

Read first: supabase/migrations/0003_audit_chain.sql — hash-chained tamper-evident ledger with per-tenant advisory locks.

2 · Care surfacefolk-care · AGPL-3.0

neighborhood-lab/folk-care — 12 verticals under packages/web/src/verticals/, API under packages/app/src/routes/, 176 tests + 12 e2e suites. Branch is develop, not main.

Transplant source, not base — AGPL and last pushed 14 March 2026.

3 · MoneyopenIMIS + Formance

openimis — 40+ Django modules. claim, claim_batch (capitation), invoice, ledger, contribution_plan, calcrule_social_protection, social_protection.

Read first: ledger/migrations/0004_trigger_protect_entry_meta.py — a PostgreSQL trigger that raises on any mutation to a closed accounting period.

Alternative: formancehq/ledger MIT, programmable in numscript.

4 · RulesZEN Engine · MIT

gorules/zen + gorules/jdm-editor. Decision tables as portable JSON; bindings for Node, Python, Go, Java, .NET, iOS, Android.

Every AU rate, threshold and split lives here as a versioned, approved artifact — never a hard-coded number in application code.

5 · ComplianceCISO Assistant

intuitem/ciso-assistant-community — 200+ frameworks as YAML in backend/library/libraries/, custom frameworks supported. The Aged Care Quality Standards become a data file.

MIT alternative: getprobo/probo.

6 · Mobilefolk-care packages/mobile

181 files, Expo 54 / React Native 0.81. Screens for care plan, incidents, medication administration, schedule, biometric lock, sync status. Offline stack in packages/core/src/sync/: offline-queue.ts, conflict-resolver.ts, sync-protocol.ts.

Second reference: openimis/claims_android_app_java.

7 · AccessOpenFGA · Apache-2.0

openfga/openfga or authzed/spicedb.

The one real gap in both care bases. folk-care derives actor identity from X-User-* headers — the caller asserts who they are. Zanzibar-style relationship checks make "can this worker read this participant" provable and testable.

Integration

How it actually wires together

One host application. One PostgreSQL instance with isolated schemas. Two sidecar services. Rules and standards as versioned data, not code. This is the whole architecture.

┌──────────────────────────────────────────────────────────────────────┐
│  BROWSER  ·  Next.js (careOS app shell)   +   MOBILE · Expo / RN     │
│  careOS office/* operations/* clinical    folk-care packages/mobile  │
└───────────────┬──────────────────────────────────┬───────────────────┘
                │  session cookie                  │  bearer token
                ▼                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  API LAYER  ·  careOS server actions + route handlers                │
│                                                                      │
│   every request ──▶ resolve actor (server-verified, never a header)  │
│                └──▶ OpenFGA check(user, relation, object) ──▶ allow  │
└───┬──────────────┬───────────────┬───────────────┬───────────────────┘
    │              │               │               │
    ▼              ▼               ▼               ▼
┌─────────┐  ┌───────────┐  ┌────────────┐  ┌──────────────────┐
│ care    │  │ sah       │  │ ZEN Engine │  │ outbox worker    │
│ schema  │  │ schema    │  │ (embedded) │  │ (same image)     │
│         │  │           │  │            │  │                  │
│careOS 62│  │AU funding │  │decision    │  │jobs · retries    │
│migrations│ │ledger     │  │tables JSON │  │notifications     │
│+folk-care│ │claims     │  │versioned + │  │document render   │
│verticals│  │statements │  │approved    │  │claim export      │
└────┬────┘  └─────┬─────┘  └─────┬──────┘  └────────┬─────────┘
     │             │              │                  │
     └─────────────┴──────────────┴──────────────────┘
                   │
                   ▼  ONE PostgreSQL instance, isolated schemas, one migration owner each
     ┌───────────────────────────────────────────────────────┐
     │  care.*      participants, plans, visits, notes, meds  │
     │  sah.*       periods, allocations, charges, claims     │
     │  audit.*     hash-chained append-only event ledger     │
     │  files       private volume, authorised download only  │
     └───────────────────────────────────────────────────────┘

  SIDECARS (separate containers, no shared DB)
     gotenberg ──▶ HTML/DOCX to PDF, network-restricted
     ciso-assistant ──▶ standards + evidence, own DB, linked by reference

The seven wiring decisions a developer needs on day one

Host

careOS is the application. Not a library, not a reference — clone it, apply its 62 migrations, and build inside it. Its app/office/* and app/operations/* routes become the product's routes. Everything else plugs in.

Database

One Postgres, three schemas, one owner each. care.* is careOS-owned — never hand-edit its migrations. sah.* is ours and holds every Australian construct. audit.* is append-only with DB triggers. Cross-schema writes go through commands, never direct SQL.

Identity

Lift careOS off Supabase auth, or keep it — decide in sprint zero. Measured cost: Supabase-specific calls run to single digits per migration. Either way, OpenFGA owns the authorisation answer:

check(worker:jane,
        can_view, participant:123)

resolved from tenant, care-team assignment and time bounds. No route trusts a client header.

Money

openIMIS schema patterns, transplanted into sah.* — not deployed as Django. Take the shapes: accounting period with lock/close, journal, analytic axis with funder code, entry meta with source-event reference, and crucially the trg_closed_period_meta trigger. Port the DDL, own the code. Formance stays the alternative if a separate ledger service is preferred.

Rules

ZEN is embedded as a library, not a service. @gorules/zen-engine in the API, the Python binding in workers, the mobile binding in the app — one decision JSON, identical answers everywhere. Tables live in sah.rule_version with an effective-date range and a named approver. No rate is ever a literal in application code.

Mobile

Transplant packages/mobile + packages/core/src/sync from folk-care into our monorepo and take ownership. It is AGPL and dormant, so it is forked deliberately and maintained by us — not tracked upstream. Its sync protocol talks to our API; its screens are rethemed. Nothing else from folk-care is a runtime dependency.

Sidecars

Exactly two, both isolated. gotenberg for PDF rendering, egress-blocked. ciso-assistant for standards and evidence, with its own database, linked from care.* by reference only. Everything else — queues, notifications, scheduling — runs in the host process until measured load says otherwise.

Repo layout

aged-care-module/
├─ apps/
│  ├─ web/                 ← careOS app (forked, owned)
│  └─ mobile/              ← folk-care packages/mobile (transplanted, owned)
├─ packages/
│  ├─ core/                ← shared types, command envelope, sync protocol
│  ├─ rules/               ← ZEN decision tables (JSON) + loader + fixtures
│  └─ sah/                 ← AU domain: funding, contributions, claims, statements
├─ db/
│  ├─ care/                ← careOS migrations 0001-0062 (upstream, unmodified)
│  ├─ sah/                 ← our migrations (funding, ledger, claims)
│  └─ audit/               ← append-only + triggers
├─ fixtures/               ← Synthea-generated participants, marked SYNTHETIC
├─ infra/
│  └─ compose.yml          ← postgres · web · worker · gotenberg · openfga · ciso
└─ tests/
   ├─ e2e/                 ← care loop, money loop, negative auth
   └─ rules/               ← every decision table has a fixture + expected output

The rule that keeps this from becoming a mess

Upstream code is never edited in place. careOS migrations stay untouched under db/care/ so upstream fixes can be pulled. Everything Australian lives in packages/sah/ and db/sah/. If a change requires editing a careOS migration, that is a signal the boundary is wrong — extend, do not patch.

Gap analysis

26 features the quote does not mention

Eight Australian vendors were torn down feature by feature. These are capabilities that two or more of them ship and that appear nowhere in the 32 quoted lines. This is the most commercially important table in this document.

The single largest omission: there is no rostering

All eight vendors treat rostering and scheduling as the core module. The quote has no line for it. Yet Support at Home claiming is downstream of the roster — you cannot claim for a service you cannot schedule, assign, verify and cost. A visit note (F05) is not a roster.

Either it is assumed to exist already in Unicare — which needs confirming in writing — or the quoted product cannot operate a care business.

Code	Missing feature	Vendors	Why it matters
EX07	Rostering & scheduling engine drag-drop, recurring, vacant shifts, conflicts, group shifts, templates	8 of 8	Claiming is downstream of the roster
EX08	SCHADS award interpretation penalties, broken shifts, allowances, overtime, breaks, public holidays	5	Australia's most complex award; misinterpretation destroys margin
EX09	Time & attendance / EVV GPS clock in-out, geofence, auto-timesheet, exception workflow	6	Evidence of delivery; gates claiming. A visit note is not verified attendance
EX10	Accounting integrations (Xero, MYOB, QuickBooks, KeyPay)	5	Universal — every vendor names Xero and MYOB
EX11	Services Australia / PRODA direct API claiming	5	F18 never states the channel, PRODA auth, or two-way balance sync
EX12	Claim rejection repair & remittance reconciliation fix one rejection without rebuilding the batch; credit notes; void-and-reissue	4	The actual operational pain. Bulk claiming without rejection repair is a demo
EX13	Client / family portal	5	Consent and Aged Care Act disclosure; deflects call volume
EX14	Service agreements, quotes, price lists, digital consent quote builder → agreement → e-signature → version history	6	Spec has document generation but no agreement lifecycle or rate card
EX15	Worker credential & expiry tracking quals, police checks, worker screening, WWCC, automated alerts	6	Standard 7 evidence. F08 is user roles, not credentialing
EX16	Worker/client matching engine (skills, proximity, preferences, exclusions, cost)	6	Named and differentiated by six vendors
EX17	Travel time & mileage (route/traffic calc, auto-km, reimbursement)	5	Both a cost line and a claimable item under SaH
EX18	Availability, leave, shift bidding / job board	5	Rostering is unusable without the supply side
EX19	Brokerage / subcontracted services purchase orders against budget, supplier invoice processing	3	Most SaH providers broker AT, home mods and allied health
EX20	Goal tracking & outcome measurement	4	F03/F04 cover plans and assessments but not measured outcomes over time
EX21	Communication log / secure messaging / SMS	6	Distinct from notifications: a durable auditable record of who said what
EX22	Complaints, feedback & continuous improvement register	3	Required alongside SIRS; F07 covers incidents only
EX23	Data migration & implementation tooling bulk CSV import, review-before-import, legacy import, bulk price updates	4	Determines whether the product can ever be sold
EX24	Open API / webhooks / developer access	5	The spec has no integration surface at all
EX25	Multi-branch / multi-entity with scoped data	4	Row-level scoping is an architecture decision, not a late feature
EX26	Custom form builder & configurable fields	5	F29 is vague; vendors mean user-built forms, fields, mandatory rules
EX27	Immutable audit log / archive-never-delete	6	F27 doesn't imply tamper-evident history or a no-hard-delete contract
EX28	Multi-funding-program support SaH + CHSP + DEX + NDIS + DVA + grandfathered HCP + private	6	Real providers run mixed books; CHSP/DEX reporting is a hard obligation
EX29	Care-management minutes as a first-class activity	3	The 10% cap cannot be enforced without recording CM activity separately
EX30	Voice dictation / AI note capture, photo attachments	4	Worker adoption depends on it
EX31	Budget rollover & unspent funds quarterly forecasting, carried HCP balances	5	F15 says quarterly budgets but never states rollover arithmetic
EX32	External referral intake (My Aged Care, fax/email/PDF) + pipeline	3	F02 is internal intake with no inbound channel

What this means for the quote

The proposal prices 32 lines. The market says a working Support at Home platform is closer to 58. The gap is not padding — it is rostering, award interpretation, attendance verification, claim rejection repair and credential tracking: the operational core of running a care business.

Two readings, and they need separating in writing: either Unicare already provides these and the module genuinely bolts on — in which case say so, line by line — or the quoted product is a records system, not an operations platform, and the delivered result will not run a business at any price.

The 10% care management cap — a concrete example

AlayaCare enforces it with a live dashboard of pooled care-management spend. ShiftCare tracks care-management minutes and activities against it. Brevity automates care-management service hours. The quote never mentions it. F22 says "Care Management" — a name — while three competitors treat cap enforcement as a headline capability. That is exactly the difference between a module list and a specification, and exactly where a fixed-price agreement goes wrong.

Notable single-vendor ideas worth stealing

Visualcare — award interpretation at roster time

Most systems interpret the award at payroll, when the money is already spent. Visualcare runs the PayCat engine as the roster is built, showing overtime exposure, broken-shift penalties and allowance triggers before the shift is confirmed. That is a margin-protection feature disguised as a UI decision.

CareSoft — ERA inside the care plan wizard

Environment Risk Assessment built into the plan flow rather than a separate form, plus a single Service Catalogue holding services, assistive technology and home modifications together with historical rates and bulk expiry management. Our spec splits AT and home mods into separate workflows; one catalogue is cleaner.

Nightingale — lone-worker safety

Safety check-in protocols with location sharing for workers alone in a client's home, plus staff exclusion management — blocking specific workers from specific clients. Both are duty-of-care features that never appear on a feature list until an incident forces them.

CareMaster — fleet and claimable logistics

Vehicle registration, insurance and inspection expiry tracking with driver assignment; and treating delivery, installation and transport as claimable line items on assistive technology — revenue most providers leave uncaptured.

CareSoft's published model sharpens ours

A live competitor publishes its domain model, and two decisions are worth adopting outright. A Lead is a first-class entity, separate from Client — "a lead becomes a client when a quote is accepted and a service agreement is created." Our F01/F02 collapse both into "Participant," losing a clean state transition and the entire pre-sales pipeline. And their whole system reduces to five core entities — Organisation, Lead, Client, Client Contact, Workforce — with everything else hanging off them, which is a useful discipline against a flat 32-module list.

They also enforce tenant isolation via PostgreSQL Row Level Security below the application layer, and archive-never-delete across clients, leads, workforce, quotes and agreements. Both match our architecture; it is useful to see them stated by someone shipping.

Evidence limits

Vendor feature lists are drawn from marketing pages, not product documentation, except CareSoft where public architecture docs were read. CareSoft's product is pre-launch — "join the waitlist" — so its list is stated intent, not shipped behaviour. Restrictive practices, waitlist/capacity planning, My Aged Care referral-portal ingestion and QI Program reporting were not evidenced on any vendor page and remain unverified rather than absent.

Design spec

What each feature actually means

A module name is not a specification. Each line below states the objects, the states, the acceptance test and the source. Expand any one. This is the level of detail a fixed-price contract needs — and precisely what the missing 05/09 scope document should have contained.

F01Participant ManagementHave

A person receiving care, their representatives, their consents and their service status — with more than one funding source at a time.

Objects

Participant · Representative (relationship type, decision authority) · Consent (scope, granted date, expiry) · FundingEnrolment (programme, start, end)

States

Lead → Active → On Hold → Inactive → Discharged. A lead converts once, on service-agreement acceptance. Discharge preserves the record; it never deletes.

Critical detail

A participant may hold multiple concurrent funding types — Support at Home, CHSP, HACC, NDIS, private. This is a competitor-validated modelling decision and is expensive to retrofit if modelled as a single field.

Acceptance

Create, read, update with duplicate review on name + DOB
Record survives service restart with identical field values
Tenant B cannot read the record by guessing its ID via direct API call
Expired consent blocks the actions it governed and says why

Source

careOS office/clients · folk-care client-demographics

F03Care PlansHave

A versioned, approved statement of goals and scheduled services. The document a visit is delivered against.

Objects

CarePlanVersion · PlanGoal · PlanService (type, frequency, duration, funding source) · Approval (approver, timestamp, exact content hash)

States

DRAFT → IN_REVIEW → APPROVED → SUPERSEDED. Rejection returns a draft with a reason. Approval binds to an exact revision hash.

Critical detail

A new approved version supersedes, never rewrites. A visit delivered last Tuesday remains attached to the plan version in force on that date — future plan changes must not retroactively alter the basis of a delivered service or its charge.

Acceptance

Editing approved content creates a new draft and invalidates prior approval for that draft
Full version history readable, with who approved what and when
A plan changed mid-visit does not alter the open visit's service basis

Source

folk-care care-plans · careOS 0010_careplan.sql

F05Worker Visit NotesHave

The record a support worker creates at or after a visit — the highest-volume write in the system and the one most exposed to poor connectivity.

Objects

Visit (scheduled, assigned, actual times) · NoteVersion · Attachment (photo, document) · Signature · Addendum

States

SCHEDULED → ASSIGNED → IN_PROGRESS → COMPLETED → REVIEWED. Cancelled, missed and note-outstanding are separate facts, not sub-states of completion.

Critical detail

A signed note is never overwritten. Corrections create an addendum, and the original stays visible. Submitting the same note twice — the classic flaky-connection case — must not create two notes or two charges.

Acceptance

Only the assigned worker can write the note; an unassigned worker is refused
Duplicate submit is idempotent — one note, one charge
A correction is visible as a correction, with both versions retained
Offline capture syncs on reconnect without duplicating

Source

folk-care visits · careOS 0045_verified_visit, 0013_visit_events

F07Incident (SIRS) ManagementPartial

Serious Incident Response Scheme handling: capture, triage, a human reportability decision, statutory notification, follow-up and closure.

Objects

Incident · ReportabilityDecision (decided by, rule version, rationale) · ExternalReport (submitted at, reference, outcome) · CorrectiveAction

States

REPORTED → TRIAGED → ACTIONS_OPEN → REVIEWED → CLOSED. Reportability and external-report delivery are independent states — deciding something is reportable does not mean it was reported.

Critical detail

Reportability is decided by a named human, assisted by a versioned rule table — never determined by a model. Statutory timeframes drive escalation. The rule content is Australian and must be authored; the mechanism is not.

Acceptance

Deadline timers fire from the approved rule version in force at incident date
Reopening is auditable and preserves prior closure
An unsubmitted report stays visibly outstanding — never silently marked done

Source

folk-care incidents (shell) + ZEN decision table (rules) — rule content is new work

F15Quarterly Budget ManagementAssemble

Support at Home allocates funding per quarter against a participant's classification. The system must track what is allocated, committed, spent and remaining — and roll the quarter over correctly.

Objects

FundingPeriod (quarter, open/locked/closed) · Allocation (bucket, amount) · Reservation (committed, not yet delivered) · Actual · Adjustment

Critical detail

Reserved and actual are separate ledgers. A scheduled service commits budget; a delivered service consumes it. Conflating them double-counts and is the most common defect in this category. Money is integer minor units — never floating point.

Acceptance

Two concurrent bookings cannot overspend the same allocation (race tested)
Quarter rollover moves the correct residual under the approved rule
A cancelled service releases its reservation exactly once
Closed period cannot be mutated — enforced by database trigger, not application code

Source

openIMIS social_protection.BenefitPlan.ceiling_per_beneficiary + ledger.AccountingPeriod · rates via ZEN

F17Participant ContributionsAssemble

Participants co-contribute to service cost at a rate set by their means assessment. Every charge splits between participant and government.

Objects

ContributionDecision (effective from/to, rate basis, source document) · ChargeSplit (participant portion, funded portion)

Critical detail

Effective-dated and pinned to service date, not run date. Re-running last month's billing after a rate change must reproduce last month's numbers exactly. A missing contribution decision blocks financial output rather than defaulting to zero.

Acceptance

Approved fixture produces an exact expected split, to the cent
A mid-period rate change applies from its effective date only
Revision history shows every decision that ever applied and when

Source

openIMIS contribution_plan (effective-dated via HistoryBusinessModel) · split arithmetic as a ZEN decision table with a named approver

F18Claim ManagementAssemble

Turning delivered services into a claim to government, then reconciling what comes back.

Objects

ClaimBatch · ClaimLine · SubmissionAttempt · RemittanceLine · Reconciliation

States

DRAFT → VALIDATED → APPROVED → EXPORTED or SUBMISSION_PENDING → ACCEPTED / PART_REJECTED / REJECTED / UNKNOWN → RECONCILED.

Critical detail

UNKNOWN is a first-class state. A submission that times out is not failed — resubmitting it risks duplicate payment. It stays visibly unresolved until a human or a receipt resolves it. An export file is never described as a submission receipt.

Open scope question

The quote does not say whether submission is a direct API integration or a CSV export. Competitors ship direct Services Australia claiming as standard, so an export is not parity. This is the largest hidden scope item in the proposal.

Acceptance

The same service cannot appear on two batches
Partial rejection reconciles line-by-line, not batch-wide
A replayed remittance import changes no totals

Source

openIMIS claim + claim_batch

F19Monthly StatementsAssemble

The participant-facing financial record: opening balance, services delivered, contributions charged, closing balance.

Objects

StatementVersion · StatementLine · AdjustmentNote

States

DRAFT → CHECKED → ISSUED. A correction after issue creates a new revision referencing the issued statement — it never edits the original.

Critical detail

Opening + entries must reconcile to closing, and to the underlying claim and contribution records. Once issued, the period is closed at the database level. This is the single most reputationally damaging thing to get wrong — participants and their families read these.

Acceptance

Reconciles to source records for an approved fixture, to the cent
Attempting to mutate a closed period raises a database exception
A reissue is visibly a reissue, with the original retained

Source

openIMIS ledger.AccountingPeriod close + trg_closed_period_meta

F23Restrictive PracticesBuild

Recording any practice restricting a person's freedom of movement or action, and the authorisations that must exist before it is used.

Objects

RestrictivePracticeRecord (type, rationale, least-restrictive alternatives considered) · Authorisation (type, authoriser, expiry) · ConsentReference · Review (cadence, outcome) · links to BehaviourSupportPlan and Incident

Critical detail

The system records; it never authorises. A record existing is not permission to use a practice. Missing or expired authorisation must be prominently flagged. Access is restricted beyond ordinary clinical roles.

Why this is the irreducible line

Four independent search rounds found zero open-source implementations of any safeguarding regime of this shape. The register and approval mechanism come from careOS 0018_legal_authority; the legal rule content must be authored from current official sources and signed off by a qualified human.

Acceptance

Use without current authorisation is blocked and flagged, not merely logged
Overdue reviews surface on the compliance queue
Every record links to its incident and behaviour-support context

F32Mobile ApplicationHave

The support worker's field tool: today's visits, the participant's plan, note capture, medication administration, incident reporting.

Screens shipped in the donor

Schedule · Care plan · Visit detail and note · Medication administration · Incident report · Biometric lock · Sync status · Mileage

Critical detail

Connectivity in home care is unreliable by definition. Capture must survive loss of signal, queue locally, and sync without duplicating. Offline sync must enforce authorisation — a device holding cached data for a participant no longer assigned to that worker is a breach.

Open scope question

Offline is explicitly excluded from Packages 1 and 2 and never explicitly added to Package 3. "Fully available and built out" is not a definition. Clock-only offline, notes and media offline, and full-module offline are three very different projects.

Acceptance

Airplane-mode capture, then reconnect: exactly one record, no duplicates
Revoked session invalidates cached participant data on next sync
Unsupported offline actions say ONLINE REQUIRED and preserve entered data
Real-device testing, not simulator only

Source

folk-care packages/mobile (181 files, Expo 54 / RN 0.81) + packages/core/src/sync

Ten of the thirty-two lines are expanded here — the ones carrying the most risk or the most ambiguity. The same treatment for the remaining twenty-two is a day's work and should be a precondition of any fixed-price agreement.

Sequencing

What each roll-in buys you

Repositories do not land at once. Each one is qualified, folded in, and proven before the next. Here is the cumulative coverage against the 32 quoted feature lines.

#	Roll in	Licence	New lines	Cumulative	Coverage	Days
1	careOS — the host	MIT	+10	10 / 32	31%	12
2	folk-care web verticals	AGPL	+8	18 / 32	56%	22
3	folk-care `packages/mobile`	AGPL	+1	19 / 32	59%	27
4	openIMIS schema port → `sah`	AGPL/GPL	+5	24 / 32	75%	35
5	ZEN Engine	MIT	+1	25 / 32	78%	39
6	ciso-assistant	AGPL	+1	26 / 32	81%	42
7	OpenFGA	Apache	+0	26 / 32	81%	46
8	gotenberg + node-signpdf	MIT	+1	27 / 32	84%	48
9	Grashjs/cmms (pattern only)	AGPL	+2	29 / 32	91%	52
10	Synthea	Apache	+1	30 / 32	94%	54
11	SISO UI bank + theming	—	+1	31 / 32	97%	59
12	AU rule authoring — no repo exists	—	+1	32 / 32	100%	65

The first four roll-ins are three weeks and three quarters of the value. The remaining eight add fewer lines each but rising integration cost — which is the normal shape of assembly work, and the reason a fixed-price quote for "the whole thing" hides where the risk sits.

Two roll-ins add no features at all

OpenFGA adds zero quoted lines and costs four days. It is not a feature — it is what makes F08 provable rather than asserted. Synthea is the same: pure leverage, no scope. Estimates that count only features systematically miss both, and they are exactly the items that get cut under schedule pressure and then cause the incident.

Do the first four collide?

Roll-in	Overlaps careOS?	Resolution
1 · careOS	—	It is the host. Lands whole, 62 migrations untouched
2 · folk-care verticals	Yes — real collision	Both model participants, visits, notes, care plans
3 · folk-care mobile	No	Separate runtime (React Native), talks over HTTP
4 · openIMIS → `sah`	No	Money domain. careOS has zero billing/claim/ledger code — verified by grep

Only one of the four collides, and it is resolved by a rule rather than a merge: take folk-care's UI layer, leave its schema behind. Its components, request hooks, validation and error states are repointed at careOS tables. Its ~50 migrations never land. Its billing code specifically stays out — it uses floating point, which must never become a funding authority.

Domain model

The donors already spec'd this for us

The strongest argument in this analysis: two care platforms built independently arrived at the same domain boundaries, and a national health-financing platform confirms the money side. This is not a domain model to design — it is one to ratify.

Domain	careOS	folk-care	Verdict
Identity & tenancy	`0002_identity_rbac`	organizations, users	Agreed
Participant	`office/clients`	`client-demographics`	Agreed
Consent & representative	`0012_consent_family`	family-engagement	Agreed
Care plan	`0010_careplan`	`care-plans`	Agreed
Visit & delivery	`0013_visit_events`, `0045_verified_visit`	`scheduling-visits`, `time-tracking-evv`	Agreed
Clinical & medication	`clinical`	medication administration	Agreed
Incident & safety	incidents	incidents	Agreed
Evidence & compliance	`office/evidence`, `0056_evidence_summary`	`quality-assurance`	Agreed
Workforce	`office/staff`, `0038_staff_compliance`	caregivers, shift-matching	Agreed
Money	absent	float billing only	openIMIS supplies it
AU rule content	absent	absent	Ours to design

Nine ratified, one imported, one designed

Two independent teams — one building a US home-health platform, one building a care governance system — converged on the same nine boundaries. That convergence is evidence the boundaries are correct, in a way no whiteboard session can be.

The expensive architectural thinking is done, and it agrees with itself. That is the real reason the timeline holds.

Cross-cutting patterns come free too

careOS also supplies the machinery between domains: 0027_domain_event_outbox for cross-domain writes, 0003_audit_chain for the tamper-evident audit boundary, 0018_legal_authority for authorisation records, and 0007_function_privilege_lockdown for the access boundary.

These are the parts teams usually get wrong on the first attempt.

What is genuinely ours

One domain: the Australian rule content. Support at Home funding and contribution rates with effective dates, SIRS reportability thresholds and timeframes, and the restrictive-practices authorisation regime.

Expressed as ZEN decision tables with a version and a named human approver. It is rule authoring, not platform engineering — and it is the only part no repository on earth supplies.

Delivery

Six weeks, four sprints

Two-week sprints, two developers. Eight weeks is the comfortable ceiling with client-integration slack; six is achievable if the Unicare source and scope spec arrive on day one. Compare against the quoted 8–14 weeks for the same 32 lines built from scratch.

WorkstreamW1W2W3W4W5W6W7W8

S0 · Qualifyspike + decide

S1 · Care loopintake → note

S2 · Money loopcharge → statement

S3 · Assuranceevidence + requests

Mobileparallel, after S1

Client bindingblocked on access

Dashed row = cannot be scheduled until Unicare access is granted. It is the only genuine schedule risk on the project; everything else proceeds without it.

Board

Sprint tickets

S0 · Qualifyweek 1

Stand up careOSsupabase start + apply 62 migrations. Confirm audit chain and append-only guards fire.1d

Stand up folk-careBranch develop. Run 176 tests + 12 e2e. Record pass rate.1d

Run openIMISopenimis-dist_dkr compose. Prove the closed-period trigger rejects a mutation.1d

Forged-header negative testProve tenant B cannot read tenant A by ID or header. Both bases.0.5d

Generate Synthea fixtures100 synthetic participants with meds + care plans.0.5d

DECIDE: ledgerFormance (MIT) vs openIMIS (GPL). Licence + fit.0.5d

DECIDE: folk-care licenceAGPL confirmed in LICENSE. Transplant scope or drop.0.5d

S1 · Care loopweeks 1–3

Host + identitycareOS as host. Wire OpenFGA relationship model: tenant, care team, assignment.3d

Participant + referraloffice/clients + office/intake. Multiple concurrent funding types per CareSoft model.2d

AssessmentcareOS forms engine. SurveyJS runtime for instrument rendering.2d

Care plan versioningDRAFT → IN_REVIEW → APPROVED → SUPERSEDED, bound to exact revision.3d

Visit + signed noteTransplant folk-care visit vertical. Correction/addendum path, never overwrite.3d

Incident shellfolk-care incidents + triage. SIRS rules deferred to S2.2d

GATE: care loop e2eReferral → note → incident on real DB, 2 roles, restart-safe.1d

S2 · Money loopweeks 3–5

Funding period + ceilingopenIMIS accounting period + benefit ceiling. Integer minor units only.3d

ZEN rule harnessDecision tables for rates, splits, thresholds. Version + approver on every table.3d

Charge + contribution splitService → charge → participant/funder split via ZEN. Reserve once, deliver once.3d

Claim batch + exportDRAFT → VALIDATED → APPROVED → EXPORTED. UNKNOWN never resubmits.3d

Statement closeClosed period immutable at DB level. Adjustments create revisions.2d

SIRS reportabilityZEN decision table + notification timers on the incident shell.2d

GATE: money e2eReversal restores balances; replayed import changes nothing.1d

S3 · Assuranceweeks 5–6

Standards libraryAged Care Quality Standards as CISO Assistant framework YAML.3d

Evidence registercareOS office/evidence → requirement links, freshness, review state.2d

AT + home mod requestsOne request model, two typed variants. Grashjs/cmms as design reference.3d

Restrictive practicescareOS legal_authority + ZEN authorisation checks.2d

Documentsgotenberg render; node-signpdf for stamping. Template + input version pinned.2d

GATE: package acceptanceAll selected-package rows evidenced. Restore proof. A11y pass.2d

Cost

What this actually costs to build

The quote prices this module as new construction by a team billing hours. Built the way it should be built — agents assembling proven components under human review — the input cost is compute, and compute is sold by the month.

Quoted price vs. build cost

As quoted · Package 2

$40,000

USD · 12 weeks · from scratch

Priced as new construction across 31 feature lines
~85% of those lines already exist as working open-source code
Package 3 adds $10,000 for one undefined sentence about mobile
Cites a scope specification that has never been supplied

Compute cost · same scope

$1,200

2 agent plans × 3 months @ ~$200/mo

20–50B tokens — measured against real agent sessions, not estimated
~65 agent-days across 11 workstreams
Two parallel lanes → 6–7 weeks calendar
Plan-bounded: ~20B/month per plan, so 2 plans × 3 months

Compute input is roughly 3% of the quoted price — a 33× gap. The remaining 97% is whatever the supplier's margin, overhead and hours model demands. That is not an argument that the work is free: it is an argument that the price should reflect integration, Australian regulatory content and accountability, not the reconstruction of software that already exists.

Where the effort goes

Workstream	Agent-days	Share	What consumes it
S0 · Qualify the donors	4	6%	Standing up 3 systems, negative tests, licence decisions
Host + identity + schema split	6	9%	careOS fork, OpenFGA relationship model, three schemas
Care loop	10	15%	Referral → assessment → plan → visit → note → incident
`sah` schema + ledger DDL	6	9%	Porting openIMIS accounting shapes and triggers
ZEN rules harness	4	6%	Decision tables, versioning, fixtures per rule
Money loop	8	12%	Splits, claim batch, statement close, reversal paths
Assurance + requests	6	9%	Standards YAML, evidence, AT/home-mod, restrictive practices
Mobile transplant	5	8%	Fork, retheme, point sync at our API
Documents / notifications / reporting	3	5%	gotenberg wiring, templates, report definitions
Hardening	5	8%	Negative auth, restore proof, accessibility, load
Rework and review churn	8	12%	The honest line most estimates omit
Total	65	100%	~6–7 weeks with two parallel lanes

How the token figure was derived

A first pass estimated ~260M tokens. That was wrong by roughly two orders of magnitude, because it counted generated output rather than total context throughput — and in real agent work the dominant cost is cache reads and context replay on every turn, not the code emitted.

The corrected figure is measured against actual sessions:

Measurement	Value	Source
Research + document-building session	79.2M tokens / 348 turns	This engagement, measured
Average per turn	~228,000 tokens	Derived
A larger single session on this machine	487M tokens / 1,540 turns	Measured
Roughly one month of sustained agent use	~20B tokens	Operator figure
This build, 2 lanes × 2–3 months	20–50B tokens	Plan for 50B

Note what this means: producing the research and this document alone consumed 79M tokens — a third of the original whole-project estimate, spent on analysis before a single line of product code. Real builds burn context on failed builds, re-reads, test loops and dead ends. The disciplined-turn arithmetic underestimates by 10–20×.

Why tokens are not the real constraint

50B tokens sounds enormous and is commercially irrelevant. Agent plans are flat monthly subscriptions with generous ceilings — roughly 20B tokens a month per plan — so the input cost is plan-months, not per-token metering. Two plans for three months is about $1,200 whether the build burns 20B or 50B.

The genuine constraints are human: who approves the Australian funding rules, who signs off clinical safety, and when Unicare access is granted.

What a fair price looks like

The supplier is not wrong to charge. They are wrong to charge new-construction rates for assembly work. A defensible price covers integration, the Australian regulatory content, qualification evidence, and someone carrying accountability when a claim is wrong.

On this evidence that is single-digit thousands, with a maintenance and fixes commitment attached — not $40,000 for twelve weeks, and certainly not $10,000 for a mobile app that already exists in the base repository.

The honest caveats

These figures assume the donors qualify in sprint zero — nothing has been run yet. They assume two competent reviewers, not unattended generation. They exclude the Unicare binding, which cannot be scoped until the platform is seen.

And they exclude the one thing no amount of compute produces: a qualified human signing off the funding, contribution and reportability rules.

Market

Who already sells this, and for how much

Australian providers do not lack options. A dozen commercial platforms serve this market, several with Support at Home modules already shipping. Their published pricing reframes the quote entirely.

Vendor	Model	Published price	Support at Home	Notes
AlayaCare	Enterprise	Not published	All 5 pathways	Direct Services Australia API claiming, pooled budgets, 10% care-management cap. "Rebuilt around these rules, not bolted on top"
Lumary	Enterprise	Not published	"Reform"	Salesforce-native, Salesforce-invested. AU platform at /au/; SCHADS award interpretation
Visualcare	Enterprise	Not published	Dedicated page	Database Consultants Australia. Rostering, claiming, finance, compliance
ShiftCare	Per user / month	$8–25	"NEW" badge	Min 5 staff. QuickClaim for Services Australia. Family portal +$5/client/mo
Brevity	Per client / month	$3.99–6.49	API-integrated	From $44.90/mo. Real-time budget tracking. Setup fee on higher tiers
CareMaster	Per user / month	$16–36	Some	Ex GST, min 5 users. Worker + participant apps in all tiers. NDIS-heavy
CareSoft	Unknown	Page 404s	Native	"Built ground-up… rather than patching outdated software." Very early stage
Nightingale	Unknown	Not published	NDIS-led	Award interpretation, funding engine, bulk claims
Telstra Health	Enterprise	Not published	None found	Residential-weighted — markets by "beds supported"
Person Centred Software	Enterprise	Not published	None found	Residential aged care and retirement living only
Leecare	Enterprise	Not published	None found	Residential-first

The buy-versus-build comparison

A 40-staff, 200-client provider pays roughly $600–1,440/month on ShiftCare, or ~$800–1,300/month on Brevity. Call it $12,000–17,000 a year for a maintained, vendor-supported platform with Services Australia claiming already working.

The quote asks $40,000 up front — roughly three years of a commercial subscription — to build a module that then needs maintaining forever. That comparison belongs in the conversation before anything is signed.

What the market tells us about scope

The vendors competing hardest on Support at Home are differentiating on funding mechanics, not rostering: quarterly budgets replacing daily fees, per-service client contributions, the claimable-service list, the 10% care-management cap, and direct Services Australia claiming.

That is exactly the section of the quote our source map marks hardest — and it confirms the Australian financial logic, not the care platform, is where the real work and real differentiation sit.

The claiming question this raises

AlayaCare, Brevity and ShiftCare all advertise direct API claiming to Services Australia. The quote never says whether claim submission is a direct integration or a CSV export — and those are wildly different commitments.

If competitors ship direct claiming as standard, a CSV export is not feature parity. Pin this down before signing: it is the single largest hidden scope item in the proposal.

Evidence limits on this section

All pricing above was read from live vendor pricing pages on 10 September 2026. Enterprise vendors publish nothing, implying materially higher cost. User reviews and complaints could not be gathered — Capterra, GetApp and Software Advice all returned 403 — so no claims about user satisfaction appear here. No vendor publishes implementation timelines. Carelink+ and e-Tools domains did not resolve; whether they still trade under those names is unverified.

Interface

The UI is not the hard part either

Every donor in this map ships a working interface. On top of that, SISO's component bank holds 8,538 catalogued components with curated picks. No screen in this product starts from a blank canvas.

Screen	Starting point	Bank coverage	Work required
Today / worker queue	careOS `today`	605 stat · 1,286 card	Retheme, AU labels
Participant record	careOS `office/clients/[id]`	81 tabs · 47 timeline	Add funding tab
Intake / referral	careOS `office/intake`	491 form	AU triage fields
Care plan + versions	folk-care `care-plans`	47 timeline · 72 modal	Approval UI
Schedule / visits	folk-care `scheduling-visits`	102 calendar · 14 schedule	Retheme
Visit detail + note	folk-care visits	491 form · 69 upload	Signature/addendum
Funding ledger	New — `sah`	176 table · 605 stat	Build — money table
Claims batch	New — `sah`	176 table · 12 kanban	Build — state pipeline
Monthly statement	New — `sah`	176 table · 113 chart	Build — print layout
Evidence register	careOS `office/evidence`	203 file · 176 table	Retheme
Standards dashboard	ciso-assistant	199 dashboard	Framework load
Requests (AT / home mod)	Grashjs/cmms pattern	12 kanban · 176 table	Build on request model
Admin / config	careOS `office/*`	48 sidebar · 491 form	Rule-version editor
Mobile (7 screens)	folk-care `packages/mobile`	native RN	Retheme, AU fields

Three screens are genuine new build — funding ledger, claims batch, monthly statement. Everything else is retheming and field changes on working interfaces. That is the practical reason the timeline is six weeks rather than fourteen.

Demo in a week

A clickable end-to-end demo — careOS running, Synthea participants loaded, care loop working, SISO theme applied — is a five-day job, and it is the same work as sprint zero rather than throwaway effort. It qualifies the donors and produces something to show at the same time. The money loop lands in the demo two weeks later.

Source document

The proposal, as quoted

Reproduced so every mapping in this document can be checked against what was actually offered. Feature names below are verbatim from the PDF; the F-codes used throughout this spec are ours, assigned in the order the proposal lists them.

Aged Care Module — Proposal & Delivery Packages 4 pages · SHA-256 a64cc3e5…2ff4e · received 9 Sep 2026

Project

Unicare – Support at Home (Aged Care Module). Prepared for: Client.

Stated sources

"Aged Care Module Scope Specification v1.0 (05/09/2026); internal codebase validation, Unicare platform"
— the v1.0 Scope Specification has never been supplied to us. See Open items.

Executive summary, verbatim

"Following the analysis of the proposed Aged Care Module requirements, our technical assessment confirms that it is feasible to add this new module into our Unicare platform but it does require modifications on the current architecture and building out new branches to fully support the Aged Cared Lifecycle. To provide flexibility we have prepared three different packages with different inclusions and timelines."

Package 1

$30,000

was $40,000 USD

8 weeks · F01–F14

"Small to medium providers looking to launch quickly with essential operational functionality."

Participant Management
Referrals & Intake
Care Plans
Assessments
Worker Visit Notes
Basic Clinical Records
Incident (SIRS) Management
User & Role Management
Dashboard
Standard Reports
Document Generation
Notifications
UI/UX Designs
SQA Testing end-to-end
Budget Management
Claim Processing
Participant Contributions
Monthly Statements
Assistive Technology
Home Modifications
Standards Dashboard
Evidence Management
Offline Functionality
Mobile Application

Package 2

$40,000

was $50,000 USD

12 weeks · + F15–F31

"Providers seeking a complete Support at Home solution operating entirely through a web platform." Everything in Package 1, plus:

Quarterly Budget Management
Funding Allocation Engine
Participant Contributions
Claim Management
Monthly Statements
Clinical Risk Register
Medication Management
Care Management
Restrictive Practices
Assistive Technology Requests
Home Modification Workflow
Standards Dashboard
Evidence Management
Finance Module
Configuration Centre
Advanced Reporting
Administration Portal

Platform: responsive web, desktop/tablet/mobile browser. "No Offline Capability."

Package 3

$50,000

was $65,000 USD

14 weeks · + F32

"Large organisations delivering care in the community, where staff need mobile app access alongside the complete web-based Support at Home solution." Everything in Package 2, plus:

"Aged Care Module fully available and built out for the mobile app"

That single line is the whole of Package 3's added scope: +$10,000 and +2 weeks.

Two things the comparison table adds that the scope lists never define

Page 3–4 of the proposal carries a feature-comparison grid. Two of its rows introduce grading that appears nowhere in the itemised package scopes above:

Comparison row	Package 1	Package 2	Package 3	Defined anywhere?
Clinical Management	Basic	Standard	Advanced	No
Reports	Standard	Standard	Advanced	No
Compliance Dashboard	Basic	✓	✓	Partially

Undefined grading is unpriceable as written and is the standard route to a mid-build change order — "that's Advanced, that's extra." Pin these to a field-level definition before signing, or strike them.

Feature map

All 32 quoted lines → source

Package 1 · quoted USD 30,000 / 8 weeks · ~85% covered

#	Quoted line	Status	Primary donor	Backup
F01	Participant Management	Have	careOS `office/clients`	folk-care client-demographics
F02	Referrals & Intake	Have	careOS `office/intake`	folk-care intake
F03	Care Plans	Have	folk-care `care-plans`	careOS `0010_careplan.sql`
F04	Assessments	Have	careOS `0005_forms_engine`	SurveyJS MIT / formily
F05	Worker Visit Notes	Have	folk-care visits	careOS `0045_verified_visit`
F06	Basic Clinical Records	Have	folk-care + careOS clinical	OpenEMR, Medplum
F07	Incident (SIRS)	Partial	folk-care incidents	SIRS rules → ZEN build
F08	User & Role Management	Have	careOS RBAC + OpenFGA	SpiceDB, Casbin, Keycloak
F09	Dashboard	Have	careOS `today`/`exec`	folk-care analytics
F10	Standard Reports	Have	folk-care analytics-reporting	careOS analytics
F11	Document Generation	Assemble	gotenberg MIT	jsreport, node-signpdf
F12	Notifications	Have	careOS `0036_notifications`	ntfy, Novu
F13	UI/UX Designs	Assemble	Both bases ship UI	refine MIT
F14	SQA Testing e2e	Have	folk-care 176 tests + 12 e2e	Synthea fixtures

Package 2 · quoted USD 40,000 / 12 weeks · ~80% covered

#	Quoted line	Status	Primary donor	Backup
F15	Quarterly Budget Mgmt	Assemble	openIMIS ceiling + period	Formance, django-ledger
F16	Funding Allocation Engine	Assemble	ZEN MIT	openIMIS calcrule
F17	Participant Contributions	Assemble	openIMIS contribution_plan	Formance numscript
F18	Claim Management	Assemble	openIMIS claim + claim_batch	OpenEMR X12/837
F19	Monthly Statements	Assemble	openIMIS closed-period trigger	Formance, bigcapital
F20	Clinical Risk Register	Assemble	folk-care quality-assurance	QAtrial patterns
F21	Medication Management	Have	folk-care med administration	OpenEMR
F22	Care Management	Have	careOS cadence	folk-care coordination
F23	Restrictive Practices	Build	careOS `0018_legal_authority`	Rule content irreducible
F24	Assistive Tech Requests	Assemble	Grashjs/cmms	leihs, openboxes
F25	Home Modification	Assemble	Same request core	OCA/field-service
F26	Standards Dashboard	Assemble	ciso-assistant	probo MIT
F27	Evidence Management	Have	careOS `office/evidence`	paperless-ngx
F28	Finance Module	Assemble	Formance MIT	openIMIS ledger, bigcapital
F29	Configuration Centre	Assemble	careOS visit-policy + ZEN	teable
F30	Advanced Reporting	Have	Both bases	—
F31	Administration Portal	Have	careOS `office/*`	refine MIT

Package 3 · quoted USD 50,000 / 14 weeks

F32 — one sentence, +USD 10,000, +2 weeks

The entire Package 3 addition reads: "Aged Care Module fully available and built out for the mobile app." No device list, no offline definition, no parity checklist.

folk-care already ships packages/mobile — 181 files, Expo 54 / RN 0.81, with an offline queue, conflict resolver and sync protocol. openIMIS ships a working Android claims app. CHT Core ships offline replication that enforces authorisation. Three independent working implementations.

Engineering rules

Non-negotiables for whoever builds this

Money

Integer minor units or tested decimal. Never floating point as ledger authority — folk-care's billing code uses floats; do not inherit that.
Reserve, deliver, charge, claim and pay are separate states. No double-counting committed against actual.
Closed periods immutable at the database, not in application code.
A missing rate or rule version blocks output. It never guesses.

Authorisation

IDs confer no access. Every read, write, download and background job checks independently.
Never trust a client-supplied header for identity or tenancy.
Negative tests are acceptance criteria, not cleanup: foreign tenant, unassigned worker, revoked session.

Clinical safety

Signed notes and medication administrations use correction/addendum, never silent overwrite.
Approval binds to an exact version hash. Editing approved content creates a new draft.
A restrictive-practice record is never permission to use one.
No LLM decides amounts, eligibility, medication instructions or reportability.

Rules & evidence

Every AU rate, threshold and split is a ZEN decision table with a version and a named human approver.
Effective dating is pinned to service date, not run date.
Synthetic fixtures display SYNTHETIC prominently.
Restore proof = database + files + config + external ID mappings. A dump alone is not recovery.

Before anyone starts

Open items

Two blockers

Aged Care Module Scope Specification v1.0, dated 05/09/2026. The proposal names this as its own source. It has never been supplied — so all 32 lines are module names with no field-level definition of done. That gap is exactly what gets billed against later.

Read access to Unicare. Extend, integrate or replace depends entirely on what is already there. Nothing ships without it.

Then: which package is being bought; is claim submission a direct integration or a CSV export; does "Finance Module" mean a funding subledger or full GL and payroll; who signs off the Australian rules; and does Package 3's mobile app require true offline — explicitly excluded from P1 and P2, never explicitly added to P3.

Licence positions to settle before code moves

folk-care — README says MIT, LICENSE says AGPL-3.0, GitHub API says NOASSERTION. The file governs. If it becomes the base rather than a transplant source, the product inherits AGPL. openIMIS — AGPL-3.0, Swiss jurisdiction (Berne). SurveyJS — runtime is MIT, but the Creator builder UI is commercially licensed by Devsoft Baltic OÜ. ciso-assistant — AGPL community, commercial enterprise/ directory.

Permissive spine available: careOS, ZEN, Formance, Synthea, cal.com, OpenFGA, Medplum, gotenberg, Timefold are all MIT or Apache-2.0.