Every claim signed. Every signature verifiable. Every decision — by any human, machine, or AI — proven in cryptographic proof, not faith.
The Quiet Eye Stack
QEPS
Certification Framework
47 Tests
NEMEK
Federation Layer
BFT Consensus
QUIET EYE
Oversight + Full Architecture
Immutable
CCR
Execution Runtime
Deterministic
CCSL
Governance Language
Signed Rules
PCN
Cryptographic Identity
Self-Sovereign
47
Standardized Conformance Tests
6
Regulatory Conformance Profiles
100%
Pass Rate Required — No Partial Credit
The Problem
THE TRUST CRISIS IS INFRASTRUCTURE.
The digital world runs on a tacit agreement: you trust that systems do what they claim. You trust the AI agent made the right decision. You trust the governance policy was actually enforced. You trust that the audit log wasn't altered. You trust, and you hope.
That model is collapsing. As AI systems acquire authority over critical infrastructure, financial systems, healthcare, and borders, the cost of misplaced trust becomes existential — not theoretical. We are building the cognitive layer of civilization on foundations of assumption.
"Trust without proof is not trust. It's hope. And hope is not an architecture."
Verity Intelligence was built to replace hope with proof. Not better security theatre. Not more auditable-in-theory systems. Actual cryptographic proof — at every layer, for every action, at the edge, at scale, offline if necessary.
The Quiet Eye stack encodes governance into the runtime itself. Rules are signed. Execution is deterministic. Oversight is structurally independent of governance. And the entire chain — from the first identity handshake to the last federated consensus — is independently verifiable by anyone who cares to check.
This is what governed cognitive infrastructure looks like. Not a compliance checkbox. Not a trust framework. A proof engine — for the machines and AI that will carry civilization forward.
Built For
WHERE IT MATTERS MOST
⚕
Healthcare
HIPAA-compliant governed AI with cryptographic audit trails for every clinical decision.
🛂
Border & Identity
ICAO-compliant biometric identity verification with offline-capable edge execution.
🏛
Critical Infrastructure
BFT-resilient governance for power, water, and transport systems that cannot fail.
🏦
Financial Systems
FIPS 140-3 cryptographic governance for regulated financial AI with sealed audit reports.
Get Started
PROOF IS A PRODUCT. BUILD WITH IT.
The Quiet Eye Stack
FIVE LAYERS. ONE PROOF CHAIN. ZERO ASSUMPTIONS.
The Quiet Eye architecture is not a security framework you layer onto an existing system. It is a complete rethinking of how digital infrastructure establishes, enforces, and proves trust — at the edge, at scale, without a central authority.
PCN
Personal Continuity Node
Who are you?
The Identity Foundation — Cryptographic, Self-Sovereign, Unstealable
Every actor in the Verity ecosystem — a person, an AI agent, an IoT sensor, a NEMEK node — begins here. The Personal Continuity Node is the cryptographic anchor from which all trust derives. It holds an Ed25519 key pair, capability declarations, and a node descriptor, all stored locally on the device. Never on a server. Never phoning home.
"Personal" is not a marketing word. It is an architectural commitment. Your keys live on your hardware. Your identity is yours. You can sign requests offline, authenticate without network round-trips, and resync state when connectivity returns. No cloud dependency. No single point of failure. No single point of compromise.
PCN is the root of the trust chain. Every signed artifact — every governance rule, every execution record, every audit entry — traces back to a PCN identity. Which means you can always answer the first question that matters: who authorized this?
Key Algorithm
Ed25519
Key Storage
Local device only — never server-side
Hardware Support
YubiKey, TPM, Biometric (mobile)
Network Requirement
None — offline-capable by design
CCSL
Central Compute Self-Processing Language
What are you allowed to do?
The Constitutional Governance Layer — Rules That Are Proven, Not Trusted
CCSL is the difference between trusting a system to behave and proving it behaved. It is the governance language of the Quiet Eye stack: the layer that answers what any actor is authorized to do, and that makes that authorization cryptographically verifiable.
Policy definitions compile into enforced compartment-based security rules. Every ruleset is cryptographically signed by a known identity — governance itself is tamper-evident. The static analyzer (Mini-BEV) verifies rules before execution. The sandboxed verified executor enforces them at runtime. The chain-of-state ledger records every transition.
Crucially, CCSL operates at the edge. Rules are enforced locally, not by calling home to a policy server. Which means governance survives network partition, adversarial conditions, and the full spectrum of real-world failure modes.
Attestation Format
SAF v2 multi-signature
Execution Model
Sandboxed verified executor
Static Analysis
Mini-BEV pre-execution verification
Execution Locality
Edge — network-independent
CCR
Cognitive Continuity Runtime
What was actually done?
The Execution Layer — Safe, Deterministic, Provable
After PCN establishes identity and CCSL grants authorization, CCR executes the operation. It is the governed runtime — the sandboxed environment where actions actually happen, and where proof of execution is produced.
The defining property is determinism. The same inputs produce the same outputs, every time, and that can be proven. QEPS test vectors CCR-01 through CCR-07 specifically verify this determinism under adversarial conditions.
CCR maintains persistent state across sessions without cloud dependency. It enforces strict isolation boundaries between compartments — a misbehaving process cannot bleed into adjacent operations.
Execution Model
Deterministic state transitions
Isolation
Compartment-level runtime boundaries
State Persistence
Cross-session, no cloud dependency
QEPS Tests
CCR-01 through CCR-07
QUIET EYE
Oversight Layer + Full Architecture
Is it working correctly?
The Oversight Layer — Sees Everything, Controls Nothing
Quiet Eye is both the name of the complete stack and the name of its oversight layer. As an oversight mechanism, its most important property is what it cannot do: it has no governance authority. It can observe. It can record. It can report. It cannot intervene, modify, or suppress.
This separation is not incidental. An oversight layer that shares authority with the governance layer it monitors is not oversight — it is theater. Quiet Eye's structural independence is the property that makes it trustworthy to regulators, auditors, and adversaries alike.
The audit trail is append-only and immutable. It logs the complete lifecycle of every action into a single verifiable chain. Anyone can read it. No one can alter it.
Audit Trail
Append-only, immutable
Governance Authority
None — structurally independent
Visibility
Full action lifecycle from PCN → consensus
Access Model
Public transparency by design
NEMEK
Federated Node Network
Can we agree without a center?
The Federation Layer — Coordinating at Civilizational Scale Without Central Authority
PCN, CCSL, CCR, and Quiet Eye operate at the edge device level. NEMEK operates at the network level. It is the distributed trust graph that enables coordination across millions of nodes without any central authority to attack, corrupt, or coerce.
NEMEK uses Byzantine fault-tolerant consensus. The network continues to function correctly even if some nodes behave maliciously or fail. Consensus on global governance decisions requires 5 of 7 verifier signatures.
The governance model follows subsidiarity: edge nodes maintain sovereignty over local decisions, regional coordinators handle inter-node policies, and the federation layer handles only what must be handled globally. NEMEK coordinates — it does not control.
Consensus Model
Byzantine fault-tolerant (5-of-7)
Local Finality
Sub-second
Global Consensus
~10 seconds
Target Scale
1M+ actions/sec across 10M+ devices
QEPS
Quiet Eye Production Specifications
Does it actually work?
The Certification Framework — 47 Tests. 100% Required. No Exceptions.
QEPS is not a checklist. It is the specification layer that turns architectural claims into verifiable guarantees. An 8-layer framework with 47 standardized tests, each with an RFC-quality specification and dedicated test vectors. A system either passes at 100% or it does not receive certification.
Certification reports are cryptographically sealed. SHA-256 hash chains create an immutable, blockchain-style audit trail of every test run — making the certification history itself tamper-evident.
Six conformance profiles target specific regulatory contexts: FULL (all 47 tests), LEVEL_C (critical infrastructure), EU_eIDAS (European digital identity), ICAO_BORDER (border control), FIPS_140_3 (cryptographic modules), and HIPAA_BAA (healthcare).
Every step produces proof. No step requires trust.
PCN
Proves identity
→
CCSL
Proves authorization
→
CCR
Proves execution
→
QUIET EYE
Proves correctness
→
NEMEK
Proves consensus
Real-World Deployments
WHERE PROOF IS NOT OPTIONAL.
The Quiet Eye stack was designed for the domains where trust failures aren't inconvenient — they're catastrophic. These are some of them.
01
Healthcare / HIPAA
Governed Clinical AI With Cryptographic Accountability
AI-assisted clinical decision support is only trustworthy if you can prove — not merely assert — that every recommendation was generated within authorized governance boundaries. Verity embeds CCSL governance rules directly into the AI execution runtime. Every clinical action is signed, every authorization is verifiable, and every audit trail is cryptographically sealed and HIPAA_BAA conformant.
HIPAA_BAACCR ExecutionQuiet Eye AuditPCN Identity
02
Border Control / ICAO
Self-Sovereign Biometric Identity That Works Offline
Border infrastructure operates in contested, degraded, and intermittent network environments. Identity verification cannot depend on a call to a central server. PCN's local-first architecture means identity credentials are verified on-device, with Ed25519-signed authentication that produces cryptographic proof without network round-trips.
Byzantine-Resilient Governance for Infrastructure That Cannot Fail
Power grids, water systems, and transport networks are increasingly governed by AI and autonomous systems. The consequence of a governance failure is not a bad UX — it is a city without power. NEMEK's Byzantine fault-tolerant consensus means the governance network continues to function correctly even under active adversarial conditions.
LEVEL_CNEMEK BFTEdge GovernancePartition Tolerant
04
Financial Services / FIPS 140-3
Regulated AI Governance With Sealed, Verifiable Audit Reports
Regulated financial institutions face an uncomfortable truth: the AI systems making risk, lending, and compliance decisions are not independently verifiable. CCSL governance rules encode compliance policy into the AI execution layer. CCR's deterministic execution means decisions are replayable and auditable.
eIDAS 2.0 mandates that EU member states offer digital identity wallets to citizens that they fully control. PCN's self-sovereign architecture — keys on device, no server dependency, offline-capable — maps directly to the eIDAS model. Federation via NEMEK means identity attributes can be shared across borders while maintaining local sovereignty.
Governance Built Into the AI Runtime — Not Bolted On
The standard approach to AI governance is a layer of monitoring and guardrails that the AI operates under. This is fundamentally insufficient. Verity encodes governance into the execution layer itself via CCSL. The AI agent literally cannot execute an action that the signed governance rules do not permit. Every action produces proof.
Your sector has its own proof requirements. Verity's conformance profiles are designed to meet them.
Technical Whitepaper
GOVERNED COGNITIVE INFRASTRUCTURE
A complete technical specification of the Quiet Eye architecture — the cryptographic identity, governance, execution, oversight, and federation stack for AI systems that must be trusted without assumption.
We present Quiet Eye: a five-layer architecture for governed cognitive infrastructure in which every claim about identity, authorization, execution, and consensus is supported by cryptographic proof rather than institutional trust.
The architecture comprises five components: the Personal Continuity Node (PCN), a self-sovereign cryptographic identity layer; the Central Compute Self-Processing Language (CCSL), a constitutional governance engine operating at the edge; the Cognitive Continuity Runtime (CCR), a deterministic sandboxed execution environment; the Quiet Eye oversight layer, a structurally independent append-only audit system; and NEMEK, a Byzantine fault-tolerant federated node network.
Together, these components implement the principle of trust without trust: a system design in which no participant need trust any other participant, because every relevant property of every relevant operation is proven by cryptographic evidence rather than asserted by institutional claim.
01
The Trust Crisis in Cognitive Infrastructure
Why institutional trust is structurally insufficient for AI systems operating at civilizational scale — and what it would mean to replace it with proof.
02
Architecture Overview: The Quiet Eye Stack
A system-level description of the five-layer architecture and the proof chain connecting identity, governance, execution, oversight, and federation.
03
PCN: Cryptographic Identity at the Edge
Formal specification of the Personal Continuity Node — Ed25519 key management, offline authentication, biometric binding, and the self-sovereign model.
04
CCSL: Constitutional Governance Language
The policy compilation model, SAF v2 multi-signature attestation, Mini-BEV static analysis, sandboxed execution, and the chain-of-state ledger.
05
CCR: Deterministic Execution Runtime
Determinism guarantees, compartment isolation architecture, state persistence model, and the bridge between governance and oversight.
06
Quiet Eye: Structural Oversight Independence
Why governance authority and oversight authority must be structurally separate — and how Quiet Eye implements that separation without sacrificing completeness.
07
NEMEK: Byzantine Fault-Tolerant Federation
The distributed trust graph, BFT consensus model, node admission protocol, subsidiarity governance, and performance targets at civilizational scale.
08
QEPS: Certification Without Faith
The 8-layer, 47-test framework, RFC specifications, hash-chained audit reports, and the six regulatory conformance profiles.
DESIGN PHILOSOPHY
The Quiet Eye architecture was designed around a single conviction: that the digital infrastructure underpinning civilization should not require trust in any party — not the infrastructure provider, not the governance layer, not the AI systems operating within it, and not Verity itself.
This is not an aspirational statement. It is an architectural constraint. Every design decision in the stack was evaluated against the question: does this require the user, auditor, or regulator to take our word for something? If yes, the design was rejected until the answer could become no.
The result is a system where proofs are first-class objects. Identity is a proof. Authorization is a proof. Execution is a proof. Consensus is a proof.
THREAT MODEL
The Quiet Eye stack is designed to maintain its security and governance properties under the following adversarial conditions: compromised network infrastructure, malicious edge nodes (up to 2 of 7 verifier nodes in NEMEK), physical device compromise (excluding the secure enclave), supply chain attacks on non-cryptographic components, and an adversarial oversight observer with read-only access.
The stack does not protect against: physical compromise of the secure enclave or TPM, compromise of the PCN key material prior to system initialization, or governance rules that are themselves maliciously authored.
The Quiet Eye stack is a five-layer governed cognitive infrastructure framework. This documentation covers everything needed to deploy, integrate, and certify a Verity-compliant system — from the cryptographic identity layer up through federated consensus.
Architecture at a Glance
The stack operates as a proof chain. Each layer depends on and extends the proofs produced by the layer below it:
Layer
Component
Core Property
Status
1
PCN
Self-sovereign cryptographic identity
Stable
2
CCSL
Constitutional governance at the edge
Stable
3
CCR
Deterministic sandboxed execution
Stable
4
Quiet Eye
Independent append-only audit
Stable
5
NEMEK
BFT federated consensus
v1.0
—
QEPS
Conformance certification
v1.0.0
Design invariant: No layer in the stack requires trust in any other layer or in Verity Intelligence. Every property claimed by every layer is supported by cryptographic proof that any party can independently verify.
The Proof Chain
PCN produces a signed identity assertion. CCSL produces a signed authorization proof against the current governance rules. CCR produces a signed execution trace proving deterministic state transitions. Quiet Eye appends all three proofs to the immutable audit log. NEMEK produces a BFT-consensus signature from 5 of 7 verifier nodes confirming network-level agreement.
The result is a single operation with five independently verifiable proofs. It can be verified by any party without access to Verity systems.
Important: The Quiet Eye stack provides cryptographic proof of what happened within the governance rules that were in effect. Authoring and signing governance policy is a critical operation — see the CCSL documentation for policy signing requirements.
QEPS Certification
Production deployments must achieve QEPS certification before operating in governed mode. Certification requires 100% pass rate across all applicable test vectors for the chosen conformance profile.
Current conformance profiles: FULL · LEVEL_C · EU_eIDAS · ICAO_BORDER · FIPS_140_3 · HIPAA_BAA
Getting Started
QUICK START
Get a Verity-compliant node running locally in under 10 minutes. This guide walks through PCN initialization, a minimal CCSL governance policy, and your first CCR execution with a verified audit trail.
Prerequisites
Before starting, ensure you have a supported hardware security module available. PCN key material must be generated and stored in hardware — software-only key storage is not permitted in governed mode.
Requirement
Minimum
Notes
Hardware security
YubiKey 5 / TPM 2.0
Required for PCN key generation
OS
Linux 5.15+ / macOS 13+
Windows support via WSL2
Runtime
CCR v1.0+
Included in the SDK
Network
Optional
All core operations are offline-capable
Step 1 — Initialize Your PCN
PCN initialization generates your Ed25519 key pair on the hardware security module and produces a signed node descriptor. This is the identity anchor for all subsequent operations.
verity pcn init --hsm yubikey --profile operator
Output: PCN-{fingerprint}.json — your signed node descriptor. Store this; it is your identity on the network.
Step 2 — Author a Governance Policy
A CCSL policy defines what actions are authorized for which identities under which conditions. The minimal policy below permits a single operator to execute read-only operations.
Before operating in governed mode, run the applicable QEPS test suite against your configuration. All tests must pass at 100%.
Never skip pre-flight. A node that hasn't passed QEPS certification will be refused admission to NEMEK federation and will log all operations as ungoverned.
Getting Started
CORE CONCEPTS
Five concepts underpin everything in the Quiet Eye stack. Understanding them is more important than understanding any individual component API.
1. Proof-First Design
In a proof-first system, a claim is only valid if it is accompanied by cryptographic evidence that any verifier can independently check. The Quiet Eye stack does not ask verifiers to trust Verity, trust the node operator, or trust the governance author. Every claim — identity, authorization, execution, consensus — is a proof object, not an assertion.
2. The Trust Chain
Trust in the Quiet Eye stack is not a property of any single component. It is an emergent property of the chain: PCN proves who you are → CCSL proves what you're allowed to do → CCR proves what was actually done → Quiet Eye proves the system is working correctly → NEMEK proves the network agrees. Break any link and the chain is broken.
3. Structural Independence of Oversight
The Quiet Eye oversight layer has no governance authority. It cannot modify, suppress, or selectively report on the operations it observes. This is not a policy constraint — it is an architectural property. An oversight system that shares authority with the system it monitors is not oversight.
4. Edge Sovereignty
Every layer in the stack is designed to operate without network connectivity. PCN authenticates offline. CCSL enforces governance rules locally. CCR executes deterministically without cloud calls. The network (NEMEK) is used for consensus when available, not as a dependency for local operation.
5. Certification as First-Class Infrastructure
QEPS certification is not a compliance checkbox run at the end of a project. It is infrastructure. The test suite runs continuously. Certification reports are cryptographically sealed. The certification history is itself tamper-evident via SHA-256 hash chains. If a node's behavior changes, the certification record shows exactly when.
Stack Components
PCN
The Personal Continuity Node is the cryptographic identity anchor for every actor in the Verity ecosystem — humans, AI agents, IoT devices, and NEMEK nodes alike. Keys live on hardware. Identity is self-sovereign. Authentication works offline.
Key Generation
PCN uses Ed25519 for all signing operations. Key generation must occur on a supported hardware security module — the private key never leaves the hardware boundary. Supported HSMs include YubiKey 5 series, TPM 2.0, and mobile biometric enclaves (iOS Secure Enclave, Android StrongBox).
Ed25519 properties relevant to PCN: 64-byte signatures, fast verification, no per-signature randomness requirement (deterministic), resistant to timing side-channels, and small key sizes suitable for constrained devices.
Node Descriptor
After key generation, PCN produces a signed node descriptor — a JSON document containing the public key, capability declarations, node type, and a creation timestamp. The descriptor is signed by the private key, making it self-authenticating. It is the PCN identity artifact shared with other parties.
Offline Authentication
PCN authentication produces a signed challenge-response that verifiers can check against the node descriptor without any network call. This is the property that enables Verity deployments in air-gapped, intermittently connected, and adversarially degraded environments.
Key Specs
Property
Value
Algorithm
Ed25519
Signature size
64 bytes
Key storage
HSM only — never in software
Network requirement
None
QEPS tests
PCN-01 through PCN-06
Stack Components
CCSL
The Central Compute Self-Processing Language is the constitutional governance layer of the Quiet Eye stack. It defines what any actor is authorized to do — and makes that authorization cryptographically verifiable, enforced at the edge, without calling home.
Policy Model
CCSL policies are declarative rule sets that compile into enforced compartment-based security boundaries. Policies are authored in the CCSL DSL, statically analyzed by Mini-BEV before deployment, cryptographically signed by an authorized identity, and then enforced at runtime by the sandboxed verified executor inside CCR.
Signing Requirements
Every deployed CCSL policy must carry a valid SAF v2 multi-signature attestation. The minimum signing threshold and required signatories are defined at the system level during initialization. A policy without valid signatures will be rejected by CCR — governance cannot be silently bypassed.
Policy authoring is a high-privilege operation. The PCN identities authorized to sign governance policies should be held to the same standard as cryptographic root-of-trust material. Compromise of a policy-signing key is a governance compromise.
Chain-of-State Ledger
CCSL maintains a chain-of-state ledger recording every policy transition — creation, amendment, activation, and retirement. Each entry is signed and linked to the previous entry, creating an immutable governance history. The ledger is available to Quiet Eye for audit.
Mini-BEV Static Analysis
Before any policy is deployed, Mini-BEV performs static verification: checking for conflicting rules, unreachable permissions, privilege escalation paths, and specification violations. A policy that fails Mini-BEV analysis cannot be signed or deployed.
Property
Value
Attestation format
SAF v2 multi-signature
Static analysis
Mini-BEV pre-deployment
Execution locality
Edge — network-independent
QEPS tests
CCSL-01 through CCSL-09
Stack Components
CCR
The Cognitive Continuity Runtime is the governed execution environment where operations actually happen. Its defining property is determinism: the same inputs always produce the same outputs, and that can be proven.
Deterministic Execution
CCR enforces deterministic state transitions. Every execution produces a signed execution trace that includes: the input state hash, the operation identifier, the CCSL authorization proof used, the output state hash, and a timestamp. This trace is the execution proof — it can be replayed and verified by any party.
Why determinism matters: A non-deterministic runtime cannot be audited. If the same inputs can produce different outputs, there is no way to verify that the execution trace represents what actually happened. CCR's determinism guarantee is the property that makes CCR execution auditable.
Compartment Isolation
CCR enforces strict isolation between compartments. Each operation runs in an isolated execution context — a misbehaving or compromised operation cannot access the state of adjacent compartments. Compartment boundaries are defined in the CCSL policy and enforced at the runtime level.
State Persistence
CCR maintains persistent state across sessions without cloud dependency. State is cryptographically sealed between sessions and can only be resumed by the PCN identity that created it. This enables long-running governed processes that survive network partition, device restart, and operator changes.
Property
Value
Execution model
Deterministic state transitions
Isolation
Compartment-level boundaries
State persistence
Cross-session, sealed, no cloud
QEPS tests
CCR-01 through CCR-07
Stack Components
QUIET EYE
The Quiet Eye oversight layer observes everything and controls nothing. It is the structurally independent audit system that records the complete lifecycle of every operation — from PCN identity through NEMEK consensus — into an append-only, immutable log.
Structural Independence
Quiet Eye has no governance authority. It cannot modify operations, suppress audit entries, or intervene in execution. This is not a policy constraint — it is an architectural property enforced by the system design. The oversight layer and the governance layer are structurally separated, with no shared authority surface.
Why this matters: An oversight system with governance authority is not oversight — it is governance wearing an oversight label. Regulators, auditors, and adversaries alike can trust Quiet Eye precisely because it cannot be used to govern.
Audit Trail Structure
Every operation logged by Quiet Eye produces a structured audit entry containing: the PCN identity of the actor, the CCSL authorization proof, the CCR execution trace, the NEMEK consensus record (when available), a timestamp, and a SHA-256 link to the previous entry. The log is append-only — entries cannot be modified or deleted.
Public Verifiability
The Quiet Eye audit trail is designed for public verifiability. Any party with access to the log can independently verify any audit entry without trusting Verity, the node operator, or any other party. The verification requires only the node descriptor of the actor and the public specifications.
Property
Value
Audit trail
Append-only, immutable
Governance authority
None
Entry chaining
SHA-256 linked
QEPS tests
QE-01 through QE-05
Stack Components
NEMEK
NEMEK is the federated node network — the distributed trust graph that enables coordination across millions of nodes without any central authority to attack, corrupt, or coerce. It uses Byzantine fault-tolerant consensus. It coordinates; it does not control.
Byzantine Fault Tolerance
NEMEK consensus requires 5 of 7 verifier signatures for global governance decisions. The network continues to function correctly even with up to 2 malicious or failed verifier nodes. No single party can make unilateral changes to global governance state — consensus is required.
BFT in practice: Byzantine fault tolerance means the network is resilient not just to node failures, but to actively malicious nodes — nodes that send false messages, selectively withhold information, or attempt to manipulate consensus. Up to ⌊(n−1)/3⌋ malicious nodes are tolerated.
Node Admission
Nodes must hold a valid QEPS certification to be admitted to the NEMEK federation. This ensures the trust properties of the network are maintained as it scales. A node that loses certification is automatically suspended from the network until recertification is achieved.
Subsidiarity Model
NEMEK implements a subsidiarity governance model: edge nodes maintain full sovereignty over local decisions, regional coordinators handle inter-node policy, and the federation layer handles only what cannot be handled locally. NEMEK never overrides local governance — it extends it to the network level when necessary.
Property
Value
Consensus model
BFT (5-of-7 threshold)
Local finality
Sub-second
Global consensus
~10 seconds
Target scale
1M+ actions/sec, 10M+ devices
QEPS tests
NEMEK-01 through NEMEK-08
Certification
QEPS
The Quiet Eye Production Specifications are the certification framework that turns architectural claims into verifiable guarantees. 8 layers. 47 tests. 100% pass rate required. No partial credit.
Framework Structure
QEPS is organized into 8 layers corresponding to the components and cross-cutting concerns of the Quiet Eye stack. Each layer has a set of numbered test cases, each with an RFC-quality specification and dedicated test vectors that can be run deterministically.
Layer
Tests
Coverage
PCN
PCN-01–06
Key generation, offline auth, HSM binding
CCSL
CCSL-01–09
Policy compilation, signing, Mini-BEV
CCR
CCR-01–07
Determinism, isolation, state persistence
Quiet Eye
QE-01–05
Audit immutability, independence
NEMEK
NEMEK-01–08
BFT consensus, node admission
Integration
INT-01–07
Full proof chain, cross-layer
Adversarial
ADV-01–03
Threat model verification
Regulatory
REG-01–02
Profile-specific requirements
Sealed Certification Reports
QEPS certification reports are cryptographically sealed. Each report includes: a SHA-256 hash of every test result, a chain link to the previous certification run, the PCN identity of the certifying operator, and a timestamp. This makes the certification history itself tamper-evident — any alteration to a past report breaks the chain.
Version: QEPS v1.0.0 — Released February 10, 2026 Specifications: QEPS-RFC-001 through QEPS-RFC-010
Certification
CONFORMANCE PROFILES
QEPS defines six conformance profiles targeting specific regulatory and operational contexts. Each profile specifies which of the 47 test vectors are required. All required tests must pass at 100%.
Profile
Tests Required
Context
FULL
All 47
Complete stack certification — no exemptions
LEVEL_C
44
Critical infrastructure — power, water, transport
EU_eIDAS
38
European digital identity regulation (eIDAS 2.0)
ICAO_BORDER
35
International border control and biometric identity
FIPS_140_3
32
US federal cryptographic module requirements
HIPAA_BAA
30
Healthcare AI with PHI handling
Profile selection is permanent per deployment. A node certified under HIPAA_BAA cannot be used in a LEVEL_C deployment without re-running the full applicable test suite and producing a new sealed report.
Certification
TEST VECTORS
Every QEPS test case has a corresponding test vector — a fully specified, deterministic input/output pair that any implementation must reproduce exactly. Test vectors are the executable form of the QEPS specification.
Running the Test Suite
The QEPS test runner is included in the Verity SDK. Test vectors are versioned alongside the QEPS specification — a test run always records which version of QEPS it was executed against.
verity qeps run --profile FULL --output report.sealed.json
The --output flag produces a cryptographically sealed report. Omit it for a local development run without sealing.
Vector Stability
Test vectors for released QEPS versions are immutable. A change to a test vector constitutes a new QEPS version. This ensures that a certification report referencing QEPS v1.0.0 vectors means exactly the same thing regardless of when it was produced.
Certification
RFC SPECIFICATIONS
The QEPS RFC series provides the normative prose specifications underlying the test vectors. They are written to RFC standards — unambiguous, implementable, and versioned.
RFC
Title
Status
QEPS-RFC-001
PCN Key Generation and Node Descriptor Format
Final
QEPS-RFC-002
PCN Offline Authentication Protocol
Final
QEPS-RFC-003
CCSL Policy Language Specification
Final
QEPS-RFC-004
SAF v2 Multi-Signature Attestation Format
Final
QEPS-RFC-005
CCR Deterministic Execution Model
Final
QEPS-RFC-006
CCR Compartment Isolation Requirements
Final
QEPS-RFC-007
Quiet Eye Audit Trail Format and Integrity
Final
QEPS-RFC-008
NEMEK BFT Consensus Protocol
Final
QEPS-RFC-009
Node Admission and Federation Governance
Final
QEPS-RFC-010
Sealed Certification Report Format
Final
Deployment
EDGE DEPLOYMENT
The Quiet Eye stack is built for environments without reliable connectivity. All core operations — identity, governance enforcement, execution, and audit — function without network access. The network is used for consensus when available, not as a dependency.
Offline Operation
A Verity node in offline mode operates with full governance enforcement. PCN authenticates locally. CCSL policies are enforced from the local policy store. CCR executes deterministically. Quiet Eye logs to the local audit trail. Operations are queued for NEMEK consensus when connectivity is restored.
Designed for: border control at remote crossings, clinical AI in facilities with intermittent connectivity, critical infrastructure in air-gapped environments, and autonomous systems operating in contested network conditions.
Sync on Reconnect
When a node reconnects to the NEMEK federation, it synchronizes its local state with the network. Queued operations are submitted for BFT consensus. The node's local audit trail is merged into the federated audit record. Conflicts are resolved by the consensus protocol — local operations are never silently dropped.
Deployment
FEDERATION SETUP
Joining the NEMEK federation requires a valid QEPS certification and an admission request signed by your PCN. Federation is permissioned — the network maintains its trust properties by only admitting certified nodes.
Admission Process
The node admission process has three steps: certification (your node must pass the applicable QEPS profile), admission request (a signed request sent to the federation including your node descriptor and certification report), and verifier consensus (5 of 7 active verifier nodes must approve the admission).
Admission typically completes within 2–3 consensus rounds (~30 seconds).
Verifier Nodes
The NEMEK verifier set is the 7-node group responsible for global governance consensus. Verifier nodes must hold FULL QEPS certification and maintain sub-second local finality. Verifier set membership is itself governed by NEMEK consensus — no single party controls the verifier set.
Deployment
REGULATORY PROFILES
Verity's conformance profiles map directly to regulatory frameworks. Each profile specifies exactly which QEPS tests are required and what configuration constraints apply. Deploying under a regulatory profile produces a sealed report referencing the specific regulatory standard.
Profile Selection
Choose the profile matching your primary regulatory obligation. If your deployment spans multiple frameworks — for example, a healthcare system at a border — select the profile with the higher test count, or run FULL to satisfy all frameworks simultaneously.
Regulatory profiles are advisory mappings, not legal opinions. Verify the applicable regulatory requirements for your jurisdiction and deployment context with qualified legal counsel.
Security Pilots
START
WITH PROOF.
We work directly with security and infrastructure teams to run structured pilots against your specific threat model and compliance requirements. No sales cycle. No generalized demos. Just the stack, your environment, and a proof at the end.
Run the full QEPS test suite against your environment. Walk away with a sealed, independently verifiable certification report — not a vendor's word.
⚖
Regulatory Alignment
We scope every pilot to your conformance profile — HIPAA_BAA, FIPS_140_3, ICAO_BORDER, EU_eIDAS, LEVEL_C, or FULL. Bring your compliance requirements; we bring proof they're met.
🏗
Edge Deployments
The Quiet Eye stack is built for environments without reliable connectivity. If your infrastructure operates at the edge, offline, or under adversarial network conditions — that's exactly what we designed for.
Not ready for a pilot?
Read the full technical whitepaper or explore the stack documentation first.
