Proof
The discipline is only real if it survives contact with actual instruments. Each example shows the same three stages: source document, compiled artifact, verification.
The real artifact
Regulation (EU) 2024/1689, compiled and sealed — live on the NOMOS Exchange, not a mockup.
Real seal
Rules extracted
851
Version
1.0.0
Verification tier
Compiled
Jurisdiction
EU
Seal hash (SHA-256)
c86b56fd5754543bc44f8c343f923797a14e4921746f892ea1c2b519e3e718fb
Every one of the 851 rules is traced to a specific Article, Recital, or Annex of the official OJ text — not paraphrased. Verify the hash yourself; it doesn't depend on trusting this page.
How compilation works, illustrated
The panels below are a simplified illustration of the pattern above — one rule, not 851 — so the shape of the pipeline is readable at a glance. They are not an official interpretation of the Regulation, and the version and hash shown are placeholders, not the real seal shown above.
01 · Source document
Regulation (EU) 2024/1689
113 articles, 13 annexes, 180 recitals. Classification of a system depends on purpose, deployment context, and a set of exemptions spread across three separate articles.
02 · Compiled artifact (illustrative)
artifact: eu-ai-act/high-risk-classification
version: 2.3.0
source:
instrument: Regulation (EU) 2024/1689
clause: Article 6(2), Annex III(4)(a)
definitions:
employment_system:
scope: instrument
text: AI system intended for recruitment or
selection of natural persons
rules:
- id: R-6.2-annexIII-4a
when:
all:
- system.purpose in employment_system
- deployment.region == 'EU'
then:
classification: high_risk
obligations: [risk_management, data_governance,
human_oversight, logging]
unless:
- exemption.article_6_3 == true03 · Verification (illustrative)
input { purpose: 'cv_screening', region: 'EU' }
artifact eu-ai-act/high-risk-classification@2.3.0
digest b7f0…9ac1
result classification = high_risk
cited R-6.2-annexIII-4a ← Annex III(4)(a)
replay deterministic (1000/1000 identical)
status VERIFIEDIndependently verified
The Model Context Protocol standardises how an agent discovers and calls a tool. It says nothing about whether a given call should be allowed — that question is left to whoever wires the agent up. nomos-guard is a transparent MCP proxy that sits between an agent and any existing MCP server, checks every tools/call against a sealed authority artifact, and only forwards it on allow.
Real, third-party run
Protocol
MCP (stdio)
Policy
Sealed .nomos artifact
Verified by
Independent third party
Failure mode
Fail-closed by default
An independent party connected an external MCP server to the published nomos-guard gateway and drove real tool calls through it against a live, public NOMOS artifact — built and debugged with no involvement from this project. A call within the artifact’s declared threshold was forwarded and executed; a call that crossed it was escalated, and the downstream handler that would have carried out the action was never reached. Real audit hashes were produced for each run.
How the guard loop works, illustrated
The panels below reconstruct the shape of one call for readability — the exact argument values and audit hash are illustrative, not the literal payload from the verified run above. The rules themselves (the $1,000 threshold, the 30-day window) are the real public demo policy, pub_refund_v1.
01 · Tool call
issue_refund
The guard is a transparent MCP proxy — the downstream server needs zero changes and never learns the guard exists. Only tools/call is governed; discovery and reads pass through untouched.
02 · Policy check (illustrative)
// host calls tools/call — the guard intercepts before the
// downstream MCP server (issue_refund) ever sees it
tool issue_refund
args { refund_amount: 1500,
days_since_purchase: 12 }
// tool args become rule inputs; the tool name is injected
// so a rule can also gate on which tool is being called
POST /verify
artifact pub_refund_v1
decision issue_refund
inputs { ...args, tool: 'issue_refund' }
caller { agent_id, tool, correlation_id }03 · Verdict (illustrative)
// pub_refund_v1's rules:
// refund_amount > 1000 → escalate (dual sign-off)
// days_since_purchase > 30 → deny (outside return window)
// otherwise → allow
allowed false
outcome escalated
rule_id R-refund-threshold
verdict_description "Exceeds $1,000 — requires dual sign-off.
Do not retry with adjusted arguments;
route to a human reviewer."
audit_hash 4e9a…c105
→ issue_refund is never called. The downstream handler
that would have moved money is not reached.If the policy check itself can’t complete — the API is unreachable, or times out — the default is to block the call, not wave it through. A gateway that allows every call when its own governance layer is down isn’t a gateway.
Enterprise policy
Internal policy has no regulator forcing rigour, which is precisely why it drifts. These are the four families where decomposition pays back fastest.
Leave entitlement, eligibility, escalation thresholds — high volume, high dispute rate, definitions that change quietly.
Approval limits, vendor conditions, exception paths. The clearest example of decision logic already living in prose.
Access, classification, retention. Rules that already have machine consumers and no machine-readable source.
Clinical pathways where the cost of an unrecorded interpretation is measured in outcomes, not fines.
Have an instrument worth decomposing in public? Contributed examples are how this field builds shared reference material.
Contribute an example