Where must containment hold?
The system layers establish whether the relevant boundary concerns one AI system, a distributed ecosystem, sovereign authority, or civilization-scale stability.
Architecture overview
One Architecture for Bounded AI Execution
SafeWave combines system containment, protocol enforcement, and specific control substrates into a modular architecture designed to keep advanced AI bounded, observable, interruptible, containable, recoverable, and under legitimate human authority.
This page describes the complete SafeWave architectural universe—not what every deployment requires.
Most systems will use only a much smaller subset of the 34 components, selected according to their actual control gaps, operating environment, and assurance needs. The SafeWave Assessment Questionnaire is the simplest way to identify the appropriate combination.
Complete 34-component architecture portfolio
Most deployments use only a small subset
Risk-matched component selection
Software-to-silicon deployment pathways
Define where containment appliesFrom an individual AI system to ecosystems, institutional environments, and civilization-scale infrastructure.
Govern how execution proceedsRuntime behavior, escalation, replication, pathway selection, and participation or re-entry remain governed under changing operating conditions.
Apply the control mechanism requiredAuthority, scope, memory, compute, telemetry, privacy, robotics, finance, identity, and other risks receive specific controls.
The canonical model
SafeWave separates the scope of containment, the rules governing execution, and the control mechanisms that enforce those rules.
This separation allows organizations to address a specific control gap without replacing their models, applications, cloud systems, devices, or operating environment. Components can be deployed selectively, then combined as autonomy, coupling, consequence, and assurance requirements increase.
4 components
System Containment Layers
Define the scale and environment across which AI behavior, authority, propagation, and consequence must remain contained.
5 components
Protocol Enforcement Layers
Govern runtime behavior, escalation, replication, pathway selection, and participation or re-entry under changing operating conditions.
25 components
Core Enforcement Substrates
Provide the specific mechanisms required to bound authority, scope, memory, compute, privacy, identity, robotics, finance, interaction, 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.
How the architecture works
Each layer answers a different control question.
How may execution proceed?
The protocol layers govern runtime behavior, escalation, replication, pathway selection, and participation or re-entry under changing operating conditions.
What mechanism enforces the boundary?
The core substrates supply the specific controls for authority, goals, memory, compute, identity, privacy, provenance, telemetry, robotics, finance, devices, and other risks.
SafeWave is not a single guardrail or one monolithic control plane. It is a coordinated family of deterministic control components that can be composed according to the system and the risk.
The complete architecture
All 34 canonical components
The architecture currently comprises four system-containment layers, five protocol-enforcement layers, and twenty-five core enforcement substrates. SafeCompanion is included within the twenty-five substrates.
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.
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.
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.
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.
Deployment depth
Architectural role and enforcement depth are separate decisions.
The 34 components describe what must be controlled and how the controls coordinate. Deployment depth describes where those controls are enforced. A component may be implemented at one or more enforcement depths—from applications and runtime infrastructure to firmware, hardware-rooted trust, or silicon—according to the risk and assurance requirement.
Interpretation above. Deterministic enforcement at the lowest practical layer.
Context-sensitive decisions may remain in software, while selected boundaries are anchored more deeply so application changes, failures, compromise, or model behavior cannot bypass them.
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 and siliconTrust roots, counters, privilege gates, protected state, non-bypassable ceilings, and hardware-rooted evidence.
Architectural boundary clarification
What SafeWave is—and what it is not
SafeWave complements model safeguards, cybersecurity, identity management, permissions, observability, governance, containers, isolation, and virtualization. It does not replace them.
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.
SafeWave does not promise that defects, misuse, or compromise never occur. It is designed to keep those events from automatically becoming uncontrolled execution or systemic failure.
Why a new layer emerges
Every compute era introduces infrastructure for the failure mode it creates.
As systems reach new levels of scale, density, autonomy, and coordination, previous controls stop being sufficient. New infrastructure layers emerge to restore stability and enable the next wave of capability.
| Era | Infrastructure layer | Problem addressed |
|---|---|---|
| Cloud computing | AWS and cloud infrastructure | Made scalable compute available without owning every server. |
| Distributed applications | Cluster orchestration | Managed applications and services across large compute environments. |
| AI compute | GPU programming and acceleration | Made massively parallel computation accessible to modern AI workloads. |
| Global internet services | Traffic, security, and edge infrastructure | Stabilized and protected services operating at internet scale. |
| Autonomous AI systems | SafeWave execution-control architecture | Bounds authority, escalation, propagation, resource demand, recovery, and consequence as AI systems act. |
Incremental adoption
Start with the material control gap, then expand as the system requires.
Most systems will require only a much smaller subset of the 34 SafeWave components. The specific combination depends on the system’s actual control gaps, operating environment, and assurance requirements. The simplest way to identify what is needed is to complete the SafeWave Assessment Questionnaire. An assessment identifies the specific execution-boundary gaps, maps them to the relevant components, and determines the appropriate enforcement depth.
AssessIdentify the material gaps in authority, scope, memory, compute, propagation, recovery, privacy, identity, robotics, or other control surfaces.
MapConnect each gap to the relevant system layer, protocol layer, core substrate, and evidence requirement.
ImplementIntegrate the required controls at the application, runtime, orchestration, device, firmware, or silicon layer.
Verify and expandTest boundary behavior, preserve evidence, review changes, and add controls as capability or consequence increases.
Further technical detail
Continue into the architecture
Architecture Directory
Browse all 34 components and open the current definition page for any named component.
Engineering Brief
See how the architecture is translated into implementation-ready engineering without disclosing proprietary mechanisms.
Protocol Enforcement
Explore runtime, escalation, replication, pathway selection, and participation or re-entry governance.
Open Models & Execution Control
See how candidate model pathways can be evaluated using evidence, constraints, and defined acceptance criteria.
Mission-Critical Autonomy
Review how bounded behavior, intervention, and recovery apply where consequences are high.
SafeChip Architecture
Examine silicon anchoring for control-plane integrity and non-bypassable enforcement.
AGI Overview
Explore capability-aware enforcement as autonomy and strategic leverage increase.
Escalation Stability
Review retry storms, coordination cascades, propagation loops, and machine-speed amplification.
How SafeWave Was Formed
Understand how disciplined problem definition and patent development became an engineering architecture.
A practical next step
Map one real system to the architecture.
The SafeWave questionnaire can be completed privately in the browser using a real, hypothetical, composite, or anonymized deployment. A submitted questionnaire can produce a private, system-specific report identifying the control gaps that appear material and mapping them to the relevant components, evidence requirements, and implementation pathways. The report is available at no cost and with no obligation.