The 28-Category AI Architecture Decision Framework (28-CAADF)
Stop selecting technologies. Start deciding architecture.
Publication Date: September 29, 2026
Last Updated: November 11, 2026
Framework Status: Evolving Research
The 28-Category AI Architecture Decision Framework (28-CAADF) is an independently developed body of architectural research, continuously refined through ongoing research and practice.
✍️ About the Author
Sanjoy Kumar Malik — Senior Technology & Architecture Leader with 20.7+ years of corporate IT experience and 27+ years of total professional experience, spanning enterprise solution architecture, technology strategy, digital transformation, application modernization, enterprise integration, distributed systems, security, and AI-native architecture. He is a TOGAF 10 Certified Enterprise Architecture Practitioner and AWS Certified Solutions Architect – Professional.
He is the creator of The 28-Category AI Architecture Decision Framework (28-CAADF), a systematic approach to making AI architecture decisions in an era where intelligence itself is becoming an architectural capability.
Most AI architectures are not designed. They accumulate.
A model is picked during a proof of concept. A vector database arrives with the first prototype. An agent framework follows the next conference talk. Six months later the system is in production. Latency is climbing, costs are unpredictable, nobody can explain why it was built this way, and changing any one part breaks three others.
That is not a technology problem. It is a decision problem.
Production AI systems bring together intelligence, knowledge, retrieval, context, agents, tools, applications, infrastructure, security, governance, evaluation, economics, and continuous change. These concerns do not live in isolation. Every decision reaches into the others.
Read it left to right: the left group holds the choices you make, and the right group holds what those choices cost you.
The two groups
“One decision...” (left, dark navy boxes): three design choices you control: Model choice, Retrieval design and Autonomy level.
“...many consequences” (right, white boxes): the downstream effects those choices set off. The blue box, Unit economics, is the end point where everything lands.
The arrows
Each arrow means “directly affects.” Following them gives four chains:
Model choice affects both Latency and Infrastructure. One choice has two separate consequences. Retrieval design affects Answer quality. Autonomy level affects the Authorization model, which in turn affects the Governance burden. This is the only chain with a middle step: how much freedom you give the system changes how you must control access, and that changes how much oversight you carry. Latency, Infrastructure, Answer quality and Governance burden all feed into Unit economics (the blue arrows).
The takeaway: A choice that looks purely technical, like which model to use or how to retrieve data, ends up shaping cost and business viability. The blue box is the point: every decision on the left reaches Unit economics, directly or through a chain. Authorization model is the one consequence that doesn’t point at Unit economics itself. It matters through the Governance burden it creates.
A model decision reshapes latency and infrastructure. A retrieval decision reshapes context quality. An autonomy decision reshapes authorization and governance. A performance requirement reshapes cost. Architecture is the discipline of seeing those ripples before they reach production.
Conventional technology-selection thinking cannot see them. 28-CAADF was built to.
From technology selection to architecture decisions
Most AI architecture conversations open with the wrong questions:
Which model should we use? Which vector database? Should we use RAG? Which agent framework? GPUs or CPUs?
These are legitimate questions. They are also downstream questions, and answering them first is how architectures accumulate instead of being designed.
Technology choices should emerge from architectural reasoning. They should never replace it.
This leads to the central thesis of the framework:
There is no universally best AI architecture. There is only an architecture whose collective decisions satisfy the business and technical conditions the system must operate within.
AI architecture is a decision system
A production AI architecture is the sum of many decisions made under competing requirements. Each one creates consequences.
Nothing is free. Every meaningful decision moves something else:
| A decision that improves... | ...can quietly cost you |
|---|---|
| Quality | Latency |
| Autonomy | Governance and authorization overhead |
| Cost efficiency | Intelligence |
| Scalability | Operational complexity |
| Knowledge freshness | Infrastructure and synchronization effort |
The architect's job is not to pick winners. It is to understand the decision space, the consequences of each available choice, and how those choices interact with everything else.
The 28-category perspective
The framework examines AI systems through 28 architectural decision categories, organized into eight planes that together describe the full decision space of a modern AI system.
I use the word categories deliberately, not technologies. They provide architectural coverage. They do not prescribe products, vendors, models, frameworks, or implementation patterns.
Each plane forces a question that technology selection alone never asks:
| Plane | The question it forces |
|---|---|
| Intelligence | How much intelligence does each request actually need? |
| Knowledge | Where does what the system knows live, and how does it reach the model? |
| Agentic execution | What may the system do on its own, and who authorizes it? |
| Application and runtime | How does it behave under real users and real load? |
| Trust | What happens when it fails, is attacked, or is audited? |
| Quality | How do we know it is good, and keep knowing it? |
| Economics | Can the business sustain it at scale? |
| Enterprise evolution | How does it survive change, tenants, and organizational growth? |
The exact decomposition of the categories, their internal decision structures, and the mechanics that connect them are intentionally not published. This page explains the architectural thinking behind the framework, not the machinery inside it.
The Architecture Envelope
The most important idea in the framework is the Architecture Envelope.
An AI system does not operate in unlimited architectural space. It operates inside a region defined by what the business requires and what reality allows. Define that region first, and technology choices stop dominating the conversation.
These dimensions cannot always be optimized independently. An architecture that is excellent on one axis can be unsuitable once the complete envelope is considered. That is why the framework asks, before any technology is chosen:
What architecture envelope must this AI product operate within?
A well-formed envelope is specific enough to be measured. For example, illustratively: a latency ceiling, a quality floor, an availability target, a freshness window, and a cost per transaction the business can sustain.
Choice is not fitness
Choosing an architecture answers one question: what did we decide?
Architecture fitness answers the one that matters: how well does the resulting architecture satisfy the envelope it was designed for?
This shifts the conversation from:
"Did we choose the right technology?"
to:
"Does the architecture actually satisfy the operating envelope?"
It applies equally to greenfield design and brownfield assessment, which is where most of the real-world value lives.
Architecture is not finished at deployment
Traditional practice treats architecture as a design-time activity. AI systems break that assumption.
Models evolve. Pricing shifts. Traffic grows. Data accumulates and knowledge goes stale. Quality expectations rise. Regulation changes. Threats evolve. Business criticality moves. The architecture that was right six months ago may be wrong today.
So the framework treats architecture as an evolving decision system. Every significant decision moves through a lifecycle, and the lifecycle never ends.
A decision should never disappear after implementation. It should remain understandable, measurable, and ready to be reconsidered when the assumptions underneath it change.
Two starting points, one discipline
The framework supports two fundamentally different situations. Designing a new AI system and evolving an existing one are not the same activity, and it should not pretend they are.
| From Intent | From System | |
|---|---|---|
| Situation | A new AI product or capability | An AI system that already exists |
| Direction | Design forward from business need | Assess backward, then evolve forward |
| Core task | Make the right decisions before building | Recover the decisions that emerged, and test whether they still hold |
Beyond the number 28
The number 28 matters because it establishes a deliberate coverage model. But the number is not the point.
Architectural sophistication does not come from adding more categories. It comes from understanding:
- what decisions need to be made
- what constrains them
- what trade-offs they introduce
- how they interact
- where independence is possible
- how outcomes are validated
- when decisions must be revisited
This framework is not another checklist. It is a decision discipline.
What it is, and what it is not
| 28-CAADF is not... | It is... |
|---|---|
| An LLM selection guide | A way to decide how much intelligence a system needs |
| A RAG implementation guide | A way to reason about how knowledge reaches intelligence |
| An agent framework | A way to decide what autonomy a system should have |
| A cloud reference architecture | A way to derive infrastructure from requirements |
| A vendor comparison matrix | A way to stay independent of any single vendor |
| A technology checklist | A discipline for making decisions explainable |
| A static reference architecture | A mechanism for evolving architecture over time |
It does not prescribe a technology stack. It does not claim one optimal architecture exists. It gives architects a structured way to reason about the choices that shape their system.
What it enables
| The question | What the framework gives you |
|---|---|
| How do we get from a business requirement to a coherent AI architecture? | Architecture from business intent |
| How do we weigh competing objectives? | Explicit, structured trade-offs |
| Which decisions influence which? | Visible decision dependencies |
| What should be able to change without a redesign? | Capability independence |
| Does what we built meet what we need? | Measurable architecture fitness |
| When should we revisit a decision? | Deliberate architectural evolution |
These questions stop being optional the moment AI moves from experiment to production.
Who it is for
The framework is written for the people who answer for AI architecture outcomes: CTOs, Chief AI Architects, Heads of AI Architecture, Enterprise Architects, AI Platform Leaders, and senior engineering leadership.
It applies across deterministic AI, generative AI, RAG systems, agentic AI, multimodal and real-time AI, enterprise AI platforms, and domain-specific AI products.
The principle
The move from AI experimentation to production demands more than increasingly capable models. It demands architectural discipline.
Do not begin with the technology. Begin with the intelligence the business needs, the architecture envelope the system must satisfy, and the decisions required to construct and evolve that architecture.
The deeper framework contains the detailed decision structures, relationships, governance mechanisms, and operating mechanics behind this philosophy. For now, I am deliberately keeping those private.
An evolving body of architectural research
28-CAADF is being refined through continued work on enterprise AI, knowledge-intensive systems, agentic architectures, AI platforms, and production-scale intelligence systems.
The goal is not to prescribe one architecture. It is to establish a disciplined way of making decisions that remain explainable, measurable, adaptable, and evolvable as AI changes.
So the question is not:
Which AI technology should we choose?
The question is:
What set of architectural decisions will let the intelligence we need operate within the business, technical, trust, quality, scale, and economic envelope we must satisfy, while remaining capable of evolving as those conditions change?
That is the problem the 28-Category AI Architecture Decision Framework exists to solve.