Ship Before You're Ready — Implementation-Ready Course Content Spec

1. Title and Source Files Used

Course title: Ship Before You're Ready Course number: 01 Primary source of truth: 01-ship-before-ready/curriculum.md Secondary source used for delivery tone and learner experience cues: 01-ship-before-ready/website-prompt.md

Source precedence rule: If this document and the website prompt conflict, curriculum.md wins on learning goals, assessments, and facilitation philosophy. The website prompt informs visual language, urgency, and student-facing messaging, not pedagogy.

2. Design Decisions at the Top

1. This is a 2-week course built around a 48-hour non-negotiable sprint.

The curriculum names a 2-week duration but details Day 0 through Day 3 explicitly. This spec resolves that by using Week 1 for the core instructional arc and Week 2 for repetition, consolidation, and habit formation.

1. Shipping is the product; polish is secondary.

Assessment rewards public completion, scope discipline, and evidence of action. A highly polished but unshipped project scores below an imperfect shipped one.

1. The course is cohort-based with live facilitation plus asynchronous build time.

The 48-hour sprint only works if students feel social pressure, visible deadlines, and public accountability.

1. Students can ship in any medium, but every artifact must be shareable.

Acceptable outputs include a tool, landing page, essay, prototype, deck, workflow, community event, dataset, automation, or media artifact. Every output must produce a URL, file, public post, or other verifiable share artifact.

1. Deadline integrity is part of the curriculum.

Extensions are not granted except for true emergencies defined before course launch. A missed deadline is handled through reflection and recovery, not deadline drift.

1. Psychological safety is built through normalization, not lowered standards.

Facilitators celebrate imperfect shipping, model their own unfinished work history, and prevent shame spirals, while still holding hard lines on time and proof.

1. The experience should feel urgent and manifesto-driven.

The website prompt's brutalist, countdown, high-contrast energy should carry into slides, worksheets, timers, email copy, and facilitation language.

1. LLM grading is evidence-based and conservative.

The LLM may assess clarity, specificity, reflection quality, and rubric alignment. It may not invent proof of shipping, infer originality without evidence, or override missing timestamps/screenshots.

1. Week 2 exists to convert a one-time adrenaline event into a repeatable operating system.

The course does not end at launch. It ends when the learner can articulate and calendar their next shipping cycle.

3. Delivery Model Assumptions

Audience

• Ages 15-25
• No prerequisites
• Mixed technical confidence is expected
• Students may ship solo or in pairs; pairs are allowed only if both students submit distinct reflections and clearly scoped contributions

Cohort Shape

• Recommended cohort size: 12-24 students
• Minimum viable cohort: 8 students
• Ideal staffing:
• 1 lead facilitator
• 1 operations producer/timekeeper
• 1 build coach or TA per 12 students

Modality

• Default model: live online cohort
• In-person adaptation is acceptable if the 48-hour deadline and proof-of-shipping standards remain unchanged
• Required synchronous windows:
• Day 0 kickoff
• Day 1 sprint launch
• Day 2 checkpoint
• Day 3 demo and debrief
• Week 2 protocol workshop
• Week 2 closeout

Calendar Assumptions

• Week 1
• Day -2 to Day -1: onboarding and setup
• Day 0: psychology of waiting
• Day 1 to Day 2: 48-hour sprint
• Day 3: debrief
• Week 2
• Day 5 or 6: systems and repetition lab
• Day 8 to Day 10: micro-ship and final commitments

Core Platforms

• Video: Zoom, Meet, or equivalent
• Chat/accountability: Slack, Discord, or WhatsApp cohort thread
• Submission hub: Notion, Airtable form, LMS, or shared drive
• Build stack: student's choice
• Public proof options:
• URL
• public doc
• social post
• Git repo
• Figma prototype link
• event page
• shareable PDF plus timestamped announcement

Required Pre-Course Setup

Before Day 0, every student must submit:

• a short intro
• time zone
• build medium they are most likely to use
• a list of tools/accounts they already have access to
• one project they have been postponing

Accessibility and Risk Assumptions

• Students may have low confidence, perfectionism, or fear of public judgment
• Public shipping can be adapted to "limited public" if safety requires it
• Students should be encouraged to choose a project with manageable reputational risk
• Facilitators should explicitly prohibit projects involving medical, legal, financial, or safety-critical claims unless appropriately supervised

Evidence Package Requirement

Every major submission should include an evidence bundle when relevant:

• direct link or file
• timestamp or screenshot
• 1-2 sentence description of intended audience
• statement of what changed from idea to shipped version

4. Detailed Course Content Broken Down by Module, Session, Lesson, Activity, Timing, Facilitator Moves, and Student Outputs

Module 0 — Onboarding and Constraint Setup

Purpose: Remove logistics as an excuse before the sprint begins.

Session 0.1 — Pre-Course Orientation

• Timing: 45 minutes live + 20 minutes async submission
• Lessons:
• The course rewards action, not readiness theater
• Constraints create momentum
• "Shareable" is a non-negotiable requirement
• Activities:
• 10 min: facilitator opens with course contract and deadline philosophy
• 10 min: examples of acceptable shipped outputs across mediums
• 10 min: explain assessment, proof standards, and no-extension policy
• 15 min: students fill out the "What I'm tempted to overbuild" worksheet
• 20 min async: tool/account check and intro form
• Facilitator moves:
• Frame the course as a behavior change lab, not a content-consumption experience
• Show one polished failure example and one messy shipped example; ask which one actually changed reality
• Normalize that confusion at the start is expected
• Student outputs:
• onboarding form
• tool readiness checklist
• initial "thing I am waiting to start" note

Module 1 — The Psychology of Waiting (Day 0)

Session 1.1 — The Readiness Myth

• Timing: 90 minutes live
• Session objective: Students identify readiness-seeking as a pattern rather than a rational necessity.

Lesson 1.1A — Why Humans Wait

• Timing: 25 minutes
• Content:
• loss aversion
• status quo bias
• identity protection
• fear of visible incompetence
• Activity:
• 5 min silent self-audit: "What do I say I need before I start?"
• 10 min mini-lecture
• 10 min pair discussion
• Facilitator moves:
• Ask for exact language students use to delay action: "after exams," "after I learn more," "after I have a team"
• Translate vague fears into observable behaviors
• Student outputs:
• personal delay pattern list
• one sentence naming their primary readiness excuse

Lesson 1.1B — Cost of Waiting

• Timing: 20 minutes
• Content:
• compound interest on momentum
• compound interest on fear
• opportunity cost of delayed iteration
• Activity:
• students plot one delayed idea on a simple timeline: first thought, delay period, missed iterations, lost feedback
• Facilitator moves:
• Push students to quantify delay in weeks or months, not feelings
• Ask, "How many feedback cycles did waiting cost you?"
• Student outputs:
• delay-cost timeline

Lesson 1.1C — Reading Discussion: Smart Quitting vs Avoidant Waiting

• Timing: 20 minutes
• Content:
• guided discussion on the distinction between strategic quitting and fear-based delay
• Activity:
• small-group debate using the prompt: "When is not shipping actually the correct choice?"
• Facilitator moves:
• Prevent shallow anti-planning takes
• Clarify that this course is anti-stalling, not anti-thinking
• Student outputs:
• 3-bullet distinction between wise restraint and avoidance

Lesson 1.1D — Reflection Drafting

• Timing: 25 minutes
• Activity:
• students draft their 300-word reflection in class
• Facilitator moves:
• Require concrete examples, not motivational slogans
• Encourage one sentence that begins: "The real thing I am protecting is..."
• Student outputs:
• draft of Assignment A1: Readiness Myth Reflection

Session 1.2 — Case Study: Before It Was Obvious

• Timing: 75 minutes live
• Session objective: Students see that credible outcomes often began as visibly incomplete attempts.

Lesson 1.2A — Case Burst: SpaceX, Airbnb, Instagram

• Timing: 30 minutes
• Content:
• SpaceX first three launches: repeated visible failure with continued iteration
• Airbnb cereal-box phase: ugly intermediary moves to preserve momentum
• Instagram compressed build-to-launch pace as contrast to over-preparation
• Activity:
• facilitator presents each case in 5-7 minute bursts
• students complete a "What was shipped before it was obvious?" grid
• Facilitator moves:
• Keep focus on behavior, not mythology
• Ask, "What did they release before they deserved confidence?"
• Student outputs:
• case study comparison grid

Lesson 1.2B — Would You Have Shipped?

• Timing: 20 minutes
• Activity:
• corners exercise or poll:
• I would have shipped earlier
• I would have waited
• I would have quit
• I do not know
• Facilitator moves:
• Surface differences between analytical caution and ego protection
• Invite students to notice when hindsight bias is making them braver than they would have been
• Student outputs:
• one-paragraph response explaining their choice

Lesson 1.2C — Sprint Framing

• Timing: 25 minutes
• Content:
• overview of the 48-hour sprint rules
• what counts as original
• what counts as shipped
• how to choose a project small enough to finish
• Activity:
• students list 10 project ideas to prepare for Day 1
• Facilitator moves:
• Ban "startup" as a scope category unless re-scoped to a shippable artifact
• Encourage ideas that create a single user-visible outcome in 48 hours
• Student outputs:
• 10-idea sprint list

Module 2 — The 48-Hour Sprint (Days 1-2)

Session 2.1 — Sprint Launch Workshop

• Timing: 120 minutes live
• Session objective: Students narrow from many ideas to one scoped artifact and begin building before leaving the session.

Lesson 2.1A — Idea Filtering

• Timing: 25 minutes
• Activity:
• students score each of their 10 ideas against four criteria:
• can be shipped in 48 hours
• produces a visible output
• slightly scary
• meaningful to someone beyond the student
• Facilitator moves:
• Force tradeoffs
• Reject ideas that depend on too many external approvals
• Student outputs:
• ranked idea matrix

Lesson 2.1B — Scope Lock

• Timing: 30 minutes
• Activity:
• students complete a one-page scope brief:
• who it is for
• what problem it solves
• what the minimum shipped version includes
• what is explicitly cut
• where it will be published
• Facilitator moves:
• Ask, "What is the one thing this artifact must do to count as real?"
• Require a kill list of nice-to-haves
• Student outputs:
• Assignment A2: Scope Brief

Lesson 2.1C — Launch Post Skeleton

• Timing: 15 minutes
• Activity:
• students pre-write the structure of their eventual 200-word launch post
• Facilitator moves:
• Explain that public language creates psychological commitment
• Student outputs:
• launch post outline

Lesson 2.1D — First Build Block

• Timing: 50 minutes
• Activity:
• silent work sprint to create the first visible version
• Facilitator moves:
• Interrupt only for blockers
• Require every student to post a screenshot, sentence, wireframe, repo, or draft before session end
• Student outputs:
• first proof-of-existence artifact

Session 2.2 — Async Build Window: Hour 2-24

• Timing: 22 hours async with structured check-ins
• Session objective: Convert idea into minimally viable reality.
• Student work expectations:
• build core version
• eliminate major blockers
• document decisions in a simple build log
• Required checkpoints:
• Hour 6: screenshot or proof of working draft
• Hour 12: one blocker and one solved problem
• Hour 24: version that could theoretically be shared if needed
• Facilitator moves:
• Maintain visible deadline pressure in cohort chat
• Reply to perfectionist spirals with scope reduction, not reassurance alone
• Use short prompts: "What are you cutting?" "What is live already?" "What is the single failure point?"
• Student outputs:
• build log
• checkpoint posts

Session 2.3 — Mid-Sprint Critique

• Timing: 45 minutes live at approximately Hour 24
• Session objective: Force students to confront whether they are actually on track to ship.

Activities

• 15 min: each student gives a 60-second status report:
• what exists
• what still blocks shipping
• what they are cutting
• 20 min: facilitator triage and peer feedback
• 10 min: deadline recommitment

Facilitator moves

• Sort students into three categories:
• on track
• over-scoped but salvageable
• at risk of missing ship
• For over-scoped projects, mandate a smaller version immediately
• For at-risk students, define a "floor ship" that can be published within 6 additional hours

Student outputs

• revised scope
• updated publish plan

Session 2.4 — Async Build Window: Hour 24-42

• Timing: 18 hours async
• Session objective: Move from build mode to launch-readiness mode.
• Student work expectations:
• fix the most damaging issue
• add only one meaningful improvement
• prepare shipping assets
• Shipping assets checklist:
• title
• one-sentence description
• thumbnail or screenshot if applicable
• URL/file
• launch post draft
• Facilitator moves:
• Repeat the rule: no new major features after Hour 30
• Push students toward publishable framing
• Student outputs:
• near-final artifact
• launch asset pack

Session 2.5 — Launch and Announcement Lab

• Timing: 75 minutes live near Hour 42-46
• Session objective: Remove the final emotional barrier to public release.

Lesson 2.5A — Launch Readiness Review

• Timing: 25 minutes
• Activity:
• peer review in pairs using a launch checklist
• Checklist items:
• is it accessible?
• is the audience clear?
• does the artifact actually do or say something complete?
• is the call to action or next step visible?
• Facilitator moves:
• Block students from reopening core architecture choices
• Define "good enough to learn from"
• Student outputs:
• peer-reviewed launch checklist

Lesson 2.5B — Publish Block

• Timing: 30 minutes
• Activity:
• students hit publish, post, send, or share live during the session if ready
• Facilitator moves:
• Count down publicly
• Ask students to paste links in chat immediately after launch
• Student outputs:
• Assignment A3: Shipped Artifact
• Assignment A4: Launch Post

Lesson 2.5C — Immediate Reflection

• Timing: 20 minutes
• Activity:
• quick write:
• what felt hardest?
• what turned out easier than expected?
• what almost stopped the shipment?
• Facilitator moves:
• Capture emotional state before retrospection rewrites memory
• Student outputs:
• raw sprint reflection notes

Module 3 — The Debrief (Day 3)

Session 3.1 — What Actually Happened

• Timing: 120 minutes live
• Session objective: Convert the shipping event into explicit learning.

Lesson 3.1A — Demo Round

• Timing: 60 minutes
• Activity:
• each student gets:
• 2 minutes to show the artifact
• 1 minute to describe what changed between idea and final version
• 1 minute for peer questions
• Facilitator moves:
• Keep demos focused on what is real and visible
• Celebrate clarity of scope and honesty about tradeoffs
• Student outputs:
• demo recording or presentation notes

Lesson 3.1B — Imagined Difficulty vs Actual Difficulty

• Timing: 25 minutes
• Activity:
• students fill a two-column analysis:
• what I thought would be hard
• what was actually hard
• Facilitator moves:
• Highlight mismatch patterns such as overestimating technical build and underestimating emotional resistance
• Student outputs:
• difficulty comparison sheet

Lesson 3.1C — Reframing Failure

• Timing: 35 minutes
• Activity:
• structured postmortem on projects that shipped imperfectly or missed target quality
• Prompt set:
• what was the smallest true win?
• what failed because of scope?
• what failed because of avoidance?
• what should be repeated?
• Facilitator moves:
• Separate missed quality from missed integrity
• Avoid false consolation; insist on specific lessons
• Student outputs:
• Assignment A5: Sprint Postmortem

Session 3.2 — Building the Muscle

• Timing: 90 minutes live
• Session objective: Turn the sprint from an isolated event into a repeatable practice.

Lesson 3.2A — Designing a Personal Shipping Environment

• Timing: 25 minutes
• Content:
• accountability partners
• time-boxing
• pre-commitment devices
• default tool stacks
• Activity:
• students design a "fast-start environment"
• Facilitator moves:
• Ask for environmental design, not aspiration statements
• Student outputs:
• fast-start environment map

Lesson 3.2B — Monthly Ship Cycle Design

• Timing: 20 minutes
• Activity:
• students place a recurring sprint date on their calendar for the next 3 months
• Facilitator moves:
• Require dates, not intentions
• Student outputs:
• 3-month shipping calendar

Lesson 3.2C — Ship Protocol Workshop

• Timing: 45 minutes
• Activity:
• students draft a one-page operating procedure covering:
• how they choose projects
• how they set deadlines
• how they decide what to cut
• what public proof they require
• what they do if fear spikes
• Facilitator moves:
• Push for if/then rules
• Ban vague advice to self
• Student outputs:
• Assignment A6: Ship Protocol

Module 4 — Consolidation and Repetition (Week 2)

Session 4.1 — Systems Lab

• Timing: 75 minutes live in Week 2
• Session objective: Identify what made shipping possible and build systems to repeat it.

Activities

• 15 min: review anonymized patterns from cohort sprint data
• 20 min: students diagnose their top three friction points
• 20 min: students redesign one tool/process to reduce startup time by 50 percent
• 20 min: peer review of ship protocols

Facilitator moves

• Translate emotional complaints into operational fixes
• Examples:
• "I got overwhelmed" becomes "I did not define a floor ship"
• "I wasted time deciding" becomes "I need a default stack and publish channel"

Student outputs

• revised ship protocol
• friction-to-system conversion worksheet

Session 4.2 — Micro-Ship Challenge

• Timing: 4-6 hours async within Week 2
• Session objective: Reinforce that shipping is repeatable without 48 hours of adrenaline.

Rules

• Must be started and finished inside a single day
• Must be meaningfully smaller than the main sprint artifact
• Must still be shared with a real audience or public channel

Suggested micro-ship formats

• publish a short essay
• release a simple landing page
• ship a workflow automation
• host a small event invite
• post a public build note with a resource attached

Facilitator moves

• Emphasize repeatability over ambition
• Reward fast scope selection

Student outputs

• Assignment A7: Micro-Ship Artifact

Session 4.3 — Final Review and Commitment Close

• Timing: 60 minutes live
• Session objective: End with visible evidence that students now possess a repeatable shipping practice.

Activities

• 20 min: micro-ship showcase
• 20 min: final reflection prompt:
• what changed in my behavior?
• what still causes hesitation?
• what will I ship in the next 30 days?
• 20 min: public commitment round

Facilitator moves

• Require one concrete next shipment date from every student
• Close with identity shift: from "someone preparing" to "someone who ships"

Student outputs

• final commitment statement
• next-30-day ship pledge

5. Assignments and Artifacts

Graded Core Assignments

Required but Non-Weighted Completion Artifacts

Submission Requirements by Artifact

A1 — Readiness Myth Reflection

• 300 words target, acceptable range 250-400
• Must identify one real project the student has delayed
• Must explain the cost of delay
• Must name one fear or identity protection mechanism

A2 — Scope Brief

• One page maximum
• Must include audience, promise, floor ship, kill list, and publish channel

A3 — Shipped Artifact

• Must be accessible to evaluator
• Must have evidence that it was published/shared by deadline
• Must be original enough that the student made meaningful decisions
• Must be complete enough that a real audience can understand what it is

A4 — Launch Post

• 150-250 words
• Must state:
• what was built
• who it is for
• why it was worth shipping now
• invitation or next step

A5 — Sprint Postmortem

• 250-500 words
• Must distinguish scope failure from execution failure

A6 — Ship Protocol

• One page target, up to two pages allowed
• Must include at least five if/then rules
• Must include calendar commitments
• Must include a method for handling fear, perfectionism, or avoidance

A7 — Micro-Ship Artifact

• Smaller than A3
• Same proof requirements as A3, but pass/fail

6. AI/LLM Grading and Assessment Framework

Role of the LLM

The LLM acts as a structured evaluator for written work and a rubric interpreter for shipped artifacts. It is not the sole authority on proof of publication when evidence is missing or ambiguous.

What the LLM Can Reliably Grade

• reflection specificity
• quality of causal reasoning
• clarity of audience and problem statement
• evidence of scope discipline
• protocol quality and actionability
• alignment of launch post with shipped artifact

What the LLM Must Not Infer

• that an artifact was shipped if no evidence bundle is provided
• that a student created original work if the submission is inaccessible
• that project quality equals learning quality
• that confidence in writing equals real behavioral change

Recommended Evaluation Inputs

Every LLM evaluation packet should include:

• course rubric excerpt for that assignment
• raw student submission
• artifact link or screenshot when relevant
• timestamp or publish evidence
• prior scope brief when grading the shipped artifact

Recommended Evaluation Outputs

The LLM should return:

• numerical score
• rubric row scores
• evidence-backed rationale quoting or paraphrasing the submission
• confidence level: high, medium, or low
• missing evidence flag if applicable
• one concrete next action for the student

Assessment Logic by Assignment

A1 — Reflection

• Look for specificity over abstraction
• Reward causal honesty
• Penalize vague self-help language with no real example
• Heuristic flags:
• Strong: names a real delayed project, pinpoints fear, quantifies delay cost, states a changed belief
• Average: describes delay generally, offers some specifics, but remains partly generic
• Weak: motivational clichés, no real project, no mechanism of delay

A3 — Shipped Artifact

• Grade shipping integrity first, quality second
• Required checks:
• Was it shipped/shared by deadline?
• Is the audience identifiable?
• Is there a complete user-visible outcome?
• Is scope appropriately bounded?
• Heuristic flags:
• Strong: real link or clear evidence, coherent minimum viable outcome, obvious tradeoffs, artifact understandable by outsider
• Average: shipped but muddy audience, weak framing, or minor completion gaps
• Weak: draft only, inaccessible artifact, private unfinished build, or no verifiable proof

A4 — Launch Post

• Reward concise communication and real ownership
• Check alignment between post claims and actual artifact
• Penalize inflated claims unsupported by artifact

A6 — Ship Protocol

• Reward operational clarity
• High scores require reusable rules, triggers, and dates
• Penalize aspirational statements without execution mechanics

Human Escalation Triggers

Escalate to human review if:

• submission includes safety-sensitive claims
• originality is disputed
• artifact access is broken
• evaluator confidence is low
• evidence of deadline compliance is ambiguous

Concrete LLM Heuristics for Scoring

Use the following conservative heuristics:

• Deadline proof present: + essential for any score above developing on A3/A4
• Audience named concretely: strong signal of real-world orientation
• Kill list or cut features referenced: strong signal of scope discipline
• Specific failure analysis: strong signal of learning
• Generic productivity language: negative signal unless tied to evidence
• Artifact inaccessible: cap A3 at 50/100 pending human review
• No public/share evidence: cap A3 at 59/100 even if artifact appears complete
• Protocol lacks dates or triggers: cap A6 at 69/100

7. Rubrics, Scoring Criteria, and Evaluator Prompt Guidance

Score Bands

Rubric: A1 Readiness Myth Reflection

Rubric: A3 Shipped Artifact

Rubric: A4 Launch Post

Rubric: A6 Ship Protocol

Weighted Final Grade Formula

• A1 Reflection: 20 percent
• A3 Shipped Artifact: 40 percent
• A4 Launch Post: 20 percent
• A6 Ship Protocol: 20 percent

Minimum Passing Conditions

A student should not pass the course unless all of the following are true:

• A3 submitted with some proof of shipping attempt
• A4 submitted
• A6 submitted
• student attended or completed equivalent evidence for the Day 3 debrief

Evaluator Prompt Guidance

Use the following prompt template for LLM grading:

You are evaluating student work for the course "Ship Before You're Ready."

Your job is to grade against the provided rubric, not against your personal taste.
This course rewards shipping, scope discipline, honesty, and evidence of action.
Do not reward polish over shipping. Do not invent evidence that is missing.
If proof of shipping is missing or ambiguous, say so explicitly and lower confidence.

Inputs:
1. Assignment type: {A1|A3|A4|A6}
2. Rubric: {paste relevant rubric}
3. Student submission: {paste submission}
4. Evidence bundle: {links, screenshots, timestamps, scope brief if relevant}

Return exactly:
- Score: X/100
- Band: Exemplary | Proficient | Developing | Not Yet
- Confidence: High | Medium | Low
- Rubric breakdown: one line per criterion with points and rationale
- Evidence used: bullet list of specific details you relied on
- Missing evidence or concerns: bullet list
- Feedback to student: 120-180 words, direct and specific
- Next action: one concrete step the student should take within 7 days

