KeystoneIntelligence
Technical brief · rev 1 · 31 July 2026Every claim below states how you check itPatent pending

One question across every database. And a record of how it was answered.

Keystone reads the schemas of your PostgreSQL, MySQL and MongoDB instances, works out which columns correspond, and returns a single correlated table. Your databases never connect to each other, and every statement runs inside a read-only transaction the database itself enforces. Below is each claim with the mechanism behind it — and the way to verify it yourself.

The first two claims below restate chapters from the opening page. Four more follow, and each of the six is paired with the way you check it. The opening page’s third chapter — running inside your own walls — is set out in full under Two ways to run it.

At a glance
EnginesPostgreSQL · MySQL · MongoDB
Write accessNone — read-only transaction
Your databasesNever connect to each other
Model keysYours, not ours
DeploymentHosted or inside your walls
01

The claims, and what backs them

6 entries
01

It finds the join across databases by itself

Every connected schema is read and compared. Keystone determines which columns actually correspond, then correlates the result sets in memory. You never write the join, and the databases never talk to each other.
How you checkAsk a question that spans two of your own databases. The answer shows the join it chose and a confidence figure for it.
02

It cannot modify your data

Two independent layers. Writes, schema changes, privilege escalation, stacked statements and injection patterns are refused before they reach the connection — including when phrased in plain English rather than SQL. Underneath that, every statement runs inside a read-only transaction opened with BEGIN READ ONLY, so even if the first layer were bypassed the database itself rejects the write.
How you checkType “delete every customer”. It is blocked, and the attempt appears in the log with your name on it. Then read postgresConnector.ts and find the second layer.
03

The log resists the administrator, not just the user

Queries, logins, admin actions and blocked attempts are all captured, and the log tables are protected by the database itself, not by application code. A trigger refuses deletes outright, and refuses edits — the only change it permits is a foreign key being nulled when the user or workspace it pointed at is removed. Clearing a log is restricted to the workspace owner, the clearing is itself recorded, and simply reading the blocked-attempt log writes an access record with your name on it.
How you checkOpen the audit view, then look for your own visit to it in the meta-audit trail. Then try to edit or delete a log row directly in the database — both are refused by PostgreSQL.
04

A workspace can have its own database, not just its own rows

Point a workspace at a connection string of your own and Keystone provisions its tables there, so that workspace’s data is physically separate rather than a filtered view of a shared table. Role checks are enforced at the API and return 403 at the server, not hidden in the interface.
How you checkCall the API directly as a lower-privileged user. It refuses at the server, not in the browser.
05

The model sees your schema, not your records

What goes to the model is database, table and column names, their types, and your question as you typed it. Result rows are not sent. Sample values are drawn only from enum-shaped columns, and only after a denylist has removed anything that looks like a person — with the values themselves scrubbed for emails, phone numbers and card numbers. On your own key, the model provider is your sub-processor rather than ours.
How you checkRead piiPolicy.ts — one shared policy governs both sampling paths, so the rule cannot drift between them.
06

The model may write the prose. It may not write the numbers.

Every figure in an insight report is computed by the statistical engine. The model is allowed to rewrite the wording, and then every number it emits is traced back to the maths. One figure that cannot be traced and the whole narrative is thrown away and the computed version is shown instead. Where there is no data, the panel stays empty.
How you checkConnect an empty datasource. The panels stay empty instead of filling with plausible-looking numbers.
02

Two ways to run it

Your regulator decides this, not us
Mode A

Hosted by us

The fastest way to start. Your database credentials are encrypted and cannot be read back out. Query results are kept in your session history so you can return to them, and they live in our environment.

  • Time to first querySame day
  • Where results are keptOur environment
  • Residency guaranteeContractual
  • Retention policyOurs, published
Mode B · for regulated buyers

Inside your own environment

Keystone is deployed in your data centre or private cloud. You hold the storage, the logs and the model key. “Your data never leaves your databases” becomes a statement about topology, not about trust.

  • Time to first queryDeployment-dependent
  • Where results are keptYours
  • Residency guaranteeStructural
  • Retention policyYours, enforced by you
03

A run, on the record

Measured, not illustrated
Correlation queryRead-only · audited
Asked in plain English
Show patients with their total insurance claim amounts and clinical records
100
Rows returned
100%
Join confidence
2
Databases joined
0
Writes possible
Sources · two separately connected PostgreSQL datasourcesJoin discovered by the platform, not supplied

Bring a question your current tooling cannot answer.

We will connect two of your databases and answer it in the session — or tell you plainly that we cannot.