Broadly applicable
The pressure must matter across languages, vendors, and workload shapes. A useful specialty rule can remain an overlay instead of becoming a universal factor.
Comparative research · 2026.3
Borrow the pressure.
Reject the costume.
A credible manifesto should show its competitors, not merely cite its ancestor. This comparison asks what each body of work optimizes, what the Twenty-Two- Factor App adopts, and where it deliberately refuses a universal claim.
01 · The selection test
A factor must earn
the number.
Twenty-two is editorial compression, not numerology. A practice enters the set only when it passes all five tests; otherwise it remains a useful pattern, specialty overlay, standard, or implementation guide.
Architecturally load-bearing
Ignoring it must create a recurring production failure, unsafe default, or lifecycle dead end—not merely miss a fashionable tool or preferred implementation.
Distinct enough
The factor needs its own design decision and evidence. Related concerns can overlap, but two labels must not reward the same work twice.
Falsifiable in practice
A team must be able to fail a litmus test. Aspirations without an observable boundary, owner, or decision do not qualify as commandments.
Durable under change
The wording names intent and system behavior. Ports, vendors, orchestration products, and deployment fashions may change without invalidating the rule.
02 · Revision note
Correctness earned
two explicit factors.
Edition 2026.3 retires Outcome Ownership and Cost as Architecture as standalone universal factors. Ownership remains required wherever a commandment calls for evidence, authority, or follow-up; cost remains a constraint across capacity, observability, resilience, delivery, and sustainable operation.
Their numbered slots now cover two harder-to-retrofit production blind spots: explicit formal state and functional decision logic, followed by memory-safe languages, total types, explicit absence, and contained unsafe interoperability. Earlier factor URLs redirect here so the revision remains reviewable instead of silently rewriting history.
03 · Compare and contrast
Twelve lenses.
One compressed set.
“Overlap” names the factors most directly pressured by each source; it does not claim equivalence. The distinctions matter as much as the borrowings.
Twelve-Factor + Fifteen-Factor
- Optimizes for
- Portable, deployable cloud applications
- Strongest overlap
- I–XIII
What this guide borrows
The durable original ten remain the foundation. Kevin Hoffman’s API-first, telemetry, and authentication/authorization additions become Contract-First Interfaces, Observability & SLOs, and Secure by Design.
Where this guide differs
This guide retires transport-specific port binding and promotes logs into a complete signal-and-decision model. It broadens API-first beyond HTTP and broadens identity into the full secure-development lifecycle.
The Reactive Manifesto
- Optimizes for
- Responsive, resilient, elastic, message-driven systems
- Strongest overlap
- VII, XIII, XV
What this guide borrows
Bounded response time, backpressure, isolation, elasticity, and failure containment sharpen Concurrency, Observability & SLOs, and Resilience & Fault Containment.
Where this guide differs
Message-driven architecture is a strong pattern, not a universal commandment for every CLI, embedded workload, batch process, or local application. The Twenty-Two-Factor set specifies outcomes and bounds without prescribing one communication model.
SRE + Principles of Chaos Engineering
- Optimizes for
- Measurable reliability under realistic disturbance
- Strongest overlap
- VIII, XIII, XV, XVIII
What this guide borrows
SLIs, SLOs, error budgets, release safety, production readiness, steady-state hypotheses, realistic failure injection, and bounded experiments make reliability claims testable.
Where this guide differs
SRE is an operating discipline and Chaos is an empirical practice; neither is reduced here to a checkbox. Their evidence loops support several factors rather than becoming a vague “test more” commandment.
DORA Capabilities
- Optimizes for
- Delivery performance, organizational outcomes, and wellbeing
- Strongest overlap
- I, V, IX, XVIII, XIX
What this guide borrows
Version control, continuous delivery, small changes, loosely coupled teams, monitoring, database change management, maintainability, customer feedback, and sustainable pace reinforce the delivery and feedback disciplines.
Where this guide differs
DORA reports empirically associated capabilities and outcomes; this guide states architectural obligations. It deliberately avoids turning deployment frequency or any single metric into a universal target detached from context.
Well-Architected Frameworks
- Optimizes for
- Cross-pillar workload quality and explicit trade-offs
- Strongest overlap
- VII, XII–XVIII, XXII
What this guide borrows
Operational excellence, security, reliability, performance efficiency, cost, and sustainability confirm that production quality is multi-dimensional and that improving one dimension can tax another.
Where this guide differs
Provider frameworks are deep review catalogs. This guide is a shorter, vendor-neutral set of application pressures. Performance and cost remain cross-cutting constraints through Concurrency, SLOs, Resilience, delivery, and Sustainability rather than context-free universal factors.
CNCF Architecture + OpenGitOps
- Optimizes for
- Portable, interoperable, observable, resilient desired state
- Strongest overlap
- IV, XI, XIII, XV, XVII
What this guide borrows
Interoperable contracts, vendor-neutral telemetry, declarative versioned state, automatic reconciliation, and continuous drift detection shape the application and infrastructure boundaries.
Where this guide differs
Cloud native is one deployment context, not the definition of modern software. The commandments also apply to mobile, desktop, edge, embedded, local-first, and regulated systems where Kubernetes or GitOps may be the wrong implementation.
SAMM + SSDF + Secure by Design
- Optimizes for
- Security ownership from requirements through operations
- Strongest overlap
- XII, XIV, XVI, XXI
What this guide borrows
Threat modeling, security requirements, safe defaults, verification, vulnerability response, supply-chain evidence, memory-safe implementation, and responsibility for customer security outcomes broaden the earlier identity-only rule.
Where this guide differs
SAMM is a maturity model and SSDF is a practice catalog. Factor XII is the compressed architectural commandment; it does not replace either framework, a domain threat model, or a formal safety case.
Manifesto for Agile Software Development
- Optimizes for
- People, working software, collaboration, and response to change
- Strongest overlap
- IX, XI, XVIII–XIX
What this guide borrows
Short feedback, working software, direct collaboration, and response to change reinforce representative testing, contract evolution, and progressive delivery.
Where this guide differs
The Agile Manifesto is about values for making software; this guide is about system properties and lifecycle evidence. Neither can substitute for the other, and process labels do not prove architectural fitness.
Local-first Software
- Optimizes for
- Speed, offline use, longevity, privacy, and user control
- Strongest overlap
- VI, XI, XV, XVI, XIX
What this guide borrows
Data Lifecycle & Privacy now treats portable export, durable formats, offline usefulness, and provider exit as practical agency—not just compliance workflows.
Where this guide differs
Local-first is compelling for user-authored and collaborative data, but central authority is appropriate for banking, marketplaces, and other domains. The factor requires agency and lifecycle control without prescribing CRDTs or device-primary storage.
Sustainable Web + Green Software + FinOps
- Optimizes for
- Efficient, open, honest, resilient technology within physical limits
- Strongest overlap
- XVI, XXII
What this guide borrows
Useful-work units, energy and hardware efficiency, carbon awareness, cost evidence, accessibility, honesty, and explicit trade-offs connect resource use to value and harm.
Where this guide differs
Cost remains a cross-cutting design constraint rather than a standalone factor, and price is not a physical-impact signal. “Renewable” and offsets do not excuse waste, while efficiency work must not export harm into accessibility, privacy, labor, or reliability.
Google’s Sixteen-Factor AI Extension
- Optimizes for
- Prompts, model state, non-deterministic quality, and AI trust
- Strongest overlap
- I, II, VI, XII–XVI, XIX–XXII
What this guide borrows
Prompts, context logic, behavioral specifications, models, evaluation sets, and guardrails are first-class versioned inputs. Quality and tool-use safety must be measured as product behavior, not inferred from HTTP success.
Where this guide differs
AI introduces distinct hazards, but they fit the universal rules: prompts and specs are source, models are dependencies, memory is state, evaluations are SLO evidence, tools require least privilege, and critical workflows need explicit states and guarded effects. AI-specific standards remain an overlay.
Formal Methods + Memory-Safe Languages
- Optimizes for
- Explicit system behavior and elimination of preventable defect classes
- Strongest overlap
- XX–XXI
What this guide borrows
State-machine specifications, safety and liveness properties, immutable functional cores, typed errors, exhaustive matching, memory safety, explicit absence, and isolated unsafe boundaries turn reviewer assumptions into checkable constraints.
Where this guide differs
Types and safe languages prevent important classes of failure but do not prove requirements, authorization, concurrency, or domain correctness. Formal rigor is proportional to risk, and every model must state its assumptions and connection to implementation.
04 · Honest boundary
A field guide is not
a complete profession.
These commandments do not replace user research, accessibility standards, secure-development maturity models, domain regulation, formal safety cases, incident command, engineering management, or specialty guidance for AI, medical, financial, embedded, and other high-consequence systems.
Their job is narrower: expose the cross-cutting architectural pressures that are easiest to postpone and hardest to retrofit, state a boundary against cargo culting, and leave every claim open to evidence and revision.