Trust architecture
This page is the picture version of the rest of this section. Three diagrams describe the trust model at the same public altitude as the pages around them: how one organization's work stays separate from another's, how the data you connect becomes one harmonized picture, and how an agent's action reaches a write. Each diagram is written out in the prose above it, so the page reads correctly with images turned off.
Organization isolation
Every organization works in its own environment, on HIPAA-eligible Google Cloud infrastructure in US regions. Inside that environment sit the three things that carry risk: the organization's operational data, the agents and workflows that act on it, and the audit trail that records what happened. Access, key management, and audit history are all scoped to the one organization.
Nothing crosses between environments. Another organization's data never reaches your agents, your model context, or your audit history, and the reverse holds too. The boundary is enforced below the application, so a bug in a screen cannot serve one organization's records to another. See Access and audit for the controls behind that boundary.
The diagram shows the supported isolation model. It does not assert a dedicated stack for every organization, a single placement for every deployment, or an audited control.
The Nucleus mesh
Nucleus is the connect product. It brings the software you already run onto one shared substrate, harmonizes the records against a common data model, and keeps that data flowing into your own data environment. The diagram reads left to right: business systems in, harmonized operational data in the middle, and the surfaces your team actually works in on the right.
The lines are not all the same. A solid line is a documented connection available today, which is how a dispatch platform and the regulatory and knowledge corpora connect. A dashed line is shown conceptually only: billing and finance systems and general files and spreadsheets illustrate the shape of the mesh, and they are not a committed integration. Which sources are available to you depends on your plan and your configuration.
In the middle, the harmonized data carries three properties that matter for trust: it is mapped to one common data model, it is scoped to a single organization, and access to it is audited. On the right, it feeds AI Studio where you build and test agents, AI Operations, the run offering that starts with Routines in AI Studio, and the intelligence dashboards and reports your team reads.
The diagram is a conceptual view of the flow. Solid lines assert a documented connection, dashed lines assert nothing beyond illustration, and neither asserts a delivery date or a committed integration.
The agent control loop
An agent that can only read is a reporting tool. An agent that can write needs a control loop around it, and this is the loop the product applies:
- Scoped request. A person or a schedule triggers the agent, and the agent runs inside access limits that already exist for that requester. It cannot widen its own scope. See AI and PHI for how that scoping works on the AI side.
- Agent proposes. The agent drafts the action and shows the evidence behind it, so a reviewer can see what it intends and why.
- Operator approves. Where approval applies, a person reviews the proposal and signs off before the write happens.
- Audited write. The action is recorded: who acted, what changed, and when. Entries are append only, so the record survives even someone with broad access.
Two qualifications belong with that loop. Approval is configured per organization and per action, so some steps are set to run without a human pause, and the diagram is not a claim that every action everywhere waits for a person. Reads are scoped the same way as writes, and the audit entry is kept whether or not a person was in the loop.
The diagram shows the control loop the product applies. It does not assert that every action in every deployment has already completed this path, or that a human pause applies to every step.
See also
- Access and audit for roles, isolation, and append-only audit logging.
- Data handling for how data is classified and what is logged.
- AI and PHI for how AI features stay inside the operator's scope.