docs: [verified] answer the six-month AI Architect assignment

docs/strategy/roadmap.mdx

@@ -1,7 +1,7 @@
 ---
 id: roadmap
 title: Roadmap
-description: Build proven skills in human and AI Agent work, starting with Delivery, as the foundation for the future autonomous SDLC.
+description: Proposed month-by-month work, capacity, dependencies and decisions for a solo AI Architect.
 hide_table_of_contents: true
 ---
 
@@ -9,35 +9,45 @@ import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
-## Two stages toward Target
+## Six months, two investment decisions
 
-<ArchifyDiagram name="strategy-roadmap" title="Adopt skills → Future Autonomous Agent" story />
+<ArchifyDiagram name="strategy-roadmap" title="Proposed months 1–4: learn and test; months 5–6: retain or stop, then hand over" story />
 
-**Humans direct, guide and review throughout.** Stage 1 standardizes skills in human + AI Agent work across the SDLC. Proven skills, measurements and working practices become the foundation for Stage 2: the future Autonomous Agent in [Target](./target-operating-model.mdx).
+**Humans direct, guide and review throughout.** This is a proposed plan, not an agreed schedule or budget. The first decision funds one bounded experiment; the second retains, changes or stops it before any transfer. The [six-month strategy](./target-operating-model.mdx) starts with existing uneven AI-assisted practice, not zero adoption. A Target operating model is only a conditional long-term reference.
 
-Target operating model—not deployed autonomy, an agreed schedule or approved KPI thresholds. Stage 1 is useful in its own right; Stage 2 requires a separately justified change in authority, not graduation for using enough skills.
+**Month 1 — Discover and earn trust.** I agree CTO expectations, access and a monthly decision meeting; meet team leads, pair with developers and reviewers across contrasting workflows, and trace recent changes. Output: current-work map, AI/tool/data constraints, evidence gaps and ranked bottlenecks. Dependency: willing access to real work. Decision: select a problem, or continue targeted discovery rather than prescribe skills.
 
-## Stage 1: Delivery first
+**Month 2 — Agree one experiment.** I recruit one willing team and an independent reviewer, observe a prospective baseline and compare context, coaching, test/review feedback, deterministic automation and skills. Output: the [experiment packet](./stage-01-skills-adoption.mdx), effort cap, acceptance rules and stop date. Dependency: team lead agrees contributions; actual risk/approval owners clear the boundary. No partner, reliable checks or lawful evidence means no live pilot.
 
-<ArchifyDiagram name="strategy-roadmap-adoption" title="Delivery first → Other SDLC phases, order undecided" story />
+**Month 3 — Work beside the team.** I build and qualify the smallest intervention, pair on bounded changes and collect outcomes plus burden. Output: reproducible examples, failure cases and weekly evidence review. Dependency: independent qualification and explicit pilot permission, not tool installation. Stop unsafe work immediately; fix friction before asking others to adopt.
 
-Start with Delivery, then extend skills adoption to the remaining SDLC phases. Their order is not yet decided. **Delivery keeps improving as adoption expands.**
+**Month 4 — Compare and choose.** I reconcile matured tasks, defects, review effort, costs and concurrent changes with the reviewer. Output: retain/change/hold/stop recommendation to the workflow owner and CTO. Dependency: comparable matured tasks and reconciled sources. Low task supply or missing follow-up means inconclusive, not success. Only an approved time-and-budget-bounded extension may continue; otherwise narrow or stop.
 
-## Improve within each phase
+**Month 5 — Transfer selectively.** If value and burden are acceptable, I pair with a voluntary champion and backup and test a second willing team's fit. Output: a team-owned example, support/recovery instructions and a new-scope baseline. Dependency: team capacity and funded upkeep. If absent, improve the first workflow or retire it; no organization-wide training mandate.
 
-<ArchifyDiagram name="strategy-roadmap-loop" title="Each phase: understand → baseline → topology → use → collect → reassess → repeat" story />
+**Month 6 — Handover and CTO evidence review.** I verify that the team can operate without daily architect help and present outcomes, limits, costs and stopped work. Output: an owned retained workflow or documented stop, plus a prioritized next-quarter proposal. Dependency: independent evidence and actual owner acceptance. The CTO decides the next investment, not an automatic autonomy phase.
 
-Repeat this loop within every phase—not as six global roadmap stages. Skills topology defines **what skills exist, how they relate, when they are used and how they work together**, including handoffs—not just a catalogue.
+## Delivery first, replication only if earned
 
-## Delivery in practice
+<ArchifyDiagram name="strategy-roadmap-adoption" title="One willing Delivery team → a separately agreed transfer, or stay and improve" story />
 
