PowerPoint

On this page

Document type: Internal briefing-author guide
Use for: Building Polyrhythm PowerPoint briefings from one selected Polyrhythm template
Primary templates: polyrhythm-template-powerpoint-dark.potx or polyrhythm-template-powerpoint-light.potx
Audience: Polyrhythm staff, technical leads, proposal/capture support, and partners building Polyrhythm-authored decks
Status: Working internal guide

1. Purpose

Use this guide to build clear, reviewable PowerPoint briefings that feel like Polyrhythm and use one selected template consistently.

A good Polyrhythm deck should:

Make the decision, problem, system boundary, or request clear.
Use one provided template consistently instead of designing slides from scratch or mixing themes.
Make complex systems legible without fake dashboards or visual theater.
Support claims with evidence, artifacts, caveats, or [Needs input] markers.
Sound senior, precise, technically credible, mission-literate, and calm under complexity.
Show software control, integration discipline, testability, security, evidence, and fieldability.

This is not a template-design guide. Do not use it to redesign the templates, create new brand motifs, or invent alternate slide systems. Use it to build good briefings with the templates Polyrhythm already provides.

2. The briefing standard

A Polyrhythm briefing should feel like a controlled technical review.

It should be:

Clear: The audience understands the point of the deck and the role of each slide.
Reviewable: Claims, assumptions, risks, and evidence can be checked.
Technically serious: Diagrams, labels, and terminology reflect real systems and constraints.
Field-aware: The deck connects software work to integration, test, security, change, and fielded behavior.
Restrained: The presentation looks premium without becoming cinematic, glossy, or theatrical.

It should not be:

An investor pitch deck.
A generic consulting deck.
A fake SaaS dashboard.
A prime-contractor weapons-glamour deck.
A pile of screenshots.
A dense report pasted into PowerPoint.
A collection of technical-looking shapes that do not communicate real structure.

3. Start with the briefing job

Before opening PowerPoint, write down the job of the briefing.

Question	Fill in before building slides
Audience	Who is receiving the deck? Executive buyer, prime, program office, technical evaluator, partner, candidate, internal team, or mixed audience?
Decision or action	What should the audience decide, approve, understand, review, or do next?
System or problem boundary	What system, interface, failure mode, capability, proposal section, or delivery path is in scope?
Top claims	What are the 2 to 4 claims the deck must prove or make clear?
Available proof	What artifacts, examples, diagrams, technical notes, past performance, approved facts, or source material can support the claims?
Missing proof	Which claims need `[Needs input]`, caveats, release review, or removal?
Distribution controls	Is a distribution, classification, customer, or release marking required?

If the deck cannot answer these questions, do not compensate with more slides. Clarify the briefing job first.

4. Recommended deck arcs

Short briefing: 8 to 12 slides

Use this for executive conversations, partner reviews, customer introductions, and focused technical briefings.

Title cover - What is this briefing and who is it for?
Problem or decision frame - What issue, failure mode, opportunity, or decision matters?
Briefing map - How the conversation will move.
System or context orientation - What boundary, interface, mission context, or delivery path matters?
Polyrhythm role or capability - What we do in this context.
Evidence path or integration flow - What supports the claim or shows the system logic.
Decision, recommendation, or implication - What the audience should conclude.
Risks and open assumptions - What remains unresolved.
Request or next gate - What happens next, who owns it, and what input is needed.

Longer technical or proposal deck

Use this for technical evaluation, proposal support, architecture review, or detailed partner materials.

Title cover - Establish the briefing subject, audience, date, and status.
Executive summary - State the decision, recommendation, or technical posture.
Thesis or briefing map - Show how the argument will move.
Architecture or system-orientation slide - Define the boundary, interface, delivery path, or system context.
Evidence/detail slide - Show the artifacts, assumptions, source notes, or verification path that support the point.
Technical or proposal detail slide - Explain the implementation, approach, risk, or evaluation material.
Control slide - Reset around a decision, tradeoff, risk disposition, or next gate.
Repeat detail sections as needed.
Appendix divider - Mark the transition to supporting material.
Registers, tables, standards maps, source notes, and supporting evidence.
Closing or request - End with one ask, owner, next gate, or decision path.

