What is final documentation — explained for kids?

Good project docs cover problem, research, design, build, test and reflection — not just the result. For Class 7.

What's the most common mistake children make about this concept?

Documentation is a formality written after the project is done — a build log maintained throughout the project is the source material for documentation

How does Dhee Learning teach this in a Class 7 session?

Dhee opens with a question — for example: "Your capstone project is finished. Why do you need to write a document about it — can't people just use it and see for themselves how it works?" — listens to your child's answer, then probes the reasoning behind it. The session ends when the child can apply the idea to a brand-new situation, not just recall it.

How to document an AI project — telling the whole story

What this concept actually says

A project document tells the complete story: problem, research, design, build, test, and reflection — not just what was built
Documentation of known limitations and ethical considerations is mandatory — it demonstrates intellectual honesty
Good documentation enables someone who was not part of the project to understand, evaluate, and if necessary, continue it

An analogy your child will recognise

Medicine package insert

Every medicine in India comes with a package insert: what it treats, how to take it, side effects, who should not take it. A medicine without this insert can be dangerous even if it's effective — because the user can't calibrate when to use it and when not to. Your project documentation is this insert: it tells users what the system does, how to use it, and what to watch out for.

Architect's blueprint

A beautiful building without blueprints cannot be repaired, extended, or understood by anyone except the original builder. The moment that builder leaves, the knowledge leaves too. Project documentation is the blueprint — it captures the structure and the reasoning so the building can outlast its creator.

Common misconceptions to watch for

Documentation is a formality written after the project is done — a build log maintained throughout the project is the source material for documentation
Showing only your successes makes the project look better — judges and real stakeholders are more impressed by rigorous honesty than by a polished but incomplete account

Key facts in one breath

A complete capstone document should include: problem statement, research summary, design decisions and rationale, build process summary, test results, known limitations, ethics review, and reflection
The 'reflection' section is often the most valuable part for the student — it is where learning is made explicit and transferable
Documentation of failed attempts and pivots is as valuable as documentation of successes — it shows a real design process
Open-source AI projects that include thorough documentation of limitations (like model cards) are considered more trustworthy, not less impressive

How Dhee Learning teaches this — the 3-stage question loop

Every Dhee Learning session for this concept follows three stages. We share the questions Dhee actually asks, so you can hear what a session sounds like.

Stage 1 — Surface

Your capstone project is finished. Why do you need to write a document about it — can't people just use it and see for themselves how it works?

Rote answer

"Child says 'documentation is required' without articulating what function it serves"

Understood

"Child explains that the product shows what was built; the documentation explains why decisions were made, what was tried and failed, what limitations exist, and how to continue the work — without documentation, the project exists but cannot be understood, trusted, or built upon"

Stage 2 — Reasoning

A judge at the showcase reads your documentation and finds no mention of the three issues identified in user testing. They ask: 'Were there any problems during testing?' What does leaving out those problems say about your documentation — and what does it say about your ethics?

Follow-up Dhee may use: Is there a way to present known limitations that actually makes the project look stronger, not weaker?

Stage 3 — Application

Write the 'Limitations and Known Issues' section of your final documentation. For each limitation, include: what it is, why it exists, and what someone using the system should know or do because of it. Then write a one-sentence reflection: what would you do differently if you started this project again?

Misconception Dhee watches for: Child writes limitations in passive, vague language ('some errors may occur') to minimise their apparent significance — rather than naming them clearly so users can make informed decisions

Related concepts

Class 7

Goodhart's Law — when AI optimises the wrong thing

Class 7

How to run an AI ethics review — fairness, privacy and harm