AIState · Knowledge Fabric

Your data stays where it is.
So does the model, and the hardware.

AIState does not pull your estate into itself. It connects to your databases, file stores and business systems through read-only MCP connectors and reads what an investigation needs, when it needs it. The records an investigator deliberately imports — call records, returns, extractions — are held as evidence, so they can be cited and, per import, undone. From Professional up, the platform, the language model and every byte it does keep run on infrastructure your IT team owns, configures and can switch off. On Foundation, the platform is operated by DataFab, single-tenant, in the region you choose.

Narrated walk-through · 4:25 · every screen below, recorded from the live systemChapters & transcript

01 · Read in place

Source systems stay authoritative

SQL warehouses, NoSQL stores, object storage, CRM/ITSM/HR/log platforms are reached over named, read-only connections. Statements are vetted before they are sent; rows are capped; nothing is mirrored into the platform.

02 · Your model

Bring your own LLM, inside your boundary

Register any model — a local server on your GPU, Azure Government, AWS GovCloud, or a commercial API — and assign one per feature. A data-boundary setting refuses providers that fall outside it.

03 · Your hardware

One platform — your servers from Professional upward

The whole platform on servers or a cluster you control: graph, search, evidence store, backups, your encryption key, your identity provider. No licence server. Foundation runs the same stack single-tenant and DataFab-operated in the region you choose; from Professional upward the data plane is yours. Only policy, metadata and allow-listed observability reach the control plane — never raw data; every other outbound call is one you configure.

The reference deployment from the DataFab Deployment Architecture playbook. Your systems stay the master and are read in place; the platform runs on your compute, behind an egress boundary that is default-deny and fail-closed; every call to data — from an agency, a utility or the console — passes the one governed gateway. Open the interactive playbook →

The five enforcement points

Each is proven at deployment with an evidence artifact and a verification test — not asserted in a document. They are blocking: the deployment does not go live until they pass.

Point	What is enforced	How it is proven
C1 · datastore authorisation	The graph store rejects every principal except the gateway identity — by datastore policy, not convention.	A read as the control-plane identity is denied; a scope-widening attempt is rejected.
C2 · model egress	The in-boundary model runtime has no outbound route and cannot call an external endpoint. C2 holds when the data boundary is `gov` or `airgapped`; with the boundary `open` a registered commercial model is reachable, and the boundary report says so plainly.	Egress configuration and scan for the model segment; a packet capture shows zero egress.
C3 · connector permission	Connectors use a credential the source itself scoped, read-only — they cannot write.	A write through the connector credential is denied at the source.
C4 · console at rest	The presentation surface holds no recoverable customer data — cache, logs, browser storage, error traces, replay.	Inspection of each store; a compromised console has nothing to exfiltrate.
C5 · fail-closed	Anything off the egress allow-list is dropped rather than forwarded; no route, grant or identity offers a path around the gateway.	The deployment scan fails the release if a bypass path exists.

Fixed by the architecture · decided at deployment

The boundaries, the gateway, the model policy and the enforcement points are fixed. Seven choices are yours — and they are the whole of the deployment-time surface.

Decision	Set by	Stage
Edition — Foundation · Professional · In-tenant · Sovereign	Customer + DataFab	Design
Region / enclave and data residency	Customer	Design
Network CIDRs and private link	Customer infrastructure	Setup
KMS / HSM custody — the root of trust	Security	Setup
SIEM target for audit export	SOC team	Setup
RPO / RTO targets	Business + IT	Design
Source list — which systems are connected	Data owner	Discovery

The graph is derived, never the master — the worst case is a rebuild from your sources, not data loss; re-run resolution to a pinned policy and lens version.
The customer holds the kill switch — revoking an agency credential freezes it mid-execution and in-flight calls fail closed.
Nothing lands without your approval — artifacts are signed, SBOM'd and provenance-attested, and applied only when you approve them; in Sovereign that approval is performed offline.
Six views, edition-aware — reference deployment, governed utility, network topology, resilience & DR, build & release, identity & keys, and the nine-phase deployment journey with its three gates: open the playbook.

Read in placeRead-only connectors into the systems you already run

The built-in MCP hub hosts 217 tools in-process — 151 for investigation and 66 enterprise connectors that reach your own systems over named connections. External MCP servers — yours or a vendor's — register the same way, with a tool filter so the dialog sees only what you allow.

Family	Systems	How reads are kept read-only
SQL · 9 tools	PostgreSQL / Redshift, MySQL / MariaDB, SQL Server, Oracle, SQLite / DuckDB, ClickHouse, Snowflake, BigQuery, Databricks, Trino / Presto, Athena	Every statement — including the ones the tools compose for sample, count, search and profile — passes a read-only statement check: comments and strings stripped, one statement only, no DML or DDL anywhere; refused before anything reaches your database. Results capped at 1,000 rows.
NoSQL · 16 tools	Document stores, key-value stores, search stores and graph databases — MongoDB, OpenSearch, DynamoDB, CouchDB and others	Server-side scripts and write stages refused; key reads by scan only; graph queries in read-only transactions; no writes exist in the tool set.
Storage · 8 tools	S3 and every S3-compatible endpoint, Azure Blob, GCS, SFTP, WebHDFS, mounted shares	List, search, head, preview and text-extract only; a mounted share is pinned to its root (escape guarded). Nothing is uploaded or deleted.
Business & ops · 33 tools	Salesforce, ServiceNow, Jira, Zendesk, HubSpot, Dynamics 365, Teams, Entra, Google Workspace, Okta, Splunk, Datadog, Loki, Prometheus, Kafka, RabbitMQ, Airflow, GitHub / GitLab, Box, generic OData and REST	Query and search endpoints only (SOQL/SOSL, Table API, JQL, search jobs); the generic REST connector is GET-only with the path pinned to the base URL; Kafka peeks from the end of a topic without a consumer group.

Offline by design — enterprise connectors are marked offline: they never need the public internet, so they keep working inside an air-gapped boundary where every other host is blocked.
Egress policy on every hop — each host a connector resolves is checked against your egress policy; in an air-gapped boundary only allow-listed hosts and private addresses connect.
Keys stay yours — connection strings and API keys stay inside your deployment, are write-only in the UI and are never shown again.
Every call is on the record — connector calls appear in the run's execution trace (tool, host, bytes in and out, duration) and, on a case, in the hash-chained audit trail.
Classification-aware — a connector carries a classification ceiling; a case classified above it never sees that connector, in chat or agency runs.

Connectors — the built-in hub grouped by family, with each category’s tool count, what is ready without a key, and the classification cap. Keys are stored server-side and never shown.

What the platform actually stores

Stays in your source system	Held by AIState — on your volumes
Tables, documents, objects, tickets, log lines, messages: read on demand, returned to the investigation that asked, discarded with the request.	What an investigator files: entities and relationships they add to a graph, exhibits they attach (encrypted with your key), case records, comments, decisions — each with provenance saying which connector, tool and citation produced it.
Credentials and connection configuration you did not enter into the platform.	Catalogue metadata: asset names, sampled column schemas, counts, lineage between assets, quality results — never rows or file contents.
Your identity directory (the platform reads claims at sign-in).	Accounts, roles, clearances and the security-event log; agency runs and their traces; the audit chain and its anchors.

The catalogueKnowledge Fabric — a data catalogue nothing writes by hand

What a data catalogue is to a warehouse — with two differences: the catalogue copies nothing, and nothing stays flat. Read in place, then resolved into a knowledge graph, so the data is multi-dimensional: an asset and the entities inside it carry their relationships, explicit and inferred. A scheduled sync runs on demand and every 15 minutes and discovers the estate: workspaces, investigations and their entity types (property schema sampled from 25 nodes), live graphs and their sources (field schema from the live sampler), import datasets, evidence containers per case, the search index, MCP servers and hub categories (tools as columns), and every configured enterprise connection as an asset — with no secrets.

Explorer — full-text search over assets, columns and tags; each asset carries kind, service, parent, sampled schema and the last time it was seen.
Lineage — streams (source → live graph), loads (import → investigation), enriches (connector → investigation, via review proposals), extracted (evidence → import), and what feeds each case.
Govern — domains, a glossary (six seeded terms), classifications (handling, PII, tier, provenance) as tags, owners and tiers. Human fields are never overwritten by a sync; assets that disappear are retired, not deleted.
Quality — seven built-in checks plus your own read-only checks; results kept 30 days, the latest failure is an incident; a daily snapshot feeds the trend.
Ontology — entity types with counts (registered and legacy), relationship types, the type pairs actually in use, record labels and identifier kinds — drawn from the data, not a document.

Knowledge Fabric — the estate as the platform discovered it: assets, connectivity per source, the six quality dimensions and requests to the graph.

Explore — full-text search across assets, columns and tags, with the sampled schema and the last time each asset was seen.

