delivery-presentation

name	delivery-presentation
description	Build a client-facing HTML slide deck (Soapbox marketing brand, clickable slides + fullscreen) to present ANY deliverable — decarb plan, RSRA, portfolio analysis, retrofit plan, GRESB submission. v2 = the INITIAL PRESENTATION (open items expected, revisions collected); a 'final presentation' variant will follow. v2.0.0

Delivery Presentation — Initial Presentation

Turn a deliverable into the deck for the FIRST client walkthrough. This is the initial presentation: open items and pending decisions are expected, and the deck's job is to surface them and collect revisions — not to declare the work finished. (A separate 'final presentation' deck type will exist later for the post-revision close-out; do not improvise one.)

The deck's purpose (drives every slide)

1. Familiarize the client with the asset.
2. Talk through methodology — and highlight assumptions and unknowns.
3. Talk through what we found.
4. Evaluate options — scenarios side by side, tradeoffs explicit.
5. Collect additional feedback — the deck ends by asking for it.

When to use

• First delivery of any engagement deliverable; gate reviews / interim readouts.

How it renders

Same client-render path as all named reports:

fill_report(artifact_id, template: 'delivery-presentation', data: { deck: {...}, slides: [...] })

REVISIONS ARE DATA-ONLY — this is a hard rule. To change a rendered deck, call fill_report(same artifact_id, template, updated_data) with the new JSON payload and NOTHING else. NEVER save_file a hand-built deck, and NEVER hand-edit the inlined template HTML or reproduce its markup / chart / waterfall renderers — the template (fetched fresh from GitHub on every fill_report) owns all layout and rendering. Hand-rebuilding is what mangles charts, drops blocks like the value bridge, and reintroduces overflow; it also bypasses template fixes (a baked artifact does NOT pick up template updates — only a re-fill_report does). You only ever touch the data payload. Same discipline as the decarb render gate — see [[decarb-plan-workflow]].

Persist the payload so revisions have a source of truth: at first render, save_file the deck JSON to Reports/<asset-slug>-deck.data.json. To revise, read that JSON, edit it, re-fill_report with the edits, and overwrite the .data.json. (This is the ONLY report-related thing save_file touches — the data payload, never rendered HTML.)

Title and Agenda slides are AUTO-GENERATED — never author them. Fixed section order (the template groups slides regardless of array order):

Background → Methodology → Assumptions & Questions → Results → Revisions & Next Steps

Contract: templates/delivery-presentation/schema.json; worked example: example-data.json. Block types: bullets, stats (tiles; accent: true = dark-gradient money tile, max ONE per slide), table, bars, questions (chips: open/resolved/adjudicated — rendered client-side as Open / Resolved / Confirmed), quote, two_col, waterfall (value-bridge SVG), trajectory (time-series carbon SVG — BAU vs planned vs CRREM 1.5°C vs BPS target line).

⚠ EXTERNAL DELIVERABLE — no internal-process language. The deck goes to external parties (owners, lenders, buyers) with no context for our internal workflow. Never write "Gate 1/2", "adjudicated", "verifier", "Confirmed finding ", "P0–P5", "phase N", "locked at gate", or "roster" in any slide text, chip note, subtitle, or table cell. Phrase provenance in client terms ("confirmed with the owner", "per the AEI energy audit"). "Expert-in-the-loop" is allowed brand voice; the internal machinery behind it is not.

Slide plan (client-locked, learned from the Westminster pilot)

Section	Slides
Background	Asset profile ONLY (stat tiles + key facts). NO "why now"/motivation slide.
Methodology	One slide: the process actually run, "expert-in-the-loop" voice (never "human-in-the-loop").
Assumptions & Questions	Confirmed assumptions (chips) + open unknowns (chips) — this drives the meeting discussion.
Results	1) Measure/finding list (table) → 2) Stacking logic / why this order → 3) Carbon trajectory (trajectory block: BAU vs planned vs CRREM 1.5°C vs BPS/Reg-28 line — the emissions outcome over the hold) → 4) Value bridge (waterfall) → 5) Incentives — the actual programs (table: real program names, per-unit/per-ton rate, $ to this asset, status; e.g. Xcel ASHP rebate, DRCOG Power Ahead, §48E ITC) → 6) The Decision, combined with results tradeoffs (scenario stat tiles ≥2 plans side-by-side + what each choice trades away). NO capital-stack slide. Scope-boundary slide ("what this doesn't do") may follow.
Revisions & Next Steps	LAST slide = Action items: no dates/urgency columns; each item exists to clear an open question from the Assumptions slide; the final item is always "Collect desired revisions to this plan and report."

Layout rules (template enforces, but author to fit)

• Stat tiles lay out on a balanced grid (3-up for 5–6 tiles). Keep bullet blocks to ≤5 items — the most important ones; the template auto-shrinks to fit but overflow-by-density is an authoring failure.
• No orange text on green surfaces (the accent money tile number is white). Orange stays on paper surfaces.

Density & voice rules

• Limited verbosity, high impact: ≤6 bullets/slide, ≤12 words/bullet; split rather than cram.
• Visual where relevant: stats/waterfall/table over prose; one idea per slide.
• Fiscally sound: every number carries its basis inline ("5.35% exit cap", "vs 10% hurdle").
• Present ≥2 scenarios where applicable; make the tradeoff explicit on the Decision slide.
• Numbers not yet through verification are marked "Interim". Title/subtitle should say "Initial presentation" so no one mistakes it for the final.
• 6–12 content slides for a full delivery; 4–6 for a gate review.

Sourcing discipline

Build slides FROM the verified engagement artifacts (state ledger, final report payload, verifier findings) — never re-derive or fabricate numbers. Reuse the report's fill_report data object as the source of truth and summarize down. Chart blocks (waterfall) must carry the SAME numbers as the report's charts.