PowerPoint templates

Document type: Build-ready design brief Revision: 02 Status: Template design requirements Primary output: Microsoft PowerPoint .potx template system with dark and light themes Secondary outputs: Example .pptx, PDF preview, component library, one-page usage guide

1. Purpose

This document defines the requirements for a premium PowerPoint template system for Polyrhythm Software, LLC. It is not a brand redesign. It translates the current Polyrhythm brand into a practical, durable presentation system for defense software, aerospace, DoD engineering, technical evaluation, proposal support, and partner briefings.

The template must feel like Polyrhythm: senior, precise, technically credible, mission-literate, calm under complexity, services-first, anti-theater, and built around software control, integration discipline, evidence, testability, security, and fieldability.

The first release must be visually distinctive enough to avoid generic defense-contractor PowerPoint, but restrained enough to work in program office, prime contractor, integrator, evaluator, and partner settings.

2. Source basis and controlling assumptions

Polyrhythm.com is the definitive visual expression of the brand. It is newer than the Brand Voice Guide and should control visual interpretation where there is a conflict.

The Brand Voice Guide remains the controlling source for voice, claim discipline, proof discipline, and positioning restraint.

The template system should carry forward the following brand signals from Polyrhythm.com:

• Dark, technical, metadata-forward presentation.
• Operational identifiers and review context.
• Capability-sheet framing.
• Schematic structure rather than decorative imagery.
• Evidence paths, artifact language, and reviewability.
• Calm, controlled language.
• No theater, no exaggerated claims, no borrowed prime-contractor scale.

The template must not create the impression that Polyrhythm is a product-suite company, mini-prime, generic consultancy, SaaS platform, cyber-dashboard vendor, or hype-driven defense-tech startup.

3. Design thesis

The Polyrhythm PowerPoint system should feel like a controlled engineering workspace for defense software.

It should make complex systems legible without turning them into fake dashboards. It should look native in a technical review, architecture discussion, proposal appendix, capability briefing, prime partner conversation, and executive decision meeting.

The template should express:

• Software control: source, dependencies, build, scan, sign, promote, deploy, evidence.
• Integration discipline: seams, interfaces, handoffs, data paths, ownership zones, assumptions, verification points.
• Complex aerospace and defense systems: controlled boundaries, mission systems, modeling and simulation, hardware/software interfaces, field constraints.
• Evidence and reviewability: artifacts, citations, decision records, assumptions, open risks, test status, standards maps.
• Senior engineering judgment: direct titles, restrained typography, no exaggerated claims, visible tradeoffs.
• Controlled speed: progress through gates and artifacts, not velocity theater.
• Fieldability: capability that can be integrated, secured, tested, changed, and supported.

4. Strategic visual posture

The template should be forward-leaning, but not theatrical. It should feel more advanced than a compliance deck and more disciplined than a defense-tech launch deck.

The correct visual territory is:

• Dark-native but not gloomy.
• Schematic but not fake-HUD.
• Asymmetric but not chaotic.
• Metadata-aware but not bureaucratic.
• Technical but not visually dead.
• Premium but not glossy.
• Defense-literate but not militarized.

The visual system should create interest through structure, contrast, pacing, and precise information design. It should not rely on cinematic photography, glowing grids, dashboard cosplay, decorative code, or orange overload.

5. Signature layout mechanics

These mechanics are the core of the template. They make the system recognizably Polyrhythm and prevent the design from becoming a generic collection of boxes.

Every major layout should use at least one of these mechanics. No slide should use all of them at once.

5.1 Evidence spine

A vertical or horizontal structural line that organizes artifacts, assumptions, source notes, decision markers, or verification points.

Use for: technical deep dives, risk slides, decision records, standards maps, evidence paths, appendix slides.

Anatomy:

• Thin Graphite or Steel rule.
• 3 to 6 labeled evidence nodes.
• Optional artifact IDs in mono.
• One active item may use Flare.
• Source or caveat line at the end.

Good use: a technical slide where the left side explains the issue and the right evidence spine lists SRC, BUILD, SCAN, TEST, REVIEW.

Do not use: as a decorative timeline with fake artifacts.

5.2 Active interface trace

A single highlighted path showing the seam, data route, dependency, integration risk, or decision point under discussion.

Use for: architecture, integration flow, mission system boundary, data pipeline, secure delivery path.

Anatomy:

• One Flare connector or short path.
• Muted secondary paths in Steel or Graphite.
• Labeled source and sink.
• Explicit seam label.
• Optional risk or evidence tag.

Good use: show one active telemetry path through a system diagram while surrounding nodes remain quiet.

Do not use: multiple competing orange lines, glowing lines, or animated command-center effects.

5.3 Metadata rail

A controlled rail for briefing context, identifiers, revision information, distribution placeholders, dates, and document status.

Use for: covers, capability statements, formal proposal slides, appendix dividers, document-control-heavy decks.

Anatomy:

• Top, left, or bottom rail.
• Mono labels at 8 to 10 pt.
• May include Capability Statement, Rev XX, Draft, [Needs input], date, CAGE, UEI, NAICS, distribution placeholder, customer placeholder.
• Should be lighter on ordinary slides.

Metadata density levels:

• Full: cover, capability statement, proposal title, appendix divider.
• Light: ordinary briefing slide with section code and slide number.
• Minimal: thesis slides, large diagrams, executive control slides.

Do not use: full metadata on every slide.

5.4 Capability sheet card

A reusable card format that presents a Polyrhythm capability as a reviewable work product, not a sales slogan.

Use for: capability overview, one-capability briefings, partner decks, leave-behinds, service descriptions.

Anatomy:

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

Good use: Aircraft Mission Systems card with interfaces, telemetry paths, hardware/software boundaries, verification artifacts, and delivery posture.

Do not use: product-suite cards, vague benefit claims, unsupported customer references.

5.5 Schematic field

A subtle background or side-field made from editable PowerPoint lines, nodes, ports, and labels.

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

Anatomy:

• Low-contrast grid or diagram fragment.
• No more than 20 percent visual dominance unless it is the main diagram.
• May bleed near the edge on covers and dividers.
• Should support orientation, not decoration.

Good use: a dark cover with a partial interface map entering from the right edge while the title block remains quiet.

Do not use: ornamental schematics that imply nonexistent system detail.

5.6 Decision record block

A consistent visual form for engineering judgment.

Use for: executive summary, decision slide, trade study, design review, risk disposition.

Anatomy:

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

Good use: a trade-study conclusion that shows why an option was selected and what remains uncertain.

Do not use: as a generic summary box with marketing copy.

5.7 Controlled asymmetry

Polyrhythm should not feel like a centered corporate template. Use disciplined imbalance.

Use for: covers, dividers, thesis slides, architecture slides, field notes.

Rules:

• Offset title blocks from center.
• Let schematic fields occupy one edge or corner.
• Use uneven but intentional column spans such as 5/7, 4/8, or 3/6/3.
• Keep body copy aligned to a rational grid.
• Do not create random visual drift.

6. Theme strategy

The template must include dark and light themes in one .potx, with equivalent layout names and placeholder structures.

6.1 Dark theme

Primary use cases: executive briefings, capability intros, architecture discussions, technical reviews, thesis slides, section dividers, thought leadership, partner conversations.

Behavior:

• Ink #0E1721 is the native canvas.
• Fog and Stone carry title and body text.
• Steel carries muted labels.
• Graphite carries rules, panels, and secondary boundaries.
• Flare marks the active item, not the whole slide.
• Use schematic fields for orientation.
• Use dark slides to create distinction and control attention.

Limits:

• Do not build entire long decks as dark slides.
• Avoid dense dark tables unless they are very small.
• Avoid 9 pt muted labels on dark backgrounds in live briefing decks.
• Do not use glowing neon effects.

6.2 Light theme

Primary use cases: proposals, leave-behinds, printed decks, technical appendices, tables, risk registers, standards maps, source-selection-safe material, detail-heavy evaluator slides.

Behavior:

