Chapter 36 — Field or community practice
Lesson map
Lesson 36 published. Map, example, EX071.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Forms of practice"]
N2["36.2 Working within processes"]
N3["36.3 Communication"]
N4["36.4 Reflection"]
N5["36.6 Practical activity"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX071"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Forms of practice"]
N2["36.2 Working within processes"]
N3["36.3 Communication"]
N4["36.4 Reflection"]
N5["36.6 Practical activity"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX071"]
[Learning outcomes]
|
v
[36.1 Forms of practice]
|
v
[36.2 Working within processes]
|
v
[36.3 Communication]
|
v
[36.4 Reflection]
|
v
[36.6 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX071]
Learning outcomes
You will (1) apply course skills in a supervised placement or community project; (2) work within an organisation's authorization and change processes; (3) communicate with non-specialists; and (4) reflect on practice using evidence.
36.1 Forms of practice
Placements might involve supporting an organisation's cryptographic inventory, writing internal guidance on PQC, testing a library upgrade in a lab, or helping a community organisation (a library, charity or small business) understand which of its services rely on vendors that must migrate. The learning comes from doing real work under real constraints.
Whatever the setting, agree at the start what you will produce and who will use it. A short inventory or a page of guidance that a team actually adopts teaches more than a large report nobody reads, and it gives you concrete evidence for your practice log.
36.2 Working within processes
Organisations have change control, security policies and supervisors. Follow them. Obtain written scope from your supervisor. Never run tools on production systems without approval; never take data home. If you notice something serious — for example, an exposed private key — report it through the organisation's process immediately.
Ask early how changes are approved, because a lab test that seemed simple may need a ticket and a review. Keep copies of approvals with your log. Working inside these processes is part of the learning: a migration in a real organisation moves at the speed of its change control.
36.3 Communication
Non-specialists need plain language. Instead of "migrate KEX to ML-KEM-768 hybrid", say "update how our systems agree secret keys so that recorded traffic stays protected even if powerful quantum computers are built". Check understanding by asking what the listener will do next.
A short written summary after a meeting helps too. It records what was agreed in words both sides understand, and it lets the listener correct a misunderstanding before it turns into wrong action. Keep technical detail in an appendix for those who want it.
36.4 Reflection
Keep a practice log: what you did, what evidence you produced, what surprised you, what you would do differently. Link entries to course concepts. Reflection turns experience into transferable skill.
Write entries soon after the work, while details are fresh, and keep them brief. Include mistakes and what you learned from them, since these are often the most useful entries. Over a placement, the log shows how your judgment developed, which is exactly what assessors look for. Note any evidence you can share and anything you must keep confidential.
36.5 Worked example
A student volunteers with a small (synthetic) community credit cooperative that uses a hosted banking platform. With the manager's written approval, the student reviews the vendor's public security documents and contract, finds no PQC roadmap, and drafts three questions for the next vendor meeting: which algorithms protect data in transit, when hybrid key exchange will be supported, and whether the vendor maintains a cryptographic inventory. The student also writes a one-page plain-language explainer for the board.
The questions were agreed with the manager first.
36.6 Practical activity
Write a scope agreement and the first three entries of a practice log for your placement or a simulated one.
The scope agreement should name your supervisor, the systems or documents you may access, what you will produce, and what you must not do. Each log entry should record the task, the evidence produced and one reflection. If you are simulating a placement, base it on the HCU case and state which parts are invented. Ask your supervisor to sign the agreement.
36.7 Common errors and limits
- Acting outside agreed scope to be helpful.
- Using jargon with non-specialists.
- Logs that list tasks without evidence or reflection.
- Keeping notes only in your head, so that nothing can be shown later.
- Promising results the organisation did not ask for.
- Taking copies of documents outside the agreed scope.
- Assuming silence means approval.
- Forgetting to close the placement with a handover of what you produced.
Each makes it harder for the organisation to trust the work or use it. A weekly check against the scope helps.
Exercises
- EX071 — Plain language. Explain "signature migration" to a non-technical board member in three sentences. Rubric: 3 = accurate, jargon-free, actionable.
- EX072 — Escalation. You find a private key in a shared folder during a placement. List your next four actions. Rubric: 3 = stop, report via process, do not copy/use, document.
Synthesis
Supervised practice applies course skills within authorization and change processes, with plain communication and evidence-based reflection.
Continue studying — chapter 36 of 40
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →