Course 3.5: Platform Training (Locked Tenant Reality)

4 hours. Same three builds, same centaur/cyborg framing, same frontier discipline as Course 3. What changes is the execution layer. When the tenant is locked and Power Platform is not on the table, students still ship working tools by Monday using static HTML and free public hosting that reaches MCEN. The session produces two artifacts in parallel: deployable tools, and a Capability Gap Map that documents what production access would unlock.

Reality Track 4 Hours Builders

Prerequisite: Builder Orientation. Required access: genai.mil, a text editor, a free GitHub account, and the ability to reach github.io from your duty workstation.

Open the Slide Deck Open the Facilitator Hand-Outs Open the Facilitator Pack Open the Instructor Cheat Sheet Open the Student Handout Open the Live Fill-In Handout

Reference builds: Watch Bill · TEEP · Resources: Capability Gap Map · Static Hosting Cheat Sheet

Companion course: Course 3: Platform Training (the Power Platform version this course pivots from).

The Three Layers

Today the room sits across three layers. Some are available right now. Some are not. We work every layer we can reach, and we document the wall where the work stops.

Layer What It Is Status Today What You Use It For
1. Spec genai.mil. Conversation. Thinking out loud with an AI on a CUI-aware tenant. Always available. Design, decompose, draft, prompt-write, peer-review your own logic.
2. Prototype Static HTML in a single file. Deployed to GitHub Pages or another free public host that MCEN can reach. Always available. Build the tool. Run it offline. Print it. Share the URL. Hand it to a Marine on a phone.
3. Production Power Apps, Dataverse, Power Automate, real connectors, identity, write-back. Often unavailable. Tenant-dependent. Where the tool gets 10x better if access is granted. Document the wish today.

Opening Line for the Room

"Today we design the tools our units need, build everything we can right here, and clearly mark where we hit the wall. That wall map becomes the case for changing what we have access to."

Closing Line for the Room

"Power Apps skills die when you turn in your CAC. HTML skills don't."

Agenda

Time Module 201 Skills Applied
0:00 to 0:15 Setup, Hosting Check, Three Layers All six (quick check)
0:15 to 0:35 Whiteboard Planning (Centaur Phase 1) Task Decomposition, Context Assembly
0:35 to 1:20 Build #1: Watch Bill Builder (Centaur Phase 2 to 4) Context Assembly, Quality Judgment
1:20 to 1:30 Break and Failure Sharing Frontier Recognition
1:30 to 2:30 Build #2: TEEP Builder (Cyborg Mode) Iterative Refinement, Workflow Integration
2:30 to 2:40 Break
2:40 to 3:30 Build #3: Your Problem (Choose Your Mode) Task Decomposition, all six
3:30 to 3:50 Frontier Map and Capability Gap Map Wrap Frontier Recognition
Total Course Time 3 hours 50 minutes instruction. Schedule a 4-hour block to absorb overruns.

Contingency Plan: If Public Hosting Is Blocked Today

If GitHub Pages does not load from your network for any reason, the course still runs. Pivot to:

  1. Build to a local file: Every reference build runs offline as a single .html file. Students open their build directly from file:// in a browser. They can demo it, print it, attach it to an email, and copy the source into a Confluence or wiki page that does render on MCEN.
  2. Hand-carry the bundle: Email the .html file to the Marine who will use the tool. They double-click. It works.
  3. Add a Capability Gap Map row: "Hosting reach is blocked on this network." That is a real, fixable policy gap. Capture it.

The pedagogy holds either way. Centaur and cyborg patterns are independent of where the file lives.

Module 1: Setup, Hosting, Review

Duration: 15 minutes

Pre-Flight Access Check

Before starting Module 2, confirm each item below. Resolve issues now, not during a build.

  • genai.mil: can sign in, can start a conversation. This is your AI tool for every build today.
  • Text editor: Notepad, Notepad++, VS Code, or any editor that saves a plain .html file.
  • Browser: Edge or Chrome. Both render every reference build identically.
  • GitHub account: A free personal account at github.com. Personal email is fine. Two-factor is required and you will set it up today if you have not already.
  • github.io reachable: Open jeranaias.github.io/ExpertDrivenDevelopment/builds/watch-bill.html from your duty workstation. If it loads, you are good. If it does not, see the contingency plan above.
  • Clipboard works: You can copy text out of the browser and paste into Outlook. Many DoD workstations restrict this in odd ways. Test it now.

