-**Human + AI Agent → proven skills and working practices → future Autonomous Agent.**
+Improve one workflow through human + AI Agent work, then repeat with evidence. This is the practical first stage of the [Roadmap](./roadmap.mdx), not permission to deploy the autonomous [Target](./target-operating-model.mdx).
-This first stage of the [Roadmap](./roadmap.mdx) standardizes skills in real human + AI Agent work. It builds the foundation for [Target](./target-operating-model.mdx), while people direct the work, verify outcomes and improve the skills.
+
-## Delivery first
+**Read the arrows as handoffs, not a checklist of page approvals.** Governance bounds every activity. Measurement supplies selected definitions throughout. Quality establishes candidate fitness; Adoption tests usefulness in real work; Maintenance returns failures and changed conditions to qualification.
-Start with the engineering path: codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Understand actual practices, tooling, controls and problems before changing them.
+## Delivery first: one change, from intent to accepted work
-Adoption then extends to other SDLC phases; their order is not yet decided. Delivery keeps improving as adoption expands.
+**Illustrative Delivery workflow throughout these pages — not an Eldorado pilot or measured result:** a Product Engineering developer uses an AI Agent to prepare a bounded code change and regression tests. An independent reviewer checks the exact change and evidence. Existing release authority remains unchanged; the skill cannot approve or deploy its own output.
-## Repeat within each phase
+First trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Identify the friction to improve—for example, incomplete regression evidence that sends changes back for rework. Verify that this is the actual problem before choosing a skill.
-**Understand the current situation → select relevant KPIs and establish a workflow baseline → engineer skills topology → use skills in real work → collect agreed metrics and feedback → understand the new current situation → repeat.**
+Adoption can extend to other SDLC phases; their order is not yet decided. Delivery keeps improving as adoption expands.
-Skills topology connects what skills exist, how they relate, when they are used and how they work together. Compare accepted outcomes, quality, cost and review effort with the baseline; use friction and feedback to revise the skills and working practices. These are repeating steps within each phase, not additional roadmap stages.
+## Carry evidence forward, not assumptions
-## Put the foundation into practice
+1. **Understand and baseline.** Product Engineering maps the selected workflow and desired improvement. Select relevant KPIs from [Measurement](./measurement/index.mdx); [Baseline](./baseline.mdx) records current outcomes, acceptance rules and explicit gaps. A baseline describes work; it grants no approval.
+2. **Engineer a connected candidate.** Under [Governance](./skills-governance.mdx), connect repository understanding → change/test preparation → independent verification. Specify triggers, inputs, outputs, handoffs, pinned dependencies and forbidden actions. This skills topology is more than a catalogue.
+3. **Qualify before exposing real work.** [Quality](./skills-quality.mdx) compares candidate, current-approved and no-skill paths on declared cases. The independent Quality Engineering reviewer accepts evaluation evidence; the owning team's designated approver authorizes only the tested pilot envelope, with Architecture & Security review where risk requires it. Failed checks or missing authority mean rework or hold, not an automatic pilot.
+4. **Pilot and compare.** [Adoption](./skills-adoption.mdx) applies that revision to a bounded real-work cohort, retaining the manual path. Compare accepted outcomes, quality, review/rework cost and feedback with the starting position. Live tasks and qualification trials remain separate populations.
+5. **Decide and maintain.** The owning team's designated workflow owner decides retain, improve, stop or propose expansion from the comparison and independent evidence. [Maintenance](./skills-maintenance.mdx) keeps retained revisions supported and feeds defects into requalification. A new scope returns to Baseline; a changed revision returns to Quality. The new current situation starts the next loop.
-- [Measurement](./measurement/index.mdx) — distinguish Workflow effectiveness from Skills effectiveness & health; candidate inclusion does not require collection or baselining.
-- [Baseline](./baseline.mdx) — understand current workflow outcomes first, select relevant metrics and record feasible starting evidence or explicit gaps; absent skills are not zero performance.
-- [Governance](./skills-governance.mdx) — define ownership, authority and approval of skills.
-- [Quality](./skills-quality.mdx) — qualify skills and verify their outcomes before wider use.
-- [Adoption](./skills-adoption.mdx) — compare workflow outcomes and observe skill use separately, with a supported client and a manual path.
-- [Maintenance](./skills-maintenance.mdx) — monitor both tracks to improve or retire skills, control versions and recover from unsafe updates.
+These are recommended responsibilities within existing teams, not appointed people or already approved controls. Before work starts, record the actual accountable person, independent reviewer, acceptance rules and permitted effects. Missing assignments keep the affected decision on hold.
-Proven skills, measurements and working practices support [Stage - 02 - Autonomous Agent](./stage-02-autonomous-agent.mdx); adoption alone does not grant autonomous execution authority.
+
+Where each topic helps—and what it gives the next activity
-These six topics belong to Stage 01, not six additional roadmap stages. Establish a baseline per workflow as adoption reaches it—not a mandatory company-wide baseline of every registry metric.
+| Topic | Use it when | Carry forward |
+| --- | --- | --- |
+| [Measurement](./measurement/index.mdx) | Choosing or interpreting evidence at any point | Relevant contracts for Workflow effectiveness and Skills effectiveness & health; no mandatory full catalogue |
+| [Baseline](./baseline.mdx) | Understanding a workflow or a material scope change | Workflow map, selected definitions, evidenced starting position or gaps |
+| [Governance](./skills-governance.mdx) | Designing, approving, distributing or withdrawing any revision | Named accountability, authority envelope and exact-revision decision record |
+| [Quality](./skills-quality.mdx) | Introducing or changing skills, clients, models or dependencies | Versioned evaluation results, failures, limits and independent recommendation |
+| [Adoption](./skills-adoption.mdx) | Introducing a qualified candidate into bounded work | Comparable outcome report, user feedback and retain/improve/expand/stop decision |
+| [Maintenance](./skills-maintenance.mdx) | Keeping a supported workflow dependable | Reviewed revision, regression cases, recovery evidence or retirement |
-**Next:** [Browse the Measurement registry →](./measurement/index.mdx)
+The six topics are connected lifecycle activities, not six rigid sequential approval gates. The sidebar is a reading map: you can consult Measurement before, during or after any activity.
+
+
+
+Proven skills and working practices may support [Stage - 02 - Autonomous Agent](./stage-02-autonomous-agent.mdx). Stage 01 can remain valuable indefinitely; progression requires a separate case for authority and readiness.
+
+**Start here:** [Understand and baseline one workflow →](./baseline.mdx). Consult the [Measurement registry](./measurement/index.mdx) when selecting evidence.
-**Proven skills and measured practices → future Autonomous Agent → human-directed SDLC.**
+**A separate authority decision, not the reward for skills adoption.**
This future stage of the [Roadmap](./roadmap.mdx) builds on [Stage - 01 - Skills Adoption](./stage-01-skills-adoption.mdx). The destination is [Target](./target-operating-model.mdx): an Autonomous Agent that executes and governs the SDLC cycle, with humans retaining direction and review.
+
+
## Build on what has been proven
Carry forward proven skills, measurements and working practices from real human + AI Agent work. The skills foundation provides [governance](./skills-governance.mdx), [quality checks](./skills-quality.mdx), [adoption feedback](./skills-adoption.mdx), [measurement](./measurement/index.mdx) and [maintenance](./skills-maintenance.mdx); it is not permission to expand authority automatically.
## Introduce authority deliberately
-Establish reliable observation and evidence assembly, then proposing and routing work, before granting scoped execution authority. The Roadmap describes recommended controls and hold conditions, including exact-artifact approvals, independent review, recovery and human takeover. Sensitive decisions remain human; missing evidence never means permission.
+Establish reliable observation and evidence assembly, then proposing and routing work, before granting scoped execution authority. In the **illustrative Delivery workflow**, preparing a patch under human supervision does not authorize the central agent to merge or deploy it. A proposal must explain which extra operation is needed, why Stage 01 is insufficient, the exact resources/data it may touch and how humans can stop it.
+
+The owning department's designated accountable approver decides the proposed workflow scope, with Architecture & Security accepting the authority/data boundary, Quality Engineering independently assessing behavior and Platform & IT verifying enforcement and recovery. These are recommended functions within existing teams—not appointed approvers or granted permissions. Unresolved release approval roles remain a hold condition; the agent cannot appoint its own authority.
+
+Require exact-artifact approvals, separated credentials, independent checks, idempotency and duplicate/outage recovery, an auditable task ledger, and a tested stop/human-takeover path outside the model. Sensitive decisions remain human; missing evidence never means permission. A readiness failure returns to [Stage 01](./stage-01-skills-adoption.mdx) or redesign; it does not justify a larger experiment.
+
+The output is either a recorded hold or a narrowly scoped authorization with conditions and invalidation rules. Monitor outcomes and authority violations separately. A material boundary change reopens the decision; harmful behavior revokes mutation authority and activates takeover, feeding evidence back into [Quality](./skills-quality.mdx) and [Maintenance](./skills-maintenance.mdx).
This is future direction, not deployed autonomy, agreed delivery dates or approved KPI thresholds. The transition depends on reviewed evidence and explicit authority decisions, not adoption volume alone.
+**Return to dependable work:** [Continue the Stage 01 improvement loop →](./stage-01-skills-adoption.mdx).
+