For longer decks, avoid more than three dense slides in a row. Insert a control slide every three to four dense slides to reset the audience around the decision, risk, or system boundary. Use the selected theme for every slide in the briefing.

5. Choose one theme for the briefing

Polyrhythm provides dark and light templates. Theme choice is a briefing-level decision, not a slide-level pacing device.

Pick one template before building the deck:

Use polyrhythm-template-powerpoint-dark.potx for a dark briefing.
Use polyrhythm-template-powerpoint-light.potx for a light briefing.

Do not mix dark and light layouts in the same briefing. A deck should use either the PR-DK layout family or the PR-LT layout family from start to finish.

Choose the dark template when the briefing is primarily:

An executive or partner conversation.
A capability introduction.
A thesis-led technical review.
An architecture or integration discussion.
A recruiting, thought-leadership, or field-note deck.
A short briefing where contrast and schematic structure help control attention.

Dark briefings still need evidence, tables, and detail when the story requires them. Keep those slides readable: simplify tables, split dense material across slides, use larger labels, and avoid long blocks of muted text on dark backgrounds. If the briefing will be dominated by registers, standards maps, or dense appendix material, choose the light template at the start.

Choose the light template when the briefing is primarily:

A proposal section.
A leave-behind.
A printed or PDF-forward deck.
A technical appendix.
A table-heavy, register-heavy, or standards-map-heavy deck.
Source-selection-safe or detail-heavy evaluator material.

Light briefings must still feel like Polyrhythm. Keep the structure evidence-oriented and technical: interfaces, caveats, review paths, decision records, schematic fields, and controlled use of Flare. Do not let the deck become a generic consulting presentation.

Good default pacing inside either theme

Pace the briefing by slide density and slide job, not by switching themes.

A strong sequence usually moves from cover, to decision frame, to briefing map, to system orientation, to evidence or detail, to decision or next gate. Sparse slides should reset attention. Dense slides should prove the point. Control slides should reconnect the audience to the decision, risk, or system boundary.

If a deck seems to need both dark and light slides, the problem is usually theme selection. Decide which use case controls the briefing and rebuild in that template. If the material truly needs two visual modes, create two separate deliverables: for example, a dark executive briefing and a separate light evidence appendix.

6. Layout chooser

Use the layout that matches the job of the slide. Do not start from blank slides unless the available layouts cannot support the content.

The table below uses [DK/LT] as shorthand. After choosing a theme, replace it with the selected layout prefix only:

Use PR-DK layouts in a dark briefing.
Use PR-LT layouts in a light briefing.

Do not combine PR-DK and PR-LT layouts in the same deck.

Template layout	Use for	Author guidance
`PR-[DK/LT]-00 Base Content`	Custom content	Use sparingly. Do not make this the default slide.
`PR-[DK/LT]-01 Title Cover`	Primary opening	Use for the main deck opening. Keep the title direct and metadata accurate.
`PR-[DK/LT]-02 Formal Cover`	Proposal or partner opening	Use when the deck needs a formal customer, partner, or proposal posture.
`PR-[DK/LT]-03 Capability Statement`	One-capability leave-behind	Use for a capability that can be reviewed as a work product, not a sales slogan.
`PR-[DK/LT]-04 Briefing Map`	Agenda and navigation	Use to show how the conversation will move. Keep section labels specific.
`PR-[DK/LT]-05 Section Divider`	Topic shift	Use to reset the audience before a new section or appendix.
`PR-[DK/LT]-06 Thesis`	One strong point	Use for a concise argument. Do not turn it into a paragraph slide.
`PR-[DK/LT]-07 Two Content`	Two-part explanation	Use for problem/response, before/after, risk/mitigation, or two bounded claims.
`PR-[DK/LT]-08 Three Content`	Three related points	Use for three capabilities, three constraints, or three evidence categories. Avoid generic service menus.
`PR-[DK/LT]-09 Title + Content`	Standard body slide	Use for most ordinary briefing content. Keep one main idea.
`PR-[DK/LT]-10 Full Content`	Large diagram, table, or image	Use when the visual object is the slide. Keep labels readable.
`PR-[DK/LT]-11 Evidence Timeline`	Evidence path	Use for source-to-review logic, test paths, artifact chains, assumptions, or review gates.
`PR-[DK/LT]-12 Executive Summary`	Decision framing	Use for recommendation, alternatives, assumptions, evidence, open risk, and next gate.
`PR-[DK/LT]-13 Integration Flow`	Source-interface-sink logic	Use to explain a seam, handoff, dependency, data route, or integration risk.
`PR-[DK/LT]-15 Chart Explanation`	One data story	Use for one chart and one takeaway. Include source and methodology.
`PR-[DK/LT]-16 Register`	Structured evidence	Use for risks, actions, artifacts, assumptions, status, or ownership.
`PR-[DK/LT]-17 Data Table`	Dense evidence	Use for real tabular data. If the deck is table-heavy, choose the light template before building; do not switch only table slides to light.
`PR-[DK/LT]-18 Content with Caption`	Technical object plus explanation	Use for a diagram, screenshot, model, architecture note, or artifact with source context.
`PR-[DK/LT]-19 Comparison`	Trade study or alternatives	Use for alternatives, criteria, decision, and caveats.
`PR-[DK/LT]-20 Picture with Caption`	Approved real imagery	Use only with credible engineering or field-adjacent imagery. Avoid stock theater.
`PR-[DK/LT]-23 Team / SME Profile`	Staffing credibility	Use for people, roles, relevant experience, and approved proof. Avoid inflated bios.
`PR-[DK/LT]-26 Closing / Request`	Final ask	Use for one request, one next gate, owner, contact, or decision path.
`PR-[DK/LT]-28 Field Note`	Insight or thought leadership	Use for a sharp observation, recruiting point, or internal field note.
`PR-[DK/LT]-31 Modeling & Simulation`	Domain cover	Use to open an M&S-focused deck or section.
`PR-[DK/LT]-32 Aircraft Mission Systems`	Domain cover	Use to open an aircraft mission systems deck or section.
`PR-[DK/LT]-33 Software Engineering`	Domain cover	Use to open a software engineering deck or section.
`PR-[DK/LT]-35 Modeling & Simulation`	Domain divider or content section	Use when the deck shifts into M&S detail.
`PR-[DK/LT]-36 Aircraft Mission Systems`	Domain divider or content section	Use when the deck shifts into AMS detail.
`PR-[DK/LT]-37 Software Engineering`	Domain divider or content section	Use when the deck shifts into software engineering detail.

7. Use signature mechanics with restraint

The templates include recurring Polyrhythm mechanics. Use them to organize content, not to decorate slides.

Evidence timeline or spine

Use for artifact chains, assumptions, source notes, decision markers, verification points, standards maps, risk slides, and appendix evidence.

Good use:

SRC -> BUILD -> SCAN -> TEST -> REVIEW
Assumption -> Evidence -> Open risk -> Decision -> Next gate
Requirement -> Interface -> Test seam -> Artifact -> Reviewer

Rules:

Use 3 to 6 meaningful nodes.
Use real evidence labels. Do not invent artifact IDs.
One node may use Flare to show the active item.
End with a source, caveat, or [Needs input] when proof is incomplete.

Active interface trace

Use for architecture, integration flow, mission-system boundaries, data routes, secure delivery paths, and dependency risk.

Rules:

Highlight one active route or seam.
Keep secondary paths muted.
Label source, sink, interface or contract, ownership zone, data direction, and assumption.
Do not use multiple orange routes unless the slide is explicitly comparing them.

Metadata rail

Use for briefing context, identifiers, revision information, dates, customer placeholders, and distribution markings.

