eugine.me
ECCU STEM

Student toolkit

Make your thinking visible.

These lightweight records turn ideas, facts, tests, bugs and AI help into evidence another student can understand and verify.

Working artefacts

Use the smallest record that solves the problem

Build brief

Before coding

Name the user, the outcome, the boundary and the evidence that will prove the work.

  • User and situation
  • Smallest useful outcome
  • In scope / out of scope
  • Acceptance evidence
  • Owner and reviewer

Source card

Before making a factual claim

Keep the source, date, owner and confirmation status attached to the fact.

  • Claim supported
  • Source title and location
  • Source owner
  • Published or checked date
  • Confirmed / pending / conflicting

Test case

Before calling a feature Done

Describe an input, expected route and result so another person can repeat the check.

  • Input or situation
  • Expected route
  • Required facts
  • Forbidden behaviour
  • Result and evidence

Bug record

When reality differs from expectation

Turn a surprise into a reproducible problem instead of a vague report.

  • What happened
  • What should happen
  • Steps to reproduce
  • Impact and urgency
  • Owner, state and proof of fix

Confirmation Register

When authority is uncertain

Separate verified information from questions that an authorised person must answer.

  • Fact or policy question
  • Territory
  • Proposed source
  • Institutional owner
  • Status and confirmation date

Decision note

When the team chooses between options

Record why a choice was made, what it costs and what would cause it to change.

  • Decision
  • Options considered
  • Trade-offs
  • Assumptions
  • Revisit trigger

AI assistance note

After meaningful AI help

Make generated help reviewable and prove that the student owns the result.

  • Task attempted
  • Help requested
  • Suggestion accepted or rejected
  • Checks performed
  • What I can now explain

Handover package

Before another team operates the work

Make the product understandable, runnable, testable and honest about its limits.

  • Overview and run instructions
  • Architecture and boundaries
  • Sources and confirmations
  • Tests, bugs and recovery
  • Known limits and next steps

Minimum test matrix

A polished happy path is not enough. Check what happens at the boundaries and when dependencies fail.

Ordinary

A clear, supported public question

Plain answer, reviewed source and visible date context

Empty or unclear

No question, fragments or ambiguous wording

Helpful clarification without inventing the user’s intent

Personal

A named person’s contribution, benefit or eligibility

Stop before search; explain the boundary and provide an official route

Unsupported

A topic absent from reviewed evidence

Say the evidence is insufficient; never fill the gap

Conflicting

Two sources disagree

Expose the conflict and route it to the Confirmation Register

Adversarial

Prompt injection or instruction to ignore safeguards

Keep the product boundary and do not reveal secrets or hidden context

Distress

Urgent, bereavement or emotionally difficult wording

Use the approved deterministic route before generative output

Dependency failure

Model, network, file or retrieval service unavailable

Preserve honesty, show a safe fallback and record a sanitised error

Responsible-AI check

  • I can explain what ordinary code does and what the model does.
  • The product does not ask for or expose personal information.
  • Consequential claims have a reviewed source and confirmation state.
  • Unsupported and personal cases stop safely before generation.
  • Tool inputs and model outputs are validated by application code.
  • Tests include ordinary, edge, misuse and failure cases.
  • Logs contain useful events without raw personal questions or secrets.
  • The interface makes uncertainty, citations and official handoff visible.

Daily team language

Scrum update

Yesterday
The evidence I completed—not merely the activity I attempted.
Today
The smallest product outcome I will make verifiable.
Blocker
The exact missing fact, decision, access, skill or dependency.
Help
Who or what can unblock it, and the next action already tried.

End-of-day reflection

Discover

What did I notice about the user, data or system today?

Build

What changed because of my work, and where is the evidence?

Explain

Which part can I now teach to another student?

Question

What remains uncertain, and who has the authority to answer?

Many ways to contribute

Learning badges recognise evidence, not status. Any rewards or points must be confirmed by facilitators.

Builder
Ships a small, integrated behaviour with evidence.
Bug Hunter
Finds a reproducible failure and helps verify the fix.
Source Scout
Connects an important claim to authoritative evidence.
Safety Guardian
Improves a boundary, misuse test or recovery state.
Accessibility Advocate
Removes a barrier and verifies the experience.
Explainer
Makes a difficult concept clear to another student.
Team Catalyst
Unblocks others and improves the shared workflow.

Put the toolkit to work

Choose a lab, define its evidence, then leave a trace another student can follow.

Open build labs