Runtime architecture

Identity, policy, and execution authority

Application keys bind a tenant, app, environment, expiry, revocation state, and route capability. The gateway selects the exact assigned policy ID and version, preferring an application assignment over that tenant environment’s default. Missing or ambiguous production authority fails before provider dispatch.

A registered text skill binds its schema, destination, data class, budgets, policy, alignment, and credential revision into an execution grant. Authority is refreshed before and after execution, and intent and result records use the audit outbox. Deterministic checks control effects; advisory model output cannot grant tools or approve release.

Supported input and release behavior

The chat endpoint accepts bounded text messages and supported generation options. Images, audio, tool calls, streaming, and unknown fields are rejected. JSON sanitization recursively evaluates supported JSON values, including normalized FHIR content and structured credential fields. Detection remains heuristic and does not establish complete de-identification, clinical validity, or legal compliance.

ALLOW and ALLOW_WITH_WARNINGS may release data. REDACTED releases only a transformed artifact that passes revalidation. BLOCKED and ESCALATE_HITL withhold data. A requested remediation is an obligation; completed enforcement receipts record what actually ran. A hold alone does not mean that a human approved the output.

Provider and connector boundaries

OpenAI, OpenAI-compatible, and Anthropic adapters use tenant-bound HTTPS destinations, DNS admission with pinned resolution, redirect rejection, byte limits, cancellation, deadlines, and bounded retries. Circuit breakers are scoped to tenant and endpoint within one process; distributed capacity and hosted network behavior still need qualification. Persisted tenant provider keys use authenticated encryption bound to the tenant, provider, and canonical endpoint. Legacy plaintext credentials require an explicit migration.

Epic diagnostic scenarios retain real OAuth and FHIR sandbox Patient read/search. Simulated connectors perform no network effect. Public JWKS publishes only validated public RSA fields; private signing material belongs on the gateway host. The connector does not write to Epic or provide a qualified clinical release workflow.

Evaluation profiles and deliberate diagnostics

Guided scenarios select versioned synthetic fixtures using server-validated scenario and tier identifiers bound to the configured demo app. Their raw diagnostic panel shows that fixture, and their governed panel shows the measured enforcement result. Caller content cannot become an observe-mode authority grant. Freeform requests remain enforced.

Approved descriptive alignment still needs an executable capability adapter before it can authorize runtime behavior. Clinical high-risk, current regulatory evidence, generated-code execution, and unrestricted customer agents remain unsupported and held. Engineering review skills in the repository organize implementation work; they do not grant product-runtime permissions.

Data handling and evidence

Ordinary runtime decision and grant records contain derived findings, identifiers, and digests. This is not a claim that every database table is raw-free: Epic sandbox diagnostic snapshots and uploaded evaluation material have separate storage and retention paths. Explicitly enrolled nonclinical apps use purpose-bound encrypted artifacts for exact-output review; held content is excluded from ordinary decision telemetry. Review is limited by the original grant expiry and returns final content only to the original application audience.

Review the current enterprise-readiness page and deployment evidence before using a profile with real regulated data. Backup restoration, load and outage behavior, tenant isolation in the deployed topology, incident response, and domain validation remain deployment-specific qualification work.

Deployment topologies

These diagrams illustrate proposed customer VPC and API integration patterns. They are architectural options, not evidence that each topology has been deployed or qualified. Select and test identity, networking, storage, retention, and observability for the actual environment before production use.

Figure 1. Illustrative LSAS Platform deployment in a customer VPC alongside existing identity, APIs, and observability.

Figure 2. Payload sanitize endpoint in front of existing customer APIs, returning a sanitized payload plus LSAS Platform metadata.