docs: present AI strategy as a diagram-first story

docs/strategy/index.mdx

@@ -3,11 +3,28 @@ id: index
 title: AI adoption strategy
 description: Govern skills first; outcomes before activity; explicit target status.
 slug: /
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## How do we reach dependable AI-assisted work?
+
+Start with governed skills, then widen coordination only when evidence supports it. The destination is one logical SDLC coordinator alongside people using qualified local coding agents.
+
+<ArchifyDiagram name="strategy-journey" title="Skills and quality evidence precede wider coordination" story />
+
+- **Skills first:** reusable working knowledge, not permission to act.
+- **People stay accountable:** the six departments and eleven teams keep their decisions.
+- **Outcomes before activity:** quality, risk and total cost determine whether to continue.
+
+<details>
+<summary>Strategy rationale and reading map</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 ### Govern skills first, expand authority only with evidence
@@ -30,4 +47,8 @@ Success means accepted outcomes with maintained quality, controlled risk and und
 - [Skills maintenance](./skills-maintenance.mdx) — Review, drift, deprecation, rollback and incident handling.
 - [Roadmap](./roadmap.mdx) — Evidence-gated phases, no promised dates or budgets.
 
+</details>
+
+**Next:** [See how people, skills and delivery controls connect →](./target-operating-model.mdx)
+
 </div>

docs/strategy/measurement.mdx

@@ -2,11 +2,30 @@
 id: measurement
 title: Measurement
 description: Full KPI contracts, minimal events, illustrative calculations, privacy and limits.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## Is AI-assisted work worth continuing?
+
+Judge accepted outcomes alongside quality, delivery flow, risk, cost and human experience. Validate source coverage before calculating; missing evidence is unknown, not success.
+
+<ArchifyDiagram name="strategy-measurement" title="Collect evidence, validate it, calculate balanced measures and decide" story />
+
+**Illustrative only:** 1 accepted task ÷ 4 matured starts × 100 = **25%** confirmed success. One unresolved task stays in the denominator; known-outcome coverage is **75%**. These are synthetic data, not Eldorado results.
+
+- **16 contracts:** exact definitions below; 9 prototype calculations, 7 explicitly unimplemented metrics.
+- **Balanced evidence:** no productivity rankings, composite score or causal ROI claim.
+- **Privacy first:** no raw prompts or code by default; protect small cohorts and agree retention before collection.
+
+<details>
+<summary>Collection, baseline, event and privacy contracts</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 ### Decide what counts before counting
@@ -33,6 +52,11 @@ Many-to-many task/attempt/skill/client associations preserve exact immutable ver
 
 The privacy starting proposal is 30 days for raw structured analytics events and 12 months for aggregated trends, subject to the responsible owners' review. Keep the approved catalog/approval record for the supported revision's lifetime and its required audit period, which must be decided separately. Incident evidence uses a restricted, explicitly authorized hold and deletion schedule, not an indefinite analytics exception. Suppress reports below five people and prohibit drill-down or overlapping cohort slices that reconstruct identities. Five is a proposed minimum, not a guarantee against re-identification. No raw prompts, code, screens, customer cases or secrets are collected by default. Publish the purpose, lawful collection basis, access/deletion route and retention before collecting. Consent is not presumed to be an appropriate employment-law basis.
 
+</details>
+
+<details>
+<summary>All 16 KPI contracts — formulas, populations, owners and limits</summary>
+
 ## Metric contracts
 
 Each contract is a prospective collection design. No live source or observed baseline is established. N and D refer to the numerator and denominator shown for that metric.
@@ -341,6 +365,11 @@ Independently accepted domain outcomes against a predeclared business rubric, se
 | Gaming and limits | Weaken rubric or count drafts as customer benefit; lock rubric and independently audit acceptance. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Domain owner signs acceptance: Operations service accuracy; Marketing claims/rights; Finance reconciliation accuracy; HR policy correctness; Product usability/value. Not revenue uplift. |
 
 
+</details>
+
+<details>
+<summary>Run the nine-metric synthetic prototype and inspect omissions</summary>
+
 ## Run the synthetic measurement example
 
 **Executed synthetic example — not Eldorado results.** The bundled fixture produces 1 independently accepted task from 4 matured starts: 25% confirmed success. One unresolved task remains in that denominator; known-outcome coverage is 75%. Selection precision and recall are each 1 / 2 = 50%. Allocated synthetic cost is EUR 60 / 1 accepted outcome = EUR 60 per accepted outcome. These deliberately small samples demonstrate arithmetic and missingness, not a baseline, target or ROI claim.
@@ -349,4 +378,8 @@ From the private documentation checkout, run `node scripts/ai-kpi.mjs` and `node
 
 The executable covers validated success, selection precision/recall, change fail and rework rates, escaped quality, policy effects, cost and human experience. Other catalog metrics remain contracts rather than implemented collectors; output lists the omissions. Snapshot inputs are simplified, pre-reconciled records, not a production ingestion system. Conflicting duplicates reject the calculation rather than silently choosing a value.
 
+</details>
+
+**Next:** [Use findings to maintain, quarantine or replace skills →](./skills-maintenance.mdx)
+
 </div>

docs/strategy/roadmap.mdx

@@ -2,11 +2,28 @@
 id: roadmap
 title: Roadmap
 description: Evidence-gated phases, no promised dates or budgets.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## What must be true before widening the rollout?
+
+Advance by exit evidence, not promised dates or usage volume. Each stage can hold, narrow or stop; changed client, data or authority boundaries reopen earlier gates.
+
+<ArchifyDiagram name="strategy-roadmap" title="Foundation, pilot, reliable distribution, coordination and departmental expansion have exit gates" story />
+
+- **Start bounded:** named people, lawful data handling and a reproducible baseline precede the pilot.
+- **Prove recovery before coordination:** verified versions, revocation and human takeover are prerequisites.
+- **Expand by department:** accepted outcomes, guardrails, total cost and experience justify continuation; sensitive decisions remain human.
+
+<details>
+<summary>Stage-by-stage entry evidence, work, exit gates and hold conditions</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 ### Foundation
@@ -51,4 +68,8 @@ description: Evidence-gated phases, no promised dates or budgets.
 
 There are no invented launch dates, budgets, staffing commitments or guaranteed gains. Phase gates permit narrowing or stopping. Re-evaluate earlier phases when the underlying client, provider, data scope or authority changes.
 
+</details>
+
+**Next:** [Return to the strategy destination →](./index.mdx)
+
 </div>

docs/strategy/skills-adoption.mdx

@@ -2,11 +2,28 @@
 id: skills-adoption
 title: Skills adoption
 description: Workflow-led coaching, client choice, feedback, manual path.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## When should a pilot become a team workflow?
+
+Expand only when a bounded canary produces independently accepted work and useful feedback. Teach people to verify artifacts and recover without AI, not merely invoke a skill.
+
+<ArchifyDiagram name="strategy-adoption" title="Choose a workflow, coach a canary, verify outcomes and improve before expansion" story />
+
+- **Team-led:** the departmental owner defines the outcome; People &amp; Administration Squad supports learning.
+- **Choice within support:** qualify the client path instead of promising identical agent behavior.
+- **No adoption quotas:** retain a manual path; rejected suggestions and non-use are feedback, not poor performance.
+
+<details>
+<summary>Onboarding responsibilities, coaching and feedback safeguards</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
@@ -17,4 +34,8 @@ Use short worked examples, peer pairing, office hours and a clear catalog search
 
 No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
 
+</details>
+
+**Next:** [Measure accepted outcomes, not activity →](./measurement.mdx)
+
 </div>

docs/strategy/skills-governance.mdx

@@ -2,11 +2,28 @@
 id: skills-governance
 title: Skills governance
 description: Contract, lifecycle, decision rights, adapters, locking, exceptions.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## Who can approve a skill for use?
+
+The owning team authors the skill; independent reviewers assess it before exact-revision approval. Data &amp; AI maintains the catalog, while Platform &amp; IT verifies distribution and revocation.
+
+<ArchifyDiagram name="strategy-governance" title="An owner proposes; independent review and canary evidence precede approval" story />
+
+- **Separate duties:** the author cannot provide the only approval; higher risk involves Architecture &amp; Security.
+- **Pin the whole bundle:** content, adapters and executable dependencies travel together.
+- **Keep controls authoritative:** exceptions expire and cannot bypass protected release, payment or identity controls.
+
+<details>
+<summary>Ownership, client qualification, exceptions and rollback</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 ### A contract that travels, controls that stay authoritative
@@ -33,6 +50,11 @@ A cached verified bundle may support explicitly permitted low-risk work if its m
 
 Rollback restores the approved manifest and dependencies, invalidates affected sessions, revokes unsafe revisions, runs a smoke test and verifies effective state. It cannot undo data disclosure or commands already executed. Those require incident response.
 
+</details>
+
+<details>
+<summary>Catalog contract — required fields</summary>
+
 ## Catalog contract
 
 | Contract | Definition |
@@ -59,6 +81,11 @@ Rollback restores the approved manifest and dependencies, invalidates affected s
 | procedure | Prerequisites, bounded steps, expected artifacts, verification, failure handling, escalation |
 
 
+</details>
+
+<details>
+<summary>Lifecycle transitions and required evidence</summary>
+
 ## Promotion and retirement
 
 | Transition | Required evidence |
@@ -70,4 +97,8 @@ Rollback restores the approved manifest and dependencies, invalidates affected s
 | any active state → quarantined | Incident or unsafe/unknown provenance; central deny immediately |
 | quarantined → experimental | Reviewed correction; new immutable revision; requalify, never auto-restore approval |
 
+</details>
+
+**Next:** [See the evidence needed to qualify a skill →](./skills-quality.mdx)
+
 </div>

docs/strategy/skills-maintenance.mdx

@@ -2,11 +2,28 @@
 id: skills-maintenance
 title: Skills maintenance
 description: Review, drift, deprecation, rollback and incident handling.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## What happens when a skill drifts or causes harm?
+
+Monitor usefulness and safety throughout a revision's life. Unsafe behavior triggers containment; a correction returns through independent tests and approval, never automatic reinstatement.
+
+<ArchifyDiagram name="strategy-maintenance" title="Monitor, triage and test corrections; promote safely or contain and roll back" story />
+
+- **Named ownership:** Data &amp; AI coordinates catalog health with the owning teams.
+- **Early triggers:** incidents and client, model or dependency changes override the calendar.
+- **Recovery is verified:** rollback restores a known-good bundle; it cannot undo disclosure or past effects.
+
+<details>
+<summary>Review responsibilities, incident handling and proposed review intervals</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 Every approved skill has an accountable owning team, independent reviewer, review due date, supported client matrix and rollback bundle. Review both usefulness and safety, not just metadata freshness. Proposed maximum review intervals are recorded by risk tier; incidents, dependency changes, model/client drift or repeated failures trigger earlier review.
@@ -25,4 +42,8 @@ Owner ratification is required before adoption. Review earlier after incidents o
 | R2 | 60 |
 | R3 | 30 |
 
+</details>
+
+**Next:** [Use exit evidence to choose the next rollout stage →](./roadmap.mdx)
+
 </div>

docs/strategy/skills-quality.mdx

@@ -2,11 +2,28 @@
 id: skills-quality
 title: Skills quality
 description: Risk tiers, independent evaluation, repeated trials, adversarial conformance.
+hide_table_of_contents: true
 ---
 
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## What evidence is enough to promote a skill?
+
+Risk determines the evaluation depth, not whether safety checks apply. Independent evidence must show useful outcomes and no failed mandatory gate before promotion.
+
+<ArchifyDiagram name="strategy-quality" title="Classify risk, test independently, then pass every mandatory gate" story />
+
+- **R1:** approved nonsensitive drafting. **R2:** code or customer-impacting material. **R3:** privileged or sensitive effects; human-authorized, outside initial autonomous scope.
+- **No averaging away harm:** a critical unauthorized effect blocks promotion.
+- **Proposed floors need owner ratification:** missing coverage or acceptance rules means qualification is incomplete.
+
+<details>
+<summary>Evaluation design, adversarial cases and interpretation</summary>
+
 **TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
 
 Quality has four separate questions: was the right skill selected, was the procedure executed safely, did the artifact pass independent checks, and did the workflow produce useful outcomes? A successful invocation answers none of the remaining questions by itself.
@@ -21,6 +38,11 @@ Include adversarial repository text, malicious referenced code, wrong permission
 
 Report denominators, task mix, trial counts, per-client results and uncertainty. A passing benchmark is evidence within a tested envelope, not proof that all future tasks are safe. Material model, client, adapter or dependency changes trigger requalification.
 
+</details>
+
+<details>
+<summary>Proposed R1 / R2 / R3 sample sizes and thresholds</summary>
+
 ## Proposed qualification floors
 
 These are local design defaults for responsible-owner ratification, not approved service levels or guarantees. All mandatory checks must pass regardless of aggregate score.
@@ -57,4 +79,8 @@ These are local design defaults for responsible-owner ratification, not approved
 
 Artifact success denominator is every planned executed trial, retaining failures and abandonment. Trials of same task are correlated: show per-task and per-client strata; do not inflate independent sample size. Selection floors use independent labels. Report 95% uncertainty intervals clustered by task for outcome comparisons; no regression versus current approved path beyond a preregistered owner-approved margin. Missing margin/precision rule prevents promotion.
 
+</details>
+
+**Next:** [Introduce qualified skills through a bounded pilot →](./skills-adoption.mdx)
+
 </div>

docs/strategy/target-operating-model.mdx

@@ -2,12 +2,28 @@
 id: target-operating-model
 title: Target operating model
 description: One logical coordinator; local client choice; independent authority; all departments.
+hide_table_of_contents: true
 ---
 
 import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## Who coordinates, and who can authorize delivery?
+
+One logical coordinator routes work; people retain authority. Local agents propose changes, while independent CI and human approval govern what the release service can execute.
+
+<ArchifyDiagram name="strategy-target" title="People authorize; skills guide; independent gates protect release" story />
+
+- **Local choice:** Copilot, Claude Code and Cline use qualified adapters and pinned skills.
+- **Central controls:** neither laptops nor the coordinator hold production credentials.
+- **Existing organization:** six departments, eleven teams; Data &amp; AI owns coordination, not their decisions.
+
+<details>
+<summary>Trust boundaries, recovery and detailed delivery path</summary>
+
 ## Coordination without transferred authority
 
 The diagram is an overview; the equivalent delivery path below remains readable on narrow screens. Expand the diagram to inspect its trust boundaries and use its zoom controls for individual relationships.
@@ -38,6 +54,11 @@ The registry distributes reviewed immutable content and adapters, not ambient cr
 
 Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.
 
+</details>
+
+<details>
+<summary>Responsibilities and first workflows for all eleven teams</summary>
+
 ### Department contributions
 
 ### Product / Product Management
@@ -110,4 +131,8 @@ Product keeps two teams; Technology keeps five; the other four departments keep
 
 See the existing [organization structure](/organization/structure/), [department collaboration](/organization/collaboration/) and [SDLC responsibilities](/organization/sdlc/).
 
+</details>
+
+**Next:** [Decide who owns and approves each skill →](./skills-governance.mdx)
+
 </div>