One implementation
NOMOS Protocol provides infrastructure for creating, exchanging, and verifying machine-readable authority.
Reference Architecture
This architecture is the framework. It describes what has to exist between an institution's rules and a machine acting on them, regardless of who builds it.
NOMOS occupies the middle three layers: a representation for policy structure, a format for versioned authority artifacts, and a runtime that evaluates them deterministically and emits verifiable decision records.
It is not the framework, and the framework does not depend on it.
The developer surface
Layer VI, today — @nomosprotocol/sdk
import { nomos } from "@nomosprotocol/sdk";
const verdict = await nomos.can({
authority: "eu-ai-act.nomos",
ai_system_circumvents_refugee_convention: true,
});
// -> { allowed: false, verdict: 'DENIED',
// reason: 'Rule "Prohibition..." triggered...',
// query_id: 'qry_...', url: '/queries/qry_...', ... }What's universal here isn't the package name. It's the shape: ask whether something is permitted, get back a verdict, a reason, and a citable proof you can re-check independently. That shape is what a Layer VI runtime — any Layer VI runtime — should answer.
nomos.can() is NOMOS's current expression of it, the same way fetch() is the web platform's expression of "get me this resource" — owned by the platform, implemented by every browser.
Today there's one implementation, which makes this a direction, not yet a standard. It's stated here so the distinction is on record before it needs to be.
NOMOS's own pipeline
Inside NOMOS specifically, those three layers expand into their own five-step pipeline — one implementation's answer to Authority Engineering, Authority Artifacts, and Authority Runtimes.
Other implementations of those same three layers — an enterprise policy engine, a government Rules-as-Code platform — would draw this differently. The layers above are what has to exist; this pipeline is only how NOMOS chose to build it.
Responsibilities
Create
A representation for definitions, rules, conditions, exceptions and decision logic, with clause-level provenance back to the source instrument.
The open .nomos spec ↗Exchange
Content-addressed, signed artifacts that can be published, discovered, and cited by parties who did not author them.
NOMOS Exchange ↗Verify
A runtime that replays a decision against the exact cited artifact version and confirms the outcome independently of the operator.
A live sealed artifact ↗Where it runs
The architecture above and the pipeline before it are abstractions. In practice, NOMOS ships as three product surfaces built on the same compiler and runtime.
Studio
Where an institution compiles its own artifacts: a policy document is checked for contradictions, triangulated against behavioral data where it exists, scored for readiness, and sealed. Studio is the only place a seal is minted.
NOMOS Studio ↗Exchange
Where sealed artifacts are published, discovered, forked, and queried — including by third parties with no account of their own, through a keyless API.
NOMOS Exchange ↗Policy Control Plane
The store-of-record layer for institutions managing one policy across years of amendments: version lifecycle, distribution to every organisation it governs, and acknowledgement receipts. A management layer around sealed artifacts — it does not change how they evaluate.
Policy Control Plane ↗If you only take one thing from this site, take this architecture. Any implementation — NOMOS included — should be evaluated on whether it makes authority representable, versionable, and independently verifiable.