The 28-Category AI Architecture Decision Framework (28-CAADF)

Publication Date: September 29, 2026
Last Updated: September 29, 2026
Framework Status: Evolving Research

✍️ About the Author​

Sanjoy Kumar Malik — Principal AI Architect, Enterprise AI Strategist, and Senior Engineering & Technology Leader with 20+ years of corporate IT experience and a broader 27+ year professional journey, spanning Enterprise Architecture, software architecture, cloud-native systems, engineering leadership, and AI architecture. He is a TOGAF 10 Certified Enterprise Architecture Practitioner and AWS Certified Solutions Architect – Professional.

Sanjoy focuses on translating business strategy and AI opportunity into coherent enterprise architecture and scalable engineering execution. He works at the intersection of business, technology, architecture, and AI, helping organizations establish the architectural foundations, technology capabilities, and engineering systems required to turn AI initiatives into production-grade, scalable, governed, and economically sustainable enterprise capabilities.

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.

🌐 Website • 💼 LinkedIn

A systematic way to reason about the architectural decisions behind modern AI systems​

Modern AI architecture is becoming increasingly difficult to reason about.

The challenge is no longer simply choosing a model, a vector database, an agent framework, or a cloud platform. Production AI systems bring together intelligence, data, knowledge, retrieval, context, agents, tools, applications, infrastructure, security, governance, evaluation, economics, and continuous evolution.

More importantly, these concerns do not exist in isolation.

This is where conventional technology-selection thinking begins to fall short.

I have developed the 28-Category AI Architecture Decision Framework (28-CAADF) to approach this problem from a different perspective.

The framework treats AI architecture not as a collection of technologies, but as a connected system of architectural decisions.

From Technology Selection to Architecture Decisions​

A common AI architecture discussion begins with questions such as:

Which model should we use?

Which vector database should we choose?

Should we use RAG?

Which agent framework should we adopt?

Should the system run on GPUs or CPUs?

These are legitimate questions, but they are usually downstream questions.

Before answering them, an architect needs to understand what the system actually needs to achieve.

The architectural reasoning begins closer to:

Business Intent → Product Vision → Intelligence Requirements → Architectural Requirements → Architectural Decisions → Architecture → Validation → Measurement → Evolution

The technology choices emerge from that reasoning.

They should not replace it.

The objective is therefore not to identify a universally "best" AI architecture. The objective is to construct an architecture whose collective decisions satisfy the business and technical conditions within which the system must operate. This is a central thesis of the framework.

AI Architecture Is a Decision System​

I view a production AI architecture as the consequence of many architectural decisions made under competing requirements and constraints.

A simplified view is:

Requirements → Constraints → Architectural Decisions → Trade-offs → Architecture → Outcomes

Every meaningful decision introduces consequences.

It may improve quality while increasing latency.

It may improve autonomy while increasing governance requirements.

It may reduce cost while affecting intelligence.

It may improve scalability while introducing operational complexity.

It may increase knowledge freshness while adding infrastructure and synchronization requirements.

This means architecture cannot be reduced to selecting technologies independently.

The architect's responsibility is to understand the decision space, the consequences of the available choices, and how those choices interact with the rest of the system.

That is the problem this framework is designed to address.

The 28-Category Perspective​

The framework uses 28 architectural decision categories to systematically examine the major concerns involved in modern AI systems.

I deliberately use the word categories rather than technologies.

The categories are intended to provide architectural coverage across the AI system rather than prescribe particular products, vendors, models, frameworks, or implementation patterns.

At a high level, the framework considers concerns spanning areas such as:

• Intelligence
• Knowledge
• Agentic execution
• Application and runtime architecture
• Trust
• Quality
• Economics
• Enterprise evolution

These areas are interconnected rather than isolated.

The exact decomposition and internal decision structure are intentionally not described here.

The purpose of this article is to explain the architectural thinking behind the framework, not to publish the framework's internal decision machinery.

The Architecture Envelope​

One of the central ideas behind the framework is the Architecture Envelope.

An AI system does not operate in an unlimited architectural space.

It operates within a set of requirements and constraints.

For example:

How intelligent must the system be?

What quality level is required?

What latency can the business tolerate?

How reliable must it be?

How fresh must its knowledge be?

What security and privacy boundaries are required?

What scale must it support?

What economics can the business sustain?

These dimensions collectively define the operating region within which an architecture must function.

A simplified representation is:

                    Intelligence
                         │
                         │
             Quality ────┼──── Latency
                         │
          Reliability ───┼──── Economics
                         │
             Security ───┼──── Scale
                         │
                      Freshness

The important point is that these dimensions cannot always be optimized independently.

An architecture that is excellent from one perspective may be unsuitable when the complete operating envelope is considered.

The framework therefore encourages architects to establish the required architectural envelope before allowing technology choices to dominate the discussion.

The detailed mechanics used to derive and evaluate that envelope remain part of the underlying framework.

Architecture Is Not Finished When the System Is Deployed​

