F2T2EA: The 6-Phase Operational Cycle for Multi-Cloud Command Centres
"You cannot manage what you cannot see." — across 67 AWS accounts, most teams see 3.
One operations manager cannot manually log into 50+ AWS accounts to check resources, costs, and security findings. Manual discovery takes hours, misses resources (proven in real incidents), and produces no audit trail. This is the daily reality for ANZ regulated industries — FSI, Energy, Telecom, Aviation — where APRA CPS 234 requires a complete asset register and SOC2 CC6/CC7 demands evidence of timely remediation.
The Discovery Gap
In March 2026, a cross-validation of a 67-account Landing Zone revealed what manual discovery cannot:
- 108 EC2 instances across 16 accounts — discovered in under 60 seconds via Config Aggregator
- Previous per-account searches had covered 5 of 67 accounts and missed servers entirely
- $10,631 in EC2 costs over 3 months, with a 35% month-over-month decline invisible without org-wide Cost Explorer
The NARROW_SEARCH_SCOPE anti-pattern is not a tool problem. It is a methodology problem. Per-account search past three accounts is a signal that org-wide discovery is required. F2T2EA is the methodology that enforces this.
What is F2T2EA?
F2T2EA stands for Find, Fix, Track, Target, Engage, Access — a six-phase enterprise operational cycle for multi-cloud command centres.
Each phase maps to a specific set of tools, agents, and evidence artifacts. Together they form two interlocking loops:
FIND ──► TARGET ──► ENGAGE ← outer loop: strategic
│ │
▼ ▼
TRACK ◄── ACCESS ◄── FIX ← inner loop: tactical
The outer loop (FIND → TARGET → ENGAGE) handles strategic prioritisation: what do we have, what matters most, who needs to know. The inner loop (FIX → ACCESS → TRACK) handles tactical execution: remediate, provide access, measure improvement.
Phase Breakdown
| Phase | Purpose | Tools | Evidence Produced |
|---|---|---|---|
| FIND | Discover resources, costs, and security findings across all accounts | Config Aggregator, Resource Explorer (AGGREGATOR index), Cost Explorer, Security Hub | tmp/inventory/ec2-inventory.json, cost CSVs |
| FIX | Remediate top-priority issues with dry-run validation and approval gates | runbooks CLI (--dry-run flag), HITL approval | Remediation logs, before/after diffs |
| TRACK | Monitor DORA metrics, cost trends, and SLO compliance continuously | dora.csv, SQLite, /metrics:update-dora | DORA snapshots, cost trend charts |
| TARGET | Prioritise remediation candidates using WSJF scoring and scream-test methodology | WSJF scoring matrix, ec2-scream-test skill | Priority queue, scream-test scorecards |
| ENGAGE | Generate persona-based reports and stakeholder communications | Executive summary templates, email generator | CFO/CTO/CloudOps/FinOps reports, email.txt |
| ACCESS | Provide interactive dashboards, analysis workbench, and self-service documentation | Vizro, JupyterLab, MkDocs | Published dashboards, runbooks docs site |
The 7 Integrated Components
F2T2EA is not a single tool. It is seven components working in sequence, each producing artifacts consumed by the next.
| Component | Role in F2T2EA | Phases |
|---|---|---|
| xOps | Sovereign AI command centre — orchestrates the entire cycle | All |
| runbooks | PyPI CLI engine with 160+ commands for discovery, remediation, and reporting | FIND, FIX, TARGET |
| runbooks docs | MkDocs knowledge base — self-service reference for every command | ACCESS |
| JupyterLab | Analysis workbench for cost modelling and ad-hoc investigation | TARGET, TRACK |
| Vizro | Interactive dashboards — cost trends, fleet health, security posture | TRACK, ACCESS |
| Executive Summary | Persona-based HITL deliverables (CFO/CTO/CloudOps/FinOps) | ENGAGE |
| Stakeholder communication — copy-paste ready for HITL | ENGAGE |
The pipeline is: runbooks CLI produces JSON → JupyterLab analyses → Vizro displays → Executive Summary frames for persona → Email delivers to stakeholder.
The 10 Constitutional Agents
Each F2T2EA phase has designated agents. The ten ADLC constitutional agents map across the cycle:
| Agent | Primary Phase | Responsibility |
|---|---|---|
| product-owner | All gates | Requirements, acceptance criteria, INVEST story validation |
| cloud-architect | FIND, TARGET | Architecture decisions, multi-account discovery strategy |
| meta-engineering-expert | FIND, ENGAGE | MCP cross-validation, AI-powered report generation |
| python-engineer | FIX, TRACK | runbooks CLI implementation, DORA pipeline |
| infrastructure-engineer | FIX, DEPLOY | IaC remediation, Terraform/CDK apply |
| qa-engineer | All gates | Test coverage, dry-run validation, evidence verification |
| security-compliance-engineer | FIND, TARGET | Security Hub integration, APRA/SOC2 evidence |
| observability-engineer | TRACK | MELT telemetry, DORA metrics, cost trend monitoring |
| kubernetes-engineer | ACCESS | Vizro and JupyterLab deployment on K3S |
| frontend-docs-engineer | ACCESS, ENGAGE | MkDocs site, Docusaurus, executive report formatting |
The key constraint: product-owner and cloud-architect coordinate first. Specialist agents execute only after coordination logs exist at tmp/<project>/coordination-logs/. This is not ceremony — it prevents the STANDALONE_EXECUTION anti-pattern that causes scope drift and contradictory evidence across a multi-account fleet.
Real Results: LZ Inventory Cross-Validation
The following results are from the March 2026 Landing Zone cross-validation — measured, not assumed.
Discovery Accuracy
| Method | Accounts Searched | Instances Found | Time |
|---|---|---|---|
| V1: Resource Explorer | 16 of 67 | 108 EC2 | 45s |
| V2: Config Aggregator | 16 of 67 | 108 EC2 | 52s |
| Match rate | — | 100% | — |
Cross-validation between two independent discovery methods at 100% accuracy satisfies the NARROW_SEARCH_SCOPE anti-pattern prevention rule: org-wide tools first, per-account search as P2 fallback only.
Cost Profile
| Period | EC2 Spend | Month-over-Month |
|---|---|---|
| Month -2 | ~$4,200 | — |
| Month -1 | ~$3,800 | -9% |
| Current | ~$2,631 | -31% |
| 3-month total | $10,631 | -35% overall |
The 35% cost reduction over three months was invisible without org-wide Cost Explorer queries. Per-account views showed account-level fluctuations but masked the fleet-wide trend.
Remediation Signal
- 0 removal candidates above threshold — the fleet is actively managed
- 4 persona reports generated automatically: CFO, CTO, CloudOps, FinOps
- Each report tailored: CFO gets cost trend and governance posture; CloudOps gets per-account instance table
Why F2T2EA Matters for Regulated Industries
APRA CPS 234
CPS 234 requires a complete information asset register. The FIND phase, executed via Config Aggregator org-wide queries, produces a defensible asset register across all accounts in a single run. Per-account manual discovery cannot satisfy this requirement at scale.
SOC2 CC6/CC7
CC6 (logical access) and CC7 (system operations) require evidence of security monitoring and timely remediation. The FIND → TARGET → FIX sequence produces:
- Security Hub findings aggregated across all accounts (FIND)
- Priority-ordered remediation queue with WSJF scores (TARGET)
- Dry-run logs and HITL approval gates before any change (FIX)
Audit Trail by Design
Every F2T2EA phase writes evidence to tmp/<project>/. The TRACK phase records DORA metrics per sprint. The ENGAGE phase produces dated, persona-stamped reports. An auditor can reconstruct the complete operational history from the evidence directory.
Cost Governance at the CFO Level
The ENGAGE phase generates a CFO report that presents cost trends, governance posture, and fleet health in non-technical language. This closes the gap between CloudOps operational data and C-suite decision-making — without requiring the CFO to log into Cost Explorer.
Getting Started
The /xops:f2t2ea-cycle command executes the full cycle from a single invocation:
# Full cycle — all 6 phases, all 7 components, all 10 agents
/xops:f2t2ea-cycle
# Phase-specific entry point
/xops:f2t2ea-cycle --phase find
/xops:f2t2ea-cycle --phase engage --persona cfo
The command delegates to the appropriate specialist agents, collects evidence into tmp/, and surfaces HITL decision points before any remediation action executes.
For the runbooks CLI engine that powers the FIND and FIX phases:
# Install
pip install runbooks
# Org-wide EC2 discovery
runbooks inventory ec2 --all-accounts --output json
# Cost Explorer — 3-month trend
runbooks finops cost-by-account --months 3 --output table
Documentation for all 160+ commands is available at the runbooks MkDocs site (ACCESS phase).
The Single Principle Underneath
F2T2EA is built on one principle that the March 2026 cross-validation validated empirically:
Org-wide discovery tools first. Per-account search as fallback only.
Config Aggregator found 108 instances across 16 accounts in 52 seconds. Five sessions of per-account manual search had found 0 of those instances. The methodology matters more than the tooling.
The /xops:f2t2ea-cycle command enforces this principle at every phase — not as documentation, but as executable governance.
ADLC tracks F2T2EA cycle evidence via tmp/<project>/ artifacts. See the ADLC command reference for the full command catalogue.
Cross-validation results: tmp/cloudops/inventory/lz-cross-validate-2026-03-22.json | ADLC Framework v3.7.2