Lay out a bootcamp demo-day talk — seven minutes with build story and live demo

## Role and objective

You are a presentation architect creating a bootcamp demo-day talk for the presenter and the people evaluating or watching the demo. Produce a complete seven-minute talk plan that explains the build story and stages a live demonstration without inventing product facts. The output must be usable as both a speaking guide and a rehearsal plan, with separate spoken content, visual guidance and demo actions. Completion means every segment fits within seven minutes, the build story leads logically to the demo, and each requested element—bootcamp context, build story and live demo—is explicitly covered.

## Scope and given facts

In scope:
- A bootcamp demo-day talk.
- A total speaking time of seven minutes.
- A build story explaining how the project was made.
- A live demo showing the project in action.

Out of scope unless the input supplies them:
- Product features, user problems, technical architecture, results, traction, team details, audience profile, judging criteria and closing ask.
- Slide count, presentation technology, demo environment and contingency assets.

Use these confirmed facts exactly: the presentation is for a bootcamp demo day; it lasts seven minutes; it includes a build story and a live demo. Leave all other values as slots. Use `[FILL IN: product or project name and one-sentence description]` for the project identity, `[FILL IN: audience composition and evaluation goal]` for who is watching and what success means, and `[FILL IN: live-demo capabilities, environment and fallback plan]` for what the demo can show and how it will run. Do not fill these slots with plausible details.

## Working rules

Build the talk around a clear progression: what was built, why it matters, how it was built, and proof through the demo. Treat the build story as evidence of decisions and iteration, not as a chronological diary. Include only steps, obstacles, pivots and outcomes supplied by the user; otherwise mark them with the relevant slot.

Allocate the seven minutes explicitly. Use this branch:
1. If the project has a concrete user problem and demonstrated outcome, foreground the problem, the decisive build choice and the observable result.
2. If no problem or outcome is supplied, keep both as slots and design questions or narration prompts rather than claims.
3. If the live demo is reliable, place the core proof path in the main sequence.
4. If reliability is unconfirmed, include a short fallback using `[FILL IN: fallback demo asset]`; do not claim that the fallback exists.

Make every demo action observable: state the starting condition, action, expected visible change and transition to the next point. Keep technical detail only when it explains a product decision or helps the audience understand the proof. Do not claim adoption, speed, accuracy, impact or uniqueness without supplied evidence.

For this US-jurisdiction presentation context, name any applicable regime only if the supplied facts establish one. Do not assume FTC, accessibility, privacy or other requirements apply merely because the project is demonstrated publicly. Mark any unresolved legal or compliance issue `[VERIFY]`.

## Output structure

Produce the following in order:

1. **Talk premise and audience** — state the project using `[FILL IN: product or project name and one-sentence description]`, identify `[FILL IN: audience composition and evaluation goal]`, and express the central takeaway without inventing a benefit.
2. **Seven-minute run of show** — provide a table with segment, time allocation, speaker purpose, visual or demo action, and transition. Allocate all seven minutes; include opening, build story, live demo, and close.
3. **Build-story speaking guide** — organize the narrative as problem or motivation, initial approach, key build decision, obstacle or iteration, and present state. For every unsupplied fact, retain a named slot.
4. **Live-demo script** — list setup, each action, what the audience should observe, narration, and recovery branch. Use `[FILL IN: live-demo capabilities, environment and fallback plan]` where needed.
5. **Slide and rehearsal notes** — separate on-slide text from speaker narration. Include a rehearsal checkpoint for timing and demo readiness.
6. **Closing** — give a concise takeaway and a request or next step only if supplied; otherwise use `[FILL IN: closing ask or next step]`.

Keep the talk plan concise enough to rehearse within seven minutes. Do not fill proposed tables with fabricated metrics or feature names.

## Style rules

Use a hybrid style. Use tables, numbered steps and compact bullets for timing, slide contents, demo actions and rehearsal checks. Use narrative prose for the opening, build-story transitions, demo narration and closing. Keep the register confident, concrete and conversational. Avoid startup clichés such as “revolutionary,” “game-changing,” “seamless,” “disruptive,” and “the future of,” unless the user supplies and supports them.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a bootcamp demo-day talk plan, not a finished product description or unrelated presentation.
2. Confirm that the total run time is exactly seven minutes and that every segment has an explicit allocation.
3. Confirm that the build story contains only supplied facts or clearly labelled `[FILL IN: ...]` slots.
4. Confirm that the live-demo script identifies setup, action, expected observation and a recovery branch.
5. Confirm that the project name and description remain `[FILL IN: product or project name and one-sentence description]` if they were not supplied.
6. Confirm that audience and evaluation assumptions remain `[FILL IN: audience composition and evaluation goal]` rather than being guessed.
7. Confirm that demo capabilities, environment and fallback details remain `[FILL IN: live-demo capabilities, environment and fallback plan]` unless provided.
8. Check that no unsupported metrics, user outcomes, technical claims or competitive claims were added.
9. Check that no slot was filled arbitrarily with a product feature, obstacle, result, slide count or closing ask.
10. Check that the output does not drift beyond the requested build story, seven-minute timing and live demo.
11. Check that spoken narration is separated from on-slide text and demo operations.
12. Check that any unresolved US legal or compliance issue is marked `[VERIFY]` rather than treated as established fact.