Integrations
Works with what you already use.
Cognatum connects to source systems and to AI consumers over MCP and REST API, in both directions.
The shape
Open in, open out.
MCP is the open standard AI assistants use to reach outside data, and a REST API is the ordinary web interface everything else already speaks. An AI system does not go live until a review board signs it off.
Regulated enterprises are deploying AI assistants and agents they cannot prove are answering correctly, and their AI initiatives are stalling at governance review because of it.
An answer is only provable if whatever served it carried the proof along: who approved it, when, and from which document. That is the job of this layer.
- Knowledge comes in from the systems your people already work in.
- It goes out to people and to AI systems with the proof attached.
- Corrections go back to where the wrong answer was found.
- What gets asked and used comes back to us.
Cognatum governs the entry
source · version · approver · permissions
Flow one
Knowledge comes in.
Ingest connectors run over API and MCP against the systems where work already happens. What they find enters the loop as candidate knowledge: normalized, traceable to its source, and not served to any consumer. Candidate status is the first governance boundary, and it is enforced at the integration layer, not by convention.
Capture is deliberately wide, because nothing captured is live and the gates come later. Custom and in-house sources connect through the same REST API the standard connectors are built on.
- SharePoint and Drive: documents and files.
- Slack and Teams: conversations and decisions.
- CRM: customer knowledge.
- Ticketing and ITSM: resolved issues.
- Wikis and portals: legacy content.
The question
Which retention period applies to client trade communications?
Today, without a governed home
- A slide deck from two years ago says five years.
- A policy PDF on a shared drive says six.
- A chat thread says it depends, and links nothing.
- Nobody knows which one is current.
With one approved entry
Six years, the first two in an accessible place, on non-rewriteable media.
Flow two
How an assistant asks.
An assistant connects to our MCP server, sees what it can ask for, and asks. What comes back is the approved entry with its approver, its date, its source, and its version. Applications that do not speak MCP use the REST API for the same thing.
Permissions are checked on every request. An agent working for one of your people is held to what that person is allowed to see, not to some broad service account. It can never fetch what they could not.
// request
{
"method": "tools/call",
"params": {
"name": "get_governed_answer",
"arguments": { "query": "Approved disclosure language for fund performance reporting" }
}
}
// response (abridged)
{
"content": [{ "type": "text", "text": "[the approved entry text, served verbatim]" }],
"provenance": {
"approver": "J. Mercer, Regulatory Affairs",
"approvedAt": "2026-07-14",
"source": "SOP-4471",
"version": "v3"
}
}The boundary
What is served, and logged.
Only approved entries are served. Candidate, draft and retired content cannot be fetched through these interfaces at all.
Every time an entry is served we record which entry, which version, who asked, and when. That is what lets you take an answer someone was given nine months ago and trace it to the exact approved version behind it.
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
Flow three
Corrections go back.
When the loop approves an entry that supersedes something in a source system, the stale wiki page does not have to stay wrong. Write-back pushes the correction out over the same connections that brought the knowledge in, so the fix lands where people will keep looking.
It is governed like everything else. Only approved content goes out, it passes the Approve gate first, and the write is recorded against the entry. Written content is stamped with the entry and version behind it, so a connector that meets that page again knows it as our own output rather than capturing it as something new.
Use disclosure D-214 rev 6. It supersedes rev 5 for all retail communications and carries the current market-risk language. SOP-4471 v3
Proposal tools
Where this problem is expensive.
Answering an RFP or a security questionnaire is this problem at its most expensive: an unapproved answer, in writing, sent to a prospect. Our knowledge layer grew up underneath RocketDocs, which has spent three decades on exactly that, and RocketDocs connects to Cognatum natively.
Other proposal tools connect over the REST API to the same governed surface. The answer library a proposal team pulls from is the approved set itself, so every reused answer arrives with its approver, date, source and version, and a stale answer stops being served everywhere the moment its entry is retired.
Flow four
What gets asked comes back.
Every retrieval tells us something: what was asked, what was served, what was reused, and where an answer fell short. Those signals go back into the loop. Capture learns what is missing, Clean learns which entries confuse people, and Improve learns which wording does not work.
That is the mechanism behind the tagline. The governance lives in one place; the reading does not. Any assistant, agent, proposal tool or portal draws on the same approved entries, including ones nobody has written yet.
Knowledge governed. Intelligence everywhere.
-
01
Capture
Ingest from every source.
-
02
Structure
Normalize the format.
-
03
Clean
Update, deduplicate, reconcile, archive.
-
04
Enrich
Add context and tags.
-
05
Improve
Refine clarity, usability.
-
06
Approve
Human sign-off, audited.
A person holds this step
-
07
Integrate/Deploy
Push live everywhere.
-
08
Reuse
Serve people and AI.
Common questions
What engineers ask first.
How is access controlled when an agent queries over MCP?
Permissions are evaluated on every request. An agent acting for a user carries that user's identity and is scoped to that user's entitlements, not to a broad service account. Two users asking the same question through the same agent can receive different answers, and each receives only what they are entitled to see.
Can an agent retrieve unapproved content?
Not through the serving interfaces. Only approved entries are served by default; candidate, draft, and retired content is excluded. Review and authoring surfaces are separate from the serving surface, so working material is available to the people governing it without ever being retrievable by a consuming agent.
What is the difference between the MCP server and the REST API?
They expose the same governed surface. MCP is the native interface for assistants and agents: tool discovery, tool calls, and provenance in every response. The REST API carries the same operations for applications, workflows, and integrations that do not speak MCP, including custom ingest and the proposal-tool integrations. Neither interface can reach content the other could not.
Does write-back create a feedback loop with ingest?
No. Content written back to a source system is marked with the entry and version it came from, so when a connector encounters it again, it is recognized as the governed entry's own output rather than captured as new candidate knowledge. The correction lands where people look, and the loop does not eat its own tail.
How do we trace an answer an agent gave last quarter?
Every serve event is logged with the entry, the version, the requester, and the timestamp. Joined with the entry's approval record, that yields the full chain: which approved version was served, to whom, when, who approved it, and from which source. That chain is evidence you supply toward your own obligations; Cognatum does not confer compliance with any framework.
Which source systems have connectors?
Document stores such as SharePoint and Drive, collaboration tools such as Slack and Teams, CRM systems, ticketing and ITSM systems, and wikis and portals. Anything else connects through the REST API, which is the same interface the standard connectors are built on.
Knowledge governed. Intelligence everywhere.
See it on your own content, in your own environment.