• Fog or a derived paper tint is the dominant field.
• Ink carries titles and primary text.
• Graphite carries body, captions, and structure.
• Stone supports rules and secondary fields.
• Flare is a surgical accent only.
• Use light slides for density, evidence, tables, and PDF readability.

Limits:

• Do not let light slides become generic consulting slides.
• Do not use Steel for body text on Fog.
• Do not use Flare as small text on light backgrounds.

7. Visual pacing

A Polyrhythm deck should move like a controlled technical review.

Recommended cadence:

1. Dark cover.
2. Light executive summary.
3. Dark thesis or briefing map.
4. Dark schematic or architecture orientation.
5. Light evidence/detail slide.
6. Light technical or proposal detail slide.
7. Sparse control slide.
8. Decision, request, or next gate.

For longer decks:

• No more than 3 dense slides in a row.
• Every 3 to 4 dense slides should be followed by a control slide.
• Executive audiences should see fewer than 20 percent high-density slides before the appendix.
• Technical evaluator decks may be dense, but must still include orientation and decision slides.
• Dark slides should carry orientation, thesis, and system logic.
• Light slides should carry evidence, tables, text, and reviewable detail.

8. Layout system

Build the first release around a core set of layouts. Do not overbuild. A smaller set of excellent layouts is preferable to 32 inconsistent layouts.

8.1 Core release layouts

Build these first, in both dark and light where appropriate.

No.	Layout	Purpose	Required signature mechanic
01	Title cover	Primary deck opening	Metadata rail, schematic field
02	Formal cover	Proposal or partner opening	Metadata rail
03	Capability statement	One-capability leave-behind	Capability sheet card
04	Briefing map	Agenda and navigation	Metadata rail, controlled asymmetry
05	Section divider	Pacing and topic shift	Schematic field
06	Thesis slide	One strong point	Controlled asymmetry
07	Executive summary	Decision framing	Decision record block
08	Problem or failure mode	Diagnostic framing	Evidence spine
09	Capability overview	What Polyrhythm does	Capability sheet cards
10	Three surfaces	M&S, AMS, SWE relationship	Capability sheet cards
11	Evidence path	Source-to-evidence logic	Evidence spine
12	Integration flow	Interfaces and handoffs	Active interface trace
13	Architecture diagram	System structure	Active interface trace, schematic field
14	Technical deep dive	Dense technical explanation	Evidence spine
15	Chart explanation	One data story	Decision or evidence block
16	Table or register	Structured evidence	Evidence spine

8.2 Second release layouts

Add these after the core system is working in real decks.

No.	Layout	Purpose
17	Risk and mitigation	Risk, trigger, mitigation, evidence, owner
18	Timeline and gates	Phased delivery with entry/exit criteria
19	Comparison or trade study	Alternatives, criteria, decision, caveats
20	Case study	Approved proof only
21	Standards map	Standards, applicability, evidence, caveats
22	Artifact register	Evidence inventory
23	Team or SME profile	Staffing credibility
24	Partner and teaming	Roles, handoffs, non-overlap zones
25	Appendix divider	Transition to detail
26	Closing or request	One ask, contact, next gate
27	Blank schematic canvas	Custom diagrams
28	Field note or insight	Thought leadership or recruiting

8.3 Layouts to avoid in first release

Do not build highly specific novelty layouts until the template has been tested in actual Polyrhythm decks. Avoid:

• Fake dashboard layouts.
• Decorative quote layouts.
• Icon-grid service menus.
• Full-bleed photography slides unless Polyrhythm has real imagery.
• Complex animation layouts.
• One-off layouts that cannot be reused.

9. Composition and grid

9.1 Canvas

Use standard 16:9 widescreen: 13.333 x 7.5 in.

9.2 Grid

Use a 12-column grid.

• Inner gutter: 0.12 to 0.16 in.
• Baseline increment: 0.125 in.
• Preferred spans: 3, 4, 5, 6, 7, 8, and 12 columns.
• Avoid centered default corporate layouts except for formal title pages.

9.3 Margin modes

Margins should be contextual rather than fixed.