AI Tool for Today

Use genai.mil. The January 2026 MARADMIN consolidated USMC onto genai.mil as the standard AI tenant. Anonymize PII (real names, SSNs, contact info) in your prompts unless a PIA authorizes the data. CUI-level unit context (unit name, approval chain, T&R references) is acceptable on genai.mil.

If genai.mil is briefly down, you can do your prompt and design work locally on a sheet of paper or a whiteboard. The build itself is just typing the answer into your editor.

Hosting in 60 Seconds

Your tool is a single .html file. Public hosting means a URL that other Marines can open from their phone or workstation, without you emailing the file. The path of least resistance today:

  1. Create a new repo on github.com. Name it after your tool.
  2. Drag the .html file into the browser onto the empty repo. GitHub commits it.
  3. In the repo go to Settings → Pages. Source: main branch, root. Save.
  4. Wait 60 seconds. The URL is https://<your-username>.github.io/<your-repo>/<filename>.html.
  5. Open the URL on your phone. If it loads, you just deployed a tool.

Other hosts work the same way at the conceptual level. See the Static Hosting Cheat Sheet for the full menu with MCEN-reachability notes.

Instructor Note

Walk every student through the GitHub Pages deploy of an empty placeholder file before Module 2 starts. If any student cannot reach their own github.io URL by minute 14, do not start Build #1. Either resolve the network issue or move that student to local-file mode for the rest of the day. Trying to debug hosting during a centaur build kills the build.

Centaur and Cyborg, 90 Seconds

Quick refresher from Builder Orientation. Two work patterns:

  • Centaur: distinct human phases and AI phases with clear boundaries. Human designs. AI builds. Human verifies. Best for workflows with strict business rules.
  • Cyborg: continuous back-and-forth. You discover requirements as you build. Best for exploratory work where you do not fully know what you want until you see it.

Build #1 is centaur. Build #2 is cyborg. Build #3 is your choice.

Module 2: Build #1, Centaur Mode (Watch Bill Builder)

Duration: 65 minutes (20 min whiteboard + 45 min build)

Problem: A section leader has to publish a watch bill for the next two weeks. Rotation through the available roster, skip anyone on leave, fair distribution, prints clean, emails clean. Today it is done in Excel and an email chain. MOL does not solve this. We do, today, in HTML.

Why this build: Universal NCO pain. Every section has one of these. Logic is real (rotation plus exclusions plus fairness) but small enough to ship in 45 minutes. The Marine using the tool needs zero training to read the output.

Reference build: builds/watch-bill.html. Open it now. This is what you are building toward. Use it to check your work, not to copy-paste from.

Phase 1: Human Designs (20 minutes, no AI yet)

On a whiteboard or a sheet of paper, define the tool before you touch a tool. No AI in this phase.

Filled-In Whiteboard Planning Template (Watch Bill Builder)

Business Rules
  • One Marine per day on the bill.
  • Rotate through the available roster in order.
  • Anyone marked LV, TAD, APPT, MED, or PCS is skipped (not eligible).
  • Fairness check: spread between most-watches and fewest-watches should be 0 or 1 across the period.
  • Weekends shown but not treated differently (this section stands the watch every day).
Inputs
  • Section / unit name (string).
  • Watch type (Duty NCO, Fire Watch, Quarterdeck, Phone Watch, Barracks Duty, SDO, OOD, or custom string).
  • Start date (YYYY-MM-DD).
  • Number of days (1 to 365).
  • Roster: free-text list, one Marine per line, optional - LV suffix to mark unavailable.
Outputs
  • On-screen table: Date, Day of Week, Watchstander.
  • Fairness summary: count per Marine, total slots, spread number.
  • Skipped list: who was excluded and why.
  • Email body in a textarea (plain-text monospace table) with Copy button. Subject auto-built.
  • Print: clean, no header chrome, dates and names readable on US Letter.
Edge Cases
  • Empty roster: show inline error, do not generate.
  • Everyone marked unavailable: show inline error.
  • Single available Marine plus 14 days: that Marine on every day. Surface it in fairness summary so it cannot hide.
  • Invalid date: show inline error.
  • Days > 365: cap and error.
Out of Scope (Capability Gap candidates)
  • Pulling roster from MOL or Outlook contact group automatically.
  • Reading leave block schedules from a system of record.
  • Notifying watchstanders by email when the bill is published.
  • Persisting bills across sessions for multiple sections.

Instructor Checkpoint: End of Phase 1

Walk the room. Every student should have a written plan that covers: inputs, business rules, edge cases, outputs. If a student starts writing HTML before they have an edge case list, stop them and send them back to the whiteboard. The centaur discipline is that the plan exists before the AI sees it.

Have one or two students read their plan to the room. Look for missed edge cases. Empty roster and everyone-on-leave are the two most often forgotten.

Phase 2: AI Builds (25 minutes)

Open genai.mil. Feed it your plan as one prompt. Then iterate on smaller chunks.

Student Prompt to AI (Phase 2, full plan handoff):

Build me a single-file static HTML tool called Watch Bill Builder. Constraints:

  • One .html file. Inline CSS. Inline JavaScript. No external scripts, no external fonts, no external stylesheets, no CDN. It must work 100% offline after page load.
  • Mobile responsive. Prints clean to US Letter.
  • Has an UNCLASSIFIED banner top and bottom.
  • Inputs: section name, watch type (dropdown of Duty NCO, Fire Watch, Quarterdeck, Phone Watch, Barracks Duty, SDO, OOD, Custom), start date, number of days, roster textarea (one name per line, suffix - LV or - TAD or - APPT means skip).
  • Logic: rotate available Marines in order, skip anyone with a skip suffix, build a date range starting at start date.
  • Outputs: a table of Date / Day / Watchstander, a fairness summary with per-Marine counts and a spread number, a skipped list, and an email-pasteable plain-text table in a textarea with a Copy button. Subject line auto-built.
  • Errors handled inline: empty section, empty roster, all unavailable, invalid date, days less than 1 or more than 365.

Give me the full HTML. Do not split it into multiple files. Do not use any framework.

What to Expect Back

genai.mil typically returns one large HTML block. It will run. The first pass will have at least one of: a missing edge case, a print layout that does not actually print clean, a copy button that fails on Edge, or a fairness summary that double-counts. That is normal. Phase 3 is where you catch it.

Phase 3: Human Verifies (10 minutes)

Save the AI's output as watch-bill.html. Open in a browser. Run the bill through every edge case from your Phase 1 plan. Specifically:

  1. Empty roster. Hit Generate. Does it show an inline error or silently produce nothing?
  2. All Marines marked - LV. Same test.
  3. Days = 0. Days = 400. Both should error.
  4. Single available Marine, 14 days. Does the fairness summary make the imbalance visible, or hide it?
  5. Copy email body to clipboard. Paste into Outlook. Does the monospace table survive?
  6. Hit print. Does the input form vanish? Does the bill stay readable on one page?

Instructor Verification Standard

A student declares Build #1 done only after they have tested all six checks above. Have them mark each off out loud. Verification is the discipline. The build is just typing.

Phase 4: AI Refines (10 minutes)

Take the specific failures you found in Phase 3 back to genai.mil. Be specific.

Student Prompt to AI (Phase 4, targeted fix):

In the Watch Bill Builder you generated, when I leave the roster empty and click Generate, nothing happens and no error appears. I want an inline error that says exactly "Roster is empty. Add at least one Marine." appearing below the form. Show me only the JavaScript change. Do not regenerate the whole file.

Paste only the changed lines into your file. Save. Reload. Re-test.

Phase 5: Human Accepts

One final walk-through. Does the tool match your Phase 1 plan? If yes, deploy:

  1. Drop the file into your GitHub repo.
  2. Confirm the GitHub Pages URL loads on your phone.
  3. Share the URL with one other Marine in the room.
  4. Have them test it on their phone. Watch them. Note any friction.

Key Teaching Point

At every phase boundary there is a verification checkpoint. The human is responsible for design and verification. The AI handles execution. That separation is what makes centaur reliable for any workflow that other Marines will trust.

Build #1 Success Indicators

  • A single .html file that runs offline and produces a correct watch bill.
  • Inline errors fire on every edge case in the Phase 1 list.
  • Fairness summary correctly reports the spread.
  • Email body copies cleanly into Outlook.
  • Print layout fits one page for a 14-day bill.
  • Deployed to a github.io URL that opens on a phone.
  • Student can articulate one specific point where they caught an AI error and corrected it.

Module 3: Failure Sharing

Duration: 10 minutes (during break)

This is not optional. Same beat as Course 3. The most valuable 10 minutes in the session.

Each participant shares:

  • What the AI got wrong on Build #1.
  • How they caught it.
  • How they fixed it.

Document failures on a shared whiteboard or in the classroom Capability Gap Map row. The pattern is the value. If three Marines all hit the same broken-on-first-pass behavior from genai.mil, that becomes a unit-level prompt note for next session.

Instructor Note

Create psychological safety. Share your own first-pass failure on the reference build. The more specific and honest the sharing, the better the frontier map. Frame failure as data, not embarrassment.

Module 4: Build #2, Cyborg Mode (TEEP Builder)

Duration: 60 minutes

Problem: The S-3 shop runs the Training, Exercise, and Employment Plan in a Word doc, an Excel sheet, and a whiteboard. None of those talk to each other. By Friday the brief slide is stale. Build a TEEP tool that lives in the browser, persists across sessions, and produces a current S-3 brief on demand.

Why this build: Cyborg mode is for when you do not fully know what you need until you see it. TEEP is exactly that. You will rebuild the data model at least once during this hour. That is the lesson.

Reference build: builds/teep.html. Open it. This is the destination. The path to it is messy on purpose.

Cyborg Pattern (no distinct phases)

Keep genai.mil open in one window and your editor in another. Conversation is continuous. Context accumulates in a single thread. You will not write a plan upfront. You will discover the plan by building.

Iteration 1: Get Something Visible (10 minutes)

Student Prompt to AI:

Build me a single-file static HTML TEEP tool. Stores training events with name, type, start date, end date, status (Planned / Confirmed / Executed / Cancelled), and a resources / notes field. Inline CSS, inline JS, no external dependencies. Stores data in localStorage so it survives a reload. Shows a table of events sorted by start date. UNCLASSIFIED banner top and bottom.

Save the result as teep.html. Open it. It probably works for the happy path. Now do something with it.

Iteration 2: Realize the Data Is Not Enough

Add three sample events through the UI. Try to brief them to your CO in your head.

  • You cannot tell which events are inside 14 days.
  • You cannot tell which Planned events are about to fall off because no one confirmed them.
  • You cannot count anything fast.
Student Prompt to AI:

The tool works but I cannot brief from it. Add: summary cards at the top showing total events, count by status. Add a "T-X days" indicator next to each event. Highlight events inside 14 days that are still Planned (not Confirmed) so they stand out as confirmation gaps. The summary cards must use color to communicate status at a glance.

Instructor Teaching Point: This Is Cyborg Mode

Name what just happened. The student did not plan summary cards upfront. They built, evaluated, realized it could not brief, pivoted. That is the cyborg pattern. In centaur mode this would have been a Phase 1 requirement on the whiteboard. In cyborg mode it surfaces only when you try to use the thing.

Iteration 3: Conditional Styling (Deliberate AI Failure Moment)

INSTRUCTOR: DELIBERATE AI MISTAKE COMING. DO NOT WARN STUDENTS.

On the first prompt for color-coding, genai.mil will almost always return code that does not work as advertised. Common failure modes observed in classroom runs:

  • Sets element.style.background = color on the row but the CSS class on the cell wins because of specificity, so nothing changes visually.
  • Uses element.bgColor = "red" (deprecated, ignored by modern browsers).
  • Uses a :contains() CSS selector (does not exist).
  • Compares status with loose equality and falls into the wrong branch because of whitespace.
  • Colors the wrong cell because querySelector matches the first descendant rather than the intended one.

Let students attempt this. Do not intervene yet. When hands go up, ask the four questions in the debrief below.

Student Prompt to AI:

Add color coding to the status column. Planned blue, Confirmed green, Executed gray, Cancelled red. Make the colors WCAG AA. Show me only the changes I need to apply to the file I already have.

Debrief Questions When Students Get Stuck

  1. "What did the AI tell you to do?"
  2. "What result did you expect?"
  3. "What result did you actually get?"
  4. "What would you ask the AI to clarify or fix?"

This is frontier recognition. The AI gave plausible code that does not actually do what it claimed. The human catches it. The teaching beat lands here regardless of whether the failure happens in Power BI or in vanilla JS.

Iteration 4: Fix the Conditional Styling (Student-Driven)

Student Prompt to AI (after testing the failure):

