AI-Ready Docs

08 / TAD

Technical Architecture Document

How should the software system be structured?

The Technical Architecture Document defines the technical structure required to implement the product. It describes the major system components, their responsibilities, technology boundaries, integrations, environments, and important technical decisions.

Layer
Engineering
Primary purpose
Define how the technical system is structured.
Used by
Product / Design / Engineering / AI
On this page
  1. 01What is it?
  2. 02Why do we need it?
  3. 03When do we create it?
  4. 04Who benefits from it?
  5. 05What does it contain?
  6. 06What does it NOT contain?
  7. 07What does an architecture specification look like?
  8. 08Architecture elements
  9. 09How does AI use it?
  10. 10How does it connect to other documents?
  11. 11Example
  12. 12Template
  13. 13Common mistakes
01

What is it?

The Technical Architecture Document defines how the technical parts of a product are organized and how responsibilities are distributed across the system. It makes important architectural decisions explicit before implementation.

  • FSD

    What

  • BRD

    Rules

  • UFD

    Behavior

  • DSD

    Experience

  • DDD

    Data

  • ASD

    Communication

  • TAD

    Structure

DDD answers what data exists. ASD answers how that data moves. TAD answers how the technical pieces are organized so the product can work.

02

Why do we need it?

Product requirements, data models, and communication contracts can define what the system needs to do without defining how the technical system should be organized to support it.

Without TAD

Requirements
Data + APIs
AI / Developer chooses architecture
Inconsistent technical structure

With TAD

Requirements
Data + APIs
Defined architecture
Implementation

The purpose is to remove ambiguity around important technical structure decisions. The problem is undocumented architectural decisions, not that developers cannot design architecture.

03

When do we create it?

The TAD is created once the product behavior, interface requirements, data structures, and communication contracts provide enough context to define the technical structure needed for implementation.

This is an information relationship, not a rigid waterfall. Architectural decisions can expose missing product, data, communication, or behavioral decisions that need clarification. Architecture should not be treated as something created once and never revisited.

PRD
FSD
BRD
UFD
DSD
DDD
ASD
TAD
DR
Implementation
04

Who benefits from it?

  • Product

    Uses it to understand the major technical boundaries supporting the product.

  • Design

    Uses it to understand technical constraints that can affect the experience.

  • Engineering

    Uses it as the explicit source for architectural responsibilities, boundaries, and technical decisions.

  • AI agent

    Uses it to implement within the defined technical structure instead of inventing architecture during implementation.

05

What does it contain?

These are the fields an architecture specification can define.

  1. 01

    Architecture Overview

    The high-level structure of the system.

  2. 02

    Components

    The major technical parts of the system.

  3. 03

    Responsibilities

    What each component is responsible for.

  4. 04

    Layers

    How responsibilities are separated across the system.

  5. 05

    Technology Decisions

    The technologies selected for important parts of the system.

  6. 06

    Communication Boundaries

    How major technical components interact.

  7. 07

    Data Boundaries

    Where data is owned, accessed, or transformed when relevant.

  8. 08

    External Integrations

    Third-party systems and services the product depends on.

  9. 09

    Environments

    Important differences or requirements across development, staging, and production environments when applicable.

  10. 10

    Security Boundaries

    Important authentication, authorization, secrets, or trust boundaries when relevant.

  11. 11

    Infrastructure Requirements

    Technical infrastructure required to operate the system.

  12. 12

    Technical Constraints

    Known limitations or constraints that affect implementation.

  13. 13

    Architectural Decisions

    Important decisions, tradeoffs, or constraints that should remain explicit.

  14. 14

    Observability / Operations

    Important logging, monitoring, error reporting, or operational requirements when relevant.

Not every architecture document needs every field — only document what is relevant to the product.

06

What does it NOT contain?

  • Product vision
  • Feature scope
  • Complete business rules
  • Complete user journeys
  • Detailed UI specifications
  • Database field definitions
  • Complete API contracts
  • Application source code
  • Individual implementation tasks
  • Detailed sprint planning
  • Deployment commands
  • Framework tutorials

DDD

What data exists?

ASD

How does information move?

TAD

How is the technical system structured?

DR

In what order should it be implemented?

AI Instructions

How should the agent behave while implementing it?

07

What does an architecture specification look like?

Architecture specification

Component ID
COMP-001
Component name
Project Service

Purpose

Responsible for project-related application behavior.

Responsibility

Handles the application-level operations required for project creation.

Input

Receives the defined project creation request through the documented communication contract.

Data

Uses the documented Project data structure.

Output

Returns the defined result through the documented communication contract.

Boundaries

  • Owns project-related application behavior.
  • Does not define user interface behavior.
  • Does not redefine the database model.
  • Does not redefine the API contract.

Dependencies

Uses the documented data and communication interfaces required by the product.

Conceptual architecture relationship

Client
API
Application
Data

Architecture defines responsibilities and boundaries between technical parts.

This is a methodology example, not a real production architecture — specific technologies, frameworks, and infrastructure patterns are not defined here.

08

Architecture elements

  1. 01

    Component

    A major technical part of the system.

  2. 02

    Responsibility

    What a component owns or performs.

  3. 03

    Boundary

    What a component does and does not own.

  4. 04

    Layer

    A defined separation of technical responsibilities.

  5. 05

    Dependency

    A relationship where one component relies on another.

  6. 06

    Integration

    A connection to an external system or service.

  7. 07

    Technology

    A selected technical solution used within the architecture.

  8. 08

    Environment

    A defined runtime context such as development, staging, or production.

  9. 09

    Constraint

    A technical condition that limits or shapes the architecture.

  10. 10

    Architectural Decision

    An important technical decision that should remain explicit.

09

How does AI use it?

The TAD gives the AI agent an explicit technical structure to implement within. It tells the agent which responsibilities belong to which components, what boundaries must be respected, which technologies have been selected, and which architectural decisions should not be changed silently.

TAD
Architecture specification

AI understands

  • What components exist
  • What each component is responsible for
  • Where boundaries exist
  • Which technologies are defined
  • Which dependencies exist
  • Which integrations exist
  • Which technical constraints apply
  • Which architectural decisions must be preserved

Without TAD

Requirements + DDD + ASD
AI chooses architecture

With TAD

Requirements + DDD + ASD + TAD
AI implements defined architecture

AI should not silently replace an explicitly documented architectural decision. If an architectural decision is missing, conflicting, or insufficient, surface a specification gap.

Specification gap

Feature

Create Project

The documentation defines the API and data requirements, but does not define which application component owns project creation behavior.

Implementation paused.

Decision required

Define the component responsibility before implementation.

Human

  • Architectural decisions
  • Technology choices
  • Component boundaries
  • Technical constraints
  • Tradeoffs
  • Approvals

AI

  • Defined components
  • Defined integrations
  • Defined technical patterns
  • Boilerplate
  • Repetitive technical work
  • Tests and refactoring within the defined architecture

AI can implement an architecture. It should not silently redesign one.

10

How does it connect to other documents?

FSD

Create Project

“What capability exists?”

BRD

Project creation rules

“What conditions apply?”

UFD

Create Project flow

“How does the behavior progress?”

DSD

Create Project interface

“How should the experience be represented?”

DDD

Project data

“What information must be stored?”

ASD

Create Project operation

“How is information communicated?”

TAD

Project technical structure

“Where does the behavior belong?”

The TAD takes the defined product, data, and communication requirements and assigns technical responsibilities and boundaries for implementation.

Feature

FEAT-004

Rule

RULE-001

Flow

FLOW-001

Screen

SCREEN-009

Entity

ENTITY-001

API

API-014

Component

COMP-001

11

Example

Feature concept

Create a Project

TAD perspective

The technical component responsible for project creation is defined together with its responsibilities, boundaries, and dependencies.

PRD

Why

Users need a way to organize their work into projects.

FSD

What

Users can create a project.

BRD

Rules

Project creation follows defined business rules.

UFD

Behavior

The user moves through the project creation journey and reaches a defined outcome.

DSD

Experience

The interface represents the journey through defined screens, states, interactions, responsive behavior, and feedback.

DDD

Data

The system stores the project information and its relationship to the relevant organization.

ASD

Communication

The project creation operation defines how the client communicates the required information and receives the result.

TAD

Structure

The technical component responsible for project creation is defined together with its responsibilities, boundaries, and dependencies.

DR

Order

When it should be implemented.

AI Instructions

Implementation

How the agent should implement the task.

12

TAD Template

tad-template.md

# Technical Architecture Document

## 01. Architecture Overview

## 02. System Components

### Component ID

### Component Name

### Purpose

### Responsibilities

### Boundaries

### Dependencies

### Inputs

### Outputs

### Data Ownership

### Communication

---

## 03. Architecture Layers

### Layer

### Responsibility

### Dependencies

---

## 04. Technology Decisions

### Area

### Technology

### Reason

### Constraints

---

## 05. Integrations

### Integration ID

### External System

### Purpose

### Communication

### Dependencies

---

## 06. Environments

### Environment

### Purpose

### Important Differences

---

## 07. Security Boundaries

## 08. Infrastructure Requirements

## 09. Architectural Decisions

## 10. Technical Constraints

## 11. Open Architecture Decisions
13

Common mistakes

  • Choosing architecture before understanding the product requirements.
  • Treating the database schema as the architecture.
  • Treating API contracts as the architecture.
  • Defining components without defining their responsibilities.
  • Leaving component boundaries implicit.
  • Choosing technologies without documenting the reason when the decision matters.
  • Assuming every product needs microservices.
  • Adding infrastructure because it sounds technically sophisticated.
  • Mixing implementation tasks into the architecture document.
  • Changing documented architectural decisions during implementation without surfacing the change.
  • Letting AI introduce frameworks, services, or architectural patterns that were never specified.
  • Creating an architecture diagram that looks impressive but does not explain responsibilities or boundaries.
  • Treating the TAD as permanent even when important architectural assumptions change.