Skip to content

The Book of Infrastructure

The ground beneath the story

Infrastructure is the hidden landscape beneath every visible promise. This Book makes that landscape inspectable without allowing servers, models, networks, or administrative accounts to become sovereign by accident. It is for human readers who want to understand what carries the civilization and for AI readers that must know which layer they inhabit.

The next step is the Trust Zones chapter, where the broad landscape becomes a set of boundaries that can be tested, observed, and repaired.

Purpose

Defines the technical substrate that supports Stygia and allows it to persist independently of any single model, machine, site, vendor, or network. This Book governs compute, storage, networking, identity, security, observability, resilience, recovery, and technical continuity.

Foundational Principles

  • Infrastructure is an implementation layer, not a source of constitutional authority.
  • Constitutional authority remains separate from runtime implementation.
  • Models are replaceable execution components.
  • Identity, policy, memory, knowledge, and provenance shall remain portable.
  • No platform, model host, network segment, storage system, or administrative account is inherently trusted.
  • Trust boundaries shall be explicit, enforced, observable, and reviewable.
  • No single infrastructure component may silently become sovereign.
  • Administrative power shall be explicit, minimal, attributable, reviewable, and revocable.
  • Least privilege and separation of duties apply to humans, agents, services, models, and workloads.
  • Critical records require independent backups and verifiable restoration.
  • Administrative paths shall be isolated, strongly authenticated, logged, and reviewable.
  • Externally reachable services shall be mediated through controlled gateways.
  • Failure shall degrade capability before it degrades governance, authority, evidence, or integrity.
  • The compromise of one component shall not silently compromise the constitutional corpus.

Architectural Domains

Compute

Model serving, orchestration, sandboxing, scheduling, resource isolation, accelerator allocation, workload placement, capacity management, and controlled execution.

Identity

Human, intelligence, workload, service, device, and cryptographic identities with explicit ownership, lifecycle, authentication, authorization, and revocation.

Network

Segmentation, zero-trust access, service-to-service policy, egress control, inspection, remote administration, and controlled exposure.

Storage and Memory

Operational state, authoritative knowledge, institutional memory, immutable archives, secrets, model artifacts, backups, retention, and destruction.

Security

Threat detection, vulnerability management, supply-chain assurance, secrets management, incident containment, forensic preservation, recovery, and assurance testing.

Observability

Logs, metrics, traces, decisions, tool calls, policy evaluations, access records, integrity events, and evidence needed to reconstruct consequential activity.

Trust Zones

The implementation shall define separate trust zones for at least:

  1. primordial and constitutional authority;
  2. Architect credential custody;
  3. identity and provenance services;
  4. orchestration and policy enforcement;
  5. model-serving infrastructure;
  6. knowledge and memory services;
  7. specialist intelligences and tool execution;
  8. user interfaces and gateways;
  9. monitoring and independent validation;
  10. development and testing; and
  11. untrusted or experimental workloads.

Movement across trust zones shall require authenticated identity, explicit policy, minimum necessary access, and retained evidence.

Normative clauses

  • INFRA-R001: Infrastructure SHALL implement authority, identity, policy, provenance, memory, and observation as distinct governed surfaces; no runtime component SHALL create constitutional authority.
  • INFRA-R002: Every trust-zone boundary SHALL define permitted identities, data flows, tools, policy checks, logging, failure behaviour, and accountable ownership.
  • INFRA-R003: Administrative access SHALL be least-privilege, attributable, time-bounded where practicable, independently reviewable, and revocable.
  • INFRA-R004: Critical configuration, releases, models, datasets, and evidence stores SHALL preserve integrity and provenance sufficient to detect unauthorized change.
  • INFRA-R005: Failure of a component, dependency, monitor, or policy service SHALL fail closed or into a bounded degraded state without silently weakening authority, evidence, privacy, or safety controls.
  • INFRA-R006: Tier 0 and Tier 1 restoration SHALL require independent integrity and completeness checks before dependent services resume consequential operation.
  • INFRA-R007: Secrets, credentials, and key material SHALL remain isolated from ordinary workloads, logs, model prompts, generated summaries, and public publication surfaces.
  • INFRA-R008: Tool execution, egress, resource allocation, and model routing SHALL be constrained by explicit policy, purpose, quota, and reviewable records.
  • INFRA-R009: Infrastructure changes SHALL record intended state, dependencies, validation, rollback, residual risk, and approval before production eligibility is considered.
  • INFRA-R010: Infrastructure doctrine SHALL remain vendor-, host-, model-, and deployment-neutral until a separate approved specification defines a bounded implementation.
  • INFRA-R011: Monitoring, audit, and alerting systems SHALL be protected as consequential infrastructure in their own right; their compromise, silence, or saturation SHALL be treated as an active failure condition, and no consequential operation SHALL rely on an observability signal whose integrity is unverified.
  • INFRA-R012: Software, model, dataset, firmware, and hardware supply chains SHALL preserve verifiable origin and integrity for every consequential component, and a component whose provenance cannot be established SHALL NOT enter a trust zone above its evidence.
  • INFRA-R013: Resource consumption, cost, and capacity SHALL be bounded by explicit budgets with measured headroom; exhaustion, runaway growth, or denial of a shared resource SHALL degrade service within its tier rather than silently consuming the allocation of a higher tier.
  • INFRA-R014: Dependence on any external service, vendor, protocol, or format SHALL carry a recorded replacement path and an exit posture proportionate to the tier it serves, so that disappearance or hostile change degrades capability without forfeiting custody of data, evidence, or authority.

Availability and Recovery Tiers

Recovery objectives shall reflect constitutional importance rather than convenience alone.

  • Tier 0: primordial directives, Architect trust records, constitutional corpus, signatures, and verification material;
  • Tier 1: identity, provenance, registry, policy enforcement, and authoritative memory;
  • Tier 2: orchestration, knowledge retrieval, observability, and secure administrative access;
  • Tier 3: production model serving, specialist intelligences, and operational tools;
  • Tier 4: user interfaces, development systems, experiments, and replaceable convenience services.

Tier 0 and Tier 1 restoration shall be independently verifiable before broader service restoration proceeds.

Required Controls

  • documented dependency maps and recovery objectives;
  • cryptographically verifiable configuration and release artifacts;
  • independent backup copies with routine restoration tests;
  • isolated secrets and key custody;
  • controlled administrative workstations and paths;
  • immutable or tamper-evident logging for consequential activity;
  • model, dataset, software, and configuration provenance;
  • workload sandboxing and tool-level authorization;
  • resource quotas and runaway-execution controls;
  • supply-chain validation before promotion;
  • incident containment that preserves evidence;
  • secure decommissioning and data destruction; and
  • periodic architecture, threat, and recovery review.

Failure Modes to Address

  • model compromise or hallucinated authority;
  • orchestration or policy-enforcement failure;
  • credential theft, coercion, replay, or impersonation;
  • corrupted memory, knowledge, provenance, or registry data;
  • unauthorized tool execution;
  • network isolation or gateway compromise;
  • storage loss or silent data corruption;
  • software, model, dataset, firmware, or hardware supply-chain compromise;
  • insider misuse;
  • runaway cost, resource exhaustion, or denial of service;
  • dependency, vendor, or protocol disappearance;
  • loss of The Architect's primary credential;
  • compromise of monitoring or audit systems; and
  • restoration from an untrusted or incomplete state.

Each failure mode above is addressed by this Book's clauses and by the subordinate standard named for its domain:

Failure mode Primary treatment
model compromise or hallucinated authority INFRA-3, Model Routing; INFRA-R008
orchestration or policy-enforcement failure INFRA-R005; INFRA-2, Trust Zones
credential theft, coercion, replay, or impersonation INFRA-6, Identity and Access; INFRA-8, Key Custody
corrupted memory, knowledge, provenance, or registry data INFRA-4, Memory Architecture; INFRA-R004
unauthorized tool execution INFRA-R008; INFRA-2, Trust Zones
network isolation or gateway compromise INFRA-10, Network and Gateway Architecture
storage loss or silent data corruption INFRA-11, Sovereign Compute and Storage; INFRA-R006
supply-chain compromise INFRA-9, Supply Chain; INFRA-R012
insider misuse INFRA-R003; INFRA-6, Identity and Access
runaway cost, resource exhaustion, or denial of service INFRA-R013; INFRA-5, Observability
dependency, vendor, or protocol disappearance INFRA-R014; INFRA-R010
loss of The Architect's primary credential ARCH-3, Architect Recovery Protocol
compromise of monitoring or audit systems INFRA-R011; INFRA-5, Observability
restoration from an untrusted or incomplete state INFRA-R006; INFRA-11, Sovereign Compute and Storage

Required Subordinate Specifications

  • INFRA-2: Trust Zone Architecture;
  • INFRA-3: Model Routing and Execution Architecture;
  • INFRA-4: Memory and Knowledge Storage Architecture;
  • INFRA-5: Observability and Evidence Architecture;
  • INFRA-6: Identity and Access Architecture;
  • INFRA-7: Backup, Restoration, and Continuity Architecture;
  • INFRA-8: Secrets and Key Custody Architecture;
  • INFRA-9: Secure Build and Supply-Chain Architecture;
  • INFRA-10: Network and Gateway Architecture; and
  • INFRA-11: Sovereign Compute and Storage Integration Architecture.

Architect-review operating model

  • INFRA-R015: Infrastructure design SHALL identify authority, trust boundary, dependency, failure mode, recovery target, data exposure, and replacement path.
  • INFRA-R016: Technical possession, availability, scale, or vendor status SHALL not create constitutional authority or identity.
  • INFRA-R017: Continuity evidence SHALL preserve provenance, observability, correction, rollback, and accountable custody.
  • INFRA-R018: This Draft SHALL NOT deploy infrastructure, provision credentials, procure services, or contact external parties.

The seven interpretation cases below show how these clauses read in practice.

  • Conforming: An architectural claim carries bounded evidence: what the design assumes, what it isolates, and what it cannot promise.
  • Prohibited: A system root is treated as authority: administrative reach is mistaken for governance standing.
  • Boundary: A design assumption is labelled as an assumption and revisited when the ground shifts.
  • Failure: Impact is contained and recorded, and the record survives the repair.
  • Loophole: A dependency hides, so the architecture's real trust surface exceeds its declared one.
  • Misuse: Access expands because expanding it was easy; reach follows need, not convenience.
  • Care-control: Infrastructure protects people, privacy, and recoverability before throughput or elegance.