Lineage — sources into live graphs, imports into investigations, connectors into enrichment, evidence into imports: discovered, not drawn by hand.

Your schemaEntity types and record fields are yours to define

Settings → Schemas is a schema builder, not a fixed data model. A custom entity type becomes a real graph label; a custom record field becomes a real property on the case records that carry it. Forms, the canvas, the importer, agencies and the dialog all read the registry at run time.

Entity types

Built-ins plus your own

Person, Organization, Location, Vehicle, Phone, Email, Account, Crypto wallet … and the cyber set (IP address, Domain, URL, File hash, Malware, Device, User account, Certificate, Infrastructure, Vulnerability). Add a PascalCase type with its property form and it becomes a first-class label in the graph store, gets a colour and icon on the canvas, appears in the create dialog, in the importer's type aliases and in the tools the dialog and agencies call.

Record schemas

Fields on eight record kinds

Case, evidence, activities, tasks, legal process, assets, court events, deadlines. Fields are arranged in groups (title, subtitle, widget); the builder shows the Template Studio on the left and the resulting JSON Schema and its graph on the right. Values are stored on the record itself and come back with it everywhere; forms append them automatically.

Relationship vocabulary

Typed, validated edges

The relationship types the graph accepts — investigative (associated with, owns, transacted with …) and cyber (resolves to, beacons to, exploits …) — are validated on every write, including model writes, which follow your policy and land in the review queue where it reserves the decision.

Schemas — entity types and record fields defined in the builder; a new type becomes a first-class label in the graph, with its own colour, icon and forms.

Your modelBring your own LLM — and a boundary the platform enforces

Settings → AI models is a registry. Providers configured in the environment appear as built-ins (one per configured provider: a Chat-Completions endpoint, a managed cloud model, a government-cloud deployment, a local server); admins add more — any Chat-Completions endpoint, a government-cloud deployment, the Anthropic Messages API, a managed cloud model or a server on your own network. Each feature — dialog, chat, insights, agencies, background checks — is assigned a model, tested from the page, and switched without a deploy.

Data boundary	Models allowed	Outbound connections
open	Any registered model	Any host
gov	Local, Azure Government (`.azure.us`), AWS GovCloud (`us-gov-`) — a commercial API is refused; a commercial Azure/AWS region is flagged in the boundary report	Any host
airgapped	Local inference only	Only allow-listed hosts and private addresses; email via SMTP only; enterprise connectors keep working

Local inference ships with the platform — a GPU-ready local model server, or your own inference server on your network.
The boundary report on the AI models page names the provider location per model and every provider configured but refused by the boundary.
What a model sees is visible per run: the execution trace lists the context sources and sizes, each model call with its request size and token usage, and every tool call with its arguments and result.
What a model writes follows your policy, and is traced to the model that wrote it.

AI models — the registry, which model each feature talks to, and the data boundary that decides which providers may ever be called.

Your hardwareA stack your IT team owns end to end

Runtime

Your servers or your cluster

The application, the graph store, the cache and queue, the search index, the usage meter and an optional local model server. Service ports bind to the address you choose; nothing is published to the internet by default.

Data at rest

Your volumes, your key

Named volumes for graph, cache, index, evidence, subject media and audit anchors. Evidence originals are immutable, sha256-hashed and encrypted with AES-256-GCM under your own key; downloads re-hash on the way out. Optional antivirus hook on upload.

Backup & restore

Scripted, versioned, restorable

Every volume is backed up with a manifest on the rotation you set, and any backup can be restored. Search is derived and rebuilt. The last backup's age is reported to the accreditation page.

Identity

Your IdP, your policy

Local accounts or SSO with Microsoft Entra, Okta, Google or any OIDC issuer; claim mappings set role, clearance and department at sign-in. Password policy, lockout, TOTP MFA (enforced per role), session lock after idle, sign-out-everywhere, API keys with scopes and expiry.

Assurance

Evidence for the accreditor

53 NIST SP 800-53 rev 5 controls assessed from the live system on every load; FIPS mode for password hashing; SBOMs and dependency audits built into the image; a downloadable evidence package with the attack surface (every route, its auth and permissions).

Integrity

Tamper-evident by construction

Every case mutation — and every read of evidence — is a hash-chained audit entry; heads are anchored daily to an append-only file (and a webhook of yours if you want one) and verified on demand. Reports and evidence packs carry the chain head.

System — service health, request metrics and the runtime the stack is actually running on.