Rules:

Full metadata on covers, capability statements, proposal title slides, and appendix dividers.
Reduced metadata on ordinary briefing slides.
Minimal metadata on thesis slides, large diagrams, and executive control slides.
Do not fill every slide with full metadata.
Remove or complete placeholders before sending.

Capability sheet card

Use for capability overviews, one-capability briefings, partner decks, and leave-behinds.

A good card includes:

Capability title.
Operating context.
What Polyrhythm does.
Deliverables or artifacts.
Evidence or review path.
Caveats or [Needs input] where proof is missing.

Do not use capability cards as product-suite tiles or vague benefit claims.

Decision record block

Use for executive summaries, decision slides, trade studies, design reviews, and risk disposition.

A good decision record includes:

Decision or recommendation.
Alternatives considered.
Assumptions.
Evidence.
Risk left open.
Next review or owner.

Do not use the block as a generic marketing summary.

Schematic field

Use for covers, dividers, architecture slides, agenda maps, and field-note slides.

Rules:

The schematic must communicate a real structure, flow, boundary, assumption, or risk.
It should orient the audience, not create decorative technical noise.
Do not imply system detail that does not exist or has not been approved.

Controlled asymmetry

Polyrhythm should not feel like a centered corporate template.

Use offset title blocks, uneven but intentional column spans, and edge-weighted schematic fields. Keep body copy aligned to a rational grid. Do not create random drift.

8. Writing rules for Polyrhythm slides

Use takeaway titles

The slide title should say what the audience should understand.

Weak:

Integration overview
Our capabilities
Technical approach
Architecture

Better:

The integration risk sits at the task leaderhsip boundary.
Polyrhythm clarifies interfaces before changes become rediscovery work.
The evidence path must survive build, scan, test, and review.
The decision reduces ambiguity but leaves two risks open.

Prefer concrete nouns

Use words like:

interfaces
data flows
test seams
requirements
evidence packages
architecture notes
deployment paths
control boundaries
integration plans
simulation models
telemetry paths
review artifacts
risk registers
fielded environments

Avoid vague phrases like:

innovative solutions
mission-critical stakeholders
digital transformation
next-generation platform
seamless integration
world-class team
game-changing capability

Make claims reviewable

Every claim should have proof, a caveat, or [Needs input].

Do not invent:

Customers.
Metrics.
Certifications.
Contract history.
Named programs.
Operational outcomes.
Product claims.
Accreditation or airworthiness ownership.

When proof is missing, write [Needs input]. Do not cover the gap with confident language.

Criticize failure modes, not customer types

It is acceptable to name problems like brittle software, unclear ownership, weak evidence, integration debt, hard-to-change systems, and slow paths to fielded capability.

Do not attack primes, government buyers, acquisition organizations, or customer teams as a class.

9. Content density

Use density intentionally.

Slide type	Word count guidance	Notes
Executive control slide	25 to 40 words plus one visual	Use for decision, request, or framing.
Standard briefing slide	60 to 110 words	Use one main idea and no more than three major zones.
Technical slide	120 to 180 words plus diagram or table	Use a clear takeaway title and evidence structure.
Appendix slide	Up to 250 words when table-based and legible	Make it PDF-readable. Do not use as a live briefing crutch.

Rules:

Do not exceed three major zones on ordinary slides.
Dense slides need a diagram, table, register, or evidence structure.
Do not create dense bullet slides.
Any slide requiring body text below 14 pt should be split or moved to the appendix.
For live technical briefings, prefer 16 pt or larger body text.

10. Diagrams, charts, and tables

Diagrams

A technical diagram should label the seam, not just the node.

Include:

Source.
Sink.
Interface or contract.
Ownership zone.
Data direction.
Assumption or caveat.
Evidence or verification point.

Use editable PowerPoint elements where possible. Avoid decorative schematics and SmartArt-driven diagrams that cannot carry the actual logic.

Charts

Use charts only when the data advances the argument.

Rules:

One chart per slide unless comparing closely related values.
Use the slide title for the takeaway.
Include source and methodology notes.
Highlight one series or point maximum.
Use flat charts only.
Do not use 3D, shadows, gradients, exploded pies, or decorative labels.

Tables and registers

Use tables for real tabular evidence, not for page layout.

Rules:

If the briefing is table-heavy, choose the light template before building. Do not switch a few table slides to light inside a dark briefing.
Use 4 to 7 columns for presented slides.
Move larger tables to appendix or PDF-oriented layouts inside the selected theme.
Keep status labels text-based: Risk, Open, Blocked, Ready, Review, Draft, [Needs input].
Pair status color with words. Color cannot be the only signal.

11. Photography, screenshots, icons, and motion

Photography

Photography is optional. The deck must work without it.

Use only credible engineering or field-adjacent imagery:

Labs.
Hardware.
Terminals.
Integration environments.
Test artifacts.
Engineering workspaces.
Aircraft systems where context is real and non-glamorous.

Avoid:

Camouflage.
Flag overlays.
Missile glamour.
Aircraft beauty shots as default.
Soldiers in silhouette.
Glowing server rooms.
Code rain.
Generic AI imagery.
Stock cyber visuals.

Screenshots

Use screenshots only when they support the evidence or help explain an artifact.

Rules:

Crop to the relevant area.
Add a caption or source note.
Remove sensitive or unapproved content.
Do not use screenshots as visual filler.

Icons

Use icons sparingly.

Good icon style:

One-color.
Line-based.
Geometric.
Editable.

Avoid filled cartoons, decorative icon grids, and icon menus that make services feel generic.

Motion

Use motion only for sequence or progressive disclosure.

Allowed:

Appear.
Fade.
Stepwise reveals.
Trace reveal when explaining a path.

Avoid:

Spins.
Zooms.
HUD sweeps.
Parallax.
Kinetic startup effects.
Decorative animation.

12. Slide-building workflow

Use this workflow for every deck.

Select one template. Choose either the dark template or the light template based on the deck context. Use that theme for every slide.
Write the storyline in titles first. Read the titles in sequence. They should form the argument.
Choose layouts by job. Use the layout chooser instead of making ad hoc slides.
Replace placeholders deliberately. Complete or remove [Needs input], customer placeholders, source notes, and distribution markings.
Add proof paths. Every major claim needs evidence, an artifact, a source, a caveat, or [Needs input].
Simplify each slide. One main idea. No more than three major zones.
Check visual pacing. Do not run too many dense slides in a row. Use control slides to reset.
Export to PDF and inspect. Check legibility, slide order, distribution markings, and missing proof.

13. Final QA checklist

Before sending a deck, check each item.

Story and audience

The deck has a clear audience.
The deck asks for a decision, review, next gate, or specific understanding.
The slide titles form a coherent argument.
Every slide has a role in the briefing.

Brand voice

The language is senior, precise, and technically credible.
Claims are supported or marked [Needs input].
The deck uses concrete nouns, not inflated adjectives.
The deck criticizes failure modes, not customers or primes.
Hype language has been removed.

Visual system

The deck uses template layouts rather than improvised slide designs.
The deck uses one theme consistently: all PR-DK layouts or all PR-LT layouts.
Theme selection matches the briefing job, audience, and density level.
Slide pacing is handled through density, layout choice, and control slides, not theme switching.
Flare marks one active element, not everything important.
Metadata is accurate and not overused.
Schematics communicate real structure.

Legibility

Body text is readable in a room.
Dense slides have a diagram, table, register, or evidence structure.
No important live-briefing text is below 14 pt.
Tables are readable in PDF export.
Sources, caveats, and methodology notes are present where needed.

Release discipline

Distribution and classification placeholders are correct or removed.
Customer names, metrics, programs, and outcomes are approved for use.
No unsupported accreditation or airworthiness ownership claims appear.
Sensitive screenshots and artifacts are cleared.
[Needs input] markers are resolved or intentionally retained for draft review.

