Course 09 Course Content Spec: Deep End Deployment

1. Title and source files used

Course title: Deep End Deployment

Owned output file: 09-deep-end-deployment/09_deep_end_deployment_course_content.md

Source files used

• 09-deep-end-deployment/curriculum.md
• 09-deep-end-deployment/website-prompt.md

Source-of-truth rule

• curriculum.md governs pedagogy, learning objectives, course arc, and assessment intent.
• website-prompt.md governs tone, visual language, framing, and student-facing emotional posture.
• Where the two sources differ operationally, this document resolves the ambiguity into one implementation-ready delivery plan.

2. Design decisions at the top

1. This course only works with real partner organizations. No simulated cases, dummy briefs, or classroom-only substitutes. If no partner pipeline exists, the course should not run.
2. Standardized format: Phase 0 placement + 4 live sessions + async deployment + async memo. The curriculum references "5 sessions" and the website prompt lists four live moments; this spec resolves that by treating placement as a facilitated pre-course phase rather than a numbered live class.
3. Default runtime is 3 weeks, expandable to 4 weeks. A 2-week version is possible only for highly responsive partners and smaller-scope projects.
4. The first 72 hours are the primary leading indicator. The course is designed around initial diagnosis, speed of orientation, and first contribution, not around polished final deliverables.
5. Students are judged on contribution quality under ambiguity, not domain mastery. A rough but correctly targeted artifact beats a polished but irrelevant one.
6. Reflection is part of the work, not a postscript. The identity shift matters as much as the external artifact.
7. Partner experience matters. Students are not free labor. They must create value without creating coordination drag or trust damage.
8. Assessment uses LLM support but not LLM autonomy. LLMs generate evidence-tagged draft evaluations; a human facilitator approves final grades, especially for borderline cases, partner complaints, or integrity concerns.
9. Evidence beats self-report. Students must submit artifacts, communications logs, notes, and stakeholder feedback. Unsupported claims score lower.
10. Tone should feel like a mission briefing, not school. Facilitation should be direct, high-trust, and high-standard, consistent with the website prompt's deployment framing.

3. Delivery model assumptions

Cohort and staffing assumptions

• Target cohort size: 12-24 students
• Partner count: 4-8 organizations
• Placement ratio: 1-3 students per organization, with 1 preferred for highest accountability
• Lead facilitator: runs live sessions, calibrates standards, resolves escalations
• Deployment coordinator: manages partner matching, logistics, risk, and check-ins
• Assessment lead: oversees rubric calibration, LLM evaluation pipeline, and final grades
• Optional partner liaison: useful if partners are high-profile, time-constrained, or international

Learner assumptions

• Age band: 16-25
• Prerequisite completion: at least 2 prior Project Agni courses
• Recommended prior courses: 01, 03, or 05
• Baseline capability: can write clearly, run meetings, synthesize ambiguity, and produce a basic deliverable without step-by-step instruction
• Weekly time commitment: 8-12 hours per week minimum, including partner time

Delivery format assumptions

• Primary mode: cohort-based, live-sync + field deployment
• Default duration: 3 weeks
• Live sessions: 4 synchronous sessions, 90-120 minutes each
• Async deployment time: ongoing across weeks 1-3
• Memo writing window: 3-5 days after the main deployment ends
• Communication stack: email, Slack/Discord/WhatsApp, shared drive, scheduling tool, and optional project management board

Partner/project assumptions

• Partners must offer:
• A real project with live stakes
• A named point of contact
• Access to enough context for the student to act
• A problem with genuine ambiguity
• A timeline where a student can produce useful movement in 2-4 weeks

• Partners must not offer:
• Purely clerical work
• Tasks with zero stakeholder relevance
• Fake "innovation projects" no one cares about
• Work requiring legal/regulatory responsibility beyond a student's authority
• Projects where success requires proprietary access the partner will not grant

