Components are what you know. Functions are where the chain starts.
List what is inside the product first: components, interfaces, security properties. Those are yours and nobody derives them. Then the hard part of the template, how much context and how many conditions to write, stops being a judgment call. It is a chain, and each link tells you exactly what belongs in the next.
PC, PI → FCEach function is performed by product components and reaches the outside through interfaces. Tick which.
FC → CC, CP, CZContext, in the current template, is three lists: components, persons, zones. Each exists only because a function needs it. Walk each function and ask what outside the product it depends on, and who, and where.
CC, CP, CZ → CUA condition of use exists only because something in the context must satisfy it for a function to be safe. It is born attached to the thing it constrains, which is the “affected” column the template asks for.
CU → RIA risk is a condition not met, or a function misused. Name the damage, and draw the path it takes as numbered steps.
diagramOne picture, six layers: product, properties, context, function, conditions, risk. Never drawn separately. Fix the lists and every layer fixes itself.
You work in derivation order. The generated document below follows the template’s chapter order, where context precedes functions. Both are correct: one is how you find the content, the other is how the reader meets it.
Method: The Derivation Rule for Context and Conditions of Use, Marpet & Viktor, The Value Chain Risk Institute, 2026, CC BY 4.0. The definitions and the example are the working group’s; the derivation chain and the diagram corollary are what we ask to be attributed.