The styling does not apply. I set the style inline on the cell with element.style.background and nothing changes. The browser shows the cell still white. I think a CSS class on the parent is winning the specificity battle. Give me a CSS-class-based approach instead: one class per status (.status-Planned, .status-Confirmed, etc.) defined in the <style> block, and JS that sets className on the status pill element. Show me the <style> additions and the JS line that sets the class.

Instructor Debrief: Failure Recognition

After the fix works, pause and ask:

  1. "What was wrong with the AI's first answer?"
  2. "How did you know it was wrong?"
  3. "What did you change in your prompt the second time that the AI needed in order to succeed?"

The answer to question three is usually some version of "I told it about the constraint I had discovered." That is the centaur-cyborg blend that experienced builders develop. Name it.

Iteration 5: Generate the S-3 Brief

Student Prompt to AI:

Add a button labeled "Generate S-3 Brief." It produces a plain-text briefing block in a read-only textarea. Format: header with unit and as-of date, status summary with counts, "Next 14 Days" section listing upcoming Planned and Confirmed events with T-X days, a "Confirmation Gaps" section listing any Planned events inside 14 days, and a one-line REQUEST at the end (push for confirmation gaps if any, otherwise steady state). Add a Copy button next to it.

Instructor Time Check

At 50 minutes into this build, stop adding features. The core cyborg pattern is demonstrated by Iteration 4. Iteration 5 is enhancement. If the room is on time, do it. If not, declare and move on.

Build #2 Success Indicators

  • localStorage persistence verified by reload.
  • Color-coded status with a class-based approach the student can explain.
  • Summary cards that count by status.
  • S-3 Brief generator that produces a copy-pasteable paragraph block.
  • Student restructured something at least once based on evaluation.
  • Student caught at least one AI mistake (Iteration 3 should produce one).
  • Student can explain how cyborg differs from centaur using this build as the example.

Key Teaching Point

Cyborg is faster but requires constant attention. You cannot walk away. It is the right mode when you are discovering the shape of the problem. It is the wrong mode for a Build #1 with strict approval rules.

Module 5: Build #3, Your Problem (Choose Your Mode)

Duration: 50 minutes

Each participant builds the tool they identified during Builder Orientation. Real problem, real users, real requirements. Single-file HTML. Deployed to their own github.io URL by the end of the block.

Before starting, each participant declares:

  1. What they are building. One sentence. Names the tool type and the user. Not "something for training," but "a Combat Lifesaver currency tracker for the SACO."
  2. Which mode and why. Centaur if rules are strict. Cyborg if you do not yet know the shape.
  3. At least two specific frontier risks. Where do you expect genai.mil to struggle? Common ones: date math, print layout, large lists, copy-to-clipboard variance across browsers, anything that involves dates around fiscal year boundaries.

Data Handling Reminder

CUI-level unit data is acceptable in prompts on genai.mil. PII (real Marine names, SSNs, contact info) must be anonymized unless a PIA authorizes its use. Substitute fictional names. If you are publishing to a public github.io URL, no CUI in the file itself. The file is world-readable the moment the repo is public.

Decomposition Template (5 minutes)

Fill this out before writing your first prompt.

  1. Inputs: What does the user type or select?
  2. Logic: What does the tool compute or decide?
  3. Outputs: On-screen result, printable view, copyable text, all three?
  4. Persistence: Does state need to survive reload? localStorage yes or no.
  5. Edge cases: List three. Empty input, max input, weird input.

Five minutes saves an hour.

Instructor Note

Resist solving every problem. When a Marine gets stuck, ask: "What would you tell the AI about what is going wrong?" This builds the self-sufficiency they need after the course ends. Your job is to coach the prompt, not write the prompt.

Assessment Criteria for All Three Builds

Same rubric as Course 3. Verification, frontier recognition, and appropriate use of centaur vs cyborg modes. The execution layer changed. The discipline did not.

