initial version

2026-03-18 18:03:44 -03:00
commit 9d269e902b
136 changed files with 28175 additions and 0 deletions
--- a/docs/define-phase.md
+++ b/docs/define-phase.md
@@ -0,0 +1,90 @@
+# DEFINE Phase — Detailed Guide
+
+The DEFINE phase identifies the customer's business problem and builds commitment to solve it. Output: a scoped **Value Story** and a **Joint Engagement Plan**.
+
+## Steps
+
+### 1. Ideate
+
+Create a value hypothesis expressed in the customer's business terms — not Oracle features.
+
+**Inputs:**
+- Discovery notes (unstructured)
+- Customer's public filings, strategy docs, press releases
+- Industry patterns from `kb/patterns/business-patterns.yaml`
+- Business Drivers Framework from `kb/patterns/business-drivers.yaml`
+
+**Activities:**
+- Build Customer Profile (`templates/customer-profile.yaml`) — strategic goals, Oracle footprint, industry analysis
+- Build Strategy Map (`templates/strategy-map.yaml`) — goals → strategies → capabilities → enablers
+- Parse discovery notes into structured Workload Profile
+- Identify 1-3 business drivers using the four pillars (Strategic, Financial, Business Ops, IT Ops)
+- Formulate 1+ Points of View, evaluate each against SMART criteria
+- Select the strongest PoV as the value hypothesis
+- Cross-reference with `kb/patterns/application-patterns.yaml` for proven solutions
+- Map to hypothesis family from `kb/patterns/business-drivers.yaml`
+
+**Output:** Customer Profile + Strategy Map + Draft Value Story (`templates/value-story.yaml`)
+
+**ECAL Artefacts:** See `kb/patterns/ecal-artefacts-catalog.yaml` DEF-01 through DEF-06
+**Engagement RACI:** See `kb/patterns/engagement-raci.yaml` define.ideate
+
+### 2. Validate
+
+Test the hypothesis against the customer's reality.
+
+**Activities:**
+- Review value story for SMART criteria (Specific, Measurable, Attainable, Relevant, Time-based)
+- Identify gaps in discovery data — list what we assumed vs. what we confirmed
+- Check: Is the hypothesis bold enough? Is there enough urgency?
+- Validate technical feasibility against `kb/services/` and `kb/compatibility/`
+
+**Validation checklist:**
+```
+- [ ] Business driver clearly identified and quantifiable
+- [ ] Desired outcome is SMART
+- [ ] Technical feasibility confirmed (no blockers in feature matrix)
+- [ ] Customer sponsor identified
+- [ ] Urgency driver exists (EOL, contract, compliance deadline, competitive threat)
+```
+
+**Output:** Validated Value Story with confidence flags
+
+### 3. Plan
+
+If the hypothesis is compelling, create a Joint Engagement Plan for the DESIGN phase.
+
+**Activities:**
+- Define engagement tier (small/standard/complex) — see [engagement-tiers.md](engagement-tiers.md)
+- Timebox the DESIGN phase (typically 2-6 weeks)
+- Identify resources needed (SA, specialists, customer stakeholders)
+- Define success criteria for the DESIGN phase itself
+
+**Output:** Joint Engagement Plan (`templates/joint-engagement-plan.yaml`)
+
+## Engagement Tier Selection
+
+The tier determines artifact depth. Select based on:
+
+| Signal | Small | Standard | Complex |
+|--------|-------|----------|---------|
+| # Applications | 1-2 | 3-10 | 10+ |
+| Compliance | None | 1 framework | Multiple |
+| Regions | 1 | 1-2 | 3+ |
+| Integration points | 0-2 | 3-5 | 5+ |
+| Budget sensitivity | Low | Medium | High |
+| Timeline | < 4 weeks | 4-12 weeks | 12+ weeks |
+
+See [engagement-tiers.md](engagement-tiers.md) for full tier definitions and artifact mapping.
+
+## Iterative Checkpoint
+
+Before moving to DESIGN, verify:
+```
+- [ ] Value Story approved by architect (and ideally customer sponsor)
+- [ ] Workload Profile has < 3 critical gaps
+- [ ] Engagement tier selected
+- [ ] Joint Engagement Plan agreed (timebox, resources, success criteria)
+```
+
+If the value story isn't compelling, iterate: refine the hypothesis or pick another one.
--- a/docs/deliver-phase.md
+++ b/docs/deliver-phase.md
@@ -0,0 +1,107 @@
+# DELIVER Phase — Detailed Guide
+
+The DELIVER phase ensures an efficient handover from pre-sales to implementation and tracks value realization. These are **lightweight artifacts** — the SA does not replace the implementation team.
+
+> ECAL DELIVER describes the solution implementation at high level. It provides just enough guidance and templates to deliver. It dovetails with the customer or implementation partner framework (e.g., Oracle Consulting True Cloud Method).
+
+## Steps
+
+### 1. Adopt
+
+Ensure a clean handover so the implementation team doesn't rework previous steps.
+
+**Activities:**
+- Produce Handover Document (`templates/handover-document.yaml`)
+  - Summarizes all DEFINE + DESIGN artifacts in one place
+  - Lists key decisions made and their rationale (from ADRs)
+  - Identifies open items and assumptions to verify
+- Define MVP scope
+  - What ships in Phase 1 vs. later phases
+  - Prioritize by customer value, not technical convenience
+  - Example: "Phase 1: migrate core OLTP to ADB-S with local HA. Phase 2: activate cross-region DR. Phase 3: modernize reporting with ADW."
+- Establish governance
+  - Steering committee cadence (bi-weekly for standard, weekly for complex)
+  - Escalation path
+  - Change control process
+
+**Output:** Handover Document + MVP Definition
+
+**Guidelines:**
+- Look for a Minimum Viable Product that delivers real customer benefits early
+- Incremental delivery phases should maximize customer value per the roadmap
+- Consider how to help the customer with adoption and ownership
+
+### 2. Operate
+
+Define what "running well" looks like after go-live.
+
+**Activities:**
+- Produce Go-Live Checklist (`templates/go-live-checklist.yaml`)
+  - Pre-go-live verification items
+  - Monitoring and alerting confirmation
+  - Runbook availability
+  - Rollback readiness
+- Define Success Criteria (`templates/success-criteria.yaml`)
+  - Quantitative metrics tied to the Value Story
+  - Example: "P95 latency < 15ms", "Monthly cost < $X", "Zero unplanned downtime in first 90 days"
+  - Measurement method and cadence
+- Operational handover
+  - Confirm ops team has access and training
+  - Validate monitoring dashboards are active
+  - Confirm backup/recovery has been tested
+
+**Output:** Go-Live Checklist + Success Criteria
+
+**Guidelines:**
+- Regular governance checks should continue beyond go-live
+- Data must be collected to validate business outcomes
+- Results should be reported back to the business sponsor
+
+### 3. Improve
+
+Capture learnings and validate value delivery.
+
+**Activities:**
+- Produce Lessons Learned (`templates/lessons-learned.yaml`)
+  - What worked well (reuse in future engagements)
+  - What didn't work (improve process or templates)
+  - Suggestions for ECAL/skill improvements
+- Value realization check (30/60/90 days post go-live)
+  - Compare actual metrics against Success Criteria
+  - Determine if the original hypothesis from DEFINE delivered value
+  - Identify next hypothesis to tackle
+- Feed improvements back
+  - Update `kb/field-knowledge/` with new findings
+  - Update patterns if architecture evolved during delivery
+  - Share customer success story if applicable
+
+**Output:** Lessons Learned + Value Realization Report
+
+**Guidelines:**
+- Grab any opportunity to capture a successful outcome as a customer story
+- Look back at every project for what you could do better
+- Keep in touch with the customer and track how the project is going
+- Share learnings with the team
+
+## Artifact Summary by Tier
+
+| Artifact | Small | Standard | Complex |
+|----------|-------|----------|---------|
+| Handover Document | 1-page summary | Full template | Full + appendices |
+| MVP Definition | Inline in handover | Separate section | Phased roadmap |
+| Go-Live Checklist | 10-15 items | 20-30 items | 30-50 items |
+| Success Criteria | 3-5 metrics | 5-8 metrics | 8-12 metrics |
+| Lessons Learned | Brief notes | Full template | Full + retro |
+
+## Iterative Checkpoint
+
+The DELIVER phase feeds back into DEFINE for next phases:
+```
+- [ ] Handover document complete and reviewed with implementation team
+- [ ] MVP scope agreed with customer
+- [ ] Go-live checklist validated (all items green)
+- [ ] Success criteria baselined (measurements started)
+- [ ] Lessons learned captured within 2 weeks of go-live
+- [ ] Value realization check scheduled (30/60/90 days)
+- [ ] Next hypothesis identified (return to DEFINE if applicable)
+```
--- a/docs/design-phase.md
+++ b/docs/design-phase.md
@@ -0,0 +1,132 @@
+# DESIGN Phase — Detailed Guide
+
+The DESIGN phase produces a complete, defensible architecture. Output: agreed architecture, cost estimate, operations model, and solution proposal.
+
+## Steps
+
+### 1. Current State (People, Process, Technology)
+
+Capture enough about the current state to architect the future. Frame the problem — don't gather exhaustive requirements.
+
+**Artefacts:**
+- Discovery Questionnaire (`templates/discovery-questionnaire.yaml`) — structured customer data collection
+- Business & Security Constraints — time, funding, legal, compliance, technology constraints
+- Current State Apps & Tech Portfolio — systems, assets, integrations
+- Prioritization Matrix — score apps by criticality, fit, potential, risk (in discovery questionnaire)
+- Current State Architecture — diagrams of current environment
+
+**Technology** (existing in Workload Profile):
+- Databases, compute, middleware, messaging, storage, networking, identity, integration
+- Use `config/workload-profile-schema.yaml` for field definitions
+
+**People** (new — added to Workload Profile):
+- Team size and roles (DBAs, cloud engineers, DevOps, security)
+- Skill gaps relevant to the proposed solution
+- Managed services preference (self-managed → fully managed)
+- Change management readiness (how resistant is the org to change?)
+
+**Process** (new — added to Workload Profile):
+- Deployment process (manual, CI/CD, IaC maturity)
+- Change management process (CAB, lightweight, none)
+- Incident response process (NOC, on-call rotation, outsourced)
+- Backup/recovery testing frequency
+
+**Guidelines:**
+- Frame the problem — don't gather exhaustive requirements
+- Be collaborative — share everything with the customer
+- Use whatever works — top-down and bottom-up
+- Understand business context, drivers, and desired outcomes
+- Be very clear about scope — which systems are in and out
+
+**ECAL Artefacts:** See `kb/patterns/ecal-artefacts-catalog.yaml` DES-01 through DES-09
+**Engagement RACI:** See `kb/patterns/engagement-raci.yaml` design.current
+
+### 2. Future State (Solution Design)
+
+Given the Workload Profile and Current State, compose a complete architecture. This step produces multiple design artifacts:
+
+#### Solution Design
+Core architecture composition — the existing Phase 2 workflow:
+1. Select services from `kb/services/`
+2. Dimension using `kb/sizing/` rules
+3. Compose topology from `kb/patterns/` blocks
+4. Estimate costs with explicit assumptions
+5. Validate against Well-Architected Framework (`kb/well-architected/`)
+
+#### Deployment Design
+How the solution gets built and deployed:
+- Environment strategy (dev, test, staging, prod)
+- IaC approach (Terraform, Resource Manager, Ansible)
+- CI/CD pipeline design
+- Non-production environment sizing (typically 50% of prod for test, 25% for dev)
+
+#### Transition Design
+How to get from current state to future state:
+- Migration strategy per component (lift-and-shift, re-platform, re-architect)
+- Migration tooling (DMS, GoldenGate, RMAN, Data Pump, ZDM)
+- Phased migration plan with dependencies
+- Parallel run requirements and cutover strategy
+- Rollback plan for each phase
+
+#### Operations Model
+How the solution will be operated day-to-day:
+- Use `templates/operations-model.yaml` as the artifact template
+- Monitoring and alerting strategy (OCI Monitoring, Logging Analytics, 3rd party)
+- Patching and maintenance windows
+- Backup and recovery procedures
+- Incident response and escalation
+- Capacity management and scaling triggers
+
+**Guidelines:**
+- Always look for a quick win the customer can see early
+- The operational model is just as important as the architecture
+- Don't forget non-production environments
+- Security and data locality must be understood early
+
+### 3. Confirm (Solution Proposal)
+
+Assemble all design work into a solution proposal for stakeholder decision.
+
+**Activities:**
+- Assemble the slide deck with all architecture artifacts
+- Prepare the business case: costs, benefits, timeline, risks
+- Ensure all propositions are SMART:
+  - **S**pecific: "Migrate 3 Oracle databases to ADB-S" not "Move to cloud"
+  - **M**easurable: "Reduce DB admin effort by 60%" not "Improve efficiency"
+  - **A**ttainable: Validated against feature matrix and field findings
+  - **R**elevant: Tied to the business driver from the Value Story
+  - **T**ime-based: "8-week migration" not "as soon as possible"
+- Include competitive positioning if relevant (`kb/competitive/`)
+
+**Output artifacts by tier:**
+
+| Artifact | Small | Standard | Complex |
+|----------|-------|----------|---------|
+| Slide deck (.pptx) | 6-8 slides | 10-12 slides | 12-15 slides |
+| Architecture diagram | Single-page | Single-page | Multi-page |
+| Cost estimate | In-deck table | Separate .xlsx | Detailed .xlsx |
+| ADRs | 2-3 inline | 4-6 in appendix | Full ADR docs |
+| Migration plan | 1 slide | 2-3 slides | Separate doc |
+| Operations model | In-deck summary | 1-page summary | Full template |
+| Risk register | Top 3-5 | Top 5-8 | Full register |
+| WA scorecard | Traffic lights | With recommendations | Full report |
+
+**Guidelines:**
+- Don't say anything you cannot back up with evidence
+- The roadmap must be achievable
+- Think about the person you are presenting to — what does it mean for them
+- Quality of the presentation matters — it must look professional
+
+## Iterative Checkpoint
+
+Before moving to DELIVER (or presenting to customer):
+```
+- [ ] Architecture validated against WA Framework (no critical gaps)
+- [ ] Cost estimate reviewed with explicit assumptions
+- [ ] Migration plan is achievable within stated timeline
+- [ ] Operations model addresses day-2 concerns
+- [ ] All propositions are SMART
+- [ ] Risk register has mitigations for all HIGH items
+- [ ] Feature compatibility checked (no blockers)
+- [ ] Field findings reviewed (no known issues unaddressed)
+```
--- a/docs/ecal-gaps-backlog.md
+++ b/docs/ecal-gaps-backlog.md
@@ -0,0 +1,133 @@
+# ECAL Gaps Backlog
+
+Items identified from ECAL 3.1 Practitioners Guides (01-09) + Big Bets Banking Example PDF that are **not yet implemented** in the KB. Prioritized by impact.
+
+## Priority 1 — High Impact (next sprint)
+
+### B1. Integration Catalog Template
+- **Source**: ECAL 05 FUTURE, slide 23
+- **What**: Table of all non-OOTB integrations with data flows, volumes, frequency
+- **Why**: Directly affects architecture accuracy and implementation scope
+- **Action**: Create `templates/integration-catalog.yaml` with fields: use_case, source, target, method (API/file/DB link), protocol, data_volume, frequency, direction, owner
+
+### B2. Cloud Operating Framework (52-week plan)
+- **Source**: ECAL 08 OPERATE, slide 14
+- **What**: Detailed first-year operational plan covering all 9 operational capability areas
+- **Why**: Most customers have never operated cloud — this bridges the gap
+- **Action**: Create `kb/patterns/cloud-operating-framework.yaml` with 9 capability areas mapped to weekly cadence
+- **9 Capabilities**: Program Management, Cloud Innovation, Platform Enablement, Lifecycle Management, Environments Management, Testing, Management & Monitoring, Adoption & User Support, Issue Management
+
+### B3. OCI Operationalization Framework (5 milestones)
+- **Source**: ECAL 08 OPERATE, slide 15
+- **What**: 5-milestone methodology for deploying workloads to OCI
+- **Milestones**: Preparation & Training → Conceptual & Logical Arch → Physical Arch Execution → Operations → Specific Workloads
+- **Action**: Create `kb/patterns/oci-operationalization.yaml`
+
+### B4. POD (Pool of Databases) Pattern
+- **Source**: Big Bets PDF, p.23
+- **What**: Data platform pattern for large-scale DB consolidation
+- **Characteristics**: Self-contained granular unit, standard external connectivity, internally optimized for DB, designed for maintainability/longevity, no prescribed hardware, on-prem/hybrid/cloud
+- **Action**: Create `kb/patterns/database-consolidation-pod.yaml`
+
+### B5. Banking/Financial Compliance Pattern
+- **Source**: Big Bets PDF, pp.4,19,21
+- **What**: EBA, FCA, PRA, ISO 27001/27002, NIST CSF requirements mapped to OCI services
+- **Action**: Create `kb/compliance/banking-financial.yaml` with regulation → OCI service mapping
+
+## Priority 2 — Medium Impact
+
+### B6. Extension Catalog Template
+- **Source**: ECAL 05 FUTURE, slide 22
+- **What**: Custom extensions needed beyond OOTB Oracle products
+- **Fields**: Business capability, name, type, technology, developer (customer/partner/Oracle)
+- **Action**: Create `templates/extension-catalog.yaml`
+
+### B7. Business Transition Plan Template
+- **Source**: ECAL 07 ADOPT, slide 22
+- **What**: Managing business change during technology transformation
+- **Covers**: Org change, process standardization, policy alignment, value measurement
+- **Action**: Create `templates/business-transition-plan.yaml`
+
+### B8. Training & Communication Plan Template
+- **Source**: ECAL 07 ADOPT, slide 23
+- **What**: Training delivery plan + project communication plan
+- **Action**: Create `templates/training-communication-plan.yaml`
+
+### B9. Project Governance Template
+- **Source**: ECAL 07 ADOPT, slide 25
+- **What**: Governance framework: steering committee, change control, escalation
+- **Components**: Steering committee, solution authority, change control board, project board
+- **Action**: Create `templates/project-governance.yaml`
+
+### B10. Customer Success Story Template
+- **Source**: ECAL 09 IMPROVE, slide 14
+- **What**: Single-slide format: who, industry, challenges, approach, value, turning point
+- **Action**: Create `templates/customer-success-story.yaml`
+
+### B11. Contracts & Policy Review Checklist
+- **Source**: ECAL 07 ADOPT, slide 30
+- **What**: Review checklist for all agreements (cloud services, ULA, PULA, partner)
+- **Action**: Create `templates/contracts-review-checklist.yaml`
+
+### B12. Readiness Assessment Template
+- **Source**: ECAL 07 ADOPT, slide 31
+- **What**: Ensure project team has right skills, assets, infrastructure, processes
+- **Action**: Create `templates/readiness-assessment.yaml`
+
+## Priority 3 — Lower Impact (nice to have)
+
+### B13. PoC Joint Execution Plan Template
+- **Source**: ECAL 05 FUTURE, slide 43
+- **What**: Scope, approach, timeline, success criteria, use cases, test plans, ground rules
+- **Action**: Create `templates/poc-execution-plan.yaml`
+
+### B14. Information & BI Model Template
+- **Source**: ECAL 05 FUTURE, slide 24
+- **What**: Data flows, MDM, analytics/BI architecture view
+- **Action**: Create `kb/patterns/information-bi-model.yaml`
+
+### B15. Current State Process & Capability Map Guide
+- **Source**: ECAL 04 CURRENT, slide 17
+- **What**: Guidance for creating business architecture view of current state
+- **Note**: This is mostly a customer/BA activity — skill can provide structure
+- **Action**: Add guidance to `docs/design-phase.md`
+
+### B16. RFx Response Guide
+- **Source**: ECAL 06 CONFIRM, slide 14
+- **What**: Process for responding to RFI/RFQ/RFP
+- **Note**: Primarily sales/BD activity
+- **Action**: Add brief section to `docs/design-phase.md` Confirm step
+
+### B17. Commercial Agreement Guide
+- **Source**: ECAL 06 CONFIRM, slide 16
+- **What**: BYOL, ELA, PULA, Cloud Credits options and when to use each
+- **Action**: Enhance `kb/pricing/` with licensing model guidance
+
+### B18. TCM Alignment Mapping
+- **Source**: All ECAL guides — Consulting Guidance slides
+- **What**: Map ECAL artefacts to Oracle True Cloud Method (TCM) activities
+- **Action**: Add `tcm_alignment` field to ecal-artefacts-catalog.yaml
+
+### B19. ExaCC Managed Service Pattern
+- **Source**: Big Bets PDF
+- **What**: Complete pattern for ExaCC with ZDLRA, ZFS, OEM, OKV as managed service
+- **Action**: Create `kb/patterns/exacc-managed-service.yaml`
+
+### B20. Security Constraints Checklist
+- **Source**: ECAL 04 CURRENT, slide 15
+- **What**: Structured checklist for security requirements assessment
+- **Action**: Create `templates/security-constraints-checklist.yaml`
+
+---
+
+## Completed (this session)
+
+| Item | File Created |
+|---|---|
+| Engagement RACI (10 roles, all 9 steps) | `kb/patterns/engagement-raci.yaml` |
+| Discovery Questionnaire (with prioritization) | `templates/discovery-questionnaire.yaml` |
+| Business Drivers Framework (4 pillars + hypothesis families) | `kb/patterns/business-drivers.yaml` |
+| ECAL Artefacts Catalog (60 artefacts, skill support classification) | `kb/patterns/ecal-artefacts-catalog.yaml` |
+| Customer Profile Template | `templates/customer-profile.yaml` |
+| Strategy Map Template | `templates/strategy-map.yaml` |
+| Lessons Learned per step | Included in `engagement-raci.yaml` |
--- a/docs/engagement-tiers.md
+++ b/docs/engagement-tiers.md
@@ -0,0 +1,100 @@
+# Engagement Tiers
+
+Engagement tiers scale artifact depth to match engagement complexity. Not every deal needs a 15-slide deck and full ADR set.
+
+## Tier Definitions
+
+### Small (Rapid Innovation)
+
+**Profile:** Single workload, single region, minimal compliance, short timeline.
+
+**Examples:**
+- Autonomous Database + Analytics Cloud dashboard
+- Single app migration to OKE
+- PoC or pilot deployment
+
+**Characteristics:**
+- 1-2 applications in scope
+- No compliance frameworks
+- Single OCI region
+- 0-2 integration points
+- Budget < $10K/month
+- Timeline < 4 weeks design
+
+**Artifact depth:** Highly templated, minimal customization. The Value Story can be a single paragraph. The deck is 6-8 slides. No separate operations model — include a "Day-2" slide.
+
+### Standard (Extend Capabilities)
+
+**Profile:** Multi-component architecture, moderate complexity, typical enterprise engagement.
+
+**Examples:**
+- Oracle DB migration with HA/DR to ADB-S
+- Multi-tier application modernization
+- Hybrid cloud with FastConnect
+
+**Characteristics:**
+- 3-10 applications in scope
+- 1 compliance framework (PCI, SOC2, HIPAA)
+- 1-2 OCI regions
+- 3-5 integration points
+- Budget $10K-100K/month
+- Timeline 4-12 weeks design
+
+**Artifact depth:** Full template set. 10-12 slide deck. Separate cost spreadsheet. Operations model as 1-page summary. 4-6 ADRs.
+
+### Complex (Business Transformation)
+
+**Profile:** Enterprise-wide transformation, multi-region, multiple compliance, long timeline.
+
+**Examples:**
+- Full data center migration (50+ workloads)
+- Multi-cloud architecture with OCI as primary
+- Regulated industry platform (banking, healthcare)
+
+**Characteristics:**
+- 10+ applications in scope
+- Multiple compliance frameworks
+- 3+ OCI regions
+- 5+ integration points
+- Budget > $100K/month
+- Timeline 12+ weeks design
+
+**Artifact depth:** Full customized artifacts. 12-15 slide deck (possibly multi-deck). Full operations model. Detailed migration plan as separate document. Full risk register. Comprehensive WA report.
+
+## Artifact Matrix
+
+| Artifact | Small | Standard | Complex |
+|----------|-------|----------|---------|
+| **DEFINE** | | | |
+| Value Story | 1 paragraph | Full template | Full + executive summary |
+| Workload Profile | Minimal fields | Standard fields | All fields + appendix |
+| Joint Engagement Plan | Email/verbal | 1-page template | Full template |
+| **DESIGN** | | | |
+| Slide deck | 6-8 slides | 10-12 slides | 12-15 slides |
+| Architecture diagram | Single-page simple | Single-page detailed | Multi-page |
+| Cost estimate | In-deck table | Separate .xlsx | Detailed .xlsx with scenarios |
+| ADRs | 2-3 inline in deck | 4-6 separate | Full ADR documents |
+| Migration plan | 1 slide | 2-3 slides | Separate document |
+| Operations model | 1 "Day-2" slide | 1-page summary | Full template |
+| Transition design | Inline in migration | Separate section | Separate document |
+| Risk register | Top 3-5 in deck | Top 5-8 in deck | Full register document |
+| WA scorecard | Traffic lights only | With recommendations | Full WA report |
+| **DELIVER** | | | |
+| Handover document | 1-page summary | Full template | Full + appendices |
+| MVP definition | Inline in handover | Separate section | Phased roadmap |
+| Go-live checklist | 10-15 items | 20-30 items | 30-50 items |
+| Success criteria | 3-5 metrics | 5-8 metrics | 8-12 metrics |
+| Lessons learned | Brief notes | Full template | Full + retrospective |
+
+## Tier Selection Logic
+
+Select tier based on the **highest complexity signal**. If 8 out of 10 signals say "small" but compliance says "complex", use **standard** (not complex — let the single complex dimension drive up one tier, not two).
+
+```
+IF any signal is "complex" AND 2+ signals are "complex":
+  → Complex tier
+ELIF any signal is "complex" OR 3+ signals are "standard":
+  → Standard tier
+ELSE:
+  → Small tier
+```