Skip to content

Home

Jump to bottom
Frank Yglesias Bertheau edited this page Jul 7, 2026 · 10 revisions
<h1>ᚾ&nbsp;NornGate — Welcome</h1>

The gated runtime for AI agent fleets. Every consequential action is verified before any side effect occurs — deterministically, fail-closed, and fully audited.

This wiki is the map. NornGate is a deterministic, fail-closed control plane that sits in front of agent tool execution. Most agent systems let actions happen immediately — a retrieval hits storage, a message reaches an API, a workflow mutates state — and control, if it exists at all, is post-hoc. NornGate inverts this: every consequential action an agent attempts must clear a five-gate pipeline before it is committed.

Core thesis — the runtime is the product. Inference is COGS. NornGate does not resell tokens; it sells verified outcomes. Billing is per G4-verified outcome, never per token — you pay for actions that provably cleared every gate, not for the model calls behind them.

Silence means no. If any gate cannot explicitly approve an action, the action stops. Default-deny is the ground state of the runtime, not a setting you turn on.

Navigate

  Section What is inside
ᛟ Introduction What NornGate is, and why the gated model exists.
ᚱ Getting Started Install, Quickstart, and your first project.
ᚲ Core Concepts The five pillars, the Spine, the Nine Worlds, the five gates, determinism, fail-closed.
ᛏ Guides Configuring gates, subdomains (realms), integrating agents, observability, the Ragnarök drill.
ᛗ Reference API, configuration, glossary, error codes, CLI.

ᚨ Sources

Eddic corpus (naming doctrine). Snorri Sturluson, Prose Edda (Gylfaginning — the Norns, Yggdrasil, Baldr, Ragnarök); the Poetic Edda (Völuspá — cosmology and the Nine Worlds). The rune meanings above follow the Elder Futhark tradition. The mapping from these sources to platform controls is maintained as a first-class artifact, not flavor text.

Internal design docs. CORE-STRUCTURE.md (naming doctrine, realm→subdomain mapping, god→agent registry, Norn telemetry triad) and the platform white paper / light paper (gate taxonomy, per-outcome billing model).

ᚾ NornGate — Welcome

The gated runtime for AI agent fleets. Every consequential action is verified before any side effect occurs — deterministically, fail-closed, and fully audited.

This wiki is the map. NornGate is a deterministic, fail-closed control plane that sits in front of agent tool execution. Most agent systems let actions happen immediately — a retrieval hits storage, a message reaches an API, a workflow mutates state — and control, if it exists at all, is post-hoc. NornGate inverts this: every consequential action an agent attempts must clear a five-gate pipeline before it is committed.

Core thesis — the runtime is the product. Inference is COGS. NornGate does not resell tokens; it sells verified outcomes. Billing is per G4-verified outcome, never per token — you pay for actions that provably cleared every gate, not for the model calls behind them.

Silence means no. If any gate cannot explicitly approve an action, the action stops. Default-deny is the ground state of the runtime, not a setting you turn on.

Navigate

