The magic behind the NPI/CPI dashboard — explained without code · June 2026
Every card on the NPI/CPI dashboard is built from information that
already exists somewhere else — a Product Manager's status slide, or a Jira release plan.
Nothing is typed in twice, and nothing is published without a person approving it.
This page shows exactly which part of each source ends up where on a dashboard card.
Follow the numbered, colour-coded markers: a marker on the source (left) lands on the
matching marker on the card (right).
📊
1 · The PM's slide
PMs keep writing the same PowerPoint status slides they always have.
→
📝
2 · Claude drafts a file
Claude Code reads the slide and fills in a draft text file — one per project.
→
🧑💼
3 · A person approves
The operator reads the draft and approves it by renaming the file. No approval, no dashboard.
→
🖥️
4 · The dashboard
A small script turns the approved files into the cards you see — the same way every time.
The third step is the whole point: the human is the gate, the tools just save the typing.
From the PM's PowerPoint to a project card
This is a real status slide (project QA50, April 2026). The amber markers
show what gets read off the slide — and where each piece lands on the dashboard card.
Source — PowerPoint status slide
1234567
Where it lands — project card on the dashboard
1QA50Cascade control systemindustrialisation2on-trackPHO date, from MAB pres: W28Bertil
85%
5med
Owner: BertilMAB: 2026-06-21Updated: 2026-04-28
3Develop a control system for cascading commercial PHNIX monoblocks
Plan
4 Delivered since past report
QC pro manual is being reviewed now
QA50 manual is finalized
Launch plan compiled. Aligned with Q & industrialization
Design review completed
Handover to Bertil initiated
7Test series build2026-06
Compliance documentation2026-06
PHO meeting2026-07
Maturity
85%
Components
102 / 110
Sourcing
locked
6 Budget & end date
Approved
Actuals
LBV
Budget (kEUR)
—
—
—
End date
—
Apr 29
May 15
Faded fields (owner, MAB date, BOM maturity, sourcing…) are not on the slide —
they come from the project file, which the operator fills in. Chapter 3 shows that file.
1Slide title → project code and name in the card header
2The colour chip ("On track" / "Delayed") → the status chip on the card
3Project description → the card headline
4"Delivered since past report" bullets → the same list, verbatim, on the card
5"Key Issues" → the top-risk callout (and the risk chip in the header row)
6"Deviations vs budget and planned end date" grid → the budget & end-date mini-table
7"Next steps" → the next three milestones
From the MAB Product-Spec slide — the target PHO week
The MAB deck also holds one Product Spec slide per product
(below: QE-M from the May 2026 deck, rebuilt in HTML faithful to the real slide). The dashboard
reads the highlighted values — most importantly the line after Target PHO:.
Source — MAB Product-Spec slide
QVANTUM
QE-M
Product Spec
Product data
5New compressor unit for QE-4 and 6
R290 refrigerant
Backwards compatible
Designed for a modular installation (Split)
Prices for the AIO product
Target Net Installer Price
xx kSEK
Target installed price
xx kSEK
Target BOM
xx kSEK
Project data
Project leader
2Marcus Cederholm
Tech Lead
Estimated man years
xxxx
LT target volumes
4xxxx
Key markets/segments
3UK, DE, NL, SE
Target PHO:
12026 November
Certifications:
August
Resources secured
Y
Sign off from local PM’s
(N)
Where it lands — the QE-M card on the dashboard
QE-MNew compressor unit for QE-4 and 6development1PHO date, from MAB pres: W492Marcus Cederholm
Owner: Marcus Cederholm3UKDENLSE
5New compressor unit for QE-4 and 6 — R290 refrigerant, backwards compatible, designed for a modular installation (split).
LT vol target
4xxxx
The faded stage chip is not on the Product-Spec slide — it comes from
the project file, like everything else the operator fills in by hand.
1The value after "Target PHO:" → the week on the
collapsed row, "PHO date, from MAB pres: W49". An explicit week on the slide ("W28 2026",
"wk.22") is used as written; a bare month becomes the week of that month's last day
("2026 November" → 2026-11-30 → W49).
2Project leader → the card owner
3Key markets/segments → the market chips
4LT target volumes → "LT vol target" under Maturity
5First Product-data line → the card headline
From Jira to a software-release card
Software releases aren't typed in at all. A read-only connection asks Jira
for the release plans of the Display (QD) and App (QHA) teams — below, the real QHA Releases page.
The dashboard never writes anything back to Jira.
Source — Jira "Releases" page (read-only)
1234
Where it lands — SW-release card on the dashboard
SW1App 1.24.02Release: 2026-06-15
5%
Stream: AppRelease date: 2026-06-15Work items: 19
3 Work items — 1 of 19 done
Done
1
In progress
13
To do
5
1The release version number → the card title ("App 1.24.0")
2The planned release date → "Release:" on the card
3The work-item progress behind the bar → the done / in-progress / to-do counts and the percentage bar
4The "Unreleased" filter → the selection rule: only the two next upcoming open versions per team become cards, so the dashboard always shows what ships next
The file in the middle — and the human approval
Between the sources and the dashboard sits one plain text file per project.
It's the part anyone can open, read, and check — no Excel, no database, no code. Claude fills it
in from the slide; the operator completes the few fields slides don't carry (green markers) and
approves.
The project file — projects/qa50.txt
projects/qa50.txt
# QA50 — edit the value after each colon.
# Lines starting with # are ignored.project_code: QA50
project_name: Cascade control system
owner_pm: Bertil1stage: industrialisation
status_tag: on-track
headline: Develop a control system for
cascading commercial PHNIX monoblocks
milestone_1: Test series build | 2026-06
bom_maturity_pct: 852sourcing_status: locked3top_risk: Article release flow / process
risk_severity: med
delivered_since_past_report:
- QC pro manual is being reviewed now
- QA50 manual is finalized
The approval — a rename, done by a person
projects/draft-qa50.txt→ you read it → you rename it →projects/qa50.txt
1Owner, MAB date and a few other fields aren't on the slide — the operator types them once, here
2BOM maturity comes from the component tracking, not the slide
3Sourcing status likewise — the dashboard only accepts the exact words early / mid / locked, so wording stays consistent across all projects
Two safety nets are always on:
a file still named draft-… is invisible to the dashboard, and
every refresh first makes a dated backup of all project files and of the previous site.
A wrong word (say, "Concept" with a capital C) stops the render with a message naming the
file and line — it can't slip through silently.
Nothing reaches MAB without a person approving it
The slides stay the PMs' own. Claude only drafts; the operator approves by renaming;
a small, fixed script renders. Jira is read, never written. Every weekly refresh keeps a
dated backup of both the data and the previous dashboard — so any week can be compared with,
or restored to, the one before.
