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