Confidentiality and Guardian
In CoeOS, confidentiality is an architecture, not a promise. There is a single way out, the box; every request carries a class; confidential work can only go to models you marked safe; and anything unclassified is treated as confidential (fail-closed).
The Guardian is the governance layer that applies these rules and keeps the record. Founding principle: we classify objects, never text. The Guardian does not read document content; it reasons on labels and deterministic rules.
1. The class of a conversation
Section titled “1. The class of a conversation”Every turn carries a class, confidential or open, sent from the client to the box in
the x-coeos-class header. A request without a class is treated as confidential.
- In the web app, the class is chosen per conversation with the Confidential switch, on by default. Switching a conversation to open is only possible if the instance allows it.
- The lock: a conversation that sent a confidential turn, even a failed one, never goes back to open. Its history would otherwise leave for the open side. The app keeps the rule, on a class change and on every turn: the box only sees one request at a time.
2. Where confidential goes
Section titled “2. Where confidential goes”- Every provider is declared in the box with its safety: safe or not, and its type,
local(your machines) orZDR/DPA(a cloud provider under a data processing agreement and zero data retention). - The Local table: confidential routing, axis by axis, is a separate table, composed in the box from safe models only. The administrator manages it. When it is disabled, confidential work goes to a single safe model.
- The decider that classifies a confidential request on an axis is itself a safe model.
- No fallback. If the confidential target does not answer, the turn fails. It never falls back to an open model.
| Destination class | Meaning |
|---|---|
local | stays on your machines |
cloud_dpa | cloud provider under a DPA (and ZDR) |
cloud_no_dpa | generic cloud without a DPA: open data only |
refuse | no egress allowed: an error, never a silent fallback |
3. Where open goes
Section titled “3. Where open goes”An open conversation follows the general routing: a setting published by TMB (The Monocle Bear’s benchmark), pulled by the box and enabled by the administrator. If an open model fails, the box retries the step on another provider or model (the fallback cascade). The cascade only exists for open work.
The choice between these options depends on the level: Open, Hybrid or Local.
4. The box verdict
Section titled “4. The box verdict”The box is the single egress gateway. The client stores no provider URL or key. With
every answer, the box returns its verdict in the x-coeos-decision header: requested
class, served class, provider, model, axis, use of the decider, profile. The client
audits it before displaying the answer. The box verdict is authoritative: the client
does not re-decide.
Network isolation: the app, document search and document extraction have no route to the internet; only the box does. A build check forbids any network call outside the single egress point.
5. The audit log (tamper-evident)
Section titled “5. The audit log (tamper-evident)”Every egress attempt is recorded, before sending, in an append-only log
(guardian_decisions): timestamp, kind, tint, egress class, destination,
applied rule, label source, profile, rules fingerprint, refusal reason, box
verdict. No secret (API key, DPA key) ever appears. Two invariants are
continuously checked: never a confidential line to cloud_no_dpa; never a
non-confidential line without an identified rule.
Surface: Settings › Guardian Audit (admin / DPO), with an invariants banner, filters, and a full CSV/JSON export. This is the opposable record in the sense of GDPR art. 30.
6. One collection, one label
Section titled “6. One collection, one label”The Guardian prevents mixing confidential and open in document search: an open
conversation only receives open passages; a confidential conversation can
receive both (the label never downgrades on its own). Ingesting a document of
one label into a collection of the other is refused at bootstrap. Each RAG base
therefore carries a single label, shown in settings and on the project. A company
base whose processing goes through a cloud without a DPA is never served to a
confidential turn.
7. The compliance surfaces (Settings › Compliance)
Section titled “7. The compliance surfaces (Settings › Compliance)”- Where my data goes — the level, the three classes with endpoint / region / DPA reference / health check, and the confidential destination. GDPR transparency; no secret shown.
- System card (AI Act) — the AI Act classification, engine mode, model catalogue (id, axis, label, region, DPA), contacts (support + DPO). Legal basis: AI Act art. 4 (AI literacy). Self-classified “limited risk”, with the exclusion clause: “a decision-support tool, it renders no decision producing legal effects; the final decision belongs to the lawyer”.
- Guardian Audit — the log above (§5).
- Doctrine — the firm’s “Golden Rules” (§8).
On top of this, the AI Act banner (art. 50): the user is informed they are interacting with an AI; their acknowledgement is logged (with the text fingerprint) as legal proof.
8. The doctrine — the “Golden Rules”
Section titled “8. The doctrine — the “Golden Rules””The doctrine is a set of explicit rules (GR-001, GR-002…) that the review
workflow injects into its analysis. Two levels: firm (global) and project
(override, the project wins). Key points:
- Fail-closed: rules ship disabled — the admin enables them consciously.
- Re-evaluated on every review, never cached: disabling a rule removes it from the next review immediately.
- No active rule = review refused (a review without doctrine would be empty).
Surface: Settings › Doctrine (admin/organiser). It is the firm’s asset: its know-how becomes a versioned, auditable tool.
9. Retention (GDPR)
Section titled “9. Retention (GDPR)”Automatic, daily, logged purge: technical inference data at 30 days; authentication logs at 90 days. Not auto-purged: billing/metering (kept 10 years, Belgian accounting compliance). Each purge writes an audit trace (GDPR art. 30).
10. The Guardian today, and in V2
Section titled “10. The Guardian today, and in V2”- Today: the Guardian governs egress (classes, provider safety, box verdict, audit log, base labels). The class of a conversation is chosen by the user with the Confidential switch.
- The operator switch: the Guardian is turned on or off per instance. When it is off, every request is treated as open, for instance on a demo instance with no confidential target.
- In V2: detection. The Guardian will spot personal data, client files and trade secrets in an open conversation and propose switching to confidential. Detection and decision stay apart.
11. Governance that is verified, not declared
Section titled “11. Governance that is verified, not declared”The rules are covered by test suites (labelling, propagation, document search, egress, topology, audit) and by canaries: one proves no confidential body reaches a simulated cloud endpoint, another that an open turn never sees the confidential memory. Governance is tested, not just asserted.
Why — in three lines
Section titled “Why — in three lines”- Professional secrecy: confidential work only goes to safe models; the unknown is confidential by default; a confidential conversation stays confidential; a refusal has no fallback.
- GDPR: tamper-evident audit log (art. 30), “where my data goes” transparency, DPA tracking, bounded retention.
- EU AI Act: banner (art. 50), system card (art. 4), “limited risk” classification with the final decision left to the professional.