Trust and security
What has to be true before deployment?
The required controls and the current readiness record, so investors can see the work ahead as well as the product design.
Read the hard questionsInside this chapter
Human decision boundary
Agents prepare authorized work. Named people retain consequential decisions.
Agent work
- Assemble evidence
- Check permitted requirements
- Prepare a task and receipt
- Route an exception
Named authority
Review the evidenceand decideHire · offer · start and facility policy decisions remain with accountable people.
Operating record
- Permission and scope
- Source and freshness
- Decision and rationale
- Receiving acknowledgement
The visual describes a control boundary: agents prepare authorized work and named people retain consequential decisions.
Permission and evidence are part of the workflow.
- Clinician control
- Sharing is scoped, logged and revocable. Eligible evidence can travel with consent; private employer decisions do not.
- Source truth
- A document, model answer or human review does not become a primary-source check. Missing, stale and conflicting evidence stays visible.
- Human authority
- A named person makes consequential decisions. Agents do not independently hire, reject, credential, privilege or assign workers.
- Tenant boundaries
- One facility’s data, policies and private pipeline never inform another facility, including through learned weights or aggregates. Cross-facility utility uses clinician-consented portable evidence and permitted non-facility information. Each facility orders its own background report.
Operating-map preparation does not authorize patient-data collection or a new live workflow. Patient/clinical and marketplace expansion each require their own written decision, data/security review, demonstrated demand and release evidence. These are product requirements and design boundaries. Deployment assurance depends on the evidence for the specific release.
Readiness record · October 1, 2026
The conditions for activation.
- Commercial operation
- Current: pre-revenue, with no paying customer or signed pilot. The next milestone is a signed, scoped paid pilot with a baseline.
- Product data
- Current demonstrations use synthetic data. Real clinician data requires the penetration test and fixes, restore drill and incident rehearsal.
- AI activation
- AI is off in production pending the sealed exam, model test cards and signed vendor terms. The exam plan covers at least three models from two or more vendors.
- Security assurance
- SOC 2 has not started. An independent penetration test and restore drill have not been completed. They are deployment-readiness work, not claimed certifications.
- Vendor agreement
- One business associate agreement is on record with Google Cloud, July 13, 2026. That agreement does not establish Rōvn-wide compliance or authorize a new data scope.
Source: October 1, 2026 company facts and reviewed room rules. Supporting security and legal evidence is available according to its diligence access scope.
Keep the meaning of each record intact.
A clinician-provided document, an authoritative source check, a reviewer’s acceptance and a hiring decision are different records. The system must retain those distinctions so an administrative convenience cannot silently become a claim of verification or permission.
- Portable clinician evidence
- Eligible evidence can be offered for reuse with the clinician’s permission, its provenance and freshness visible. The receiving facility decides whether it satisfies its own requirement.
- Facility-private context
- Policies, private pipelines and decisions remain within the facility’s permitted context. They cannot inform another facility through direct access, model weights or aggregate products.
- Background screening
- Each facility orders its own report through its authorized route. A previous employer’s report is not treated as a portable hiring clearance.
- Health information
- The health vendor retains the actual results. Rōvn uses the permitted pass or pending status for the workflow rather than copying clinical results into a career profile.
- Model-generated work
- A summary, suggested plan or draft remains attributable to the model and task. It cannot replace the source record, create authority or establish that an action succeeded.
These distinctions also make corrections tractable. When an underlying source or identity changes, the system can identify dependent work and reopen what needs review rather than treating every prior state as permanently valid.
Permission has a lifecycle.
The designed permission record should identify the principal, purpose, data or task, recipient, scope and applicable expiry. The clinician’s mandate and the facility’s mandate remain separate. An agent helping a clinician assemble a record does not acquire the facility’s authority to hire that clinician.
Revocation must affect future access and dependent use within the revoked scope. Corrections should preserve a traceable history and notify the affected authorized workflow. Export gives the clinician usable access to their eligible record; it does not export another party’s private decisions or expand rights to source material.
How to discuss deletion and retention precisely
Revoking sharing, correcting a record, exporting eligible evidence and deleting stored data are different actions. Their treatment depends on the data type, agreements and applicable obligations. The product must explain what changed and what remains retained for a legitimate purpose.
The investor claim is the designed control and the evidence for its implementation. We do not promise that revocation erases every historical recipient record or overrides a facility’s independent obligations. A deployment review needs the actual retention and access rules for the selected scope.
Make authority visible at the point of action.
The proposed workflow prepares evidence and options for the person entitled to decide. Consequential decisions include hiring, offers, rejection, credentialing, privileging, assignment, scheduling and starts where applicable. Permission to collect or summarize information is not permission to make those decisions.
An action needs the right authority for its task and destination, current supporting state and a record of its result. If the result is uncertain, reconcile it before repeating the action. If requirements conflict or no eligible option exists, surface that condition with an accountable owner. A plausible recommendation does not remove the conflict.
Model versions should be evaluated for the permitted task and compared with a baseline. Changed model behavior, missed exceptions or excessive human correction can narrow or stop that task’s authorization. The technology chapter describes the proposed evaluation and event architecture.
Match assurance to the actual release.
Deployment review should connect each requirement to evidence for the exact scope being activated: source rights, identity and tenant isolation, access handling, restore and incident behavior, permitted model use and recovery from interrupted work. A vendor agreement or a successful demo supports only the question it actually answers.
The current dated readiness record above consolidates the remaining activation work. Future claims should identify what was tested, by whom, against which release and with what unresolved findings. A broader clinical or marketplace package needs its own written decision and data/security review; mapping a department does not grant access to its patient records.
The aim is an operation the customer can understand and control. Investors should be able to follow a case from source to permission to action to accepted outcome, and inspect what happens when any of those links fails.