Traditional architecture practices can sometimes create the impression that architecture is primarily a design-time activity.

AI systems make that assumption increasingly difficult to sustain.

Models evolve.

Model pricing changes.

Traffic changes.

Data volumes increase.

Knowledge becomes stale.

Quality expectations change.

Regulatory requirements change.

Security threats evolve.

New models become available.

Business criticality changes.

The architecture that was appropriate six months ago may no longer be appropriate today.

For this reason, the framework treats architecture as an evolving decision system.

A simplified lifecycle is:

Identify → Frame → Explore → Decide → Validate → Measure → Reassess → Evolve

The important idea is that an architectural decision should not disappear after implementation.

It should remain understandable, measurable, and capable of being reconsidered when its underlying assumptions change.

Architecture From Intent and Architecture From System​

The framework is designed to support two fundamentally different architectural situations.

Architecture From Intent​

This is the forward-looking case.

A new AI product or capability begins with a business need and product vision.

The architect works forward toward the required intelligence and ultimately toward the architecture.

Business Need
      ↓
Product Vision
      ↓
Intelligence Strategy
      ↓
Architecture Decisions
      ↓
Architecture

Architecture From System​

The second situation is the existing enterprise.

Here, the architect starts with a system that already exists.

The challenge is to understand the architecture that has emerged, identify its decisions and constraints, assess its fitness, and determine how it should evolve.

Existing System
      ↓
Reverse Architecture
      ↓
Decision Reconstruction
      ↓
Envelope Measurement
      ↓
Decision Reassessment
      ↓
Evolution

This distinction is important because designing a new AI system and evolving an existing AI system are fundamentally different architectural activities.

Architecture Fitness​

Another important distinction is between architectural choice and architectural fitness.

Choosing an architecture answers:

What did we decide?

Architecture fitness asks:

How well does the resulting architecture satisfy the required envelope?

Consider an AI application that requires:

• a defined quality threshold
• a defined latency envelope
• a defined availability target
• a defined freshness requirement
• a sustainable economic model

The architecture should ultimately be measured against those requirements.

This changes the conversation from:

"Did we choose the right technology?"

to:

"Does the architecture actually satisfy the required operating envelope?"

That distinction is particularly valuable for both greenfield architecture and brownfield architecture assessment.

Beyond the 28 Categories​

The number 28 is useful because it establishes a deliberate architectural coverage model.

But the number itself is not the most important part.

The deeper idea is that architectural sophistication should not come from continuously adding more categories.

It should come from understanding:

• what decisions need to be made
• what constrains those decisions
• what trade-offs they introduce
• how decisions interact
• where independence is possible
• how architectural outcomes are validated
• when decisions should be revisited

In other words, the framework is not intended to become another checklist.

It is intended to provide a decision discipline.

What the Framework Is Not​

The 28-Category AI Architecture Decision Framework is not:

• an LLM selection guide
• a RAG implementation guide
• an agent framework
• a cloud reference architecture
• a vendor comparison matrix
• a technology checklist
• a static reference architecture
• a collection of preferred products

It does not prescribe a single technology stack.

It does not attempt to identify one universally optimal architecture.

Instead, it provides a structured way to reason about the architectural choices that shape different AI systems.

What It Is Intended to Enable​

At a high level, the framework is intended to help an architect reason about questions such as:

Architecture from business intent​

How do we move from a business requirement to a coherent AI architecture?

Architectural trade-offs​

How should competing architectural objectives be considered?

Decision dependencies​

Which architectural decisions influence other decisions?

Capability independence​

Which capabilities should be able to evolve independently?

Architecture fitness​

Does the resulting architecture satisfy the operating envelope it was designed for?

Architectural evolution​

When should an existing architectural decision be reconsidered?

These questions become increasingly important as AI systems move from experimentation into production.

A Framework for Production AI Architecture​

The transition from AI experimentation to production requires more than increasingly capable models.

It requires architectural discipline.

Production AI systems must operate within real business constraints.

They must handle quality expectations, latency requirements, reliability objectives, security boundaries, governance obligations, economic constraints, changing data, evolving models, and organizational scale.

The 28-Category AI Architecture Decision Framework is my attempt to bring these concerns into a systematic architecture decision discipline.

Its underlying principle is simple:

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 mechanics private.

This article is intended to introduce the architectural thinking, not disclose the complete framework.

An Evolving Body of Architectural Research​

The 28-Category AI Architecture Decision Framework is an evolving body of architectural research.

It is being refined through continued thinking around enterprise AI, knowledge-intensive systems, agentic architectures, AI platforms, and production-scale intelligence systems.

The objective is not to prescribe one architecture.

The objective is to establish a disciplined way of making architectural decisions that remain explainable, measurable, adaptable, and evolvable as AI systems change.

Ultimately, the question is not:

Which AI technology should we choose?

The more important architectural question is:

What set of architectural decisions will allow the intelligence we need to 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 is designed to address.