Risk and safeguarding assumptions

• Students must sign a professionalism and confidentiality agreement if partner work requires it.
• No student should be asked to represent themselves as an employee, expert, or decision-maker beyond their actual role.
• Students should escalate if they encounter unethical requests, unsafe labor expectations, or unmanageable ambiguity.
• Facilitators should have a fallback reassignment protocol if a partner disappears or becomes unusable in week 1.

Evidence collection assumptions

Each student must maintain a lightweight deployment record containing:

• Time-stamped notes from stakeholder conversations
• Public research collected in the first 48 hours
• Drafts and shipped artifacts
• A communication log showing initiative and follow-through
• A short partner feedback form or recorded feedback statement

4. Detailed course content broken down by module, session, lesson, activity, timing, facilitator moves, and student outputs

Course arc overview

Phase 0: Placement and partner readiness

Duration: 5-7 days pre-course Facilitated touchpoints: partner intake, student ranking, match confirmation, deployment brief release

Objectives

• Confirm only high-quality partner projects enter the cohort.
• Match students to projects where ambiguity is real but survivable.
• Preserve the "no hand-holding" philosophy without creating preventable chaos.

Partner intake requirements

Partners submit:

• Organization description
• One-sentence stated problem
• One paragraph on what is actually at stake
• Available tools/access
• Primary contact and expected response time
• Constraints, confidentiality needs, and non-negotiables

Facilitator screens for:

• Real urgency
• Clarity of stakes
• Appropriate scope
• Student safety and legitimacy
• Likelihood of meaningful contribution within 2-4 weeks

Student pre-work

Students submit:

• One-page capability profile
• Ranked partner preferences
• A short note on why each top choice fits their edge
• A statement of what kind of ambiguity they handle well and poorly

Phase 0 activity plan

Phase 0 facilitator script guidance

• Use language like: "You are being matched to a live problem, not a role."
• Do not give students hidden context the partner has not shared.
• Do tell partners that students should not be treated as passive interns waiting for tasks.

Module 1: The Briefing

Session length: 120 minutes When: Week 1, Day 1

Session goals

• Establish the psychological contract.
• Teach the 48-hour diagnostic protocol.
• Force each student to define a concrete first contribution.

Session agenda

Required takeaways from Module 1

Each student leaves with:

• A list of the first 3 people to contact
• A 72-hour deliverable
• A hypothesis about the real problem
• A top risk they will monitor
• A communication norm for escalating confusion

Deployment Window A: First 72 hours

Duration: Days 1-3 after Session 1 Primary goal: establish traction quickly

Required student actions

1. Research the organization using only public and partner-provided materials.
2. Hold at least 2 conversations:

• one with point of contact
• one with another stakeholder

1. Produce one concrete shipped output by hour 72.
2. Log what changed between the stated problem and the observed problem.

Acceptable first outputs

• A rewritten investor or donor narrative
• A scoped operating memo
• A cleaned dataset with initial insights
• A user-interview synthesis
• A product teardown with recommended decisions
• A dashboard prototype
• A process map revealing bottlenecks

Unacceptable first outputs

• "I am still getting context"
• A long note with no decision or deliverable attached
• A speculative strategy deck no one asked for and no stakeholder has seen
• A work product that ignores partner realities or permissions

Facilitator monitoring during Window A

Module 2: Mid-Deployment Check-In

Session length: 90 minutes When: End of Week 1

Session goals

• Surface the gap between initial assumptions and actual organizational reality.
• Correct under-contribution, overreach, and drift.
• Re-scope week 2 work around a sharper understanding of value.

Session agenda

Facilitator diagnostics in Module 2

Watch for:

• Students hiding behind busyness instead of shipped work
• Students creating value no one internally recognizes
• Students avoiding politically sensitive but central stakeholders
• Students over-identifying with the first person they met
• Students confusing responsiveness with alignment

Student output requirements after Module 2

By the next 72 hours, each student must submit:

• Revised problem statement
• Updated stakeholder map
• One week-2 objective
• One explicit thing they will stop doing

Deployment Window B: Focused contribution

Duration: Week 2 Primary goal: turn orientation into useful movement

Recommended work pattern

• Day 1 of week 2: align on target outcome
• Day 2-4: build, test, revise
• Day 5: present, hand off, or secure decision

Facilitator role in Window B

• Stay available for escalation, but do not rescue students from ambiguity that is still productive.
• Intervene if the student is clearly mis-scoped, blocked by access, or damaging partner trust.
• Push students to define what "partner-relevant progress" means by the end of week 2.

Module 3: Structured Debrief

Session length: 120 minutes When: End of Week 2

Session goals

• Convert raw activity into judgment.
• Separate the problem given from the problem discovered.
• Make students narrate their own behavior under pressure.

Session agenda

Peer review prompts

Peers must answer:

• What did this student do that demonstrated day-one contribution?
• What assumption did they carry too long?
• What question should they sit with before the next deployment?

Module 4: Deep End Memo

Format: asynchronous, 2,000-3,000 words When due: 3-5 days after Module 3

Memo purpose

The memo converts a live deployment into durable operating insight. It should become a future interview story, self-diagnostic artifact, and proof that the student can extract principles from live ambiguity.

Required memo structure

Memo quality bar

Strong memos:

• cite evidence
• name real mistakes
• distinguish signal from story
• show changed judgment, not just changed feelings
• connect personal reflection to real operating decisions

Weak memos:

• overdramatize simple events
• describe effort without effect
• claim growth without evidence
• avoid naming misreads, political mistakes, or shallow assumptions

Module 5: Cohort Showcase

Session length: 120 minutes When: Week 3 or 4, after memo submission

Session goals

• Help students consolidate a durable "deep end story."
• Create public accountability for learning extraction.
• Make the identity shift explicit.

Session agenda

Showcase presentation structure

Students must include:

• The original brief
• The actual situation they discovered
• The artifact they produced
• The biggest mistake they made
• The most important thing they learned about how they operate

5. Assignments and artifacts

Assignment list

Artifact standards

A2-A3: 72-hour plan and first output

Must include:

• 3 named stakeholders or stakeholder roles
• 1 working hypothesis about the actual problem
• 1 deliverable due by hour 72
• Proof of delivery
• 100-200 words on what changed between hour 0 and hour 72

A4: Week 1 status report

Must answer:

• What did you think the problem was?
• What do you now think it is?
• What did you produce?
• What is still unclear?
• What will you do in week 2?

A5: Work product

Acceptable formats:

• memo
• analysis
• prototype
• dashboard
• process redesign
• research synthesis
• communication asset
• operating recommendation

The artifact must matter to a real stakeholder. Purely performative classroom work does not count.

A7: Deep End Memo

Submission packet must include:

• memo
• appendix with artifacts or links
• partner/project context summary
• one paragraph on what the student would do differently if restarting

A9: Partner feedback

Partner form should ask:

• Was the student proactive?
• Did the student improve in relevance over time?
• Did the student produce something useful?
• Did the student require too much hand-holding?
• Would you trust this student on another ambiguous project?

6. AI/LLM grading and assessment framework

Role of the LLM

The LLM is used to:

• extract evidence from student submissions
• score against rubrics using stated criteria
• draft feedback aligned to the student's performance band
• flag contradictions, unsupported claims, and missing evidence

The LLM is not used to:

• invent missing evidence
• decide integrity violations without human review
• override documented partner feedback
• make final pass/fail decisions in disputed cases

Assessment pipeline

1. Ingest all student artifacts: plans, outputs, notes, presentations, memo, partner feedback.
2. Normalize them into one evaluation packet per student.
3. Extract evidence using the rubric dimensions below.
4. Assign provisional criterion scores with direct evidence citations.
5. Run contradiction check between student self-report and artifacts/partner feedback.
6. Generate narrative feedback matched to the student's actual evidence band.
7. Human facilitator reviews low-confidence, edge-case, or escalated evaluations before release.

Core rubric dimensions for LLM scoring

Scoring model

• Each rubric dimension is scored on a 1-5 scale.
• Deliverable scores are calculated from the relevant dimensions.
• Final course grade is a weighted composite of assignments, not a simple average of rubric dimensions.
• If partner feedback directly contradicts the student's self-report, the LLM must reduce confidence and flag for human review.

Confidence rules for the LLM

• High confidence: multiple artifacts support the same conclusion.
• Medium confidence: evidence is present but uneven or partially inferred from context.
• Low confidence: the student makes claims without artifact support, or partner data is missing.

The LLM must label each evaluation with one of those confidence levels.

Automatic flags for human review

• No first output by hour 72
• Partner reports unreliability or boundary issues
• Submission contains generic reflection with no evidence
• Work product appears substantially AI-generated without grounded deployment evidence
• Student claims impact that cannot be traced to any stakeholder response or artifact
• Severe mismatch between polished memo and weak documented execution

7. Rubrics, scoring criteria, and evaluator prompt guidance

Master performance scale

Assignment-specific scoring criteria

A2-A3: 72-hour plan + first output

A4: Week 1 status report

A5: Work product

A6-A7: Debrief + Deep End Memo

A8-A9: Showcase + partner feedback

Concrete assessment heuristics for LLM evaluation

The LLM should use the following heuristics:

• Initiative heuristic: score up when the student made specific asks, secured conversations quickly, and shipped before being fully comfortable.
• Diagnosis heuristic: score up when the student names what evidence changed their understanding of the problem.
• Value heuristic: score up when there is a visible stakeholder response, adoption, decision influence, or handoff.
• Scope-control heuristic: score down when the student built too much before alignment or stayed too abstract for too long.
• Reflection heuristic: score up when the student can name not just what happened, but why they behaved as they did and what they will change.
• Credibility heuristic: score down when the memo claims growth or impact that the artifacts do not support.
• Professionalism heuristic: score down when deadlines slip without communication, partner trust declines, or deliverables arrive without context.

Evaluator prompt guidance

System prompt for evaluator LLM

