🔍 P5Y — 5 Whys Analyser

The complete blueprint: purpose, workflow, reasoning, data, and deployment.

1. Purpose

P5Y is a sparring partner for EMEA PFHO/SCR root-cause dive deeps. When a commitment is missed, it pulls the build's real context, examines every aspect of the build, and asks critical "why" questions until the cause is a process gap rather than a symptom. The guiding rule (per the EMEA 5 Whys mechanism): attack the process, not the people — individual error is never accepted as a root cause.

2. The dive-deep workflow

Name the build; P5Y pulls DCBM live state + 5 Whys history + Lessons Learned.
It surfaces all investigation threads visible on the build.
The investigator picks a thread; P5Y asks one critical "why" at a time.
It classifies each answer and pushes back on shallow / blame / external answers.
The investigator confirms the root cause (P5Y never declares it).
Actions are captured (owner · partner team · ETA · scale).
P5Y synthesises the multi-thread conclusion: Issues | Impact | Lessons Applied To | Next Steps.

3. Reasoning — the layer ladder

Every answer is classified onto a five-layer ladder; the questioning logic uses the result to decide the next move.

Layer	Meaning
Event	The observable outcome (always Why 1).
Mechanism	How it happened — the direct causal step.
Gap	A missing control / process / verification.
Systemic	Why the gap exists at an organisational level.
Root cause	The enabling structure, named explicitly.

Push-back rules

Individual blame → process: "names a person — what process should have caught this?"
External condition → preparedness: "the shortage is a condition — why no forecast / buffer?"
"Assumed / trusted" → verification: "what was the independent check?"
Shallow chain: at Why 3+, nudge toward the organisational layer.

A rule-based reasoner runs first as the resilient baseline; a Bedrock classifier (same schema + flags, with few-shot examples) refines it when available. If the model is unreachable, P5Y falls back to the rule-based reasoner — it never stops reasoning.

4. Looking at all aspects

P5Y mines the DCBM path_to_green and customer_impact narratives, milestone dates, change reasons, and prior 5 Whys sessions into ordered threads, e.g.:

Power / MV switchgear LV switchgear QA/QC ACS configuration Corp network turn-up NEA → H2C SLA Schedule / MR / float

It connects them — e.g. an upstream delay that consumes management reserve so later slips hit MR directly and sequentially.

5. Data sources

Source	Use
DCBM consolidated snapshot (S3)	Live build state, milestones, change reasons
5 Whys 2022–2026 (S3)	Historical Why-chains / precedent retrieval
Lessons Learned register	Cross-build patterns
Colo scorecards · Intercepts · ROMP/COLP builds	Milestone & delivery reference

A structured SQLite index serves fast FBN lookups; a ChromaDB vector store powers semantic precedent retrieval.

6. Deployment & security

FastAPI backend + static SPA, containerised, on Fargate behind an internal ALB.
Reached via CloudFront (VPC origin, so the ALB stays private) + a password gate.
● AWS WAF (managed rules + per-IP rate limit) and access logging on.
Read-only against all shared data; least-privilege task role; defined in CDK.

P5Y · EMEA DC Delivery Ops · generated specification page. Behaviour, data, and security posture reflect the live deployment.