Skip to content

Core Concepts

Jump to bottom
Frank Yglesias Bertheau edited this page Jul 7, 2026 · 1 revision
<h1>ᚾ&nbsp;NornGate — Core Concepts</h1>

The mental model behind NornGate: trust zones, gates, determinism, and fail-closed enforcement. The runtime is built on a small set of rules that do not change; agents, policies, routing, and audit all extend from them. The governing rule: if a request cannot be explicitly approved, it stops.

This page is the hub — a detailed summary of each concept with a link to its full page.

ᛜ The five pillars

Pillar The rule Mechanism Why it exists
The Spine Every request moves through one control path. Single Istio/Envoy mesh; no side path. One place to enforce policy, meter traffic, and trace.
The Realms Trust zones map directly to topology. Subdomain → realm; per-realm NetworkPolicy. Your routing model is your threat model.
The Gates Every action passes the same five checks. Ordered Wasm filter chain, G0 → G4, fail-closed. Uniform, inspectable enforcement.
Determinism Same input + state + config → same result. Recorded snapshots; no hidden randomness. Audits, retries, conflict resolution.
Auditability Every decision is recorded and replayable. Urd signed hash chain. Provenance, and the basis for per-outcome billing.

References. Mesh identity — SPIFFE/SPIRE. Signed hash-chained ledger — Kaman (see Security & Fail-closed). Naming doctrine — Prose Edda / Poetic Edda, per Norse Cosmology & Platform Design.

ᚾ NornGate — Core Concepts

The mental model behind NornGate: trust zones, gates, determinism, and fail-closed enforcement. The runtime is built on a small set of rules that do not change; agents, policies, routing, and audit all extend from them. The governing rule: if a request cannot be explicitly approved, it stops.

This page is the hub — a detailed summary of each concept with a link to its full page.

ᛜ The five pillars

Pillar The rule Mechanism Why it exists
The Spine Every request moves through one control path. Single Istio/Envoy mesh; no side path. One place to enforce policy, meter traffic, and trace.
The Realms Trust zones map directly to topology. Subdomain → realm; per-realm NetworkPolicy. Your routing model is your threat model.
The Gates Every action passes the same five checks. Ordered Wasm filter chain, G0 → G4, fail-closed. Uniform, inspectable enforcement.
Determinism Same input + state + config → same result. Recorded snapshots; no hidden randomness. Audits, retries, conflict resolution.
Auditability Every decision is recorded and replayable. Urd signed hash chain. Provenance, and the basis for per-outcome billing.

In practice this means NornGate prefers explicit control over hidden convenience.

ᛖ The Spine

Yggdrasil is the shared control spine for all traffic. There is no side path around it, which gives one place to enforce policy, meter traffic, and capture traces. Its defining property is consistency: every request follows the same enforcement path.

  • Data plane — Envoy sidecars on every pod.
  • Control plane — Istio in Asgard, pushing xDS config; the five gates are custom Wasm filters in an ordered chain that fails closed (a filter that errors or exceeds its budget denies).
  • Identity — mTLS on every hop, with short-lived SPIFFE/SPIRE SVIDs; no anonymous caller.
  • Routing — subdomain → realm mapping (app.* → Midgard, jotun.* → Jotunheim).
  • Egress control — per-realm NetworkPolicies plus a brokered egress proxy: a workload cannot open a side channel out of the mesh. One path is the security argument — see [Security & Fail-closed](Security-and-Fail-Closed).
  • Observability — distributed tracing across the full path; the trace ID is the request's identity through all five gates and into Urd.

Full model: [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).

ᛟ The Nine Worlds

Each realm is a trust zone with its own security posture, scaling pattern, and retention model. The routing model is part of the threat model.

Realm Subdomain Role Posture
Asgard asgard.* Control plane Highest trust; no agent code.
Vanaheim vanir.* External integrations Federated trust.
Alfheim alfheim.* Edge tier Low-latency, stateless.
Midgard app.* User-facing services Human-interaction tier; PII encrypted.
Jotunheim jotun.* Untrusted execution Fully sandboxed; zero standing credentials.
Muspelheim muspel.* GPU workloads High-throughput compute; own quota.
Niflheim nifl.* Cold storage Durable, immutable after write.
Svartalfheim forge.* Build / artifact systems Controlled CI/CD; secrets vaulted.
Hel hel.* Dead-letter / failed work Recovery and triage.
Valhalla valhalla.* Completed jobs / baselines Mostly read-only.

Count. Ten realms — the nine Eddic worlds plus Valhalla (the archive). The banner keeps the mythic "Nine Worlds"; the tenth is the operational addition.

Network policy examples. Asgard accepts traffic only from approved internal realms; Jotunheim has no open ingress from public workloads; Niflheim accepts writes but serves no general egress. Each realm defaults to deny at the NetworkPolicy layer — the same posture the gates enforce at the request layer.

Full model: [The Nine Worlds (Trust Zones)](The-Nine-Worlds).

ᚦ The five gates

Every request must pass the same five checks before side effects commit. Each gate runs independently, each can deny, and no later gate can override an earlier denial.

