Use case: Governance rules
Situation
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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)
Section titled “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
Section titled “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
Section titled “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
Section titled “Example flow”Scenario: a team of three agents (expert, QA, leader) executing a compliance audit.
-
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.
-
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.
-
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.”
-
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.
-
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.
-
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.