The Guardian and compliance

The Guardian is the governance layer that guarantees no data leaves the authorised perimeter. It is CoeOS’s trust foundation for a professional bound by secrecy: it classifies every object, decides where it is allowed to go, records it in a tamper-evident log, and refuses rather than let a doubt through.

Founding principle: we classify objects, never text. The Guardian does not read document contents — it reasons over labels and deterministic rules. And by default, anything unclassified is confidential (fail-closed).

1. What the Guardian does

It is a single egress point: everything that leaves the application’s network (a model call, embeddings, mail, a tool, document retrieval, memory compilation) must pass its decision. There is no other door. Two notions drive it: the tint of an object (confidential or open) and the allowed destination class.

Class	Meaning
local	stays on the machine, never leaves
cloud_dpa	cloud provider under a data processing agreement (DPA)
cloud_no_dpa	generic cloud without a DPA — open data only
refuse	no egress allowed → error, never a silent fallback

2. The installation profile (fixed)

Every deployment carries a profile, set at install time and never changeable by a user:

• local (on-prem firm): confidential data stays local. It never goes to a DPA. If the local endpoint is down → error, no workaround.
• vps (dedicated cloud, e.g. OVH): confidential data goes to cloud_dpa (a provider under a DPA), never a generic cloud.

3. How an egress is decided

For each attempt, the Guardian applies a sequence of deterministic checks, in order, and never throws (it returns a verdict):

1. No label or no identified rule → refuse (fail-closed).
2. Endpoint offline → refuse (endpoint_offline, no fallback).
3. Confidential to a non-local destination without a DPA reference → refuse.
4. Confidential + local profile + non-local destination → refuse (strict: never a DPA in the local profile).
5. Otherwise: local destination → local; DPA present → cloud_dpa; open data → cloud_no_dpa; confidential without a DPA to the cloud → refuse.

No fallback. A refusal is a refusal: if the decided class has no available endpoint, an error (503) is raised; it never silently switches destination.

4. The “confidential” signal and routing

• Each turn carries a class header (x-coeos-class) sent from the client to the box. By default, everything is treated as confidential (fail-closed). A per-conversation button lets an authorised operator explicitly switch to open.
• The decision lives in the box, the single egress gateway. The client stores no provider URL or key, only the box address. The box returns its verdict (x-coeos-decision: requested class, served class, provider, model, skill axis, profile, rules fingerprint), which the client audits before showing the reply. The box’s verdict is authoritative.
• Network isolation: at startup the Guardian verifies the topology. The app, RAG 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)

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

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.

7. The compliance surfaces (Settings › Compliance)

• Where my data goes — the profile, the three classes with endpoint / region / DPA reference / health check, and the confidential destination (not editable, derived from the profile). 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”

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).

It is the firm’s asset: its know-how becomes a versioned, auditable tool.

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. Governance that is verified, not declared

The Guardian is not a promise: it is 100 test cases across 6 families (labelling 25, propagation 20, retrieval 15, egress 20, topology 10, audit 10) that check each rule exactly, plus “canary” reports proving no confidential body reaches a simulated cloud endpoint. Governance is tested, not merely stated.

---

Why — in three lines

• Professional secrecy: confidential data never leaves the authorised perimeter; the unknown is confidential by default; a refusal has no fallback.
• GDPR: opposable 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 lawyer.

The AI advises, the lawyer decides — and the Guardian proves nothing left the frame.