Chapter 25 — Design studio I
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 Studio brief"]
N2["25.2 ADRs"]
N3["25.3 Panel review"]
N4["25.4 Iterating"]
N5["25.5 Deliverables"]
N6["Practice note — Demonstration discipline"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 Studio brief"]
N2["25.2 ADRs"]
N3["25.3 Panel review"]
N4["25.4 Iterating"]
N5["25.5 Deliverables"]
N6["Practice note — Demonstration discipline"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 Studio brief]
|
v
[25.2 ADRs]
|
v
[25.3 Panel review]
|
v
[25.4 Iterating]
|
v
[25.5 Deliverables]
|
v
[Practice note — Demonstration discipline]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) produce a first end-to-end design for Lantern's ingestion path; (2) present it to a review panel; (3) capture decisions in architecture decision records (ADRs); (4) respond to critique with design changes.
25.1 Studio brief
Design the path from partner TAXII 2.1 collections to an analyst-ready store: polling, validation, normalisation, de-duplication, provenance, TLP enforcement and monitoring. Constraints: standard-library prototypes, synthetic data, BEN's zone model.
Kofi's team began by drawing the zones and placing each component in one before writing any code. The constraint to use only the standard library forced simple designs that the panel could read in full. Synthetic data meant that every test could be shared with the panel and repeated exactly, which real partner data under sharing limits would not allow.
25.2 ADRs
An architecture decision record states context, decision, alternatives and consequences in one page. "Poll every 15 minutes rather than subscribe to push" — context: TAXII 2.1 is pull-based for collections; consequences: up to 15 minutes latency.
Kofi's team wrote one record for each choice that someone might later question. The polling interval was one; the choice to reject rather than repair malformed timestamps was another. Each record lists the options considered and why they lost. When the panel challenged a choice, the team could point to the record rather than reconstructing the reasoning from memory.
25.3 Panel review
The panel includes an analyst, an OT engineer and a privacy officer. Each asks from their role: Is it timely? Is OT protected? Is personal data minimised?
Each reviewer reads the design from their own concerns, and their questions rarely overlap. The analyst asked how long a high-confidence indicator would take to reach DNS. The OT engineer asked whether anything in the design could push to substation firewalls without approval. The privacy officer's question led to the change described in the worked example. Kofi recorded every question with the answer given.
25.4 Iterating
Critique becomes backlog items. Designs improve when students change them in response, not when they defend every choice.
Kofi's team logged each panel comment as a backlog item with an owner and a decision. Most comments led to small changes; two led to new design records; one was declined with a written reason the panel accepted. The team found that accepting a fair criticism quickly earned more trust than a clever defence. The panel's second review was shorter because the earlier comments had visibly been acted on.
25.5 Deliverables
A diagram, five ADRs, an interface list, a monitoring plan and a demonstration of the pipeline on synthetic data.
Each item has a purpose. The diagram shows structure, the records show reasoning, the interface list shows what must be agreed with others and the monitoring plan shows how failures will be noticed. The demonstration proves that the pipeline runs end to end on the synthetic feed. Kofi's team submitted all five together, so the panel could check that the demonstration matched the diagram and the records.
Practice note — Demonstration discipline
The studio demonstration runs on synthetic data from a clean environment, with the commands scripted in advance. Live improvisation in front of a panel hides defects and wastes time; a scripted run shows what the design actually does. Students rehearse the scripted run twice before the panel, once on a fresh machine, so environment surprises appear in rehearsal rather than in front of reviewers. Afterwards the panel's comments and the team's responses are filed with the ADRs as the studio record.
Worked example
The privacy officer asks why the design stores full email headers from phishing reports. Kofi's ADR had no reason. He changes the design to store only sender domain, subject hash and indicator fields, and writes a new ADR recording the change.
Synthetic case. The studio panel is invented.
Errors and limits
Studios reward clarity, not volume. A design without monitoring is incomplete.
Exercises
- EX073 — ADR parts. List the four sections of an ADR. Rubric: 3 = context, decision, alternatives, consequences; 2 = three; 1 = one; 0 = none.
- EX074 — Polling consequence. State one consequence of 15-minute polling. Rubric: 3 = up to 15 min latency (plus load trade-off); 2 = latency vaguely; 1 = vague; 0 = none.
- EX075 — Header minimisation. What fields replace full email headers in the revised design? Rubric: 3 = sender domain, subject hash, indicator fields; 2 = two; 1 = keep full headers; 0 = none.
Synthesis
Design end to end, record decisions, invite role-based critique and change the design when critique is right.
Continue studying — chapter 25 of 50
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →