This document answers the four areas requested in your note.
Most platform overviews answer segregation by describing how tenants are isolated inside a shared store. Ours is answered on two different axes: your records remain in your source systems and are read in place, and what the platform derives from them is governed twice — by where it resides, and by attribute-based access controls carried on the knowledge graph itself.
The placement rule is simple and applied uniformly: a component's placement is set by the most sensitive class of data it touches. Anything that touches raw records or holds derived customer data sits with your data; anything that holds only definitions and control may sit in the managed control plane.
The catalog index, policy and ontology, identity and entitlement configuration, agent and workflow definitions, orchestration, and telemetry.
Connects to your systems, resolves what they describe into a knowledge graph, executes agents and rule chains, and stores the evidence for every execution. From the Dedicated edition upward, the entire data plane — including graph and inference — runs inside a boundary you designate.
The data-plane component that turns your existing estate into a single, governed knowledge state — without migrating it. Select a stage.
Source-system health is monitored continuously — connectivity and credential validity every five minutes, freshness continuously, schema drift daily. If a source is unavailable, the affected subgraph degrades to a clearly flagged stale state rather than failing silently.
Connections are read-oriented and MCP-first. The platform discovers, catalogs, and resolves; it does not ingest your estate into a warehouse.
| System class | Examples | Access mode | Write-back |
|---|---|---|---|
| Document management | iManage, NetDocuments, SharePoint | Read, catalog, resolve | Optional, governed |
| Case / practice management | Sector systems of record | Read, catalog, resolve | Optional, governed |
| Client relationship | InterAction, Dynamics, Salesforce | Read, catalog, resolve | Optional, governed |
| Billing and ledger | Finance systems of record | Read, catalog, resolve | No |
| Mail and collaboration | Microsoft 365, Google Workspace | Read, catalog, resolve | No |
| Data platforms | Existing lake or warehouse | Read in place | No |
| External registers | Companies House, screening sources | Read | No |
Where enabled it is a separately approved capability: each write is an explicit governed action with its own authority record, conflict resolution, and cascade control.
Connectors authenticate with read-only, source-granted credentials — the source system's own permission model is the outer wall.
A connector built in the platform's own tooling enters the same chain of custody as our artifacts — built, signed, approved, and run sandboxed with the same read-only credential model.
Cloud platform, identity, observability, notification, artifact registry. Each under a DPA; the list is published, with 30 days' notice before engaging any new sub-processor.
Contractual training opt-out in every case; not present at all in In-boundary and Sovereign editions, where inference is self-hosted.
OSINT, adverse media and sanctions screening are external by nature. Every outbound query passes a single audited broker enforcing an allow-list, field-level minimization, tokenization, rate limits, and a full audit of every term sent.
For higher-assurance deployments the pattern inverts: screening lists and licensed feeds are imported and matched inside your boundary, so no customer-derived attribute leaves. Sovereign deployments use feed-in and offline import only.
Tenancy depends on where the data plane runs — not on isolation controls layered over shared infrastructure.
Foundation is a managed, single-tenant deployment in a region you select; from Dedicated upward, the data plane runs in your own tenancy or boundary, with no shared runtime at all. This is a deployment-time decision made jointly at onboarding, alongside custody and residency.
— Where the data plane and inference run
— Who holds keys, under what separation of duties
— Whether execution depends on our infrastructure
— Isolation: logical, infrastructure, or physical
— Source records remain in their systems, read in place
— The control plane holds definitions and control only — never records or derived knowledge
— Governance applied at discovery, traversal, action and evidence
— Every access and execution audited
Managed editions run under a published shared responsibility model. DataFab is responsible for platform hosting, patching, application security, encryption, and platform monitoring; you are responsible for data-classification decisions, role assignment and access policy, IdP configuration, and residency and retention requirements. Incident response is jointly defined. Customer auditors receive read-only access on approval, and quarterly access-review reports support your own recertification cycles.
Your operational records are not copied into a shared store, migrated, or warehoused. What the platform persists is a derived knowledge state — and we prefer to name its contents precisely rather than claim it holds nothing.
That derived state is customer data, and we treat it as such: boundary-resident from the Dedicated edition upward, and encrypted under your keys from that point on.
The edition determines where the derived knowledge state physically resides and who can decrypt it. From Dedicated upward, the graph, the evidence store and the audit store all sit inside your boundary under customer-managed keys; in Sovereign, key custody is split-duty under your HSM.
Exit is correspondingly simple: removing the deployment removes the derived state; your source systems are unchanged.
Within a deployment, access is segregated by attributes carried on the graph itself — so one knowledge state serves many roles without replicating it per audience.
A role may be permitted to know two entities exist without being permitted to see that they are connected. Connections are governed objects in their own right.
Enforcement is at query time, in the data plane. The policy decision and enforcement points sit with the data — they fail closed and do not depend on the control plane being reachable. Each request is evaluated against the caller's identity context, resolved fresh from your IdP every turn, so a revoked entitlement takes effect on the next interaction, not the next login.
Views are derived at query time from a single governed graph, so there is no second store to drift, leak, or reconcile. Every access decision — subject, resource, action, outcome — is logged and retained.
Your ethical walls and need-to-know boundaries are expressed once, as attributes and policy over the graph, and hold across every surface — search, dialog, agents and reporting — rather than being re-implemented per application.
Business-domain discovery reads your own documents and systems and proposes the schemas, which your teams review and refine. No schema-migration program precedes value.
We treat source metadata as sensitive — your schema names and structures describe your business. From Dedicated upward it resides in your boundary alongside the graph.
UK-only, EU-only, or a specified region, for both data plane and control-plane metadata. On exit the deployment and its derived state are removed; nothing was taken from your source systems, so nothing needs returning.
A versioned DAG of explicit rules with defined scoring and decision routing, including hard overrides that no model output can override.
Given the same inputs, policy and versions, the same path executes — and the full chain trace, every rule, parameter, score and source record, is persisted as evidence.
Where a model assists inside a chain it does so as a bounded step whose output is validated, cited and carried with its confidence — with a deterministic fallback.
Each agent combines a language model with a structured query plan over governed sources and — the load-bearing property — a defined output schema.
The agent cannot emit fields or values outside its declared schema. Inputs are equally bounded: the query plan names the datasets, connectors and sub-agents it may touch, subject to the same graph-attribute governance as any human caller.
An agent acting for a user sees only what that user may see.
Because every agent output conforms to a declared schema, a single resolved fact base can be rendered as multiple governed facets, each carrying its own definition and citations. Headcount — a measure that famously differs by who is asking. Select an audience.
All three are correct; they answer different questions. The reconciliation between them is computed and evidenced — so “which number is right?” becomes a governance answer, not an argument.
| Edition | Inference runs | Do prompts containing customer data leave your boundary? | Provider training |
|---|---|---|---|
| Foundation | Managed, in-region | Governed content reaches the in-region managed endpoint under DPA, via structured prompt templates with field-level minimization | Contractually opted out |
| Dedicated | Your boundary (default: self-hosted) | No, by default. An external provider is possible only by your explicit sign-off, via the allow-listed egress path | Contractually opted out |
| In-boundary | Your boundary | No | Not applicable |
| Sovereign | Your boundary, self-hosted, air-gapped | No | Not applicable |
Models are substitutable without changing agent definitions — the logic lives in the query plans, schemas and rules, not the model. The model version in force at execution is pinned and recorded with the execution.
Not as a policy check on a finished answer.
Adversarial content is treated as a first-class threat. Agents read documents and mail, and treat content in those sources as data, never as instructions: the schema-bounded output contract means injected text cannot add fields, redirect tools outside the allow-list, or bypass a gate. Grounding validation rejects assertions without cited sources; consequential actions sit behind risk-classed human gates.
Configured per workflow, by you — a deployment decision with policy limits, not a runtime suggestion.
Mapped to the NIST AI RMF functions so your risk team can assess us in a structure it already uses; ISO/IEC 42001 certification in progress, building on the existing ISO 27001 certification.
| Area | Position |
|---|---|
| Certification | ISO 27001 and SOC 2 Type II — certified May 2026, audited annually. Architecture was recently Pen Test by Big4 for their own deployment |
| Security testing | Vulnerability scanning daily; third-party penetration test at least annually, report available; patch SLAs: critical 24–72 h, high 7 days, medium 30 days |
| Incident response | 24/7 SOC; P1 response within 1 hour with customer notification within 1 hour; regulator notification per requirement; post-incident report within 5 business days |
| Resilience | Knowledge graph RPO 1 h / RTO 4 h; API services RTO 15 min; audit logs RPO 15 min; region failover 4 h. Because sources remain the master, the resolved state is additionally re-derivable from your estate — loss and corruption are treated as distinct failure modes |
| Supply chain | Release artifacts signed and verified before execution; software bill of materials per release; customer approval gate before any release is applied to your deployment |
| Transparency | Published sub-processor list with 30-day change notice; monthly service and quarterly security reporting; quarterly access-review reports |
A reusable, interactive deployment playbook — six views from the logical reference through network, resilience, release and key topology, each edition-aware and each component inspectable. Deployment-specific values appear as placeholders rather than fixed numbers, because this is a reference pattern, not a network drawing.
Everything else — the boundaries, the gateway, the model rule, the enforcement points — is fixed by the architecture and does not change per deployment. That is what makes these seven the whole of the deployment-time surface.
| Decision | Set by | When |
|---|---|---|
| Edition | Customer + DataFab | Design |
| Region / enclave | Customer | Design |
| CIDRs | Customer infrastructure | Setup |
| KMS / HSM | Security | Setup |
| SIEM target | SOC team | Setup |
| RPO / RTO | Business + IT | Design |
| Source list | Data owner | Discovery |
Enforcement points C1–C5 are proven in the engineering evidence pack. Values shown as [set at deployment] are populated by engineering per environment.