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 unauthorised 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.

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.

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.

Interpretation cases: Conforming records bounded architecture evidence; Prohibited treats a system root as authority; Boundary labels a design assumption; Failure contains and records impact; Loophole hides dependency; Misuse expands access; Care-control protects people, privacy, and recoverability.