Operational Context Layer: Governed Answers and Human-Approved Actions Across Chat, Tickets, Wiki and CRM

The problem

A DACH B2B technology company runs enterprise customer projects. Each customer lives in six places at once: a ticket board, a wiki space, a chat channel, a CRM deal, several mailboxes and the meetings where the real decisions are taken. Stakeholders across sales, delivery, engineering, operations and management were interviewed before the first line of code. Their questions, condensed:

• Which of the five states of this customer is current, and who decided that?
• What changed since I last looked that I probably missed?
• Can I trust an answer, or do I have to open the source anyway?
• Can the system act on a change, and who is accountable when it does?
• What may a colleague see of my meetings and my deals, and what may an assistant see?
• Will any of this survive a security review?

The company already had digests. The chat suite summarises messages and mail per person, the wiki suite summarises pages and tickets per person. Neither cites the passage that put an item in front of you, neither carries a colleague’s signature, neither writes back into the record, and neither knows which customer a page, a thread and a ticket belong to. That gap is the whole engagement.

This case study is written for CTOs, VPs of Engineering and heads of IT in DACH companies that need a permission-aware AI assistant: governed answers and human-approved actions across chat, tickets, wiki and CRM on their own EU cloud tenant.

One table, five vocabularies. Each circle talks about the customer in its own words; the layer keeps one record under all of them, read as you, cited, signed.

Synthetic screenshot 1: the change radar, with fictional customers, people and records. Each item says when, who, which system, why it is on your radar, and quotes the mention. The signed fact carries its chain: signer first, the meeting it came from, who it is shared with, how many independent sources back it.

What the person sees

The screenshots on this page are synthetic. They show the real screens with fictional customers, people and records, so the client stays unnamed and no record leaves the tenant.

Capabilities

What people use it for, in the order they adopted it:

1. The change radar. What changed since I last looked that matters to me, folded per customer, with the mention cited or the item dropped. A day at minimum, seven at most, so time away is caught up rather than silently dropped. A source that did not answer is named on the page, so a quiet radar and a failed read are different things.
2. The morning brief. The same radar as one short text at the start of the day, counting a fact as news when it reached the graph, not only when it became true.
3. Call notes to decisions. Meeting transcripts are read live as the person and written up: notes, decisions, who agreed to do what. The decisions land in the person’s Proposals tab one row at a time. Sharing the write-ups with a colleague shows them the write-up, never the transcript.

4. Grounded questions. Ask about a customer, a page, a decision. The answer cites its sources, is trimmed to what the asker may see, and says “not found” rather than inventing.
5. Write-backs as yourself. Comment on the ticket, append to the wiki page (never replace, so inline comments stay anchored), reply in the chat thread, create a work item. Every one approved on a card, every one with a receipt.
6. The deal next to the work. CRM stage and close date beside the engineering movement, the question no single system answers.
7. The editor door. The same backend over MCP inside Claude (Cowork, Desktop, the claude.ai connector), Codex and any MCP-enabled application. Same identity, same gate, same audit trail.

something is said, or something changes in a system
  -> a person says true, or a person approves
  -> it lands, cited, for the people it concerns
  -> actions go back into the systems as the person, with a receipt

Synthetic screenshot 2: the human gate. A proposal is staged as pending and posted as a card. The same message can never open a second review; a decline is itself an audited decision.

Synthetic screenshot 3: the Proposals tab, the action inbox. One row per claim, one verdict per row. A claim that makes no checkable relation is refused with the row still pending. An assistant may propose into this queue and may not accept.

Governance guarantees

The differentiator is not the model. It is what the layer refuses to do:

1. Delegated permissions only. No service account with everything. A person sees what they would see anyway, an assistant sees what its user sees.
2. Nothing is written without a human tap. On every door, including MCP. An assistant can propose and cannot accept.
3. Never asked twice. The same message never opens a second review, and the same signal from a second message never does either; a decline and a dedup are audited decisions.
4. A review stays open until a person decides it. A lost card or a missed message never closes one, and two people never work the same row.
5. Provenance on every record, the mention cited or the item dropped. Reason, verbatim passage, author, link.

6. Rings rank sources, never people. Which system a conflicting answer should follow is shown; no grade, badge or score ever sits on a colleague.
7. HR and personal data excluded in depth. Commercial terms and anything about employment never travel, even when sharing is on. Meetings with an external participant are refused. Transcripts are never stored.
8. Append-only audit trail, including declined and deduplicated items. Rollback of a confirmed action is compensation, never deletion. Every fact is removable.
9. Gap telemetry from day one. The company sees which questions the layer could not answer, per source, so value is measured per system and never per person.
10. Data residency stated precisely. Compute and storage in the EU, on the company’s own cloud tenant. Language-model inference is not limited to the EU, and the page says so.

Guardrail

The layer never rewrites production behaviour from one session. A fact enters through a verdict, a write enters through a tap, and the audit trail keeps the declined and the deduplicated next to the confirmed. When two sources disagree, the ring says which system to follow and the chain says where to look. Nobody meets a dossier by default, and anybody can jump one hop to the record instead of sending a colleague a message.

The approval pattern behind this gate, a proposal staged as pending and a person’s tap before any write, is documented in the Human-in-the-Loop Approval Flow Blueprint.

Five capabilities this proves

1. Permission-aware answers across six systems without a service account.
2. A human gate that holds on every door, including the one an assistant uses.
3. Provenance that survives into the radar, the brief and the answer.
4. Write-backs into the systems of record as the person, with a receipt.
5. A knowledge graph that people fill through verdicts, and that pays back on the radar.

Left to right: a person says true. Right to left: a person approves the write. Everything else the layer reads is answered live and never lands on the graph.

The latest step puts the graph itself on the radar, the part no digest has:

• A colleague’s signed fact reaches the team’s radar within minutes. When a person accepts a fact and shares it with a team, everyone in that team sees it under the customer it names: the claim as the cited passage, who signed it, the team it was shared with. Membership is read as each person, so a team’s fact reaches its members and nobody else, and your own facts are not news to you.
• Where it came from, in one line. Under each item: the record it came from, who filed it, who said true to it and when, how many independent sources back it. Signer first, the meeting or mail it came from, the link to the write-up. The full chain opens on tap. It is shown as where to look, never as how much to believe.
• The test that counts. Somebody who was not in a meeting learns what was decided there without asking anybody who was. That is the sentence people use to describe the value.
• A ticket line says what moved, not where the ticket stands. “Status To Do → In Progress”, read from the change history at no extra cost. A bulk edit is one card, with the rows behind it on tap.
• Under each customer, where its changes came from. “Tickets 7 · Wiki 2 · Your mailbox 1”, the fold made visible, and a line no single system’s digest can print.
• One way onto the graph. A fact reaches the graph only through a person’s verdict or a person’s standing consent. Nothing the layer merely reads ever lands on it.

What we measured

Honest status

In pilot use on the client’s own tenant. Adoption is measured from audit events per door, never from opinions.