How CHRIS-OS works

Not a dashboard.
An operational operating system.

CHRIS-OS is middleware. It sits above every system your organisation already runs — clinical, rostering, HR, finance, WHS, incident management — ingests their data into a single canonical layer, and runs seven AI agents continuously on top of it.

The output is not a report. It is work done — documents drafted, submissions filed, leaders briefed, actions queued. Every output is timestamped, append-only, and auditable by regulators.

System architecture

Three layers. One system.

Source systems flow in. Intelligence flows up. Actions flow out. CHRIS-OS is the connective tissue — the layer that didn't exist.

SOURCE SYSTEMSCANONICAL LAYERAGENT LAYEROUTPUTSClinical systemLeecare · Epicor · AutumnCareRosteringDeputy · HumanforceHR & payrollELMO · Employment HeroFinanceTechOne · MYOB · XeroIncidents & WHSRiskMan · SafetyCultureACQSC & GPMSGovernment portalPulse surveysNative to CHRIS-OSCanonical data schema11 domains8 source system categories16 PSH hazard domainsDe-identified at boundaryAppend-only · TimestampedRow-level security (RLS)Neon Postgres · Drizzle ORMThe Sentinel2-hrThe OracleWeeklyThe StewardDailyThe ChroniclerEventThe KeeperFortnightlyThe Town CrierContinuousThe Curator2-hrPowered by Claude API (Anthropic)Monday BriefingSIRS notificationsQI submissionsBoard packsCare minutes alertsDON review queueNewsroom / CuratorVia iMessage + portal
01
Source systems
CHRIS connects to the systems providers already run — rostering, clinical, HR, finance, WHS, GPMS. No rip and replace.
02
Canonical layer
Every connector normalises data into a single schema. De-identified at the boundary. Append-only. The schema is the IP.
03
Agent layer
Seven AI agents run continuously on the canonical data. Each has a domain, a cadence, and a job.
04
Execution outputs
Agents produce work — not dashboards. Drafted documents, queued actions, filed submissions, delivered briefings.
The execution model

How a signal becomes an action.

From data ingestion to approved submission — four stages, all automated except the moment that requires human judgement.

01
Data ingestion

Connectors pull from source systems

CHRIS connects to your existing systems via authenticated API connectors. Each connector runs on a schedule — rostering every 15 minutes, HR daily, finance on-demand. Data is normalised at the connector boundary before it enters the canonical layer. Individual names are never stored — aggregation happens first. This eliminates Privacy Act exposure and makes CHRIS safe to position to staff, unions, and regulators.

02
Data model

The canonical layer creates a unified picture

All source data lands in a single Postgres schema — the canonical layer. Every table is append-only and timestamped. No data is ever modified or deleted — only new rows are added. This creates a complete, auditable history of every operational signal CHRIS has ever seen. The canonical schema spans 11 domains and 8 source system categories.

03
Intelligence layer

Agents run continuously on the canonical data

