Chapter 25 — Design studio I
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The brief"]
N2["25.2 Alternatives"]
N3["25.3 Critique"]
N4["25.4 Prototype"]
N5["25.5 Presentation"]
N6["25.6 Peer review"]
N7["Team roles"]
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 The brief"]
N2["25.2 Alternatives"]
N3["25.3 Critique"]
N4["25.4 Prototype"]
N5["25.5 Presentation"]
N6["25.6 Peer review"]
N7["Team roles"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 The brief]
|
v
[25.2 Alternatives]
|
v
[25.3 Critique]
|
v
[25.4 Prototype]
|
v
[25.5 Presentation]
|
v
[25.6 Peer review]
|
v
[Team roles]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) work in a team on a supply-chain design problem; (2) produce alternative designs; (3) critique designs against requirements; (4) present a recommendation.
25.1 The brief
Kwame's studio team of four receives a brief from Coastline: design how the mobile ticket app, now built in CI, should be signed, verified and updated, meeting the requirements from chapter 21.
Moving the mobile build into CI, after the gap found in the chain diagram, solved where the app is built but not how users and Coastline can confirm what they received. The brief asks for signing, verification and updates together, because a design that signs well but updates poorly still leaves riders on old versions. Requirements from earlier work give the team a ready test for each option.
25.2 Alternatives
Option A: traditional long-lived signing key in a hardware module. Option B: keyless signing with short-lived certificates tied to the CI identity (the Sigstore model). Option C: platform app-store signing only.
Including a minimal option, C, gives a baseline to compare against: if A or B adds little over relying on the app stores, the extra effort is not justified. The three differ mainly in where trust sits: in a key Coastline guards, in an identity and a public log, or in the store operators.
25.3 Critique
Against requirements: A is strong but needs key ceremonies and rotation; B reduces key-theft risk and adds a public transparency log but depends on an external service; C is simplest but gives Coastline no independent verification.
The team scores each option against the requirement table rather than against general impressions. Dependence on an external service, for B, is weighed by asking what happens during an outage: builds would pause signing, which fails closed. For C, the lack of independent verification fails the requirement that Coastline can check what was built from its own records.
25.4 Prototype
The team prototypes B with synthetic artifacts in a test environment, measuring time added to builds (about 20 seconds).
The prototype tests the claims made in the critique. Twenty seconds per build is small compared with the test suite, so build time is not an objection. The team also confirms that verification fails when an artifact is altered and when the certificate identity is not Coastline's CI, and records any steps that were harder than expected. Synthetic artifacts mean no real signing identity or production system is involved, so mistakes during the prototype carry no risk. Measured numbers replace guesses in the final presentation.
25.5 Presentation
Ten minutes to Ingrid and two Coastline engineers, with the requirement table, risks and recommendation.
Ten minutes forces the team to lead with the recommendation and the evidence for it, leaving detail for questions. The requirement table lets Ingrid see at once which needs each option meets. Risks are stated plainly, including the dependence on an external service for B. Kwame, as requirements owner, answers questions about coverage. The engineers' questions are noted and answered in writing afterwards, so nothing raised in the meeting is lost.
25.6 Peer review
Another studio team reviews the design and asks how verification works offline on buses with no signal; the team adds cached verification material.
Reviewers from outside the team see assumptions the authors no longer notice. The team had assumed riders' phones are always online, but buses and ferries often lose signal, and a verification step that needed the network would block riders at the worst moment. Cached verification material lets the app check updates offline, with a refresh when signal returns. The review is recorded with the change it caused, so later readers understand why the design includes caching.
Team roles
Each studio team assigns a lead, a requirements owner, a prototype builder and a reviewer, rotating in the next studio. Roles make sure no part of the design is forgotten and give each student practice in different responsibilities. Kwame acts as requirements owner, keeping the table current as the design changes.
Reflection
After the studio, each student writes one page on what they learned and would change.
Worked example
The team recommends B combined with C: app-store signing for distribution plus keyless signing and provenance for Coastline's own verification. Ingrid accepts it for a pilot.
Synthetic case. The studio brief and results are synthetic.
Errors and limits
Studio prototypes are simplified; production adds monitoring and recovery.
Exercises
- EX073 — Three options. Describe the three options. Rubric: 3 = HSM long-lived key; keyless short-lived; app store only; 2 = two; 1 = one; 0 = none.
- EX074 — Option C weakness. Why is option C weak alone? Rubric: 3 = no independent verification; 2 = partial; 1 = vague; 0 = none.
- EX075 — Offline question. What did peer review raise and how was it addressed? Rubric: 3 = offline verification on buses; cached material; 2 = partial; 1 = vague; 0 = none.
Synthesis
Compare alternatives against requirements, prototype and accept critique.
Continue studying — chapter 25 of 50
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →