In the previous articles, I explained the engineering problems that led to DANA.

I didn't set out to create an architecture.

I set out to build software that people could trust.

Over time, a consistent pattern emerged.

Regardless of the feature I was building, the application naturally organized itself into six layers.

Each layer had a clear responsibility.

Each layer solved a different problem.

And together they created an application where AI could enhance the user experience without becoming the application's source of truth.

This is DANA.

The Architecture

                        User
                          │
                          ▼
               Conversation Layer
                          │
                          ▼
                Capability Layer
                          │
                          ▼
                  Domain Layer
                          │
                          ▼
                   Truth Layer
                          │
                          ▲
                    AI Explanation
                          │
                          ▲
                 Intelligence Layer

The diagram is intentionally simple.

The important idea isn't the direction of the arrows.

It's that every layer has exactly one responsibility.

Layer 1 — Truth

Everything begins with structured truth.

In EstateIQ that includes:

  • Buildings
  • Units
  • Leases
  • Charges
  • Payments
  • Allocations
  • Expenses
  • Documents
  • Reports

These records are the foundation of the application.

Nothing above this layer should invent or modify truth without going through deterministic business logic.

The AI never owns this layer.

Layer 2 — Domain

This layer contains the application's business knowledge.

Examples include:

  • services
  • selectors
  • validation
  • authorization
  • ledger calculations
  • document confirmation
  • reporting rules

If the Truth Layer answers:

"What data exists?"

The Domain Layer answers:

"How does the business work?"

Every important business rule belongs here.

Not inside prompts.

Layer 3 — Capability

This is where DANA begins to differ from many AI architectures.

Instead of exposing raw database queries to the language model, the application exposes capabilities.

A capability is a deterministic unit of knowledge.

For example:

Revenue Analysis

Expense Analysis

Portfolio Health

Document Intelligence

Delinquency Analysis

Cash Flow Summary

Each capability:

  • has one responsibility
  • is independently testable
  • produces structured output
  • can evolve without affecting other capabilities

Conversation doesn't call the database.

Conversation calls capabilities.

Layer 4 — Conversation

This layer exists entirely for people.

Its responsibilities include:

  • understanding intent
  • maintaining context
  • selecting capabilities
  • coordinating responses
  • handling follow-up questions

Notice what it doesn't do.

It doesn't calculate balances.

It doesn't determine permissions.

It doesn't apply business rules.

Conversation is simply another interface to the application's existing capabilities.

Layer 5 — AI

The language model finally appears here.

Its responsibilities are intentionally narrow.

It can:

  • explain
  • summarize
  • compare
  • coach
  • clarify
  • translate structured results into natural language

It should never become another source of business logic.

The application has already done the difficult work.

The AI makes the results understandable.

Layer 6 — Intelligence

The final layer is responsible for continuous improvement.

Examples include:

  • Gap Tool
  • Capability Registry
  • AI Operations
  • Prompt Versioning
  • Coverage Metrics
  • Evaluation

This layer doesn't improve the language model.

It improves the application.

Every unanswered question becomes an opportunity to expand the application's capabilities.

Over time, the software becomes more knowledgeable because engineers continue teaching it—not because the language model becomes better at guessing.

Why layering matters

One lesson became obvious while building EstateIQ.

The moment responsibilities start leaking between layers, complexity grows rapidly.

If prompts contain business rules, they're difficult to test.

If AI calculates financial balances, correctness becomes difficult to guarantee.

If permissions are enforced inside conversations, security becomes harder to reason about.

Each layer exists to protect the others.

That separation makes the application easier to understand, easier to maintain, and easier to trust.

DANA is not tied to finance

EstateIQ is simply where DANA emerged.

The pattern itself is much broader.

Healthcare systems can replace financial records with clinical records.

Insurance platforms can replace leases with policies.

Manufacturing systems can replace buildings with production lines.

The layers remain remarkably similar because the underlying problem is the same.

Every high-trust application has structured truth.

Every high-trust application has business logic.

Every high-trust application benefits from conversational access to deterministic knowledge.

Looking ahead

We've now explored the architecture itself.

The next question is one of implementation.

How does a user question actually travel through DANA?

How is a capability selected?

How does the application know when it cannot answer a question?

And how does the Gap Tool turn those unanswered questions into future capabilities?

In the next article, we'll follow a single user question from the moment it's asked to the moment the application responds—and what happens when no capability exists.