System Containment
SafeSystem, SafeEcosystem, SafeSovereignty, and SafeCivilization define the scale across which AI behavior, authority, propagation, and consequence must remain contained.
Architecture overview
One architecture for bounded AI execution.
SafeWave separates what advanced AI can do from what it is authorized to cause. Thirty-five execution-control architectures define where containment must hold, how execution remains governed, and which control mechanisms enforce the required boundary. SafeSpace is a separate protected-environment architecture that coordinates the relevant controls across a bounded physical and operational environment.
The AI may propose an action, but SafeWave does not automatically grant it the authority to carry it out. Independent controls remain between intelligence and consequential execution.
The public architecture comprises 36 named architectures supported by 36 U.S. AI patent applications and filings: 4 System Containment Layers, 5 Protocol Enforcement Layers, 26 Core Enforcement Substrates, and SafeSpace as a distinct protected-environment architecture. They describe the complete SafeWave architectural universe—not what every deployment requires. Most systems use only a risk-matched subset.
The architecture model
Three execution-control families—and a separate protected-environment architecture.
SafeWave separates the scope of containment, the rules governing execution, and the specific mechanisms that enforce those rules. SafeSpace is different: it applies and coordinates the relevant SafeWave controls across a bounded physical and operational environment.
Protocol Enforcement
Governs runtime behavior, escalation, replication, pathway selection, and participation or re-entry as conditions change.
Core Enforcement
Provides the specific mechanisms required to bound authority, scope, memory, compute, privacy, identity, robotics, finance, and other execution risks.
The governing invariant is minimum sufficient execution: permit only the authority, scope, resources, pathways, tools, persistence, and consequence necessary for the legitimate task.
The complete architecture
Thirty-five execution-control architectures, organized into three families.
The four System Containment Layers, five Protocol Enforcement Layers, and twenty-six Core Enforcement Substrates form the execution-control architecture. SafeSpace is shown separately below because it solves a different problem: coordinated protection of a bounded physical and operational environment.
4 layers System Containment Layers
Define the scale at which containment must remain effective.
SafeSystemContainment within an individual intelligent system.
SafeEcosystemContainment across interacting systems and distributed environments.
SafeSovereigntyInstitutional containment that preserves legitimate human authority as advanced AI crosses organizational boundaries.
SafeCivilizationLong-horizon stability across infrastructure, institutions, and civilization-scale systems.
5 protocols Protocol Enforcement Layers
Govern the lifecycle of execution as conditions, authority, scope, and system state change.
SafeRuntimeContinuing runtime governance, state control, interruption, and recovery.
SafeEscalationControl of capability, authority, resource, and consequence escalation.
SafeReplicationGovernance of copying, spawning, propagation, and replicated operation.
SafePathwaySelects among approved models, providers, tools, hosting environments, and execution paths under supplied constraints.
SafeAdmissionGoverns node participation and re-entry under instability using non-semantic operating conditions.
26 substrates Core Enforcement Substrates
Install the specific control mechanisms required by the system and its operating environment.
SafeBaseFoundational runtime behavioral enforcement.
SafeControlExecution-capability enforcement for permitted actions and bounded capability.
SafeGoalGoal stability and optimization-boundary enforcement.
SafeMemoryPersistent-state, context, and memory governance.
SafeAGICapability-aware enforcement as autonomy and leverage increase.
SafeAssumptionIdentifies, validates, continuously revalidates, and enforces the load-bearing assumptions upon which consequential reasoning, authorization, pathway selection, and execution depend.
SafeRestraintDeterministic damping, interruption, and behavioral restraint.
SafeAuthorityGoverns human–AI authority projection and relational posture across consequential interaction.
SafeRelationGovernance of relational dynamics and system-to-system interaction.
SafeScopeTask, data, tool, environment, and consequence scope boundaries.
SafeSocialStructural amplification and harmful escalation across multi-user and socially mediated systems.
SafeProvenanceIntegrity and lineage of propagating AI artifacts such as weights, checkpoints, and modifications.
SafeTelemetryDeterministic visibility into escalation dynamics, boundary transitions, intervention, and recovery.
SafePlusDistributed coordination and multi-system containment.
SafeProcessGovernance of intermediate reasoning processes, trajectory evolution, and consequential transitions.
SafeDeviceDeterministic non-escalatory behavior at the device boundary, with optional hardware anchoring.
SafeComputeBounded compute, retries, queues, contention, degradation, and recovery.
SafeStabilityNode-level bounded behavior during degraded, uncertain, and recovery conditions.
SafeCoreExecution-substrate stability and restraint governing proceed, dispatch, retry, replay, expansion, and safe-state behavior.
SafeChipSilicon anchoring for control-plane integrity and non-bypassable boundaries.
SafeRoboticsMotion, force, access, tools, physical proximity, and embodied-AI boundaries.
SafePrivacyBounded inference and controlled disclosure in AI-mediated human assessment systems.
SafeInfluenceBoundaries on persuasion, manipulation, behavioral shaping, and influence operations.
SafeFinanceFinancial authority, transactions, spending, exposure, and market-action controls.
SafeIdentitySynthetic and inferred identity, identity repositories, impersonation, and identity-linked action.
SafeCompanionSynthetic-intimacy boundaries for companion and human-relationship AI.
Separate protected-environment architecture
SafeSpace protects the environment as a whole.
SafeSpace is a separate architectural insight: some high-consequence environments cannot be protected by governing one AI system, device, network, or application at a time. The protected object is the bounded physical and operational environment itself.
Separate architecture
SafeSpace: protected-environment governance
SafeSpace does not replace, extend, or sit above the four System Containment Layers. It is a distinct architecture for protecting a bounded physical and operational environment by coordinating the relevant SafeWave controls with the environment's digital systems, physical systems, communications, evidence, operations, and legitimate human authority.
The distinction matters: SafeSystem, SafeEcosystem, SafeSovereignty, and SafeCivilization remain the four System Containment Layers. SafeSpace does not replace any of them. It coordinates the relevant SafeWave controls across a physical environment and the systems, people, communications, authority, and operations inside it.
Bounded public environments
Airports, stadiums, shopping centres, campuses, hospitals, major venues, and other environments where digital, physical, operational, and human systems interact continuously.
High-consequence installations
Military bases and installations, critical infrastructure sites, vessels and submarines, industrial facilities, and other environments where failures can propagate across multiple systems and domains.
Highly complex environments
Space systems and other remote or constrained environments where communication, intervention, recovery, physical safety, and authority may all have to remain coordinated under severe operating limits.
In each case, SafeSpace selects and coordinates the relevant SafeWave protections for that environment. The underlying System Containment, Protocol Enforcement, and Core Enforcement architectures retain their own roles and sovereignty.
Enforcement depth
Architectural role and enforcement depth are separate decisions.
The named architectures describe what must be controlled and how the controls coordinate. Deployment depth describes where a particular control must live to remain reliable and resistant to bypass.
Interpretation above. Deterministic enforcement at the lowest practical layer.
Context-sensitive decisions may remain in software. Selected boundaries move deeper only when the required assurance cannot be preserved at a shallower layer.
Applications and policyPurpose, context, task meaning, human decisions, organizational rules, and deployment-specific interpretation.
Runtime and orchestrationAdmission, pathway, state transitions, retries, queues, tools, resources, interruption, and recovery.
Firmware and controllersProtected local state, device capability envelopes, command gates, physical interruption, and trusted recovery.
Hardware roots and siliconTrust roots, counters, privilege gates, protected state, non-bypassable ceilings, and hardware-rooted evidence where independently justified.
Deeper is not automatically better. The engineering question is whether a shallower layer can still preserve the required boundary under failure, compromise, hostile modification, or advanced autonomous behavior.
Boundary clarification
SafeWave complements existing safeguards. It does not replace them.
Model safeguards, cybersecurity, identity management, permissions, observability, governance, containers, isolation, and virtualization all remain important. SafeWave addresses the additional question of what the system is structurally permitted to execute after capability and access exist.
Not a sandboxSandboxes isolate processes. SafeWave governs whether execution is admitted, what authority it receives, how it may expand, and how it remains bounded.
Not a model-alignment methodSafeWave does not depend on controlling internal reasoning. It constrains what intelligent systems are structurally permitted to execute.
Not monitoring aloneTelemetry is necessary, but evidence without enforcement cannot prevent unsafe authority, propagation, persistence, compute escalation, or physical action.
The architecture must ensure that ingenuity does not become permission—and that capability does not silently rewrite the boundary around authorized action. A boundary that exists only in the model’s reasoning is not a boundary.
Incremental adoption
Start with the material control gap, then expand only as the system requires.
Most systems will require only a small subset of SafeWave. The specific combination depends on the system’s authority, consequence, operating environment, and assurance requirements.
1 · AssessIdentify the material gaps in authority, scope, memory, compute, propagation, recovery, privacy, identity, robotics, or other control surfaces.
2 · MapConnect each gap to the relevant containment layer, protocol layer, core substrate, protected environment, and evidence requirement.
3 · ImplementIntegrate the required controls at the application, runtime, orchestration, device, firmware, hardware-rooted, or silicon layer justified by the boundary.
4 · Verify and expandTest boundary behavior, preserve evidence, revalidate after change, and add controls only as capability or consequence increases.
Further technical detail
Choose the technical path that matches your question.
Deeper pages carry the specialized engineering, AGI, hardware, cybersecurity, protocol, open-model, and mission-specific treatment without forcing every reader through every branch.
Engineering How is the architecture translated into implementation?
Review the implementation framing, engineering pathway, evidence expectations, and how detailed architecture becomes deployable controls.
Open the Engineering Brief →Protocols How are runtime, escalation, replication, pathway, and admission governed?
Explore the protocol layer that governs execution as system state, authority, scope, and operating conditions change.
Open Protocol Enforcement →Frontier AI / AGI How does the architecture address increasing autonomy and strategic leverage?
Review capability-aware enforcement, non-delegable authority, recursive-development concerns, and the case for selectively deeper enforcement.
Open the AGI Overview →High consequence How does bounded execution apply to mission-critical autonomy?
Review bounded behavior, intervention, degraded operation, recovery, and evidence where consequences are high.
Open Mission-Critical Autonomy →Open models What changes when there is no cooperative cloud provider?
See how model pathways, local execution, evidence, constraints, and deeper enforcement are treated when ordinary provider controls cannot be assumed.
Open Models & Execution Control →Architecture directory Where are the individual public architecture definitions?
Browse the full directory and open the current public definition page for each named SafeWave architecture.
Open the Architecture Directory →A practical next step
Map one real system to the architecture.
The SafeWave assessment can be completed privately using a real, planned, public, hypothetical, composite, or anonymized system. It is designed to surface material execution-control gaps and identify which parts of the architecture may actually be relevant.
