Turn the capstone into evidence a reviewer can trust

The first page should explain the user problem, what the system does, and how to run a small example. Then show the architecture, supported workflow, evaluation approach, and current limitations. GitHub's README documentation describes how a repository README serves as an entry point. Use that entry point to guide a reviewer toward executable evidence rather than making them infer the project from a long list of frameworks.

Provide a minimal dependency setup, example configuration without secrets, a synthetic fixture, and an expected output. Separate the local demonstration from commands that need external credentials or incur usage costs. Include screenshots or a short recording only when they help explain a completed workflow. A screenshot can demonstrate interface behavior, but it cannot substitute for reproducible evaluation or establish that the backend enforces the permissions shown on screen.

For each claim, point to a run or artifact that supports it. A quality result needs dataset description, sample size, metric definition, baseline, and configuration. A latency result needs workload, concurrency, hardware or service, timing boundaries, and failure handling. An isolation result needs tested attacker capabilities and the invariant checked. State which numbers are measured, which are arithmetic estimates, and which come from synthetic fixtures.

Suppose the seed completes three invented tasks and passes six local assertions. That supports the statement that the seed passed those checks, not that a real model achieved 100 percent accuracy. If no external model or protocol server was exercised, say so. An honest blank cell labeled not measured is more useful than a guessed throughput value. Keep raw results and a script that regenerates the summary so reviewers can inspect denominators and excluded cases.

An evaluation report should compare a baseline and the final system under stated constraints. Include failure categories and an ablation that addresses the project's main architectural choice, such as whether specialist delegation improves conflict resolution relative to a single workflow with the same call budget. If delegation adds latency without improving the measured task, record that outcome and explain whether interoperability or ownership still justifies it.

Separate your original work from dependencies and generated scaffolding. Describe the contracts you designed, the failure you diagnosed, the policy you implemented, and the experiment you ran. A reviewer can assess engineering judgment from those concrete decisions. Do not claim that using a protocol means you designed the protocol, or that adapting an example means you trained a foundation model. Attribution and precise scope make the contribution easier to understand.

A useful resume bullet names an action, a system or problem, and supported evidence of its result. Before a live measurement exists, a truthful statement could be: "Built an incident-review prototype with scoped retrieval, task-state replay, and synthetic regression tests." After an actual evaluation, replace general claims with the measured quantity and its setting, such as a held-out case count, a latency percentile, or a reproducible failure reduction. Include the baseline and workload when they are needed to interpret a percentage.

Never transform fixture success into customer impact, estimated memory into measured savings, or a personal prototype into deployed production experience. Avoid unqualified claims of state-of-the-art performance or guaranteed employment. If a team built the system, describe your own responsibility accurately. Keep a private evidence note for every number so you can explain how it was calculated and what it does not establish during an interview.

The final capstone package should contain the runnable system, a small demonstration dataset, evaluation code and results, architecture and decision notes, an operations guide, and known limitations. Include pinned protocol and SDK versions, an example of a recoverable failure, and a tested cancellation or rollback path. Review the repository for secrets, private records, and claims that exceed the available evidence before making it public.

End the project report with the most informative next experiment rather than a feature wishlist. Perhaps the missing question is whether results transfer to real incident tickets, whether a different specialist reduces latency, or whether a more demanding adversarial fixture exposes a new boundary failure. A strong capstone demonstrates that you can formulate a problem, build a coherent system, measure its behavior, and communicate its limits. That combination provides useful portfolio evidence even when the best conclusion is conditional rather than spectacular.

The formatter forces a scope and denominator into the claim. The six checks are an illustrative input record, not newly executed tests inside this snippet; its only assertion checks formatting. Replace the record with actual evaluation output before presenting it as evidence about a project.