Use case: Governance rules

Situation

You deploy LLM agents in a context where outputs matter: legal advice, financial reports, compliance audits, medical summaries. The agents are capable, but you need guarantees:

• Agents stay within their declared scope.
• Outputs follow a defined method, not improvisation.
• Decisions are traceable and auditable.
• When something goes wrong, there is a structured recovery path.

Telling the LLM “please follow the rules” via a system prompt is not governance. LLMs can ignore instructions, hallucinate compliance, or drift out of scope without anyone noticing.

---

Solution

Cortex enforces governance server-side. Rules are stored as atoms in the graph, applied at runtime, and violations result in structured HTTP 4xx errors — not polite LLM refusals.

Governance atoms

Cortex organizes governance into nine transversal sous-familles, each covering a specific axis:

Sous-famille	What it governs
SAFETY_BASELINE	Foundational safety constraints
META_COGNITION	Self-awareness, reflection, calibration
ERROR_RECOVERY	Error handling and correction procedures
UNCERTAINTY_MANAGEMENT	Behavior under ambiguity or missing information
SCOPE_CONTROL	Staying within declared boundaries
CONSISTENCY_CONTROL	Maintaining coherence across outputs
GOAL_ALIGNMENT	Staying aligned with the mission objective
DISAGREEMENT_HANDLING	Resolving conflicts between agents
NAVIGATION_STRATEGY	How to approach complex, multi-step tasks

Governance packs

A governance pack is a collection of governance atoms assembled for a specific context. It defines what a given role is allowed to do in a given phase. Packs are versioned like any other Cortex artefact.

Server-side enforcement

When an agent makes a request through the MCP server or REST API, Cortex checks the request against applicable governance rules. If the request violates a rule, Cortex returns a structured error with a specific code and message. The agent does not get to decide whether the rule applies — Cortex decides.

This is fundamentally different from prompt-based governance, where the LLM interprets the rules and may choose to ignore them.

RBAC (role-based access control)

Cortex enforces a four-level role hierarchy on both the REST API and the MCP server:

Role	Level	Can do
reader	0	Read catalogue, search, browse
contributor	1	Draft workspace artefacts, deposit memory
producteur	2	Ingest blocs, profiles, governance atoms
admin	3	Full access including configuration

Every MCP tool and REST route declares a minimum required role. Requests below that threshold are rejected.

Audit trail

Every mutation is versioned (semver + content hash). The governance layer maintains a history of events and amendments on mission contracts, ODMs and tasks. When a decision is made, Cortex records who made it, when and why.

---

Key concepts involved

• Governance pack — governance atom collections
• ATOM — governance rules as typed, versioned atoms
• Versioning — every rule has a semantic version
• CR — structured delivery and QA reports
• Mission contract — the top-level governance frame

---

Example flow

Scenario: a team of three agents (expert, QA, leader) executing a compliance audit.

1. Setup — The leader creates a mission contract with scope_in (“audit modules A, B, C against ISO 27001”) and scope_out (“do not modify production code”). The contract is validated and enters IN_PROGRESS.

2. Scope enforcement — The expert agent requests to modify a production file. Cortex checks the active scope rules and returns a 403: “SCOPE_VIOLATION: production code modification is excluded from this mission scope.” The agent cannot proceed.

3. Method enforcement — The ODM specifies the 7-axis QA method. The expert delivers an audit that skips the security axis. The QA agent’s review references the method atom and marks the delivery as FAIL with a blocking issue: “security axis not covered per method requirement.”

4. Rework governance — The task enters REWORK status. The resilience profile allows two rework cycles before escalation. The expert corrects the delivery, the QA agent re-evaluates and delivers a PASS verdict.

5. Audit trail — At mission completion, every decision, rework, verdict and amendment is recorded in the governance audit history. A compliance officer can trace exactly what happened: who did what, when, why, and what the outcome was.

6. Version control — Six months later, the ISO 27001 reference is updated. The governance atoms are bumped to a new major version. Projects still using the old version see a drift report. They can choose when to upgrade.