ASA — AI Safe Architecture
An open standard for protecting AI-built apps through clear boundaries, critical safety checks, and structural discipline.
ASA defines three protection layers: Production Foundation, Business Logic Protection, and Slice Architecture. Open specification. No vendor lock-in.
The Problem
AI tools generate apps fast. But speed without boundaries creates:
- Silent safety gaps — auth bypasses, unverified webhooks, exposed secrets that only surface when exploited
- Business logic regressions — changes to one flow break another, with no automated verification
- Architectural drift — after many AI prompts, the codebase becomes a monolith where every change risks breaking something unrelated
ASA exists because modern AI needs hard boundaries, not prompt choreography.
Three Protection Layers
1. Production Foundation
Active — 24 checksProtects the systems that must not fail in production: authentication, billing, admin access, environment safety. These are the areas where a single gap means data breaches, revenue fraud, or unauthorized access.
Learn more →2. Business Logic Protection
PlannedProtects the flows that define what the product does: onboarding, checkout, subscription changes. These flows are unique to each product. Protection comes through explicit flow definition, scenario mapping, and continuous verification.
Learn more →3. Slice Architecture
Active — 10 checksProtects the app from structural decay, cascading regressions, and the "AI wall". Slices are self-contained vertical features with hard boundaries. They prevent coupling, limit blast radius, and keep AI tools working safely.
Learn more →Implementation Status
| Layer | Phase 1 Checks | Status | Metric |
|---|---|---|---|
| Production Foundation | 24 checks | Active | Trust Score (A–F) |
| Slice Architecture | 10 checks | Active | AI Chaos Index (0–100) |
| Business Logic Protection | 0 active | Planned | — |
All Phase 1 checks are automated. They are designed to produce consistent results for the same codebase and configuration.
Core Principles
Boundaries
Every critical area must have explicit limits. Slices define feature boundaries. Modules define system boundaries.
Verification
Critical claims must be testable and enforceable. Binary PASS/FAIL results, not opinions.
Isolation
A change should affect only the intended scope. Cross-slice coupling is prevented. Blast radius is bounded.
Enforcement
Safety rules must run continuously, not live only in documentation. CI/CD integration ensures every PR is checked.
Protection Layers
- Production Foundation — auth, billing, admin, environment
- Business Logic Protection — critical flows (planned)
- Slice Architecture — boundaries, isolation, drift
Standard
- All 32 Checks — complete Phase 1 registry
- Core Principles — boundaries, verification, isolation, enforcement
- Terminology — consistent vocabulary
Resources
- Adoption Guide — how to start
- FAQ
- GitHub — full specification
Earlier versions of ASA included generation-era workflows (deterministic regeneration, marker-based preservation, contract-driven pipelines). These are no longer part of the active standard. View archive →