Deployability
“Can it operate and contain failure?”
Verifies runtime latency, dependency observability, graceful degradation, and tested containment controls.
Can the system degrade gracefully or abstain entirely without allowing uncalibrated authority unchecked?
High vendor API uptime is mistaken for operational resilience and control.
A tested fallback mode and automated circuit breaker must exist before release.
Deployability: Runtime Control Surface & Dependency Failure Simulator
Vendor uptime SLAs do not prove full decision continuity. Click any dependency below to simulate a network partition or API failure and observe whether your system safely degrades or catastrophically fails.
NORMAL OPERATION
All dependencies healthy. Runtime latency within 500ms SLA.
Primary Foundation Model
Degrades to secondary localized SLM model; latency increases from 400ms to 950ms.
Vector Retrieval Service
Degrades to cached static regulatory rulebook; marks output as Low Freshness.
Autonomous Tool Gateway
CRITICAL FAILURE: No transactional circuit breaker. Missing fallback causes silent unhandled exceptions.
Deterministic Policy Guard
Hard safety halt: If policy validator is down, system abstains completely from deciding.
Audit Receipt Ledger
Queues decision in encrypted local memory buffer until database writes resume.
Human Review Escalation Queue
Queue overflow: Requests exceeding SLA are queued with auto-rejection timeouts.
Evidence Conditions for Deployability
Can the complete runtime meet the required latency, scale, availability and integration conditions of the real workflow?
Are material runtime dependencies — model/provider, retrieval, tools, pipelines and external services — observable and controlled?
Is there a tested fallback or degraded operating mode when the AI, evidence path or dependency is unavailable or outside limits?
Can a material production failure be contained without allowing the system to continue exercising authority unchecked?
Companion Book Chapters (8)
The Anatomy of a Decision
Uncertainty, Regimes, and Action Windows
Architecture as Control
Designing Controllable AI Systems
Method Selection Under Constraints
Rules, Trees, Neural Models, and Ensembles
From Release to Deployment
The AI Release Case and Fallback Architecture
Incident Response and the Decision Receipt
Traceability, Forensic Reconstruction, and Containment
Monitoring, Drift, and Permission Renewal
Continued Operation as an Active Permission Decision
Retraining and Model Change
Governing System Transitions and Candidate Replacement
Vendor Dependency and Platform Risk
Managing External Foundation Models and Vendor Lock-in
Operational Artefacts (4)
AI Release Case
Build a defensible case establishing that an AI system has satisfied all 6 independent evidence gates before production release.
Decision Receipt Schema
Cryptographically traceable data schema capturing point-in-time inputs, model version, retrieval state, and policy state for forensic audits.
Monitoring Contract
Defines runtime SLOs, drift thresholds, error budget depletion rules, and quarterly permission renewal triggers.
Vendor Dependency & Portability Review
Audit external foundation model and API dependencies for operational lock-in, SLA drift, and exit portability.