Milestone map
Milestone map
3 milestones
Write subject integration plan with baseline data
4–6 weeks (1–2 hrs/day)
Months 1–2. To deepen your innovation project, you must now apply rigorous academic methods from at least two school subjects to analyse V1.0 and plan V2.0 improvements. Identify which subjects offer directly applicable methods — for example: statistics for usage data analysis, biology or health science for a health-related product, economics for pricing or incentive design, computer science for algorithm optimisation, or environmental science for an ecology-related product. With your faculty supervisor, produce an integration plan documenting: which two subjects and which specific methods from each curriculum you will apply, what data or experiments will be run, and what questions the subject methods are designed to answer. Before any V2.0 work begins, collect baseline data that V2.0 improvements can be measured against.
Proof required
Submit: (1) your integration plan (minimum 400 words) naming at least two school subjects with the specific methods from each curriculum you will apply (e.g. 'Pearson's correlation from Statistics' not 'statistics'), the research questions each method will address, and your faculty supervisor's confirmation that the methods named are genuinely part of your curriculum; and (2) baseline data documentation showing your V1.0 starting state in a format that can be directly compared to V2.0 results.
What gets checked
- Subject methods are named with curriculum-level specificity — 'chi-square test of independence from our statistics textbook, Chapter 11' not 'we will use statistics'; the method must be one the student has actually studied
- Baseline data is collected in a format that enables pre/post comparison — the same measurement will be taken after V2.0 so that improvement is measurable rather than claimed
- The faculty supervisor has reviewed the integration plan and confirmed the named methods are real curriculum methods the student has studied — not methods researched independently for this project
Common mistakes
- Subject integration is described vaguely — 'we will use science' or 'we will apply mathematical thinking' without naming the specific curriculum technique and which subject teaches it
- Baseline data consists only of user opinions or satisfaction scores rather than measurable metrics that will change in a way that can be compared before and after V2.0
- The integration plan was written without faculty involvement and relies on methods the student has not studied in those subjects
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the student to name the specific method from each subject — they should be able to cite the lesson, textbook chapter, or class context where they learned the method; 'I researched it online for this project' is not sufficient
- Confirm baseline data exists and is in a format that will allow direct pre/post comparison with V2.0 — it should be a measurement with a specific numeric or categorical value, not a general impression
- Verify the faculty supervisor has reviewed and confirmed the integration plan before V2.0 work begins — this confirmation should be documented in the submitted plan
Apply subject methods and build V2.0
8–10 weeks (2–3 hrs/day)
Months 2–5. Run the experiments, analyses, or investigations described in your integration plan. Use the results from your subject methods to make specific, evidence-grounded decisions about what to change in V2.0. Build V2.0 incorporating those changes. Document your methods log: for each subject method applied, record what you did, what result you obtained, and what specific V2.0 decision it produced. The methods log is the core proof artefact — it directly connects academic rigour from your curriculum to product iteration decisions.
Proof required
Submit: (1) your methods log documenting at least two subject methods applied — for each: the specific technique named, the data or experiment run, the result obtained (with specifics — not 'results showed improvement' but actual values), and the V2.0 decision it produced; (2) at least three V2.0 product decisions that each trace directly to a methods log entry; and (3) a working V2.0 deployed at a shareable link accessible to the verifier.
What gets checked
- Each methods log entry names the specific academic technique used, the actual data or experiment run, and a concrete result — not 'we ran a test and it showed improvement' but the actual values, rates, or findings
- V2.0 decisions trace directly to specific methods log entries — for each of the three required decisions, there is a corresponding log entry; decisions driven by personal preference rather than methods evidence are not valid
- V2.0 is deployed and functional — accessible at a link, completing the core task independently, same standard as V1.0
Common mistakes
- Methods are described but not documented — the log describes planned analyses rather than executed ones, or names the method without showing the data and result
- V2.0 changes are cosmetic or driven by preference rather than methods log findings — 'it looks better' or 'the colours were wrong' are not valid integration evidence
- V2.0 is a mockup or significantly updated design prototype rather than a deployed, working product
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Read one methods log entry and ask the student to explain it in detail — what specific technique, what data, what result, and what decision did it produce; vague answers indicate the method was described rather than executed
- Access V2.0 at the provided link and complete the core task — verify it is deployed, functional, and can be used without the student present
- Ask: which two V2.0 features changed most because of the subject methods? The answer should be traceable to specific methods log entries with concrete result values
Produce integration report and demonstrate V2.0 impact
4–6 weeks (1–2 hrs/day)
Months 5–6. Produce an integration report comparing V1.0 and V2.0 using the same metrics collected in your M1 baseline. The report must show specific improvements traceable to specific subject method applications — not 'V2.0 is better' but 'metric X changed from Y to Z after we applied method M from subject S'. Run a final user testing session with at least three users and document whether V2.0 addresses the gaps identified in V1.0 launch feedback. Obtain a faculty supervisor statement confirming the subject integration is genuine — that the methods named are real curriculum methods the student has studied.
Proof required
Submit: (1) your integration report (minimum 600 words) comparing V1.0 and V2.0 using the same measurement framework established in your M1 baseline — including at least one quantitative before/after comparison derived from the subject methods applied; (2) a final user testing record for V2.0 (at least three users, documented specific observations and task completion); and (3) a faculty supervisor statement confirming the specific subjects and methods used are genuine curriculum methods the student has studied.
What gets checked
- The integration report shows a before/after comparison using the same metrics collected at baseline — the comparison is specific ('task completion time decreased from 4.2 to 2.1 minutes on average across 8 test sessions') not general ('users found it faster')
- Final user testing documents specific observable behaviours, not only opinions — what users did, where they paused, and whether they completed the core task, compared to V1.0 test observations
- The faculty supervisor statement names the specific subjects and methods and confirms the student applied them as part of their real curriculum study — it is not a generic commendation of the project
Common mistakes
- The before/after comparison uses different metrics than those collected in the M1 baseline — making the comparison impossible to evaluate
- User testing for V2.0 is conducted differently from V1.0 testing (different tasks, different user groups, different measurement approach) making results incomparable
- The faculty supervisor statement is a generic reference letter rather than a specific confirmation of the subject methods applied
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Check that the integration report compares the same specific metrics collected in the M1 baseline — ask the student to show you the baseline data and point to the same measurement in the V2.0 data
- Confirm the faculty supervisor statement names the specific subjects and methods and is written by someone who has seen the integration plan — not a generic letter of support
- Ask: what specifically did V2.0 do better than V1.0 because of the subject method applications? The answer should name a specific metric change with numbers, not general impressions