Platform

The load-bearing layer. What sits underneath.

Seats are the visible part. What decides whether AI is useful is underneath: how data gets in, how it’s modelled, what it’s allowed to touch, and whether it holds when the whole company logs in at once.

Architecture
Connectors
Staging areas
Data lake
Ontology
The harness
Load and scale
Observability

Five floors, one direction of travel.

Data rises from the systems you already run, lands in a governed lake, is modelled into an ontology of your company, and reaches the model only through the harness and its guardrails. Nothing skips a floor.

3.1e: Your teams — every seat, every app
3.1d: Harness + guardrails — the model inside a policy wall
3.1c: Ontology — your entities and relationships
3.1b: Governed lake — raw · curated · governed
3.1a: Your systems — email, docs, CRM, ERP, tickets

The architecture, exploded. Risers carry data upward; the model sits inside a wall of guardrails, inside the harness.

A connector is six decisions, not a login.

Most integrations fail quietly: they copy everything, ignore who was allowed to see what, and break the day a field is renamed. Ours authenticate with least privilege, map to your ontology, sync only what changed, and carry your permissions with the data.

01
Source system
Your CRM, ERP, inbox or document store — untouched.
02
Authenticate
A service identity with the least access that works.
03
Map
Fields mapped to the ontology’s types, not copied blind.
04
Sync
Changes only — on a schedule, or live where it matters.
05
Mirror permissions
Who couldn’t see it there can’t see it here.
06
Raw zone
Landed exactly as it arrived, with lineage attached.

The anatomy of one connector, from your source system to the lake’s raw zone. The record riding the line is the only thing that moves — the source is never modified.

The system that won’t let AI in still gets connected.

Some platforms refuse direct AI access — and that’s often where the most valuable data lives. We don’t force the door. The system exports on a schedule to a governed staging area, AI works there, and the core system never opens up.

A core system exporting to a staging area on a schedule. The agent reads the staging area only; the path back to the core system is closed.

Three zones, and lineage all the way down.

Raw keeps exactly what arrived, so any output can be traced to its origin. Curated cleans, types and joins it. Governed applies permissions and entity resolution, and is the only zone AI is allowed to read.

CRM record
cleaned account
resolved customer
renewal view
board slide 5

RAW: as landed · immutable
CURATED: cleaned · typed · joined
GOVERNED: permissioned · AI-ready

A record crossing the lake. The lineage beneath follows one CRM record all the way into a slide.

Your company, as a graph — so questions have a path.

Unstructured, unlabelled data is why most company AI disappoints. An ontology names what your company is made of and how the pieces relate: customers hold contracts that come up for renewal, and raise tickets about products. With that structure, a question isn’t a search. It’s a path — and the AI reads less, so it gets less wrong.

query

Which customers up for renewal this quarter have open escalations?

Answer path:RenewalContractCustomerSupport ticket

A slice of a company’s ontology. The highlighted path is how the question is answered, through every entity in between.

A harness is everything around the model.

The model reasons. The harness decides what it knows, what it can do, what it remembers, what it’s allowed to touch — and whether its work is good enough to leave the building. Work that fails the checks isn’t shipped with a warning. It goes back.

1: Context — the documents and records this task needs — and nothing it doesn’t
2: Tools — what it can do: read mail, query the CRM, write a deck
3: Memory — how your company likes things done
4: Permissions — exactly what it may touch, mirrored from your systems
5: Model — interchangeable — swapped when a better one ships
6: Checks — evals that re-read the work against its sources
7: A person — signs off wherever the decision can’t be undone

The harness, built as an object. A request passes context, tools, memory and permissions before the model sees it, and the checks before a person does. Each part lights as the request passes.

Engineered for Monday morning, not the average.

Demand isn’t smooth. It spikes when inboxes open, again after lunch, and hardest when every team assembles its end-of-day report. We plan capacity against those peaks — with per-team lanes, queueing and caching in front of the model — so the busiest hour is the one it handles best.

Illustrative

Illustrative demand peaks across a working day
09:00	Start of day — a demand peak, below provisioned capacity
13:45	After lunch — a demand peak, below provisioned capacity
16:30	End-of-day reports — a demand peak, below provisioned capacity

The shape of demand across a working day, against provisioned capacity. Shape only — no units, no benchmark.

Every task leaves a trace — and a cost.

Each request is traced end to end: which gates ran, what was retrieved, which systems were queried, how long the model took, and what the task cost. We price the task, not the token — so when a cheaper model is the right tool, we can prove it.

Trace · request 7f3aaccount manager · Sales · 09:31:04

Illustrative

0 ms2,900 ms

Guardrail · inbound
Resolve entities · ontology
Retrieve · documents
Query · CRM
Model · Claude
Check · sources cited
Guardrail · outbound
Write · audit log

Sources cited: 4Policy decisions: 2 passedCost attributed to: Sales team

One request, traced end to end. Durations are illustrative.

Ask us how your data would move.

Bring a system map, or just a list of what you run. We’ll sketch the floors with you in the first session.

Book a discovery call