Builder capstone and technical defense

What you will be able to do

1. Integrate a reproducible bounded application.
2. Demonstrate safe failure and rollback.
3. Defend architecture, evidence, limits, and ownership.

Module capstone. This lesson pulls together every skill in the module. Budget real time for it.

Prerequisites: dictionaries, loops, functions, exceptions and installed Python or paper tracing. Reuse earlier Builder artifacts only when the task requires them.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

The capstone is an evidence integration exercise. The product is not only working code: it is a repository, synthetic dataset, architecture decision record, authorization model, threat model, evaluation suite, deployment/runbook, rollback demonstration, and limitation statement. Reviewers must be able to reproduce the build from a clean environment and trace a requirement through implementation and test evidence. The public demonstration remains read-only and synthetic. The practice rubric supports feedback only and is not the certification standard.

Mechanism and implementation

Build only components justified by the task. A classifier may need no retrieval; changing-document answers need evidence; adaptive investigation may justify tools. Defend task -> model -> deployment -> harness/tools -> evidence -> human decision, including a simpler rejected alternative.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

requirements = {"valid_input", "denied_access", "unsupported_claim", "recovery"}
evidence = {"valid_input": "test-1", "denied_access": "test-2", "recovery": "test-4"}
missing = requirements - evidence.keys()
assert missing == {"unsupported_claim"}
assert not requirements <= evidence.keys()
print("missing evidence:", sorted(missing))

Engineering decisions

• Bound the application and prohibited actions.
• Choose evidence that another reviewer can reproduce.
• State residual risk and the legitimate owner for acceptance.

Worked example

The reference seed combines ingestion, authorized retrieval, structured results, evaluation, and a controlled agent. A surprise incident changes one access label; the learner detects the regression, blocks release, restores the prior manifest, and adds the incident as a test.

Diagnose the failure

A filename or checkbox is not evidence until its referenced test verifies the rule. The demo can remain private/offline. Completion does not establish operational authorization or employment outcomes.

Part 2 Guided practice

Map requirements to executable tests. Add the missing unsupported-claim test and its actual result. Independently reproduce normal and prohibited-action cases from a clean copy.

Answer criteria and feedback: A filename or checkbox is not evidence until its referenced test verifies the rule. The demo can remain private/offline. Completion does not establish operational authorization or employment outcomes.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

If reproduction fails, freeze new features. Repair setup, tests, or documentation; rerun from an empty directory; and keep the original failure record in the learning evidence. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://csrc.nist.gov/pubs/sp/800/218/final
• https://airc.nist.gov/Docs/Generative_AI_Profile.pdf

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.