Mode	Margin	Use case
Presentation safe	0.55 to 0.70 in	Executive slides, projected text, formal decks
Standard	0.50 to 0.55 in	Most briefing and proposal slides
Technical wide	0.40 to 0.45 in	Architecture, integration, charts, dense diagrams
Appendix dense	0.35 to 0.45 in	Tables, registers, standards maps, PDF review
Visual bleed	Text safe at 0.55 in, graphics may bleed	Covers, dividers, schematic fields

Critical text should remain inside 0.55 in on most slides. Schematic fields, rules, background grids, and image crops may extend beyond that zone when they do not carry essential information.

9.4 Footer system

Footer height: 0.28 to 0.35 in.

Footer content:

• Left: deck title, section, or document code.
• Center: optional classification or distribution placeholder.
• Right: slide number and optional revision marker.

Footer type:

• Default: 8 to 9 pt mono.
• Absolute minimum: 7 pt only for metadata not expected to be read during presentation.

9.5 Classification and distribution placeholders

Include optional top and bottom marking areas. Do not bake in a classification marking.

Default placeholder:

[Distribution / classification marking if required]

The placeholder must be editable and easy to remove.

9.6 Logo placement

• Covers may use the full horizontal or vertical lockup.
• Interior slides should use a small horizontal lockup or mark-only placement.
• Preserve clear space equal to the mark height.
• Do not recolor, stretch, outline, shadow, bevel, or animate the logo.

10. Typography system

10.1 Preferred fonts

Premium template:

• Sans: Inter.
• Mono: JetBrains Mono.

Compatibility template:

• Sans: Corbel, Aptos, or Arial.
• Mono: Consolas, Cascadia Mono, or Courier New.

Proposal-safe fallback:

• Sans: Aptos.
• Mono: Consolas.

The compatibility version must be designed intentionally. It should not be a broken fallback of the premium version.

10.2 Type hierarchy

Use	Size
Cover title	46 to 64 pt
Oversized sparse cover title	64 to 72 pt when composition supports it
Section title	38 to 48 pt
Slide title	28 to 34 pt
Technical slide title	24 to 30 pt
Subtitle	17 to 22 pt
Normal body	17 to 20 pt
Dense body	14 to 16 pt
Preferred live technical body	16 pt
Captions	9 to 11 pt
Diagram labels	10.5 to 12 pt preferred
Diagram labels, absolute floor	9.5 pt
Table body, live briefing	12 to 14 pt
Table body, appendix/PDF	9.5 to 11 pt
Footer	8 to 9 pt
Footer, absolute floor	7 pt

10.3 Type behavior

• Use sentence case for headings.
• Use strong weight for hierarchy, not all caps.
• Do not set body paragraphs in mono.
• Use mono for metadata, identifiers, artifact IDs, tags, sequence numbers, terminal cues, and small system annotations.
• All caps are permitted only for small metadata labels under 11 pt with slight tracking.
• Avoid long bullet stacks. Prefer labeled blocks, short paragraphs, and structured evidence.

11. Color system

11.1 Core palette

Token	Hex	Use
Ink	#0E1721	Primary dark base, title text on light
Graphite	#46515B	Borders, rules, dividers, body on light
Steel	#8B9399	Secondary labels and muted text on dark
Stone	#C0C6C9	Body text on dark, light rules
Fog	#E3E3E3	Light surfaces, high-contrast text on dark
Flare	#FF5D00	Primary accent, active route, status mark
Ember	#CD3619	Deep accent, hover/pressed, secondary emphasis
Amber	#FCAA00	Caution and signal
Flax	#F8E04D	Rare tertiary signal
Deep panel	#162230	Derived dark panel

11.2 PowerPoint theme slots

Theme slot	Color
Dark 1	Ink #0E1721
Light 1	Fog #E3E3E3
Dark 2	Graphite #46515B
Light 2	Stone #C0C6C9
Accent 1	Flare #FF5D00
Accent 2	Amber #FCAA00
Accent 3	Steel #8B9399
Accent 4	Ember #CD3619
Accent 5	Flax #F8E04D
Accent 6	Deep panel #162230
Hyperlink	Flare
Followed hyperlink	Ember

