Chapter 29 — Capstone build
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Capstone scope"]
N2["29.2 Quality and security checks"]
N3["29.3 Documentation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Capstone scope"]
N2["29.2 Quality and security checks"]
N3["29.3 Documentation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Capstone scope]
|
v
[29.2 Quality and security checks]
|
v
[29.3 Documentation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) build a capstone deliverable integrating course skills; (2) apply quality and security checks; (3) document it for others.
29.1 Capstone scope
Rosa's capstone is a trust-service health toolkit for small councils: an inventory template, the renewal planner, the log summariser, the monitoring rule and runbooks. All tools use standard libraries or vetted clients and call established cryptographic functions; none implement cryptography. The toolkit ships with synthetic sample data only. Her tutor approves the scope because it integrates inventory, automation, monitoring and handoff, the core themes of the course. She sets a feature freeze two weeks before submission, leaving time for testing and documentation rather than last-minute features.
29.2 Quality and security checks
Rosa writes tests for each script with expected outputs from the sample data, mirroring the lab results she recorded earlier. She runs a secret scanner, pins dependencies and asks a classmate to review the code using the team studio checklist. The review finds that the log summariser would crash on unexpected lines; she makes it count and report unparseable lines instead. She also checks that documentation never suggests disabling verification as a fix. Every test runs automatically on each commit, and a failing test blocks merging. She records review comments and her responses in the repository, so assessors can see how feedback shaped the final toolkit.
29.3 Documentation
The toolkit's guide explains purpose, installation, configuration, each tool's inputs and outputs, limits and the references used, including RFC 8555, RFC 5280 and NIST SP 800-57. It marks all sample data as synthetic. A section called "What this toolkit does not do" states that it does not replace a certificate authority, an HSM or professional review. Rosa believes that clearly stating limits protects users from relying on the toolkit for more than it can do. The guide includes a quick-start using the sample data, so a reader can see each tool work in under fifteen minutes. It also explains how to report problems and suggest improvements.
Worked example
Rosa builds a tested, reviewed toolkit of planner, summariser, monitor rule and runbooks, documenting references and stating its limits.
Synthetic case. The toolkit is invented; cited standards are real.
Errors and limits
Toolkits used outside their intended context can mislead. Tests on synthetic data do not prove behaviour on real data.
Exercises
- EX085 — Capstone contents. List three components of Rosa's toolkit. Rubric: 3 = three of inventory template, renewal planner, log summariser, monitoring rule, runbooks;; 2 = two;; 1 = one;; 0 = none.
- EX086 — Review fix. What problem did review find and how was it fixed? Rubric: 3 = summariser crashed on unexpected lines; now counts and reports them;; 2 = both;; 1 = one;; 0 = none.
- EX087 — Limits section. What does the limits section say? Rubric: 3 = toolkit does not replace a CA, an HSM or professional review;; 2 = statement;; 1 = vague;; 0 = none.
Synthesis
A capstone integrates skills into tested, reviewed and honestly documented tools.
Continue studying — chapter 29 of 30
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →