## Chapter 38 — Capstone implementation ### Learning outcomes You will (1) implement the capstone process in small, testable steps; (2) keep a decision log; (3) manage scope changes; (4) protect data during implementation. ### 38.1 Small steps Amara builds her lookalike process in stages: a generator that produces candidate names from HCHT's domains using simple rules (character swaps, added words like "portal" or "login", different top-level domains); a matcher that compares candidates with a downloaded, public certificate-transparency extract; a triage sheet. Each stage is tested on synthetic inputs before use. Amara keeps the rules simple at first so that the number of candidates stays manageable, and adds more only when a test shows a gap. Each stage writes its output to a file, so she can check results between stages and rerun one stage without repeating the others. ### 38.2 Decision log Each design choice is dated with reasons: "Dropped homoglyph rule for Cyrillic letters — produced 4,000 candidates, mostly noise; revisit later." The log becomes part of the final report. Amara writes entries on the day of each decision and never edits old ones; a changed decision gets a new entry that refers to the old. The log helped when her supervisor asked why a common trick was not covered: the entry showed the rule had been tried and why it was dropped. In the thesis, the log becomes an appendix that shows how the design developed. ### 38.3 Scope changes Midway, the supervisor asks to include HSSC member domains. Amara records the request, estimates extra effort, and agrees with her tutor to include only three members as a pilot, keeping the original deliverables intact. The pilot with three members tests whether the process works for domains HCHT does not own, which raises new questions about who receives the results. Amara agrees with the HSSC desk that matches for member domains go to the desk, not directly to members, under the community's normal rules. The change is recorded in the decision log and in a dated addendum to her proposal. ### 38.4 Data protection Downloaded extracts are stored on the HCHT analysis server, not a personal laptop. Results go to the supervisor only. Domains matching individuals' names are excluded from reports unless clearly impersonating HCHT. Amara checks the exclusion rule on test data before using it. Domains that look like personal names are rarely relevant to HCHT and could expose private individuals, who have no part in the project, if included. Extracts are deleted from the server when the project ends, as the proposal promised. ### 38.5 Weekly checks Every week Amara runs the matcher, triages new matches and records precision: how many flagged domains the supervisor judged suspicious. Amara records each week's precision in a small table with the number flagged and the number judged suspicious, along with the time spent. The supervisor's judgment is recorded with a short reason, so later reviewers can see what counted as suspicious. Weekly figures vary widely because numbers are small, so Amara also keeps a running total for the month. Results go to the supervisor on Fridays. ### 38.6 Testing with synthetic inputs Before using real extracts, Amara writes a synthetic list containing known lookalikes, unrelated names and edge cases such as uppercase letters and trailing dots. The matcher must flag exactly the planted lookalikes. When a change to the rules is made, the same test is rerun so regressions show up immediately. Amara's tests caught one error early. A rule for added words ignored uppercase letters in the extract, so a planted lookalike with capitals was missed. The test failed, the matcher was fixed to normalise case and the test passed. Without the planted list, the bug would have hidden real lookalikes for weeks. ### Worked example In week two the matcher flags hcht-careers.example. Triage finds a certificate issued the same day and a login form described in public scan results from a reputable passive service. The supervisor rates it suspicious and starts HCHT's takedown process through the proper team. Amara logs the match but takes no action herself. > **Synthetic case.** The domain and results are invented. ### Errors and limits Rule-based generation misses creative lookalikes. Report what the rules cannot catch. ### Exercises - **EX112 — Homoglyph drop.** Why was the Cyrillic homoglyph rule dropped, and how was it recorded? *Rubric:* 3 = 4,000 noisy candidates; logged with date/reason; revisit; 2 = one; 1 = no reason; 0 = none. - **EX113 — Scope request.** How did Amara handle the request to add member domains? *Rubric:* 3 = recorded, estimated, agreed limited pilot with tutor, kept deliverables; 2 = partial; 1 = accepted all; 0 = none. - **EX114 — Takedown role.** Who acted on the suspicious domain, and why not Amara? *Rubric:* 3 = supervisor via proper takedown team; intern lacks authority; 2 = partial; 1 = Amara; 0 = none. ### Synthesis Build in tested steps, log decisions, control scope, protect data and leave actions to those authorised. ### Continue studying — chapter 38 of 40 [← Chapter 37 (draft)](#ch-37) · [Course chapter index](../SUBJECTS.md) · [Chapter 39 (draft) →](#ch-39) ## Worked answers **EX112.** It generated about 4,000 mostly irrelevant candidates; she logged the date and reason and noted it for later review. **EX113.** She recorded the request, estimated the effort and agreed with her tutor to pilot three member domains while keeping original deliverables. **EX114.** The supervisor started HCHT's takedown process through the responsible team; Amara has no authority to act on external domains.