TOGAF↔AESOP OS
TOGAF describes architecture governance. AESOP executes it.
the framework that defines the discipline → the operating system that runs it
TOGAF ADMThe Open Group Architecture Framework
AESOP Transformation OSAI-native governance & operationalization
Preliminary
Architecture Capability Framework
Establish the architecture practice: organization structure, principles, governance framework, and tooling — before any work begins.
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.
Phase A
Architecture Vision
Scope the initiative: stakeholder mapping, high-level vision, business drivers, constraints. Secures sponsorship and sets boundaries.
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.
Phase B
Business Architecture
Define the target operating model: business capabilities, value streams, organization structure, governance, and process flows.
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.
Phases C & D
Information Systems + Technology Architecture
Target data architecture, application components, platform choices, integration patterns, infrastructure design. The full technical blueprint.
Stage 3
Design
Architecture session producing data models, application components, platform-specific configurations. A 32-file engine knowledge base fed to the 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.
Phase E
Opportunities & Solutions
Translate architecture into work packages: identify implementation projects, assess build-vs-buy, sequence delivery increments.
Stage 4
Build
Implementation across six sub-phases producing state change hypotheses, translation debt assessments, ripple maps, platform-specific output. A direct PRD endpoint — POST /api/builds/direct — is 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.
Phase F
Migration Planning
Roadmap and transition architectures: sequence work packages into transition states, define readiness criteria, estimate timelines and resources.
Stage 3.5
Operationalize
Launch Package: RACI, Tiger Team Brief, Maintenance Plan, Adoption Plan. Rollout duration auto-calibrated from readiness scores. Evaluation 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.
Phase G
Implementation Governance
Oversee implementation against the architecture: compliance reviews, deviation tracking, quality gates, conformance checks.
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.
Phase H
Architecture Change Management
Continuous monitoring of the deployed architecture: track changes in the business and technology environment, assess impact, trigger new cycles when thresholds are crossed.
Stages 7 & 8
Monitor + Repair
Monitor: drift alerts, stale evaluation 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.
TOGAF is the doctrine; AESOP is the machine. Every phase of the ADM finds its AESOP stage, but the OS does not merely mirror the framework — it makes the governance loop executable, automated, and closed by software rather than by meetings. The readiness signal, the adversarial evaluation, the drift-triggered repair: these are the places AESOP goes beyond describing governance and actually runs it.