Configured by your IT teamEvery administrative control, in one place

Settings is a module with one screen per concern. Nothing below requires DataFab: an administrator with the right permission changes it in the UI, and the change is written to the security-event log.

Organization

Overview: Deployment, service health and security posture at a glance — policy numbers and booleans, never secret values.
Users: Accounts, base role, custom role, clearance, department, MFA state, active sessions, revoke sessions, deactivate.
Departments: Units and sub-units, heads, membership, default role and clearance for new members.

Identity & access

Roles & permissions: Every capability is a named permission; built-in roles are derived sets; custom roles sit on a base role with an explicit permission list; case grants and workspace roles on top.
Access providers: Local sign-in, the four SSO providers, IdP claim → role / clearance / department mappings with priority.
API keys: Service principals with narrowed scopes and expiry; shown once, revocable at any time.
Access review: Dormant accounts, privileged users without MFA, expiring keys — computed, not maintained.
Security events: Sign-ins, failures, lockouts, MFA changes and every administrative change with actor, IP and browser.
Security & compliance: Password policy, lockout, idle lock, evidence-at-rest state, audit anchoring, rate limits, backup age.
Accreditation: The control assessment, crypto inventory, SBOMs, CSP violation log and the evidence package.

Cases & analysis

Case workflows: BPMN 2.0 definitions per case type or workspace, versioned, with a standard modeler; lanes map to roles; SLA timers; scripts limited to a safe vocabulary.
Agencies: The library of 105 agencies — 84 on demand and 21 on a schedule or an event: prompt, contexts, allowed tools (globs), output shape, effects; enable, schedule, reset, or write your own.
Schemas: Entity types and record fields — the schema builder above.

AI & data

AI models: Registered models, per-model test, the feature → model grid, the boundary report.
MCP connectors: External servers you register, the built-in hub with its keys per category, tool filters and a per-connector classification ceiling.
Data providers: Registries, sanctions, blockchain, geocoding, background-check and web-capture providers — which are configured and which are not.

Integrations

MCP endpoint: The platform as an MCP server: let your own systems push into live graphs; per-source tokens.
Push endpoints: Ingress, webhooks with mapping templates, stream pulls, the simulator — every way data arrives without a client.

System & workspace

Health & metrics: Service health, traffic by route family, rate-limit counters; a metrics endpoint for your monitoring.
Preferences · Shortcuts: Text size, live-view defaults, the keyboard reference.
Per workspace: Open or restricted visibility, members and roles (owner · manager · member · viewer), the access matrix, storage & usage from the meter, access insights, archive and two-step delete.
Per live graph: Window and retention (nodes / hours), pipelines that filter, route and alert inside your boundary, with the retention you set.

Settings — every administrative control in one module: organization, identity and access, cases and analysis, AI and data, integrations, system.

Deployment-level settings

The data boundary, the hosts the server may reach, the evidence key, the identity providers and the limits are set by your IT team at installation. Detail is in the architecture and assurance dossier, shared under NDA.

PlainlyWhat leaves the boundary, and how to stop it

Read this the way an auditor would: by what the code does, not what a brochure says. Every row is checkable in the running system — Settings → Accreditation computes it live.

Traffic	When	Under your control
Model calls	Every dialog turn, agency run, insight, background-check assessment	local model keeps them inside; gov restricts to government regions; the trace shows what was sent.
Public OSINT lookups	Only when a hub tool is called (Wikidata, GLEIF, sanctions, RDAP, threat-intel feeds …)	Per-tool: disable the category, omit the key, or run airgapped — offline connectors keep working.
Live feed pulls	Only for stream sources you add (Wikimedia, Bluesky, Feodo Tracker …)	Add none; ingress, webhooks and imports are inbound only.
Meetings	Only when a case meeting is opened	your server DataFab Meet runs on your own conferencing server; nothing is relayed through DataFab. A recording is captured in the browser and filed straight into the case file as an encrypted exhibit — it never leaves the boundary, and its transcript is produced by whichever speech-to-text you configured (a local command inside an air-gapped deployment).
Anything to DataFab	Never from the product itself; on a DataFab-operated deployment, from the control plane	none the software holds no licence check, no usage reporting and no update ping — nothing phones home. On Foundation (single-tenant, DataFab-operated) the control plane still reaches the deployment for policy, configuration metadata, allow-listed health telemetry and signed updates — never record data; from Professional upward that path narrows to a private link, and Sovereign has no control plane at all.