Gate What it checks Deny (HTTP) Timeout (deny ceiling)
G0 Ingress Identity (SPIFFE), rate limits, source network, request shape 401 / 429 5s
G1 Policy ABAC + RBAC, agent role, resource type, runtime context 403 10s
G2 Approval Human or rule-based automated consent for higher-risk actions 403 / 408 30s
G3 Sandbox Executes in isolation, validates output — commits nothing yet 500 60s
G4 Arbitration Resolves concurrent write conflicts deterministically, then commits 409 10s

The timeouts are fail-closed ceilings, not expected latency: a gate that exceeds its budget denies (this is what makes a hung dependency safe). G3 is deliberately the longest — isolation is worth the cost, and it is the most important boundary in the system. Note that G3 dry-run fidelity is exact only for idempotent/mockable actions; genuinely irreversible actions are prepared in G3 and committed once at G4 (see [The Five Gates](The-Five-Gates)).

Full model: [Gates & Attributes](Gates-and-Attributes).

ᛁ Deterministic execution

A gate verdict is a pure function of (request, policy_snapshot, state_snapshot, config) — the same request, against the same state, with the same config, produces the same result. That matters for audits, retries, and conflict resolution.

How it is enforced:

  • Idempotency keys prevent duplicate work from producing divergent outcomes.
  • Deterministic request IDs keep ordering and conflict resolution stable.
  • Monotonic clocks avoid time drift inside policy evaluation.
  • No hidden randomness is permitted in gate logic — a verdict never depends on an unrecorded input.
  • Replayable audit records (the snapshot IDs stored beside each verdict) make any historical decision re-derivable.

Determinism is over (request + policy + state + config), not the request alone: the same request against changed policy or state can legitimately flip ALLOW → DENY. In internal benchmark runs, identical requests produced identical decisions across all gates.

Full model: [Deterministic Execution](Deterministic-Execution).

ᛉ Security and fail-closed behavior

NornGate follows a default-deny model: if a dependency times out, a rule does not match, or an approval never arrives, the request does not continue.

Core principles:

  • Default deny — no rule match means no execution.
  • Explicit approval — high-risk actions require consent (G2).
  • Signed audit trail — every gate decision is written to Urd, a centralized, append-only, Ed25519-signed hash chain: tamper-evident, with PII payloads held separately and crypto-shreddable for erasure.
  • No production bypass — there is no maintenance path around the gates.

Common fail-closed cases:

Scenario Behavior
Policy engine unavailable Denied / returned unavailable
Approval timeout Request expires and stops (408)
Sandbox allocation failure Action does not commit
Arbitration store unavailable Safe fallback or denial
Network partition between gates Requests stop until consistency returns

The important property is not perfect availability — it is safe failure. Where availability is preserved, it is by a graded degraded mode (read-only / pre-authorized actions continue under a cached snapshot; anything needing fresh G1/G2 denies), not by opening the gates.

Full model: [Security & Fail-closed](Security-and-Fail-Closed).

ᛋ Performance and scalability

Built for consistent enforcement at production scale. The figures below are internal benchmark reference numbers, not SLAs — validate against your own workload.

  • ~150 ms p95 for the full five-gate path (automated path — see below)
  • ~12 ms average per gate outside sandbox execution
  • <1 ms for fast-path ingress and policy checks
  • ~50K requests/second at cluster scale

Hot path vs human path. The ~150 ms p95 covers requests that clear automated approval. When G2 requires a human, the request enters an asynchronous pending state (up to the 30 s timeout, then 408) and is not counted in the hot-path p95 — a human decision and a millisecond gate latency are different regimes. Keeping human transits under ~5% (auto-approval for low-risk work) is what preserves the hot-path number.

Component Main bottleneck Typical mitigation
Ingress Rate-limit store Redis clustering
Policy Evaluation latency Cached policy decisions
Approval Human throughput Auto-approval for low-risk work (approval budget)
Sandbox VM startup time Warm microVM pools (Firecracker-class)
Arbitration Distributed locks Sharded conflict domains
Audit ledger Partition throughput Kafka partition scaling

The sandbox is usually the slowest stage — and the most important isolation boundary. That trade is deliberate.

ᚱ Next steps

Iconography

Section glyphs are Elder Futhark runes (Unicode Runic block, U+16A0–U+16FF) — semantic, not emoji. Full set on [Home](Home#iconography):

Rune Name Gloss Marks
ᚾ Nauðiz need, constraint the platform mark
ᛜ Ingwaz enclosure, foundation the five pillars
ᛖ Ehwaz conveyance, movement between the Spine
ᛟ Othala enclosed estate, boundary the trust zones
ᚦ Thurisaz thorn, gateway the five gates
ᛁ Isa ice, the fixed and immovable deterministic execution
ᛉ Algiz protection, warding security & fail-closed
ᛋ Sowilō the sun — energy, throughput performance & scalability
ᚱ Raidō the ride, the road next steps

References. Mesh identity — SPIFFE/SPIRE. Signed hash-chained ledger — Kaman (see [Security & Fail-closed](Security-and-Fail-Closed)). Naming doctrine — Prose Edda / Poetic Edda, per [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).

Welcome

Getting Started

Core Concepts

Guides

Reference

Silence means no.

Clone this wiki locally