Seven agents run on scheduled cycles or event triggers. Each agent reads from the canonical layer, applies its intelligence model, and produces structured outputs — queue items, drafted documents, briefings, or submissions. Agents are built on Claude (Anthropic's API) with structured system prompts per domain. The Town Crier coordinates across agents to prevent alert fatigue.

04
Execution

Leaders approve. CHRIS executes.

CHRIS never acts autonomously on anything consequential. Every output lands in a review queue with context, evidence, and a single approval button. The DON's job is review and authorise — not author and compile. Once approved, CHRIS executes: submitting to GPMS, filing with ACQSC, delivering to leaders via iMessage. Every execution is logged and timestamped.

The seven agents

Every domain. Always on.

Each agent has a specific domain, a defined cadence, and a set of outputs. Together they watch every dimension of an aged care organisation simultaneously.

The Sentinel2-hr cycle
Clinical & compliance vigilance

Monitors care minutes per shift and day, 24/7 RN coverage, SIRS incident classification, clinical audit schedule, and roster compliance. Triggers alerts when thresholds are breached.

Care minutes alertSIRS draft notificationRoster gap alertCompliance breach notice
The OracleWeekly
Revenue & funding intelligence

Scans AN-ACC classifications for reclassification opportunities, benchmarks financial performance against StewartBrown data, identifies accommodation pricing optimisation, and surfaces revenue gaps.

AN-ACC reclassification briefRevenue gap analysisStewartBrown benchmark reportFunding forecast
The StewardDaily
Capacity & operational structure

Analyses rostering patterns for structural gaps — not individual missed shifts, but repeating patterns that indicate a permanent staffing problem. Surfaces root causes and recommendations.

Structural gap briefAgency dependency analysisRoster optimisation recommendation
The ChroniclerEvent-driven
Auto-documentation & evidence

Triggered by incident events. Drafts SIRS notifications, corrective action plans, board pack entries, and QI submission data. The DON reviews and approves — not authors.

SIRS notification draftCorrective action planBoard pack entryQI submission data
The KeeperFortnightly
Workforce intelligence & people health

Analyses psychosocial hazard signals from pulse surveys across all 16 ISO 45003 domains. Detects convergence events, identifies turnover precursors, and prescribes evidence-based micro-practices.

Monday BriefingTeam BriefingPSH convergence alertISO 45003 evidence pack
The Town CrierContinuous
Signal coordination & clarity

Coordinates output across all other agents. When the Sentinel and Steward both flag the same issue, the Town Crier decides what reaches which leader and when. One coordinated signal, not five separate alerts.

Coordinated briefingEscalation routingAlert suppressionCross-agent synthesis
The Curator2-hr cycle
Sector intelligence & regulatory watch

Monitors 35 external sources — government, regulators, legal analysis, sector news — every 2 hours. Surfaces regulatory changes, sector developments, and compliance intelligence. Powers The Newsroom.

Newsroom intelligence feedWeekly regulatory reportRegulatory change alert
The execution model

CHRIS doesn't tell you what to do.
It does it.

The distinction between a tool and a platform is this: a tool gives you information. A platform delivers work. CHRIS delivers work — and waits for your approval.

Documents drafted, not described

When an event occurs — a fall, a complaint, a SIRS trigger — the Chronicler drafts the required documentation within minutes. SIRS notification, corrective action plan, board pack entry. The DON receives a draft ready for review, not an alert telling them to write one.

"SIRS Priority 1 detected — Wattle Wing. Draft notification ready. 22 hours remaining. Penalty exposure: $330,000 if missed."

Actions queued, not alerted

Every output lands in a structured review queue with context, evidence, deadline, and a single action button. The DON sees three ranked actions for today — not forty alerts. Each card has everything needed to decide in under 90 seconds.

"AN-ACC reclassification: 3 residents identified. Estimated uplift: $11,400/month. Optimal assessment window: Tuesday morning."

Submissions filed, not prepared

CHRIS compiles QI data, formats it to the GPMS schema, and submits directly to the ACQSC portal after DON approval. The GPMS reference number is logged automatically. The DON never touches the GPMS portal.

"Q2 QI submission: data compiled. 14 indicators ready. Deadline: 11 August. [Review and approve →]"

Leaders briefed before they arrive

Every leader receives a briefing tailored to their role — the Monday Briefing for the DON, team briefings for team leaders, board packs for the Board. Delivered via iMessage before they walk in the door.

"Your Monday Briefing is ready. 4 signals · 3 actions · 8 minutes to read. Care minutes strong. AN-ACC opportunity flagged."
The stack

Built for production.
Deployed in Australian aged care.

Built on the same cloud infrastructure used by Australia's major health systems. No on-premise hardware. No IT project. Connected to your existing systems within weeks, not months.

Frontend
  • Next.js 15
    App Router, ISR, Server Components
  • TypeScript
    Full type safety across frontend and API
  • React 19
    Server and client components
  • Tailwind CSS
    Custom design system — forest, teal, cream
Database
  • Neon (Postgres)
    Serverless Postgres with connection pooling
  • Drizzle ORM
    Type-safe schema and migrations
  • Row-Level Security
    Multi-tenant isolation enforced at DB layer
  • Append-only design
    No deletes — full audit trail by design
AI & agents
  • Claude API (Anthropic)
    claude-sonnet-4 — intelligence and generation
  • Web search tool
    Live research for The Curator agent
  • Structured outputs
    JSON schema outputs for all agent actions
  • Simulation engine
    28 scenarios, 99% pass rate
Infrastructure
  • Vercel
    Edge deployment — auto-scaling Next.js
  • Google Cloud Run
    Agent workers — australia-southeast1
  • GitHub Actions
    CI/CD with automated simulation tests
  • Monorepo (Turborepo)
    5 packages: web, db, shared, connectors, engines
Auth & notifications
  • Passwordless auth
    Magic link — no password risk
  • Twilio
    iMessage and SMS delivery for alerts
  • Resend
    Transactional email for governance packs
  • Push notifications
    In-app for team leader briefings
Connectors
  • Deputy (live)
    Rostering — open API, highest priority
  • Humanforce (building)
    Rostering — enterprise aged care
  • ELMO / Employment Hero
    HR & payroll — Phase 2
  • RiskMan / SafetyCulture
    Incidents & WHS — Phase 3
Security & privacy

Built for a regulated environment.

Aged care handles some of Australia's most sensitive personal data. CHRIS is designed from the ground up for that environment — not adapted to it after the fact.

De-identified at the connector boundary
Individual staff names are never ingested into the canonical layer. Aggregation happens at the connector level — CHRIS sees patterns in populations, not behaviour of individuals. This eliminates Privacy Act exposure.
Row-level security enforced at the database
Every database query is scoped to a single provider by Postgres RLS. Provider A's data cannot be accessed by Provider B under any circumstances — the isolation is enforced at the storage layer, not the application layer.
Append-only audit trail
No data in the canonical layer is ever modified or deleted. Every record is immutable and timestamped. When ACQSC comes to audit, CHRIS can reconstruct the compliance evidence for any period.
Australian data residency
All compute and storage runs in Google Cloud australia-southeast1 (Sydney). No data is processed or stored outside Australia. This is the architecture, not a configuration option.
No passwords — magic link authentication
CHRIS uses passwordless authentication with magic links. There are no passwords to breach, phish, or reuse. Access is email-verified and session-scoped.
Submission approval always requires a human
CHRIS never submits to ACQSC, GPMS, or any regulatory body autonomously. Every submission requires explicit DON approval. The approval is timestamped and logged as compliance evidence.