Enterprise Questions, Answered

LSAS Platform is an AI governance evaluation platform with alignment workflows, structured assessments, policy validators, a model gateway, and connector boundary demonstrations. Supported text and payload paths produce decisions and findings. Enterprise hardening is under verification; production healthcare qualification has not been established. See the public enterprise-readiness page for current scope.

LSAS Platform combines decision records with controls on supported inputs and outputs. The gateway applies configured pattern validators and release rules. The sandbox also includes deliberately observed and simulated examples; those examples do not establish production enforcement.

A finding records the checks, policy context, and observations behind a decision. Structured assessments can check supplied evidence references and coverage. That trace does not prove source authenticity, factual truth, clinical correctness, or complete risk detection.

The current implementation does not independently verify arbitrary citations or factual claims against authoritative sources. Guided examples illustrate those risks, and the governed execution path withholds release when a required verification capability is unavailable. A pattern check or a supplied citation must not be presented as verified grounding.

LSAS Platform demonstrates boundary controls around an Epic sandbox integration using OAuth and FHIR. Its patient read and search presets make real requests to Epic's synthetic sandbox, alongside explicit simulation modes. This is a scoped integration demonstration, not an Epic certification or validated clinical workflow.

Storage depends on the subsystem. Gateway decision events contain derived telemetry, while connector payload snapshots, Run Engine assessment inputs and reports, and saved workflow definitions can contain raw supplied content. Configured external providers receive the content needed for their requests. Review the privacy page and retention configuration before supplying sensitive data; use synthetic data in the public sandbox.

LSAS Platform can be evaluated as part of a governance program. Suitability for a regulated production use has not been established. It requires verified controls, customer-specific identity and infrastructure evidence, intended-use assessment, and independent security and domain review. No certification or clinical validation is claimed.

Out of the box, LSAS Platform includes validators and policy controls for PHI and PII, PCI-like patterns, security and secrets exposure, prompt-injection patterns, and accessibility-related copy risks.

The adapter interface separates policy evaluation from supported model providers. Each provider, endpoint, model, and input format still needs explicit configuration and compatibility testing; provider independence does not imply universal API support.

Current runtime integrations cover OpenAI-compatible endpoints and Anthropic in this reference stack. Teams can extend provider adapters to support additional targets and enterprise routing patterns.

A native AWS Bedrock adapter is not included in the current reference implementation. The provider adapter interface offers an extension point, but Bedrock authentication, request mapping, transport controls, and integration tests would need implementation before claiming support.

The public sandbox is available for synthetic evaluation. Private single-tenant, customer cloud/VPC, and on-premises deployments are architecture options to qualify with the operator. The repository does not automatically provision their identity, network, residency, backup, or support controls. External provider access must be accounted for in each topology.

Teams can explore governance requirements and structured evidence handling using synthetic legal or advisory cases. Source authenticity and legal correctness are not established by the current validators. These demonstrations are not qualified for autonomous professional advice or release of client work product.

LSAS Platform models tenants, apps, memberships, and role-based access so teams can separate duties across security, compliance, and engineering while keeping a shared view of policy posture.

A proposed evaluation starts with intended use and data boundaries, followed by synthetic scenarios, control and failure testing, and deployment qualification. Milestones should depend on evidence and unresolved findings, rather than a promised 90-day production date.

The sandbox lets teams inspect example decisions and discuss their control requirements immediately. We do not have published customer outcome or time-to-production evidence. Deployment timing depends on the intended use and completion of its qualification gates.

Policy packs are versioned, assignable per tenant, app, and environment, and tied to decision telemetry. This supports change review and incident reconstruction with clear evidence of what policy version was active at decision time.

Evaluate reviewed policy packs against representative labeled examples, including missed detections and benign inputs, before changing assignments. Guided sandbox risk tiers compare fixtures; they do not edit an application's enforced policy. Pattern validators have limitations and require independent validation for the intended data.

The public sandbox includes a simulated override journey with explicit confirmation. Its recorded events are labeled public simulation activity, not authoritative tenant approvals, and it does not resume a real blocked action. The separate protected nonclinical review profile binds an assigned reviewer to an exact artifact and requires application consumption after approval. Its current grant lasts60seconds including generation; it is not a clinical sign-off workflow.

Pricing is aligned to deployment scope, tenant and environment footprint, and governance depth. The pricing page provides current package guidance and your team can map expected traffic and control requirements during discovery.

Agree the deliverables, support ownership, intended use, and acceptance evidence explicitly. Available evaluation surfaces include onboarding, policy assignments, telemetry, and assessment reports. A package description does not establish a production SLA, certification, or validated healthcare deployment.

A production decision requires demonstrated authorization and isolation, suitable validation coverage, migration and recovery rehearsals, capacity evidence, incident ownership, and customer-specific security and domain review. A successful sandbox or passing local tests alone is insufficient. The current enterprise-readiness page lists the qualification limits.