11.3 Accent rules

• Use one accent family per slide.
• Flare marks the active element, not all important elements.
• Amber indicates caution, not decoration.
• Flax should be rare.
• Never use Flare, Amber, and Flax as competing highlights on the same slide.
• Color cannot be the only indicator. Pair status color with text.

11.4 Accessibility rules

• Normal text must meet 4.5:1 contrast.
• Large text must meet 3:1 contrast.
• Do not use Flare as small text on Fog.
• Do not use Steel as body text on Fog.
• Use labels with signals: Risk, Blocked, Open, Ready, Review, Draft, [Needs input].

12. Visual language

12.1 Shape language

Use:

• Rectangles.
• Thin outlines.
• Hard-edge panels.
• Small corner radii only where useful.
• Ports.
• Brackets.
• Rule lines.
• Boundary boxes.
• Editable vectors.

Avoid:

• Blobs.
• Swooshes.
• Bevels.
• Shadows.
• 3D.
• Glassmorphism.
• Glowing UI.
• Decorative gradients.

12.2 Rule lines

• Standard: 0.5 to 1.0 pt.
• Use Graphite, Steel, or Stone.
• Use Flare only for the active route, active node, or single point of emphasis.

12.3 Schematic blocks

Build schematic blocks as editable PowerPoint groups:

• Boundary box.
• Node.
• Interface port.
• Connector.
• Label.
• Evidence tag.
• Status marker.
• Assumption marker.

Every schematic must communicate a real structure, flow, boundary, assumption, or risk. Decorative schematic noise is not acceptable.

12.4 Interface diagrams

Interface diagrams should label the seam, not just the node.

Required elements:

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

12.5 Data visualization

• Use flat charts only.
• No 3D, shadows, gradients, exploded pies, or decorative labels.
• One chart per slide unless comparing closely related values.
• Use the slide title for the takeaway.
• Use a source and methodology note where needed.
• Highlight one series or point maximum.
• Provide dark and light chart examples.

12.6 Tables

• Tables are for real tabular evidence, not page layout.
• Use thin horizontal rules.
• Minimize banding.
• Keep status tags text-based.
• Use light theme for most dense tables.
• Use 4 to 7 columns for presented slides.
• Move larger tables to appendix or PDF-oriented layouts.

12.7 Photography

Photography is optional. The template must work without it.

Use only real, credible engineering or field-adjacent imagery:

• Labs.
• Hardware.
• Terminals.
• Integration environments.
• Test artifacts.
• Engineering workspaces.
• Aircraft systems only 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.

12.8 Icons

Icon style:

• One-color.
• Line-based.
• Geometric.
• Editable.
• No filled cartoons.
• No decorative icon grids.

Preferred categories:

• Interface.
• Evidence.
• Model.
• Aircraft system.
• Source.
• Build.
• Scan.
• Sign.
• Deploy.
• Telemetry.
• Risk.
• Review.
• Decision.
• Constraint.
• Secure boundary.

12.9 Motion

Motion should support sequence and progressive disclosure.

Allowed:

• Appear.
• Fade.
• Simple stepwise reveals.
• Trace reveal only when explaining a path.

Avoid:

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

13. Content density

13.1 Word count guidance

Slide type	Word count
Executive control slide	25 to 40 words plus one visual
Standard briefing slide	60 to 110 words
Technical slide	120 to 180 words plus diagram or table
Appendix slide	Up to 250 words only when table-based and legible

13.2 Density rules

• Do not exceed 3 major zones on ordinary slides.
• Dense technical slides must include a clear takeaway title.
• A dense slide must have either a diagram, table, or evidence structure. Do not create dense bullet slides.
• Appendix slides may be denser, but must still be readable as PDF.
• Any slide that requires body text below 14 pt should be split or moved to appendix.

14. Wear-out controls

The template should contain strong brand motifs, but the motifs must not appear so often that they become mannered.

14.1 Terminal cues

Allowed cues include Rev XX, SYS * Metrics, Source -> Evidence, Status * Active, and polyrhythm:~$.