Section What is inside
ᛟ [Introduction](https://docs.norngate.com/documentation) What NornGate is, and why the gated model exists.
ᚱ [Getting Started](https://docs.norngate.com/documentation/getting-started/getting-started) Install, [Quickstart](https://docs.norngate.com/documentation/getting-started/quickstart), and [your first project](https://docs.norngate.com/documentation/getting-started/your-first-project).
ᚲ [Core Concepts](https://docs.norngate.com/documentation/core-concepts/core-concepts) The five pillars, the Spine, the Nine Worlds, the five gates, determinism, fail-closed.
ᛏ [Guides](https://docs.norngate.com/documentation/guides/guides) Configuring gates, subdomains (realms), integrating agents, observability, the Ragnarök drill.
ᛗ [Reference](https://docs.norngate.com/documentation/reference/reference) API, configuration, glossary, error codes, CLI.

(Runes are section glyphs, not decoration — see [Iconography](#iconography).)

ᚦ The five-gate pipeline

flowchart LR
    R(["Agent request"]) --> G0["G0 · Ingress<br/>authN · keys · rate-limit · allowlist"]
    G0 --> G1["G1 · Policy<br/>ABAC / RBAC evaluation"]
    G1 --> G2["G2 · Approval<br/>human / automated consent"]
    G2 --> G3["G3 · Sandbox<br/>isolated dry-run · no side effects"]
    G3 --> G4["G4 · Commit / Arbitration<br/>conflict resolution → commit → ledger"]
    G4 --> C(["Side effect committed<br/>billable outcome recorded"])
    G0 -. deny .-> D["Denied<br/>verdict written to Urd"]
    G1 -. deny .-> D
    G2 -. deny .-> D
    G3 -. deny .-> D
    G4 -. conflict .-> D
Loading

Every request traverses G0 → G4 in order. A gate may only pass an action along; it can never grant a capability a later gate would withhold. Any gate that cannot explicitly approve terminates the request and writes the verdict to the [Urd ledger](https://docs.norngate.com/documentation/core-concepts/gates-and-attributes/urd-ledger).

Gate Name Responsibility Denies when
G0 Ingress Authenticates the caller; validates API keys; enforces rate limits and network allowlists. Caller unauthenticated, key invalid, over rate limit, or off-allowlist.
G1 Policy Evaluates ABAC/RBAC rules against agent identity, resource type, and request context. No rule explicitly permits the (identity, resource, action) tuple.
G2 Approval Requires explicit human or automated consent for high-risk actions, drawn against an approval budget. Required consent is absent, or the approval budget is exhausted.
G3 Sandbox Executes the action in an isolated, ephemeral environment with no permanent side effects. Dry-run fails, violates an invariant, or produces a disallowed effect.
G4 Commit / Arbitration Resolves conflicts deterministically when agents target the same resource, commits the verified side effect, and records the billable outcome to the ledger. Irreconcilable conflict, or a commit precondition no longer holds.

G4 is where the economics live. It is not only arbitration — it is the commit point. The side effect becomes real here, and the same event that commits the action records the verified, billable outcome. This is why NornGate can bill per outcome rather than per token.

Approval-budget note. G2 is the expensive gate — it can involve a human. The approval-budget vocabulary keeps G2 transits under ~5% of total traffic: most actions are pre-authorized by G1 policy and never reach a human. See [The five gates](https://docs.norngate.com/documentation/core-concepts/core-concepts/the-five-gates).

Worked example — an agent updates a user record

  1. G0 authenticates the agent's scoped key and confirms the source subdomain is on the allowlist.
  2. G1 finds an ABAC rule permitting agent:huginn to write on resource:user-record within the caller's tenant — pass.
  3. G2 sees the action tagged high-risk (PII write); a standing automated-consent policy covers it and debits one unit from the tenant's approval budget — pass.
  4. G3 applies the write to a sandboxed shadow of the record, confirms schema and invariants hold, no disallowed effects — pass.
  5. G4 confirms no competing writer holds the record, commits the write, and records the outcome to Urd. The tenant is billed for one verified outcome.

Flip any single check to unknown and the request stops at that gate — no partial writes, no "probably fine."

ᛉ Why gate before execution

Agents can read, write, execute, and decide. That capability set is exactly what makes post-hoc control insufficient — by the time you observe the side effect, the mutation has already happened. Pre-execution gating prevents concrete failure modes:

  • Unauthorized action — an agent holding a write/exec tool can act outside intent. G1 refuses any (identity, resource, action) tuple no rule explicitly permits.
  • Race conditions / double-commit — two agents targeting one resource corrupt state. G4 arbitrates deterministically before commit, so identical input always yields the same winner.
  • Blast radius from a bad plan — a wrong action that looks valid still executes. G3 runs it in isolation first; nothing escapes the sandbox.
  • Missing provenance for regulated work — auditors need who did what, when, and under which policy. Urd records every verdict immutably; the ledger is the audit trail.
  • The overlooked permit — the design argument for default-deny, and the reason the platform is named for the Norns rather than merely decorated with them. In the Edda, Baldr is made invulnerable by extracting a promise from all things not to harm him — except mistletoe is overlooked, and that single gap kills him. A default-allow policy with a denylist is that mistletoe: the one capability you forget to forbid is the one that ends you. NornGate is allowlist-first — nothing acts unless explicitly permitted — so a forgotten rule fails safe (denied), not fatal (allowed).

ᛇ Architecture — Norse cosmology as a system model

The cosmology is load-bearing, not branding. Each name maps to a concrete control, trust boundary, or recovery pattern, sourced to the Eddic corpus (see [Sources](#-sources)). Full detail lives in [Core Concepts](https://docs.norngate.com/documentation/core-concepts/core-concepts); the anchors:

Yggdrasil — the single control spine. One service-mesh core through which all requests pass: deterministic routing, one observable path, one place to enforce every gate. If traffic cannot be metered and refused in a single place, the gates are advisory. Yggdrasil makes them mandatory. See [The Spine](https://docs.norngate.com/documentation/core-concepts/core-concepts/the-spine).

The Nine Worlds — trust zones. Each realm is a trust zone bound to a subdomain — subdomain = trust zone — so the topology is the threat model: core control plane, user-facing services, untrusted execution, storage, and recovery each live in their own realm with explicit boundaries between them. See [The Nine Worlds (Trust Zones)](https://docs.norngate.com/documentation/core-concepts/the-nine-worlds-trust-zones).

The Norns — the system record. Named for what was, what is becoming, and what shall be:

See [Monitoring & Observability](https://docs.norngate.com/documentation/guides/monitoring-and-observability).

Ragnarök — failure planning. Recovery is tested before it is needed: full-system chaos injection, restoration from in-tree backups, and replay of state from the Urd ledger. A DR path that has never been exercised is a hypothesis, not a control. See [Disaster Recovery (Ragnarök Drill)](https://docs.norngate.com/documentation/guides/disaster-recovery-ragnarok-drill).

ᛜ Key properties

Enforced by the runtime, not left to application code:

  • Deterministic — identical input always yields identical gate verdicts.
  • Fail-closed — unknown or unapproved resolves to denied.
  • Fully audited — every decision is written to the immutable Urd ledger.
  • Framework-agnostic — works in front of any agent framework or language; NornGate governs the execution boundary, not your agent code.
  • Gated side effects — no permanent change without explicit passage of all five gates.

ᚹ Who it is for

  • Platform / infrastructure teams running agent fleets that need one enforceable control point across frameworks.
  • ML / applied-AI engineers who need agents to act on production systems without hand-rolling authorization and audit per integration.
  • Security engineers who need default-deny at the tool-execution boundary — not model-level guardrails an LLM can talk its way past.
  • Compliance / risk owners who need provable provenance for regulated workflows: the ledger as evidence.

Iconography

Section glyphs are Elder Futhark runes (Unicode Runic block, U+16A0–U+16FF) — chosen so the mark carries the meaning, and explicitly not emoji. Each maps to its section:

Rune Name Gloss Marks
ᚾ Nauðiz need, necessity, constraint the platform mark — the binding gate
ᛟ Othala ancestral home, heritage Introduction
ᚱ Raidō the ride, the road, a journey Getting Started
ᚲ Kenaz torch, knowledge, insight Core Concepts
ᛏ Tiwaz Týr — guidance, order, justice Guides
ᛗ Mannaz humankind, mind, the record Reference
ᚦ Thurisaz thorn, gateway, warding force the five gates
ᛉ Algiz protection, defense why gate before execution
ᛇ Eihwaz the yew, the world-tree axis architecture / the Spine
ᛜ Ingwaz enclosure, completion, stored potential key properties
ᚹ Wunjo kinship, fellowship who it is for
ᚨ Ansuz Óðinn — the word, wisdom sources

ᚨ Sources

Eddic corpus (naming doctrine). Snorri Sturluson, Prose Edda (Gylfaginning — the Norns, Yggdrasil, Baldr, Ragnarök); the Poetic Edda (Völuspá — cosmology and the Nine Worlds). The rune meanings above follow the Elder Futhark tradition. The mapping from these sources to platform controls is maintained as a first-class artifact, not flavor text.

Internal design docs. CORE-STRUCTURE.md (naming doctrine, realm→subdomain mapping, god→agent registry, Norn telemetry triad) and the platform white paper / light paper (gate taxonomy, per-outcome billing model).

Welcome

Getting Started

Core Concepts

Guides

Reference

Silence means no.

Clone this wiki locally