You are evaluating a Project Agni course called "Deep End Deployment."
You must grade only from provided evidence.
Do not infer unstated impact.
Do not reward polish over relevance.
Do not punish roughness if the work clearly created value under ambiguity.
For every score, cite the evidence that supports it.
If evidence is missing, say so explicitly.
If the student's claims conflict with partner feedback or artifacts, lower confidence and flag for human review.
```

#### Core evaluation prompt template

Evaluate this student's performance in Deep End Deployment.

Inputs:

• Deployment brief
• 72-hour plan
• First shipped output
• Week 1 status report
• Work product
• Debrief notes
• Deep End Memo
• Showcase transcript or slides
• Partner feedback

Tasks:

1. Summarize the student's actual deployment in 120 words or less.
2. Extract evidence for these dimensions:

• Initiative under ambiguity
• Diagnostic quality
• Value creation
• Stakeholder navigation
• Reflection quality
• Professional reliability

1. Score each dimension from 1-5 with one quoted or paraphrased evidence reference.
2. Calculate provisional assignment-level judgments:

• 72-hour plan + first output
• Week 1 status report
• Work product
• Debrief + memo
• Showcase + partner trust

1. Assign confidence level: high, medium, or low.
2. Flag any contradictions, unsupported claims, or reasons for human review.
3. Write feedback in three parts:

• What the student did well
• Where the student misread or underperformed
• What they should change on the next deployment

Output format:

• Summary
• Dimension scores
• Assignment judgments
• Confidence
• Human review flags
• Feedback

#### Prompt add-ons for specific failure cases

- If the student overstates impact: "Check whether claimed partner impact is verified by partner feedback, artifact usage, or a decision trace."
- If the memo is polished but execution is weak: "Prioritize execution evidence over narrative quality."
- If the work product is rough but partner loved it: "Do not penalize low polish if usefulness is clearly evidenced."

## 8. Feedback strategy: what strong/average/weak responses look like and how an LLM should respond

### Feedback principles

- Be direct.
- Tie feedback to observed evidence.
- Separate execution feedback from identity judgment.
- Praise only what is concretely earned.
- Turn weak performance into a next-deployment playbook, not generic encouragement.

### What strong responses look like

Strong responses usually show:
- movement in the first 72 hours
- a visible shift from stated problem to actual problem
- at least one useful artifact adopted, discussed, or acted on by stakeholders
- accurate reading of organizational dynamics
- memo-level honesty about mistakes without collapsing into self-criticism theater

#### How the LLM should respond to strong work

The LLM should:
- identify the exact behaviors worth repeating
- name the operating principles the student demonstrated
- point to the next level of challenge, usually sharper stakeholder navigation or bigger-scope ambiguity

**Example feedback posture**
- "You created trust by shipping early and revising quickly once the real problem surfaced. Keep that pattern. Your next edge is political reading: get to the real decision-maker faster."

### What average responses look like

Average responses usually show:
- some initiative, but delayed sharpness
- a useful but only partially aligned artifact
- an emerging understanding of the real problem
- reflection that is sincere but not yet rigorous
- partner value that is plausible but not strongly evidenced

#### How the LLM should respond to average work

The LLM should:
- acknowledge what crossed the bar
- precisely identify where the student stayed too vague, too late
- convert the feedback into 2-3 concrete behaviors for next time

**Example feedback posture**
- "You did not freeze, which matters. But you stayed in context-gathering mode too long before putting a point of view in front of the partner. Next time, force a draft recommendation earlier, even if it is provisional."

### What weak responses look like

Weak responses usually show:
- passive waiting disguised as professionalism
- generic communication with few sharp questions
- no meaningful first output, or an output disconnected from partner needs
- reflection focused on feelings or effort rather than misread decisions
- claims of impact with little evidence

#### How the LLM should respond to weak work

The LLM should:
- state plainly that the student did not yet meet the course bar
- identify the first broken link in the chain: diagnosis, initiative, execution, or reflection
- offer a narrow corrective path instead of a long motivational speech

**Example feedback posture**
- "You did not convert ambiguity into contribution. The main failure was not effort; it was passivity. On the next deployment, schedule two stakeholder conversations in the first 24 hours and ship a draft artifact by hour 48, even if incomplete."

### Response-style guardrails for the LLM

- Do not say "great job" unless the evidence clearly supports it.
- Do not use therapeutic language to soften performance feedback.
- Do not confuse verbosity with thoughtfulness.
- Do not produce identical feedback patterns for all mid-band students.
- Always end with a specific next-deployment behavior change.

### Recommended feedback format

| Section | Guidance |
|---|---|
| Evidence-backed strength | Name 1-2 things the student did that clearly worked |
| Core miss | Identify the most important mistaken behavior or assumption |
| Consequence | Explain what that miss cost them in the deployment |
| Next move | Give one concrete operating rule for the next ambiguous environment |

## Appendix: recommended operational assets for the facilitation team

These assets should exist in the delivery environment even if they are stored outside this file:
- Partner intake form
- Student capability profile template
- Deployment brief template
- 72-hour plan template
- Status report template
- Partner feedback form
- Evaluation packet template for LLM scoring

## Implementation summary

Deep End Deployment should feel like a controlled professional stress test. The course succeeds when students are forced to create value before they feel ready, then can explain with precision what that experience taught them about contribution, judgment, and identity. The bar is not polish. The bar is day-one usefulness under real conditions.