Rules:

• Use terminal cues on covers, dividers, closing slides, and occasional technical slides.
• Do not use terminal prompts on every slide.
• Do not simulate a command center.
• Do not include decorative code blocks.

14.2 Flare accent

Rules:

• One active Flare element per slide is preferred.
• Two is acceptable only when one is a small status marker.
• Do not use Flare for body copy on light backgrounds.
• Do not make full orange slides.
• Do not use Flare as generic decoration.

14.3 Dark schematic slides

Rules:

• Use dark schematic slides for orientation and system logic.
• Avoid more than 2 dark schematic slides in a row unless presenting a technical sequence.
• Vary schematic composition: left rail, right field, central map, bottom evidence spine, split-zone architecture.

14.4 Evidence language

Rules:

• Use evidence, artifact, traceability, review, and source-to-evidence language where it clarifies the work.
• Do not force those words into every title.
• Avoid making every slide sound like the same proof argument.

14.5 Three-surface framing

Rules:

• Use M&S / AMS / SWE framing for portfolio orientation.
• Do not repeat it as the organizing structure for every deck.
• For customer-specific decks, organize around the customer problem, system boundary, decision, or delivery path.

15. Technical PowerPoint build specification

15.1 Master structure

Build one .potx with two primary masters:

1. PR-Dark Master
2. PR-Light Master

Each master should include equivalent layout names and numbering so users can switch themes without rebuilding content.

15.2 Layout naming convention

Use clear names:

• PR-DK-01 Title Cover
• PR-LT-01 Title Cover
• PR-DK-11 Evidence Path
• PR-LT-16 Table or Register

15.3 Placeholder rules

Use real PowerPoint placeholders for:

• Title.
• Subtitle.
• Body.
• Picture.
• Chart/content.
• Table/content.
• Footer.
• Date.
• Slide number.
• Classification/distribution marking.
• Source/citation line.
• Metadata rail.

Avoid generic content-placeholder abuse. Layouts should map predictably when users paste content or switch layouts.

15.4 Master-locked versus editable

Lock into masters:

• Background fields.
• Logo placement.
• Footer system.
• Optional classification zones.
• Grid and rule scaffolding.
• Static metadata locations.
• Section divider structure.

Keep editable on slides:

• Diagrams.
• Connectors.
• Evidence chains.
• Architecture blocks.
• Callouts.
• Charts.
• Tables.
• Risk and status markers.
• Image crops.
• Any customer-specific content.

15.5 Component library

Build editable components for:

• Evidence spine.
• Active interface trace.
• Capability sheet card.
• Decision record block.
• System boundary.
• Interface node.
• Port marker.
• Data-flow connector.
• Artifact tag.
• Risk tag.
• Decision tag.
• Assumption tag.
• Constraint tag.
• [Needs input] marker.
• Status labels: Open, Active, Ready, Blocked, Review, Draft.
• Terminal footer component.
• Standards table.
• Risk table.
• Timeline/gate component.
• Trade-study matrix.
• Section code marker.

15.6 SmartArt

Do not rely on SmartArt for core diagrams. Provide native editable PowerPoint components.

15.7 Cross-platform behavior

Build and QA in desktop PowerPoint.

Test in:

• PowerPoint for Windows.
• PowerPoint for Mac.
• PowerPoint for the web.
• PDF export.

Avoid:

• Unsupported effects.
• Complex transparency stacks.
• Embedded video.
• Fonts without fallbacks.
• Excessive grouped objects.
• Fragile animations.

16. Accessibility and compliance-oriented QA

Every layout must support accessible output.

Requirements:

• Every layout includes a title placeholder.
• Example slides have logical reading order.
• Images, diagrams, and charts include alt text in example deck.
• Text is real text, not embedded in images.
• Color is not the only status indicator.
• Contrast is checked for normal and large text.
• PDF export preserves tags, reading order, hyperlinks, and alt text where possible.
• Classification and distribution placeholders remain editable.
• No slide bakes in an actual classification marking unless specifically authored for that deck.

