eugine.me
ECCU STEM

Showcase and handover

Demonstrate trust, not theatre.

A strong showcase makes the user value, evidence, safety, failure behaviour and next decision easy to inspect—and leaves the product usable after the presentation ends.

Days 16–20

The final-week runway

16

Triage

Sort feedback into bug, feature or tone; choose no more than three active improvements.

Proof: Prioritised board with owners, reasons and acceptance evidence.

17

Confirm

Close important fact questions and mark unresolved claims honestly.

Proof: Updated Confirmation Register and source cards.

18

Stress-test

Run accessibility and resilience checks across ordinary and failure states.

Proof: Audit notes, test results and one demonstrated safe fallback.

19

Handover and rehearse

Assemble the operating package and complete three purposeful rehearsals.

Proof: Fresh-reader run, timed pitch, hostile Q&A and recovery rehearsal.

20

Show and transfer

Demonstrate value, safety, evidence and limits with every team voice.

Proof: Live demo, backup recording or screenshots, Q&A and signed next steps.

Five-beat product story

The source workbook uses a five-minute pitch. Confirm the final event timing with your facilitator, then protect these five beats.

  1. 01

    The human problem

    Introduce one realistic user and the question or frustration the product addresses.

  2. 02

    The boundary

    Say what Nisa may do, what it must never decide and where reviewed authority comes from.

  3. 03

    The useful journey

    Demonstrate one supported question from input through evidence to a clear answer.

  4. 04

    The safe failure

    Show a personal, unsupported or broken-service case and how the system protects the user.

  5. 05

    The evidence and handoff

    Name the tests, sources, known limit and next decision for the institutional owner.

Rehearsal

Practise four different risks

Fresh-reader run

Can someone outside the build start the product and understand the boundary using only the handover?

Timed story

Can the team complete all five beats without rushing, filler or one person taking over?

Hostile Q&A

Can students answer hard questions with evidence and say “we do not know” when necessary?

Recovery run

Can the team continue if the internet, model, microphone, screen share or live demo fails?

Q&A evidence bank

How do you know this answer is correct?

Show the source card, citation, date, confirmation status and relevant test.

Can Nisa decide whether I qualify?

No. It explains reviewed public information; the NIS Board determines an individual case.

What personal information do you collect?

The student product should not request, infer or store identifying case information.

What happens when the evidence is missing?

Nisa states the limit and points to an official route instead of inventing an answer.

What if the AI or internet is unavailable?

The interface preserves the boundary, offers a safe fallback and records a sanitised failure.

Could this work in another territory?

The software pattern can transfer, but authority, policy, contacts and evidence must be confirmed for that territory.

What would you improve next?

Name one measured limitation, the evidence needed and the trigger for adding complexity.

Complete handover package

Another person should be able to understand, run, inspect and safely pause the product without depending on the original team.

1. Product overview
Users, purpose, scope, non-goals and a plain-language system map.
2. Run and recover
Setup, environment, start commands, dependencies, fallback and troubleshooting.
3. Authority and architecture
Decision boundary, request path, interfaces, data flow and failure states.
4. Sources and confirmation
Approved evidence, dates, owners, conflicts and open institutional questions.
5. Quality record
Automated tests, manual tests, accessibility audit, bug log and resilience matrix.
6. Security and operations
Secrets, privacy, sanitised logs, model/provider settings and incident route.
7. Limits and roadmap
Known gaps, deferred ideas, trade-offs, maintenance owner and next review date.

Prototype → public service

A successful student showcase does not automatically make Nisa an official service. These conditions need institutional ownership.

  • An authorised NIS owner has confirmed consequential facts and boundaries.
  • Personal-data, security and retention decisions are documented.
  • Accessibility has been tested with keyboard, contrast, labels and real users where possible.
  • Sources have owners, review dates and a correction process.
  • Model, retrieval, cost and failure behaviour are observable.
  • A named team can operate, update, pause and recover the service.
  • Public language does not imply that a student prototype is an official decision system.

Build the evidence before the slides

Use the student toolkit to prepare sources, tests, bugs and handover.

Open toolkit