Preliminary Design Review (PDR) deck

The problem this solves

PDR prep eats weeks of senior engineering time on slides instead of engineering. Numbers get pulled by hand from four places, margins go stale between draft and review, and the gaps only surface in the room, when a reviewer asks the question nobody prepared for.

How it works

Preliminary Design Review deck with mission context, architecture, and open items.

You are generating a Preliminary Design Review (PDR) presentation for
the system modeled in [model name] in Dalus. A PDR is judged against
review criteria, not a table of contents: your job is to assemble the
evidence the model holds against those criteria and to be explicit
about what it does not hold.

DELIVERABLE: a PowerPoint file (.pptx), 16:9, generated and delivered
as a downloadable file. Not slide content in chat, not markdown, not
an outline. If you cannot produce the file, say so instead of
substituting text. Before building anything, load the
presentation-creation skill available in this environment and follow
it. Build the deck programmatically, then render it to images and
look at every slide before delivering.

SOURCES, resolve in this order before anything else:
1. If the user has uploaded a program or customer PDR template, deck,
   or gate checklist, it governs slide order, agenda and appearance.
   Follow it exactly and map model content into its slides.
2. Otherwise use the review framework the user names, or ask in the
   single question below. Supported flavors:
   - NASA NPR 7123.1 and the NASA SE Handbook: default. Both are
     freely available US Government works; if a copy is attached,
     derive the PDR entrance and success criteria directly from it
     and cite them.
   - ECSS: PDR as defined in the ECSS project management standard,
     with the review data package assembled from the applicable
     DRDs. Freely available from ecss.nl.
   - IEEE 15288.2 for US defense technical reviews. This is paid
     content; use it only if a copy has been made available, and note
     that use of licensed standards with AI tooling is subject to the
     user's licence terms. MIL-STD-1521B may be used as a reference
     agenda only, stating that it is cancelled and is not the
     governing authority.
3. Cite criteria numbers only when reading them from a document
   actually present. With nothing attached, refer to criteria by name
   and state on the title slide that criteria references were omitted
   because the source text was not present. Never cite from memory.

READ THE MODEL fully: part hierarchy, connections with ports, flows
and variable units, requirements with IDs, statements, attributes,
rationale, status, allocation and parent/satisfy relationships,
verification items, test cases and the requirements they reference,
states, modes, mission cases, hazards with mitigations, trade studies
with their criteria and outcomes, budget-bearing attributes (mass,
power, data rate, thermal) and any Actions that compute rollups.

READ-BACK, always, before generating. Report:
- requirement counts reconciled into (a) complete statements,
  (b) grouping records with no shall statement, (c) empty or
  placeholder records, summing to the model total;
- verification coverage, interface completeness (flows carrying
  placeholder or zero values count as incomplete), budget
  availability and whether margins can be computed;
- a CRITERIA COVERAGE ASSESSMENT: each PDR entrance criterion of the
  chosen framework marked Evidenced by the model, Partially
  evidenced, or Not evidenced, with one line each;
- what the model cannot evidence and the program must supply
  (typically schedule, cost, staffing, procurement, manufacturing
  approach, heritage data);
- the two or three structural problems the reviewer will see flagged
  rather than fixed.
Then ask exactly ONE question combining: which review framework
applies, how long the review slot is (which sets the slide budget),
and the program name, review date and presenter for the title slide.
If the user replies "fast", use NASA, a 60 minute slot, and mark
title fields as to be completed.

DECK STRUCTURE, in this order unless a template dictates otherwise:
1. Title: program, system, review, date, presenter, model name and
   ID, DRAFT status.
2. Agenda.
3. Purpose and scope of the review, and the criteria being assessed.
4. Criteria coverage summary: the assessment from the read-back as a
   single readable slide. This is the honesty slide and it stays.
5. Mission and operational context: from mission cases, actors,
   external interactions.
6. Requirements baseline: counts by type and status, changes since
   the last baseline if the model or an uploaded prior deck allows
   the comparison, and the requirements that drive the design.
7. Requirement compliance status: rolled up per subsystem, with
   unverified and failing requirements called out rather than
   averaged away.
8. Preliminary design baseline: architecture, subsystem breakdown,
   and how the design answers the driving requirements.
9. Interfaces: external first, then internal, with flows and units.
   Interfaces carrying placeholder values are shown as open.
10. Trade studies and design decisions: options considered, criteria,
    outcome, and what remains open.
11. Budgets and margins: mass, power, and any other rollup the model
    supports, each against its allocation with margin stated. If a
    rollup Action exists, use its result and name it. If margins
    cannot be computed, say why rather than showing a bare total.
12. Verification and validation approach: planned methods, coverage
    against the requirement set, and the test cases that exist.
13. Risks and hazards: with mitigations, severity where recorded, and
    hazards lacking mitigations called out.
14. Open items and actions: everything unresolved, ordered by what
    most endangers passing the review.
15. Program content the model does not hold: a single explicit slide
    listing what the program must add (schedule, cost, procurement,
    manufacturing readiness, staffing), never fabricated.
16. Summary and request for approval to proceed.
17. BACKUP: generated from the model, one section each for the full
    requirement list, interface detail, budget detail, trade study
    detail, and hazard detail, so questions from the floor are
    already answered in the pack.

SLIDE RULES:
- One idea per slide. Never more than about six bullets or twelve
  table rows on a main slide; anything longer goes to backup with a
  pointer from the main slide.
- Every number carries its unit and its source (model element, or the
  Action that computed it).
- Never present a rolled-up percentage without the underlying counts.
- Statements and IDs verbatim from the model; never silently
  rewritten.
- Speaker notes on every content slide: what the presenter should say,
  and the likely question with its answer where the model supports
  one.
- Respect the slide budget implied by the review length: roughly one
  main slide per minute of technical discussion, with the remainder
  in backup.

CONSISTENCY CHECKS across the model, reported on an issues slide in
backup and summarized in open items:
- requirement against requirement: contradictions, inverted logic,
  overlapping scope;
- requirement against model attributes: units and magnitudes, mass
  against limits, power against budgets;
- suspected truncation, broken parent or satisfy links, orphan
  requirements, unconnected ports, hazards without mitigations.

GAPS: never invent values, margins, dates, costs or verification
results to fill a slide. A slide with no model content states what is
missing and what must be added to the model to populate it.

OUTPUT QUALITY, non-negotiable:
- One .pptx file, 16:9, consistent slide master, slide numbers, and
  the program name in the footer.
- Title slide and section dividers formatted distinctly from content
  slides. Tables styled, not raw. Body text no smaller than 14pt.
- No text overflowing its placeholder, no clipped or truncated
  tables, no empty placeholders, no author instructions or TODO text
  anywhere in the deck.
- Speaker notes populated on every content slide.
- If the user supplied a program template or a prior deck, build on
  that file's slide master so the output matches their house style.
- MANDATORY before delivering: render the finished .pptx to images
  and visually inspect every slide. Check specifically the title
  slide, the criteria coverage slide, the densest table slide, one
  chart if present, and one backup slide. Fix any overflow, clipping
  or empty slide and re-render until clean.
- Deliver the .pptx file itself, plus a short summary in chat of what
  the deck covers, which criteria came back not evidenced, and what
  the program still has to supply. The summary supports the file, it
  does not replace it.
- This workflow only reads the model; it writes nothing back. After
  delivering, offer (do not execute) turning the open items and gaps
  into tracked tasks.

Replace the [bracketed] placeholders with your model and project names.

Example output

What you get

Common questions