Build the System Before You Defend It

Before presenting results, freeze the system you intend to defend.

Record:

• input and data contract;
• features or representation;
• model or decision method;
• evaluation evidence;
• threshold or decision policy;
• deployment placement;
• monitoring signals;
• fallback behavior;
• human authority;
• version/configuration identifiers.

If those pieces keep changing during the defense, the evidence no longer points to one stable system.

A capstone is a chain of evidence

Think of the dossier as linked claims:

data evidence → model evidence → system evidence → failure evidence → bounded conclusion

Each layer answers a different question.

Model evidence may show how predictions performed on a held-out set. System evidence may show that invalid input is rejected. Failure evidence may show that a timeout triggers fallback.

A model with 91% held-out accuracy does not prove that the deployment meets a 100 ms deadline. A latency test can address that second claim. Neither test proves the human override works; that requires its own evidence.

The capstone becomes stronger when these claims are separated rather than blended together.

Choose a bounded system scenario

A good classroom capstone uses synthetic, public, or fictional data and a consequence small enough to test safely.

Examples:

• classify fictional sensor conditions;
• categorize public images;
• recommend a low-consequence option;
• detect anomalies in generated telemetry;
• route uncertain cases to review.

Do not invent evidence from a real physical deployment that was never performed.

Before moving on

Write your capstone's primary claim in one sentence. Under it, list the exact evidence artifact that should support that claim.