17. Example deck requirements

The template delivery must include a 15 to 20 slide example deck showing correct use.

The example deck must include at least:

• 2 cover variants.
• 2 section dividers.
• 2 executive/control slides.
• 3 technical diagrams.
• 2 proposal/light slides.
• 2 dense appendix or register slides.
• 2 risk, decision, or tradeoff slides.
• 1 chart slide.
• 1 table slide.
• 1 closing/request slide.

The example deck must show pacing. It should not present isolated layouts in a vacuum.

18. Bad execution examples

The usage guide should include examples of what not to do.

Specific failure modes:

• Box soup: too many nested rectangles with no visual hierarchy.
• Orange overuse: Flare used for title marks, connectors, icons, tags, and callouts on the same slide.
• Terminal cosplay: fake command prompts or code blocks that do not support the message.
• Fake artifact labels: evidence IDs that imply nonexistent proof.
• Tiny mono text: labels that look precise but cannot be read in a room.
• Decorative schematics: diagrams that look technical but communicate nothing.
• Dark fatigue: too many dark slides in sequence.
• Generic consulting layout: three boxes and a vague headline.
• Prime-contractor theater: weapons glamour, patriotic overlays, huge claims, cinematic imagery.
• SaaS-dashboard drift: fake live metrics, status widgets, cockpit grids, and product-platform language.

19. Anti-patterns to avoid

Do not use:

• Generic defense contractor blue-gray decks.
• Mini-Anduril weapon/product launch energy.
• SaaS dashboard templates.
• Research-lab minimalism detached from delivery.
• Camouflage, flags, battlefield silhouettes, aircraft glamour, missiles, explosions.
• HUD cosplay, radar sweeps, glowing grids, fake command-center screens.
• Code rain, stock cyber imagery, generic AI visuals.
• Product-suite language unless a product is approved.
• Accreditation or airworthiness ownership claims unless specifically supported.
• Invented customers, metrics, certifications, contract history, named programs, or outcomes.
• Hype language such as revolutionary, next-generation, cutting-edge, game-changing, seamless, transformative, world-class, elite, or unsupported AI-powered.
• Orange overuse.
• Dense fake dashboards.
• Decorative schematics with no information.
• Tiny type that only works on a designer's monitor.

20. Prioritized first-version build list

20.1 Required for version one

1. Two-theme .potx: dark and light masters.
2. Core 16 layouts.
3. Signature mechanics implemented as editable components.
4. Chart and table styles.
5. Component library.
6. 15 to 20 slide example deck.
7. Accessibility QA.
8. PDF export QA.
9. Compatibility-font QA.
10. One-page internal usage guide.

20.2 Defer until version two

1. Full 28-layout expanded library.
2. Larger icon set.
3. Additional case-study layouts.
4. Additional team/staffing layouts.
5. Complex animation patterns.
6. Photography-heavy layouts.
7. Specialized proposal appendix layouts.

21. Acceptance criteria

The template is successful if it meets these criteria:

• It is recognizably Polyrhythm without requiring the logo on every slide.
• It looks credible in front of defense buyers, primes, integrators, and technical evaluators.
• It supports dense technical content without collapsing into tiny type.
• It supports executive summaries without becoming generic.
• It uses dark slides for distinction and light slides for evidence and readability.
• It includes enough visual structure to feel premium.
• It does not depend on stock photography.
• It is usable by non-designers.
• It prevents the most obvious brand failures through layout structure.
• It exports cleanly to PDF.
• It remains readable when compatibility fonts are used.
• It avoids fake dashboards, decorative schematics, and unsupported proof claims.

22. Final design direction

Build the Polyrhythm PowerPoint system around controlled engineering notation, not defense theater.

The strongest visual identity should come from evidence spines, active interface traces, capability sheet cards, decision record blocks, metadata rails, and schematic fields. These should appear as a coherent visual language across the deck, but with enough variation that the template does not wear out after one use.

The result should feel calm, technical, field-aware, and senior. It should look like a company that understands how software survives contact with real systems, real interfaces, real constraints, real evidence, and real review.