Criteria Exceeds Standard Meets Standard Developing
Functional Prototype
Does the tool work end-to-end?		 Works completely. All edge cases handled. Deployed to a public URL that other Marines can open. Works for happy path. Some edge cases not handled. Deployed. Errors on basic use. Not deployed.
Centaur Pattern (Build #1) Clear Phase 1 plan on paper. Verification checkpoints documented at phase boundaries. Student can articulate what the AI owned vs what they verified. Plan exists but is incomplete. Some verification happened. No plan. Jumped straight to AI. No verification checkpoints.
Cyborg Pattern (Build #2) Multiple iterations. Pivoted at least once based on evaluating output. Can explain why cyborg fit this build. Some iteration. At least one course correction. Tried to plan everything upfront. No pivots.
Independent Problem-Solving (Build #3) Resolved errors independently. Asked clarifying questions, not step-by-step help. Needed some guidance but applied it. Could articulate the problem. Needed constant intervention.
Verification Tested all paths including error cases. Documented at least one AI mistake they caught. Tested happy path. Caught at least one error. Assumed AI output was correct. Did not test.
Frontier Recognition Articulates at least three areas where AI struggled. Contributed to the frontier map and the Capability Gap Map. Identified at least one frontier issue. Could not identify any AI failures.

Grading Guidance

Formative, not summative. Use this to coach. The single most important indicator is Verification. If a Marine is not testing AI output, they are not ready for independent work yet. That is the core EDD discipline.

Module 6: Frontier Map and Capability Gap Map

Duration: 20 minutes

This block produces two artifacts. The Frontier Map captures where AI is reliable and where it is not. The Capability Gap Map captures where the tenant blocks the work. Both go to leadership. Both compound over time.

Artifact 1: Frontier Map (existing)

Compile all failure cases from the session. This is collective intelligence of the room. Examples adapted to the static-HTML stack:

Task Type AI Handles Well AI Handles Poorly Verification Needed
HTML form scaffolding Standard inputs, labels, basic validation patterns Accessible focus order, dependent field visibility Tab through the form. Hit Submit with everything empty.
Inline CSS for print Basic @media print rules, hiding nav chrome Color preservation flags, table page-breaks Actually print the page. Look at the PDF preview.
Date math in JS Simple day add / subtract Timezone offsets, fiscal-year boundary logic, ISO parsing Test at start of October. Test at end of December. Test across the date that bit you last time.
localStorage persistence JSON serialize / parse for simple objects Schema migration, quota errors, private-browsing mode Open in InPrivate. Reload. See what survives.
Copy to clipboard Modern navigator.clipboard.writeText Fallback for older browsers and HTTP context Test in Edge, Chrome, and on a phone.
Color coding by status Class-based styling with status in the class name Inline-style approaches that fight CSS specificity (Iteration 3 trap) Visually inspect every status value. Do not trust the first rule.

Each student adds at least two rows specific to what bit them today. Specific task type, specific failure, specific verification action. Not "check the output," but "open the file in InPrivate to verify localStorage is not just relying on cached state."

Artifact 2: Capability Gap Map (new)

This is the second deliverable of the course, and the case for changing what your tenant gives you. Every tool the room built today has a wish list: things that would make it 10x better if production access were unlocked. Capture them.

Open the Capability Gap Map template. For each of the three builds (and the unit's earlier static prototypes if any), fill one or more rows.

Field What Goes Here
Task Type The category. "Watch bill generation," "Training calendar," "Counseling tracker."
Prototype Layer Solution What the student built today. URL + one-line description.
Production Layer Wish What it would do with real connectors. "Pull roster from MOL. Read leave block from system of record. Email watchstanders automatically."
Blocking Permission / Tool The specific gate. "MOL API not exposed to unit-developed tools." "Power Automate Office 365 connector restricted at tenant level." Name it.
Beneficiary Count Rough headcount. "1 section, 12 Marines, weekly." "All of 1st Bn, 800 Marines, daily."
Estimated Time Savings Hours per week or per cycle. "2 hrs / week per section leader." Conservative is fine.

Where This Goes

Capability Gap Map rows compile across sessions. They form the evidence base for tenant policy review at the HQMC AI working group level. A single Marine asking for a connector is a request. Forty Marines documenting the same blocked connector with beneficiary counts and time savings is a policy case.

Forward your unit's compiled Capability Gap Map up through your AI POC. If you are an instructor, your set of Capability Gap Maps from each session is one of the most valuable artifacts the course produces.

Assignment Before Advanced Workshop

  1. Polish Build #3 to a deployable state. Keep the URL live.
  2. Run through the EDD SOP QA process on at least one of your three builds.
  3. Document three failure cases with specifics: what failed, how you caught it, how you fixed it.
  4. Add at least two rows to your unit's Capability Gap Map based on the limitations you ran into.
  5. Identify one area where AI capability surprised you. Something it did better than you expected.