Security & trust
Enterprise readinessThe architecture
is the control.
Written for the reviewer who signs. The firmwide standard is client-boundary execution, explicit identity, fail-closed gates, human authority, and a verifiable operating record. The HealthNext topology below shows that standard under protected health information (PHI) and clinical-decision constraints.
01 / Firmwide control architecture
Security begins with the production boundary.
The firmwide standard connects architecture, identity, AI policy, evaluation, release authority, runtime operations, and transfer. The control layers below pair each governed scope with the review artifact carried into the engagement record.
01Execution boundary
Named environments, systems, data classes, tenancy, network routes, approved destinations, retention, and operating ownership.
Review artifactArchitecture + data-flow record
02Identity and authority
Client-issued identities, least-privilege roles, typed tool permissions, human approval points, observation, elevation, and revocation.
Review artifactAccess + authority matrix
03Model and context policy
Approved models, provider path, source authority, retrieval behavior, prompt and policy versions, and permitted data classes.
Review artifactModel, tool + source register
04Evaluation and release
Representative cases, deterministic and model checks, thresholds, exceptions, shadow evidence, release authority, rollback, and stop paths.
Review artifactEvaluation + release disposition
05Runtime evidence and response
Telemetry, change records, service ownership, failure handling, incident response, durable evidence, and the improvement loop.
Review artifactRunbook + operating record
06Continuity and transfer
Repositories, configuration, infrastructure definitions, extension points, named owners, succession, data handling, and exit terms.
Review artifactHandover + continuity plan
02 / HealthNext reference implementation
The boundary, made explicit.
The following applied topology shows the firmwide standard under PHI, tenant isolation, clinical-review, and determination-record constraints. Package labels refer to the HealthNext implementation.
Agreed deployment boundary
Client-controlled cloud or private cloud, or a dedicated single-tenant environment operated under the business associate agreement (BAA).
Authorized access
Named identities and approved data flows
tenancy-abacGated inference
Approved endpoint and fail-closed model calls
modelops · phi-gateHuman authority
Clinical review and physician-signed adverse determinations
agent-harnessDurable determination record Per-tenant signatures and a write-once evidence chain
audit-evidenceAcross the boundary
De-identified metrics.
Verifiable receipts.
The receipt carries the shape of a decision. The member stays inside the agreed boundary.
Open the browser verifierImplementation detail
Six controls. Each mapped to its enforcing package.
- 01
modelopsPHI stays inside the agreed deployment boundary
The signed data architecture sets the boundary: your client-controlled cloud or private-cloud environment, or a dedicated single-tenant environment operated under the BAA. The data plane and inference endpoint follow that topology, with tenant isolation, approved data flows and client-authorized access captured in the engagement charter.
- 02
phi-gateA PHI gate that blocks, not redacts
The gate is enforced at construction — an un-gated model client cannot be built — and is applied to every model completion, where it fails closed. Redaction is a best-effort transformation that can miss; blocking is a refusal. If the gate cannot establish that a payload is safe, the call does not happen.
- 03
tenancy-abacNamed, auditable privileged access
Emergency access follows an explicit, logged approval path with named ownership. Deployment-specific access policy is defined in the engagement architecture.
- 04
canonicalMetrics leave de-identified
Operational metrics are de-identified where they are produced rather than scrubbed on the way out. The receipt that leaves your boundary carries the shape of a decision — never the member behind it.
- 05
audit-evidenceIndependently verifiable by your auditor
Each determination is signed with the deployment's per-tenant key and folded into a write-once chain. A governed decision is added to the record, never altered or deleted. The verifier recomputes the chain and checks signatures against a public key — no server, no call back to us.
- 06
agent-harnessEvery adverse determination carries a clinician's signature
The model assembles and recommends. Issuing a determination is not a capability the agent has. A licensed physician stands behind every medical-necessity denial, and the architecture enforces that rather than documenting it.
03 / How to check it
How to check each control
- 01
Compliance is architectural and checkable. The PHI boundary, the fail-closed gate and the evidence chain are enforced in construction. Reviewers can inspect each control within the agreed deployment boundary and retain the supporting artifacts.
- 02
Seeded records and scenarios on this site are synthetic. Public experiences are designed around synthetic examples. Client deployments enforce the agreed data, model, and integration boundary, with source access governed by client controls.
- 03
Payer connectivity is scoped per engagement. Connectivity runs from the client-controlled environment or dedicated single-tenant boundary, on credentials the client authorizes and can revoke, against the systems named in the charter.
- 04
The evidence chain verifies without us. Ed25519 over canonical JSON. Check any receipt yourself at /verify — it runs in your browser and makes no call back to us.
04 / Continuity and exit governance
Keep the operating record available.
On termination, data return and destruction follow the agreed client policy. The tamper-evident evidence chain remains available for the required retention lifecycle, so later review can reconstruct what happened from the same durable operating record.