TOGAF ↔ AESOP OS

TOGAF describes architecture governance — AESOP executes it.

Core Phase Mappings

TOGAF ADMThe Open Group Architecture Framework

AESOP Transformation OSAI-Native Governance & Operationalization

TOGAF · Preliminary

Architecture Capability Framework

Establish the architecture practice: org structure, principles, governance framework, and tooling before any work begins.

→

AESOP · Stage 0

Organization Layer

Departments, stakeholders, multi-org support, portfolio scoring, Kanban with WIP limits, strategic prioritization agent. An operating system, not a project.

Both establish the capability foundation
TOGAF asks "what architecture capability do we need?"
AESOP answers with a provisioned operating system — departments, prioritization, governance context — ready before the first initiative begins

TOGAF · Phase A

Architecture Vision

Scope the initiative: stakeholder mapping, high-level vision, business drivers, constraints. Secures sponsorship and sets boundaries.

→

AESOP · Stage 1

Discover

Discovery sessions with stakeholder mapping, autonomy level assessment, commitment readiness scoring, triage verdicts. Operational questions enrich the brief with organizational context.

Both scope and bound the initiative
TOGAF's vision artifact maps to AESOP's discovery session
AESOP adds commitment readiness scoring — quantifying stakeholder buy-in before proceeding, something TOGAF leaves to intuition

TOGAF · Phase B

Business Architecture

Define the target operating model: business capabilities, value streams, org structure, governance, and process flows.

→

AESOP · Stage 2

Working Agreement

RACI matrices, roles, process flows, sign-off gates. 100% deterministic — rendered from discovery data with zero LLM involvement. The formal gate between Discover and Design.

Both define governance and operating model
AESOP's Working Agreement is the deterministic contract — rendered without AI, serving as the enforceable gate before architecture design begins
TOGAF's governance artifacts, made executable

TOGAF · Phases C & D

Information Systems + Technology Architecture

Target data architecture, application components, platform choices, integration patterns, infrastructure design. The full technical blueprint.

→

AESOP · Stage 3

Design

Architecture session producing data models, application components, platform-specific configurations. 32-file engine knowledge base fed to LLM. Platform-aware (Monday.com, custom stacks).

Both produce the target architecture
TOGAF splits this across two phases (C & D); AESOP unifies them into one Design stage
The platform knowledge base injects implementation-specific constraints that TOGAF would defer to Phase E — collapsing design-time and platform selection into a single pass

TOGAF · Phase E

Opportunities & Solutions

Translate architecture into work packages: identify implementation projects, assess build-vs-buy, sequence delivery increments.

→

AESOP · Stage 4

Build

Implementation via 6 sub-phases producing: state change hypotheses, translation debt assessments, ripple maps, platform-specific output. Direct PRD endpoint POST /api/builds/direct available.

Both translate architecture into implementation
TOGAF identifies opportunities; AESOP executes them
The state change hypothesis and translation debt assessment are artifacts TOGAF has no equivalent for — they capture implementation risk that paper-based governance cannot surface

TOGAF · Phase F

Migration Planning

Roadmap and transition architectures: sequence work packages into transition states, define readiness criteria, estimate timelines and resources.

→

AESOP · Stage 3.5

Operationalize

Launch Package: RACI, Tiger Team Brief, Maintenance Plan, Adoption Plan. Rollout duration auto-calibrated from readiness scores. Eval frequency tied to autonomy level.

Both plan the transition
AESOP automates what TOGAF requires manual effort to produce
Auto-calibrated rollout duration from readiness scores means the migration plan adapts to actual project maturity rather than estimation heuristics

TOGAF · Phase G

Implementation Governance

Oversee implementation against the architecture: compliance reviews, deviation tracking, quality gates, conformance checks.

→

AESOP · Stage 5

Evaluate

Six evaluation modes: Standard 5-Agent, Cave of Shadows (adversarial), Custom Rubric, Hydra (multi-perspective), Bias Probe, KB Audit. Multi-agent panels with structured scoring.

Quality gate, automated
TOGAF's compliance reviews are manual board meetings
AESOP's six evaluation modes are AI agent panels that run automatically — adversarial testing, bias detection, and multi-perspective review provide deeper conformance checking than any human review board could sustain

TOGAF · Phase H

Architecture Change Management

Continuous monitoring of deployed architecture: track changes in business/technology environment, assess impact, trigger new cycles when thresholds are crossed.

→

AESOP · Stages 7 & 8

Monitor + Repair

Monitor: drift alerts, stale eval warnings, maintenance dashboard. Repair: Tiger Team findings feed the Forge agent for targeted fixes. Repair cycles persist data via Trace Analysis.

Continuous improvement loop, closed
TOGAF describes change management as a governance process
AESOP automates the detect → repair → verify cycle — drift alerts trigger Repair, Tiger Team findings feed the Forge agent, and Monitor confirms the fix
The loop is closed by software, not by a review board calendar

Cross-Cutting Concerns

Cross-Cutting

Requirements Management → Trace Analysis

TOGAF's Requirements Management sits at the center of the ADM cycle — every phase produces and consumes requirements, maintaining end-to-end traceability
AESOP's Trace Analysis (Stage 4.25) mirrors this: open coding → axial coding → focused repair, persisting annotations across cycles
Both are the connective tissue that makes the cycle coherent rather than a waterfall in disguise

Cross-Cutting

Content Framework → Regulatory Mapping

TOGAF's Content Framework defines the artifacts and deliverables each phase must produce — a metamodel for architecture outputs
AESOP's Regulatory Mapping (Stage 4.5) takes this further: upload regulatory templates, and the system auto-generates completed compliance documents from pipeline data
Architecture outputs map to compliance artifacts — not just described, but produced

Structural Similarities

↻

Iterative, Not Linear

Both are cycles, not waterfalls. Each phase feeds back into prior phases. AESOP's Repair triggers new evaluation cycles; TOGAF's Phase H triggers new ADM iterations.

◆

Explicit Governance Gates

Both enforce phase transitions through governance checkpoints. AESOP's Working Agreement is a deterministic gate; TOGAF's Architecture Contracts serve the same function.

≡

Design / Run-Time Separation

Both distinguish architecture design (TOGAF B–D, AESOP Design) from implementation execution (TOGAF E–G, AESOP Build/Deploy). Different concerns, different artifacts.

◎

Continuous Monitoring

Both treat monitoring as a first-class phase, not an afterthought. AESOP's drift alerts operationalize what TOGAF's Phase H describes as a process.

◉

Traceability Across Cycles

Both maintain lineage from requirements through design to implementation and back. AESOP's Trace Analysis persists annotations across repair cycles.

▶

Described → Executed

TOGAF describes what should happen. AESOP executes it. Governance, evaluation, and repair are automated by AI agents rather than managed through manual review boards.

AESOP Transformation OS is essentially TOGAF ADM made executable — a framework where architecture governance, evaluation, and repair are automated by AI agents rather than managed through manual review boards. TOGAF describes the operating model; AESOP is the operating model.