Where it sits, what it touches, and what it will not do.
Written for the people who have to integrate it rather than buy it. It covers the placement of StromaOS relative to systems you already run, the read and write surface, how control is applied, the four deployment postures, and the boundaries the platform is designed not to cross.
01Placement
StromaOS assumes you already have a data estate and does not attempt to replace it. It composes above your storage and warehousing layer and below the functional systems your teams work in.
- Below it - your lakehouse, warehouse, clinical data repository, safety database, document management system and licensed reference data. StromaOS reads from these in place. Where a posture allows it, nothing is copied out.
- Beside it - identity, secrets management, logging and observability, and your existing validation regime. StromaOS federates to your identity provider rather than maintaining a parallel user directory.
- Above it - the functional destinations for work product: submission gateways, safety reporting, document systems, analytics tooling. StromaOS produces artifacts these systems accept; it does not become the place work lives.
02Read and write surface
The integration surface is deliberately narrow, because a wide one is what makes governed systems hard to validate.
Reads
| Structured clinical and operational data | Via your existing connection method - warehouse query, mounted volume, or governed extract. Access is scoped per Fleet, not per platform. |
| Licensed reference and terminology assets | Entitlement is verified before any resolution. Where your license does not cover a use, the work is refused rather than degraded silently. |
| Documents and unstructured sources | Read for extraction and grounding. Provenance is retained at the passage level so any assertion can be traced back to its source. |
| Policy and control definitions | Your control set, expressed as executable policy. This is authored with you; the platform does not ship an opinion about your controls. |
Writes
| Work product | Datasets, analyses, documents and packages, in the formats the receiving system expects. |
| Evidence records | An open, queryable schema recording inputs, method, controls evaluated, exceptions and human authority. Exportable and readable without the platform. |
| Knowledge Management | Reusable structure - cohort definitions, mappings, method configurations - held inside the deployment boundary you choose, so the second study does not rebuild the first. |
| Nothing else | StromaOS does not write back into your systems of record unless you explicitly configure it to, and every such path is a named, controlled integration rather than a default. |
03How control is applied
The architectural claim worth reviewing is this one: control executes while the work runs, not after it. Three mechanisms carry it.
Policy evaluated before dispatch
Every action an AI agent proposes is evaluated against the applicable control set before it reaches a model or an engine. A control that fails stops the action - it does not annotate a report that someone reads later. The refusal itself becomes part of the record.
Decision rights resolved to a named human
Decisions that require authority are routed to a named individual holding that right in your organization, and the record captures what their signature meant. The platform computes, ranks and drafts; it does not decide.
Methods qualified for their intended use
Statistical and analytical methods carry a qualification state. A method not approved for the governance profile in force cannot execute under it, regardless of who requests it.
04Deployment postures
Four postures, chosen by where your data has to stay. The posture changes the integration work materially, so it is the first question worth settling.
| Posture | Where execution happens | Integration implication |
|---|---|---|
| Managed | Operated for you | Lowest integration effort. Data reaches the platform through governed transfer; suits functions where the data is already externally processed. |
| Your VPC | Your cloud account, your network | Execution and data both remain in your perimeter. Requires network, identity and key management work with your platform team. |
| Embedded | Inside the data platform you already run | Execution goes to the data rather than the reverse. The highest-fidelity option where your warehouse is the system of record; requires compute integration. |
| Air-gapped | No outbound connectivity | For classified and sovereign environments. Updates and method qualification move through a controlled channel; expect a different release cadence. |
05Boundaries
Worth stating explicitly, because most integration risk comes from assumed behavior rather than documented behavior.
- It is not a system of record. Your clinical data repository, safety database and document system remain authoritative. StromaOS does not become the place the truth lives.
- It does not centralize data to work. In VPC, embedded and air-gapped postures, execution goes to the data. Federation exchanges signed evidence records, not source data.
- It does not hold decision authority. Every decision right resolves to a named human in your organization. There is no configuration in which the platform signs on your behalf.
- It does not supply your licensed data. You bring your own entitlements. The platform verifies them and refuses uses they do not cover.
- It does not silently degrade. A control that cannot be evaluated, an entitlement that cannot be verified or a method that is not qualified produces a refusal and a record, not a best-effort result.
06What an architecture review covers
If you want this applied to your estate rather than read in the abstract, the review is a working session - typically ninety minutes with your platform, security and quality representation present.
- Your data estate and where execution would sit within it
- Identity federation, secrets handling and network posture
- Your control set, and which controls are expressible as executable policy today
- Your validation regime and what qualification of the platform would involve
- The first function to deploy against, and the parts of it where the answer is no
Bring your architecture and we will bring specifics.
The form provides the technical context needed to make the first conversation specific, about your estate rather than our capabilities.