Technology & AI
What must the technology prove?
Connect sources, permissions, work and accepted outcomes. Evaluate reliability, decision usefulness and full delivery cost before extending the system.
Inside this chapter
The technology path
Build the context that makes intelligence useful.
A model can draft, chase and organize. It cannot establish what is current, who has authority or whether a consequential decision was made by the right person. Rōvn is being built around those facts.
Technology architecture
A layered design keeps capability separate from authority.
Experience
Clinician platform · Facility OSOrchestration
Agents · workflow engine · exception routing · human reviewWorkforce graph
Workers · facilities · roles · requirements · evidence · permissions · decisions · state · outcomesTrust
Provenance · receipts · freshness · consent · audit · human authority · model/version trackingIntegration boundary
Primary sources · boards · registries · facility systems · ATS · HRIS · background providers · payersModel layer
Frontier models · model router · evaluations · shadow testing · permission boundariesModels provide capability. Rōvn provides context, authority, evidence, workflow and memory.
Integration names indicate a planned boundary and source category, not a claim that a connection is live.
The operating record · proposed architecture
Preserve the connection between context, action and result.
The record should explain a completed workflow: the situation, requirements, options, authorized decision, actions, exceptions and actual outcome. More stored records alone do not establish better intelligence.
- Source adapters
- Typed operating model
- Policy and mandate checks
- Durable workflow
- Authoritative destinations
- Outcome feedback
What the model needs to represent
- People and authority
- Worker, facility, site, department and responsible actor; the permission or mandate for this purpose and action.
- Evidence and requirements
- Source, version, timestamps, freshness and acceptance state; the requirement and policy that apply to this role and site.
- Resources and work
- Qualified availability, relevant resources, commitments, dependencies, deadlines and exception owners.
- Decisions and outcomes
- Options considered, authorized choice and basis, action receipt, receiving-system acknowledgement and independently confirmed outcome.
- Evaluation and economics
- Baseline, waits, human effort, agent/vendor cost, missed outcomes and recovery. Compare usefulness and reliability before extending the mandate.
Link events to the tenant, site, subject and workflow, with source version, purpose, actor and evidence pointers. Preserve source responsibility and correction history without copying sensitive payloads into every record.
One facility’s data, policies and private pipeline never inform another facility, including through learned weights or aggregates. Clinician-consented portable evidence and permitted non-facility information support cross-facility utility. Sharing consent is not training permission.
Inspect accepted handoffs and recovery →The event model · proposed
Give every operational fact a place, purpose and source of truth.
For a record to support execution or evaluation, the organization needs to distinguish a fact reported by a source, a facility’s interpretation of that fact, a prepared recommendation, an authorized action and what happened afterward.
| Question | Planned record field or receipt | Why it changes the workflow |
|---|---|---|
| Whose work is this? | Tenant, site, subject, workflow and the accountable owner. | Prevents a fact or action from drifting across facilities or departments. |
| What was known, and when? | Event and ingestion times, source, version, evidence pointer and freshness state. | Lets a new source event invalidate a decision that was prepared on old information. |
| Why was access allowed? | Purpose, consent or facility mandate, actor and action scope. | Makes the permission boundary inspectable and supports revocation. |
| What changed? | Before/after state, authorized decision, action receipt and destination acknowledgement. | Separates a requested change from a confirmed external result. |
| Did it help? | Outcome, elapsed waits, human effort, costs, exception and recovery history. | Makes a baseline comparison possible without treating activity volume as value. |
Sensitive source material need not be copied into every event. The model should preserve a pointer and purpose-limited access while the authoritative source keeps its declared responsibility. Corrections, withdrawals and expiries must invalidate dependent views and prepared work; a durable audit receipt does not imply that the old evidence remains usable.
Evaluation before intelligence
A forecast matters only if it improves a permitted decision.
Future intelligence is an operating capability to earn, not a label created by storing more data. Every proposed forecast or optimization needs a named user, decision, horizon, baseline and failure path.
- Start with availability at prediction time
- Use only inputs that would have existed when the forecast was made. Treat late events, corrections and future leakage as explicit evaluation problems, not data-cleaning details.
- Compare against a simple baseline
- Show error and calibration by the operating group that will use the result. A retrospective association or simulation does not show that an intervention improved the facility’s outcome.
- Require feasible options
- A recommendation has to respect qualifications, approved constraints, authority and actual resource limits. When no feasible staffing option exists, expose the shortfall and its owner instead of manufacturing an answer.
- Observe prospective use
- Measure whether authorized people found the proposal useful, what they overrode, what it cost to review, and whether realized outcomes improved without worsening the chosen workforce or safety measures.
- Keep a fallback
- When a forecast drifts, an integration changes or a model/vendor fails, restrict the use, recalibrate or return to the approved manual process with the affected state visible.
Facility intelligence develops only in its authorized context. One facility’s private data, policies and pipeline never inform another facility, including through learned weights or aggregates. Consent to share a career record is not permission to train a model.
What compounds
Completed work can give the next workflow a better start.
Rōvn’s technology thesis centers on the operating record: source evidence, permissions, decisions and a history of accepted reuse. Models can improve over time while that context preserves what the workflow requires and what happened before.
Workforce graph
The graph preserves the relationship around each action, not a loose collection of profiles.
GRAPH
- Workers
- Facilities
- Roles
- Requirements
- Evidence
- Permissions
- Decisions
- Relationships
- Workflow state
- Outcomes
The graph is a planned representation of permissioned relationships. It does not infer authority or override local facility policy.
The same record could support a clinician’s career history and help a facility understand its own delays, readiness and outcomes. Broader network and intelligence products need evidence of repeat use, useful decisions and permitted inputs.
Compounding value is a thesis to validate through real workflows and documented acceptance. No shared model or analytics product gains rights to another facility’s private data.
Examine the workforce intelligence thesis →The boundary
Models prepare work. Named people make consequential calls.
AI and model governance
Model output enters a controlled workflow; it does not become authority by itself.
- 01Scoped inputPermission and task context define the allowed work.
- 02Model routerRoutes capability behind explicit boundaries.
- 03EvaluationVersion, quality and failure patterns are recorded.
- 04Shadow testingPotential changes are assessed before workflow use.
- 05Human authorityExceptions and consequential decisions route to people.
Source evidence and the facility’s decision remain independent of model output. A task must have an explicit scope, a permitted actor and a review path before a model is used around it.
Deployment plan, October 1, 2026: a sealed exam on at least three models from two or more vendors, a published test card for each, and signed vendor terms before activation. Current activation status is in the readiness record.
Research and build plan
Six technology bets to test.
Each bet has a proposed first proof and a measure. These are research and implementation goals, with December 31, 2026 as the target for the first proof work. Real-data and AI activation remain subject to the readiness requirements.
- 01 · Time the whole path
- Record each step, wait and owner from open role to first shift. First proof: one timed start beside the facility’s baseline. Measure elapsed time and the share spent waiting.
- 02 · Prepare the decision
- Put requirements, dated evidence and exceptions on one decision page. First proof: a staging checker that connects claims to evidence and routes unchecked items to a person. Measure unchecked claims reaching action and administrative minutes.
- 03 · Compare source checks
- Run permitted checks beside the facility’s existing process before relying on them. First proof: a documented comparison with source rights established. Measure false alerts and time from a confirmed change to the responsible person.
- 04 · Earn one action class
- Begin with document-follow-up messages that a person approves before sending. First proof: synthetic staging cases with approval and edits recorded. Measure approval without editing and unsafe actions.
- 05 · Establish accepted reuse
- Let a clinician offer eligible evidence to a named second facility. First proof: written acceptance criteria, followed by an accepted check. Measure checks accepted without being rebuilt; each facility keeps its own decisions and background report.
- 06 · Test a capacity forecast
- Backtest public staffing data against a simple baseline. First proof: a published comparison with error shown. A forecast would be offered only if the comparison supports it, with an operator correction window before publication.
The earning sequence
Capability expands only after the record and the controls hold.
- Initial architecture · plan
- Use frontier models behind task-specific permissions and evaluations. Preserve source evidence, logs and consequential decisions outside model output.
- 2027 · goal
- Publish current model evaluations and operate authorized workflows at paying facilities, with evidence of what worked and what did not.
- 2030 · goal
- Develop narrow models trained on the appropriately permitted operating record, running alongside rented frontier models with published evaluation cards. This goal depends on having the data, permissions and evidence to support training.
- Long-term vision
- Build the coordination and operating dataset that future superintelligent systems could use in healthcare, with permission, source evidence and outcomes preserved and people retaining consequential decisions.