Build the Evidence Package

Your repository contains code. The capstone needs something stronger: a trace from what you claim to why another person should believe the claim.

That trace is the evidence package.

Start with requirements, not screenshots

Create a verification matrix:

The matrix exposes holes immediately.

If a required row says:

Evidence: screenshot of main menu

but the requirement is “save tasks,” the evidence does not prove the claim.

Architecture evidence should answer ownership questions

Create a diagram that shows meaningful responsibilities and data flow.

For example:

USER
  ↓ input
main.py
  ↓ calls
service.py
  ↓ reads/writes
storage.py
  ↓
tasks.json

That is better than a decorative cloud of file names because the arrows have meaning.

For each important arrow, be able to say:

what crosses this boundary?
which side owns the decision?
what happens when the boundary fails?

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

If your diagram includes an API, database, AI tool, or file that the final application does not actually use, remove it.

Git evidence tells the development story

Choose several meaningful commits, not necessarily the oldest or newest.

For each selected commit:

CLAIM
What changed?

REASON
Which requirement, bug, or architecture decision caused the change?

EVIDENCE
What test, diff, or runtime result supported acceptance?

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

A useful history demonstrates controlled development. It does not need to pretend the project was built perfectly in one straight line.

A bug-fix commit can be excellent evidence if you can explain the failure and the test that now protects it.

Boundary and failure evidence matters more than a perfect demo

Select at least:

one normal required path
one exact boundary
one empty/missing/invalid case
one controlled failure

The cases depend on your project.

For a score system, the exact threshold may matter.

For a persistence app, a missing or malformed file may matter more.

For an API client, timeout, HTTP failure, or changed data shape may be the relevant boundary.

Do not manufacture dramatic failures that have nothing to do with the requirements.

Run one controlled failure safely

A controlled failure should be reversible and bounded.

Examples:

rename a local fixture so a read fails
use a supplied malformed JSON fixture
pass an invalid boundary value
point a test client at an intentionally invalid test path

Record:

EXPECTED:
OBSERVED:
ERROR / OUTPUT:
SYSTEM RESPONSE:
RECOVERY / LIMITATION:

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Never use real credentials, destructive commands, unauthorized systems, or private data to make the failure look more impressive.

Dependency evidence

Open your dependency declaration if the project has one.

For each third-party package that remains, answer:

Where is it imported?
What responsibility does it serve?
Could the project run without it?
How does a new developer install the declared version/range?

Remove unused packages deliberately and rerun the project/tests.

Dependency cleanup is part of the final system state.

AI/agent evidence, when applicable

If AI or an agent materially contributed, the strongest evidence is not a list of prompts.

Document at least:

one candidate accepted after verification
one candidate revised by a human
one candidate or plan rejected
one exact evidence item that caused a decision

If you used no AI, write:

No AI-assisted code was required for this capstone.

That is completely valid.

AI use is not a capstone requirement.

Documentation must survive a cold start

Your README should allow another person to answer:

What does this project do?
Which Python version/environment is expected?
How are dependencies installed?
How do I run it?
How do I run the tests?
Where is persistent/config data stored?
What are the major modules/responsibilities?
What known limitations remain?

Do not trust the README because it looks detailed.

Lesson 5 will test it from a cold-start perspective.

Assemble, do not duplicate

Your evidence package can point to existing artifacts:

repository paths
commit IDs
pytest output
screenshots when visual state matters
architecture diagram
verification matrix
controlled-failure record
AI review record

Do not paste the entire source code into a separate report.

The repository remains the canonical code. The evidence package is the map that makes the important claims inspectable.

Evidence quality test

For each capstone claim, ask:

Could another developer inspect this evidence and disagree with me for a concrete technical reason?

If the answer is no because your evidence is only “I think it works,” strengthen it.

If the answer is yes because the artifact is observable, you have something defensible.