Governed Solutions / Sovereign AI
Bound what your AI can reach.
Your AI reads only what a person approved, and only what the asker is allowed to see. Every answer and every refusal is logged.
Where the work already happens
Cognatum, the governed layer
approved · versioned · permissioned
Who asks
Who asks
Cognatum, the governed layer
approved · versioned · permissioned
Where the work already happens
Without Cognatum
Nobody can say what it can read.
“I should only answer or act when approved knowledge, access, and confidence rules allow it.”
Security will ask what the assistant can read. A project stops on the day nobody can answer that in one sentence.
An assistant is pointed at a shared drive and a wiki, and it reads whatever is in them.
Nobody can state the bound: which files it may open, whether it just answered one person with another person's material, or when what it read stopped being true.
So the answer to "what can it see" is a shrug, and a shrug is what stops the project.
In the primary region, with backups replicated to the secondary region in the same jurisdiction.
No source · no approver · no date
With Cognatum
Reach is the thing you can bound.
It reads approved entries and nothing else, inside the clearance of whoever asked, and the request leaves a record either way.
An unapproved entry is not withheld, it is unreachable. A draft nobody has signed and an entry retired last quarter are not results the assistant declines to show. They are not results at all.
Requests in
One assistant, one asker
- Approved disclosure language
- Current supervisory procedure
- A draft nobody has signed
- An entry retired last quarter
Served
With approver, date, version
-
Disclosure D-214 rev 6
J. Mercer · approved 2026-07-14
-
Procedure WSP-11 v4
Supervision · approved 2026-06-30
Not served
Not fetchable at all
-
Draft entry
No approval on record
-
Retired entry
Archived 2026-04-11
One assistant asking for four things: two approved entries served with an approver and a date, and a draft and a retired entry that are not fetchable at all
How it works
Four bounds on every request.
Clearance
It stops at the asker
What comes back is decided when the answer is made, by what the person who asked is allowed to see. An agent is held to that person, never to a shared account.
Surface
Drafts are not fetchable
Only approved entries are served. Draft, candidate and retired content cannot be reached through these interfaces at all, so there is nothing to leak.
Record
Both outcomes are logged
Which entry, which version, who asked, and when. A refusal is written down too, so a denial can be explained rather than guessed at.
Ground
Where it runs is Sovrinty
Your own hardware, another country, which vendors may connect: that is Sovrinty, a separate product. Named here so nobody buys the wrong thing.
Your tenant boundary
Runs where you put it: your hardware, your region
Inside, never served
- Drafts nobody has signed
- Candidate entries
- Retired entries
Not fetchable through any interface, so there is nothing to leak.
Crosses out, per asker
- Approved entries the asker is cleared for
Decided when the answer is made, against the person who asked.
Written down either way
Which entry, which version, who asked, when. The refusal is recorded with the answer.
In practice
Data that cannot leave.
Somebody has to sign this system off before it goes near a regulated process, and the data may not leave your environment.
What this settles is the reach. The assistant answers from approved entries only, bounded by the clearance of whoever asked, and every serve and every refusal is written down.
That record is an export rather than a reconstruction: approver, date, source and version behind each answer, in the shape an audit asks for.
Where the environment itself is the requirement, that is Sovrinty, and it is bought separately. This comes first, because control needs something to hold.
Which categories of data may leave the tenant boundary?
Entry D-529
- v4 In force
Model telemetry added to the categories that may not leave the boundary.
R. Okonjo, Director of Information Security · 2026-06-30
- v3 Superseded · retained
Residency statement aligned to the in-region deployment.
J. Park, Director of Enterprise Apps and Data · 2025-11-19
- v2 Superseded · retained
Exception process added for support access under break glass.
M. Alvarez, Compliance · 2025-03-25
- v1 Superseded · retained
First approved version.
R. Okonjo, Director of Information Security · 2024-09-10
→ what the entry said on a date is a lookup
Common questions
What teams ask first.
Is this the same as Sovrinty?
No, and the difference is worth being exact about. Cognatum decides what an AI may reach: which entries, under whose clearance, and what the request leaves behind. Sovrinty decides where the knowledge base runs and which vendors and model providers may connect to it. Sovrinty is a separate product with its own site, it runs on top of Cognatum, and you can buy this without buying that.
Can an agent see something the person could not?
No. An agent acting for one of your people carries that person's identity and is scoped to what they are entitled to see. Two people can ask the same question through the same agent and get different answers, or none.
Does this keep our data in our own country?
That is the other product. Cognatum governs what is served and to whom; Sovrinty governs where the knowledge base itself sits and who may connect. If a jurisdiction is a hard requirement for you, say so early, because it changes what you need to buy.
What do we hand an assessor?
The record: which entry answered, who approved it, on what date, at which version, and who asked. Denied requests are in it too. It is evidence toward duties your organization already carries, and it does not make you compliant with anything on its own.
Knowledge governed. Intelligence everywhere.
See it on your own content, in your own environment.