14. Common fixes

Weak execution	Better execution
Title says `Integration approach`	Title names the specific interface, risk, decision, or handoff.
Three generic capability boxes	Capability cards with context, deliverables, artifacts, evidence, and caveats.
Orange used on title, icons, connectors, and callouts	One Flare element marks the active route, status, or decision point.
Architecture diagram has unlabeled boxes	Diagram labels source, sink, interface, ownership zone, data direction, assumption, and evidence.
Dense dark table	Simplify the table, split it across slides, or choose the light template for the whole deck before building.
Evidence IDs imply proof that does not exist	Replace with real source labels or `[Needs input]`.
"Seamless, cutting-edge, next-generation solution"	"Lower-friction integration path with explicit interfaces, test seams, and reviewable artifacts."
Terminal prompt on every slide	Use terminal cues only on covers, dividers, closing slides, or occasional technical slides.
Customer-specific deck organized around Polyrhythm service areas	Organize around the customer problem, system boundary, decision, or delivery path.

15. Sample Polyrhythm slide-title patterns

Use these patterns as starting points, not fixed copy.

The risk is not software volume; it is unclear ownership at the interface.
This decision reduces integration ambiguity but leaves two risks open.
The evidence path needs to survive build, scan, test, and review.
The test seam must be explicit before the next integration event.
The architecture is only useful if it changes the integration path.
Polyrhythm's role is to make the software layer easier to understand, test, and change.
The next gate is a reviewable artifact set, not a status meeting.
The diagram shows the active seam, not the entire system.

16. Audience guidance

Audience	Emphasize	Avoid
Executive buyer or customer	Decision, risk, fieldability, evidence, next gate	Dense technical proof before orientation
Technical evaluator	Interfaces, assumptions, data flows, test seams, artifacts, caveats	Hand-waving or marketing claims
Program office	Schedule implications, decision support, ownership clarity, controlled speed	Deep jargon without translation
Prime or partner	Complementary role, clean handoffs, non-overlap zones, program discipline	Anti-prime rhetoric
Startup or prototype team	Prototype-to-field transition, reusable patterns, integration survival	Heavy process language or prime-scale posture
Candidate or recruiting audience	Serious systems, real constraints, low theater, senior judgment	Perk-first or "elite team" language

17. Decks not to build

Do not build:

A fake dashboard deck.
A generic consulting deck.
A stock-photo defense theater deck.
A product-suite deck unless the product claim is approved.
A dark technical appendix that forces tiny labels, dense registers, or unreadable tables.
A dense bullet-report deck.
An orange-overload deck.
A terminal-cosplay deck.
A decorative schematic deck where the diagrams do not communicate real structure.

18. Reusable briefing prompt

Use this prompt when asking for help drafting or revising a Polyrhythm deck.

Build this Polyrhythm briefing using one selected Polyrhythm PowerPoint template. Do not mix dark and light themes in the same deck.

Audience:
Decision or action:
System/problem boundary:
Approved facts:
Claims needing proof:
Selected template: [dark / light]
Required layouts:
Distribution/classification marking:

Tone:
Senior, precise, technically credible, mission-literate, calm under complexity, anti-theater, evidence-driven, and outcome-oriented.

Rules:
- Use concrete nouns: interfaces, data flows, test seams, requirements, evidence packages, architecture notes, deployment paths, control boundaries, risk registers, and fielded environments.
- Use only the selected layout family: `PR-DK` for dark or `PR-LT` for light.
- Do not switch themes for individual slides, tables, appendices, or section dividers.
- Pace the deck with sparse slides, dense slides, control slides, and appendices inside the selected theme.
- Use `[Needs input]` where proof is missing.
- Do not invent customers, metrics, certifications, contract history, named programs, or outcomes.
- Do not claim accreditation or airworthiness ownership unless specifically supported.
- Avoid hype language, dashboard theater, stock defense imagery, and product-suite posture.
- Criticize failure modes, not customer types.