Additional rules:
- Cap A3 at 50/100 if the artifact is inaccessible.
- Cap A3 at 59/100 if there is no verifiable shipping proof.
- Cap A6 at 69/100 if there are no dates, triggers, or recurring cadence.
- Penalize generic motivational language when it replaces concrete analysis.
- Reward explicit feature-cutting and audience clarity.
```

### Evaluator Calibration Notes

- Compare the submission to course intent, not professional industry standards
- A crude but real artifact should outperform a sophisticated draft
- A student who clearly learned from a messy launch may still score well
- Avoid punishing beginner technical ability if the shipping standard was met

---

## 8. Feedback Strategy: What Strong/Average/Weak Responses Look Like and How an LLM Should Respond

### Feedback Philosophy

Feedback should reinforce action, honesty, and repeatability. It should never accidentally teach students that their real mistake was "not being impressive enough." The LLM should sound clear, unsentimental, and constructive.

### Strong Response Pattern

**What it looks like:**

- student chose a tight scope
- artifact shipped on time with clear proof
- reflection identifies real fear or avoidance mechanism
- launch post is plain, accurate, and audience-aware
- ship protocol contains reusable rules and dates

**How the LLM should respond:**

- name the specific behavior that worked
- show why the decision quality was strong
- identify one leverage point for the next shipment
- avoid telling the student to make it prettier unless it affects usefulness

**Example feedback stance:**
You made the correct tradeoff by cutting scope and protecting the deadline. The artifact is small, but it is real, accessible, and aimed at a defined audience. Your protocol is strongest where it turns emotion into procedure.

### Average Response Pattern

**What it looks like:**

- student did ship, but the artifact or post is muddy
- reflection contains some specificity but also generic language
- protocol has good instincts but weak triggers, dates, or enforcement
- scope was mostly controlled, though some drift is visible

**How the LLM should respond:**

- acknowledge the shipment first
- isolate the single biggest weakness
- convert broad advice into one operational change
- keep tone steady; do not overpraise

**Example feedback stance:**
You crossed the most important threshold by shipping, but your audience and value proposition remain too vague. The next improvement is not a better artifact. It is a sharper sentence describing who this is for and what changed for them.

### Weak Response Pattern

**What it looks like:**

- no proof of shipping or only a draft
- reflection avoids vulnerability and stays abstract
- launch post overclaims relative to the artifact
- protocol is aspirational, with no dates or rules

**How the LLM should respond:**

- be direct about what is missing
- separate the missing standard from personal worth
- require a concrete recovery action within 24-72 hours
- avoid vague encouragement

**Example feedback stance:**
This submission does not yet demonstrate shipping integrity because the artifact proof is missing and the protocol does not contain executable rules. The immediate fix is to publish the smallest valid version and document the timestamp, then rewrite the protocol with dates and if/then triggers.

### Recommended LLM Feedback Structure

For every evaluated assignment, the feedback block should follow this sequence:

1. state the core verdict in one sentence
2. cite 2-3 pieces of evidence from the submission
3. explain the most important gap
4. assign one next action
5. ask one reflective question only if it sharpens future action

### Phrases the LLM Should Prefer

- "The strongest choice you made was..."
- "The evidence for shipping is..."
- "The main gap is..."
- "To improve this, change..."
- "Your next shipment will be easier if..."

### Phrases the LLM Should Avoid

- "This is amazing"
- "I love this"
- "You are clearly passionate"
- "Just believe in yourself"
- "Try harder next time"

### Recovery Guidance for Missed Shipments

If a student misses the shipping deadline, the LLM should:

- mark the missed standard clearly
- ask for a 24-hour recovery plan
- require a floor-ship version
- direct the student to identify the exact point where scope or avoidance broke the process

Suggested response structure:

- "You did not meet the shipping standard yet."
- "The missing evidence is..."
- "Within 24 hours, publish the smallest valid version by doing..."
- "For your postmortem, name the moment you should have cut scope but did not."

---

## Implementation Notes for Course Team

- Use countdown visuals, bold deadlines, and manifesto-style copy in slides and workspace assets to match the website direction.
- Keep templates brutally simple: one-page scope brief, one-page protocol, short evidence forms.
- Do not overteach product frameworks during the sprint; they become new excuses.
- The facilitator's highest-leverage intervention is aggressive scope control.
- The course succeeds if students leave with less reverence for readiness and more evidence that they can create under constraint.