Pitch Package

Pitch Package

Make the real project's core behavior and technical contribution easy to understand within the event's time limit.

Workflow

1. Read the actual implementation, available demo artifacts, event requirements and existing project story. Inventory implemented, partially implemented, simulated and proposed capabilities.
2. Select one user situation and one end-to-end action that the project can demonstrate. Connect the visible output to the initial problem or creative aim.
3. Build a timed script for the event's required duration. Front-load the core purpose and show the working behavior early; skip routine account setup where appropriate.
4. Pair each important claim with a live action, reproducible measurement, screenshot or inspectable artifact. State sample size and conditions for measured gains.
5. Write the project story in the submission form's actual fields and limits: purpose, behavior, implementation, hard challenge, learning, contribution and realistic next step.
6. Prepare concise Q&A answers about required technology, novelty, prior work, AI assistance, failure modes and what the team built during the event.
7. Rehearse at natural speed. Reduce content rather than accelerate speech. Confirm that screen text is readable and the relevant output is visible when mentioned.
8. Create an operator runbook with starting state, inputs, reset steps and a clearly labeled fallback. Check judge access to required links before handing off.

Outputs

Use existing project conventions or place drafts under artifacts/pitch/:

• demo-script.md: timestamps, spoken words, screen actions, expected output and fallback.
• project-story.md: submission-ready text matched to required fields and length limits.
• judge-qa.md: short answers with supporting evidence or an explicit unknown.
• demo-runbook.md: setup, run, reset, dependencies and fallback labeling.

Create screenshots, a recording or slides only when requested or useful to the required submission. A script is not a finished video; report accurately which assets exist.

Truth and submission constraints

• Do not claim live execution for replay, cached output, simulation or edited recordings. Label time compression when timing matters.
• Do not invent user quotes, measured gains, traction, partnerships, awards or completed features.
• Separate current behavior from future plans and narrow examples from broad reliability claims.
• Explain AI-generated work, reused components and prior materials according to the event's requirements.
• If the rubric values learning or technical exploration rather than commercialization, reflect that instead of forcing a startup pitch.
• Preserve honest limitations while giving the working capability enough time to be understood.
• Preparing this package does not imply authorization to upload, publish, message or submit it; use the user's existing authorization for those actions.

Done when the timed demo, written story and Q&A make consistent claims supported by the actual project.