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. The public architecture comprises 36 named architectures: 35 execution-control architectures that define where containment must hold, how execution remains governed, and which control mechanisms enforce the required boundary, plus SafeSpace as 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.
Find the right control
Thirty-six distinct architectures. One searchable technical directory.
The directory presents each named SafeWave architecture with a concise role description and a link to its individual public definition. Each retains its own governed object, trigger conditions, mechanism, and enforcement output. They are not interchangeable controls or a single package that every deployment must install.
Use the directory to examine System Containment, Protocol Enforcement, Core Enforcement Substrates, and SafeSpace in detail; use this overview to understand how the architecture fits together.
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.
Engineering available for technical evaluation and licensing.
SafeWave has developed substantial implementation-oriented engineering specifications and toolboxes for selected architectures, including defined control boundaries, integration requirements, failure handling, recovery, evidence, and verification criteria. Qualified organizations can engage in licensing discussions now; actual deployments require platform-specific implementation, integration, testing, and independent validation.
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 SafeAGI’s external, non-delegable constraints on advanced AI authority; evidence-driven tightening of enforcement as risk changes; and selectively deeper protection where assurance requires it.
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.
