Assignment
Use your pilot artifacts to prepare a fifteen-minute case review and a reproducible sandbox demo for a peer.
Build sequence
- Present the problem, baseline, chosen design, and rejected alternative.
- Demonstrate a normal task, an integration failure, and rollback.
- Answer three changed-constraint questions without inventing new results.
- Ask the peer to identify missing evidence and revise the case study.
Acceptance checks
- The reviewer can reproduce the main workflow and find the acceptance evidence.
- Simulated outcomes and actual measurements are clearly distinguished.
- The case includes one mistake, its diagnosis, and a justified design change.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: present the complete engagement
Use the Northstar artifacts you have built across the course. Your case study should connect the initial customer problem to the final decision, with evidence at each transition. A collection of screenshots without reasoning does not demonstrate delivery skill.
Prepare a ten-minute presentation: two minutes on discovery and baseline, two on architecture and alternatives, two on the working prototype, two on evaluation and incident recovery, and two on the recommendation and handoff. Keep all business numbers labelled measured, estimated, or simulated.
Evidence packet: discovery brief, assumption register, data inventory, architecture decision, access matrix, integration tests, evaluation scorecard, UAT outcomes, rollout ledger, incident timeline, operator guide, and handoff runbook. Link each to the release or fixture version it describes.
Panel questions: why did you choose drafting instead of automatic resolution? Which evidence changed the architecture? What failed during the pilot? Which requirement did you decline or defer? Who can operate the system after you leave? What would justify expanding to another tenant?
Worked recommendation: “Revise before expansion: the draft workflow reduced simulated handling time on supported tickets, but policy freshness and operator training need improvement. Keep the two-operator pilot, assign a policy owner, retest the failed cases, and review expansion after those gates pass.” A recommendation to stop can also be a successful engineering outcome when evidence shows the intervention is not useful.
Independent challenge: introduce a new customer constraint during the review, such as no external model processing or an unavailable ticket API. Explain the effect on architecture, scope, cost, and success criteria. You may propose search-only behavior or a narrower workflow rather than pretending the original design still fits unchanged.
Assessment: score problem understanding, technical correctness, evidence quality, operational ownership, and communication separately. Require remediation for an unresolved authorization or recovery failure even if the demo is persuasive. End with a development plan naming two skills to strengthen and a concrete follow-up exercise for each.