-**Understand the engineering path first:** codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Inspect actual practices, tooling, controls and problems with the people doing the work, rather than assuming the documented process is the real one.
+**Delivery keeps improving** whether transfer happens or not. The order of any other workflows is not yet decided. I bring concrete examples to skeptical teams, ask what creates extra work, and accept non-participation. A skeptic can help judge a demo without joining a pilot. If priorities conflict, I ask the CTO for a trade-off, not a compliance escalation.
 
-**Establish the comparison, then engineer skills.** Select relevant metrics/KPIs and a baseline for comparable work before changing it. [Measurement](./measurement/index.mdx) supplies optional definitions; [Baseline](./baseline.mdx) records the actual starting position or gaps. Connect skills to the engineering path, with clear triggers, dependencies and acceptance checks; [Quality](./skills-quality.mdx) qualifies the candidate before bounded real use.
+## Keep one learning loop
 
-**Use, collect, compare, repeat.** A human works with an AI Agent on real changes. Collect results, friction and feedback alongside quality, cost and verification effort. Compare with the baseline to understand the new current situation; retain, improve, stop or propose expansion. Changed revisions return to qualification; changed workflows need a fresh comparison.
+<ArchifyDiagram name="strategy-roadmap-loop" title="Understand current AI work → baseline → choose intervention → bounded pilot → evidence → retain, change or stop" story />
 
-Follow the **illustrative Delivery workflow** in [Stage 01](./stage-01-skills-adoption.mdx): prepare a bounded code change and regression tests, then hand the exact artifact to independent review. Its dependency diagram shows what passes between activities and who decides whether work can progress. Governance and Measurement support the whole loop; they are not one-time gates.
+Repeat the learning loop, not a predetermined tool rollout. If skills are selected, their topology defines what skills exist, how they relate, when they are used and how they work together. Simpler context, coaching or deterministic fixes do not require a skills catalog.
+
+## Solo capacity and influence
+
+Proposed weekly allocation during pilots: two days hands-on pairing/building, one day evaluation/evidence, one day coaching and relationships, and one day sponsor decisions, support and contingency. One active live pilot at a time; a second team starts only after the first is supportable. This is a capacity envelope, not known company availability.
+
+Ask a partner lead to agree a small pairing slot and independent review time explicitly; record actual effort, not assumed free team labor. Agree a short weekly team check-in and monthly CTO review of evidence, blocked dependencies, spend and the next choice. Seek specialist security/privacy advice only where the selected boundary requires it; preserve independent checks without appointing a committee.
+
+Trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Repair critical acceptance/data gaps before live use. Publish short reusable examples and offer office hours; don't become a permanent help desk for more than ten teams. Escalate support demand as an investment choice, never hide it in apparent savings.
+
+Follow the **illustrative Delivery workflow** in [the experiment packet](./stage-01-skills-adoption.mdx). Its diagram and worked decision keep benefit, burden and safety connected. [Measurement](./measurement/index.mdx) supplies optional definitions; [Baseline](./baseline.mdx) records actual starting evidence. Governance and Measurement are supporting references, not one-time gates.
 
 <details>
 <summary>Readiness questions behind the roadmap</summary>
@@ -54,7 +64,7 @@ Inventory actual client hosts/builds, provider/data terms, authority and event a
 
 Close critical gaps such as exposed secrets, unclear approval authority or unreliable acceptance checks. Broader refactoring and non-critical debt can run alongside the selected work. Stage 1 introduces no new privileged autonomous actions.
 
-### Engineer and evaluate connected skills
+### If skills are the chosen intervention
 
 Use a small registry, immutable skill contracts, qualified client adapters, evaluations and coaching. Verify the measurement calculations with synthetic fixtures before interpreting real outcomes. Require mandatory safety checks, independent task acceptance, reconciled source coverage and user feedback. Hold or narrow scope if quality or coverage is inadequate; usage alone does not justify expansion.
 
@@ -64,12 +74,12 @@ Prove canary updates, effective-version readback, version locking, exception exp
 
 Use evidence to choose the next SDLC phase; no second or third phase is assigned here. Continue the improvement loop in Delivery and every phase already using skills.
 
-### Prepare for the future Autonomous Agent
+### Consider autonomy only as a separate future option
 
-Stage 2 builds on proven skills, measurements and working practices—not permission inferred from adoption alone. [Stage 02](./stage-02-autonomous-agent.mdx) owns the separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
+Beyond six months may mean deeper coaching, deterministic tooling or no expansion. If additional autonomous authority solves an evidenced problem, [future options](./stage-02-autonomous-agent.mdx) require a separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
 
 </details>
 
-**Next:** [Stage - 01 - Skills Adoption →](./stage-01-skills-adoption.mdx)
+**Next:** [Work through one bounded experiment →](./stage-01-skills-adoption.mdx)
 
 </div>