When only part of a product carries an external evidence obligation, do you apply one traceability standard everywhere or two?
answer
- Scope the obligation before choosing ceremony
- The closure, not the module boundary
- Uniform ceremony decays into form-filling
- Split boundaries erode without a rule
- Name the trigger to revisit
basics
~20 sDecide from where the obligated behaviour actually reaches, not from the module diagram. One standard everywhere is simple but taxes work that never needed it and decays into form-filling; two are cheaper until the boundary erodes unnoticed.
solid answer
~50 sFirst compute what the obligation actually reaches: the named behaviours plus the components, datasets and deployment units they run through. That closure, not the module boundary, is the real obligated set. If it is small, stable and structurally separated, two standards are defensible — but only with the boundary enforced: a derivable rule for what is inside, a review rule that obligated behaviour may not depend on anything kept lighter, and promotion happening in the same change that pulls a component in. If the closure is broad or moves every release, one standard costs less than re-adjudicating the boundary continuously. Name what each costs over years. Two standards erode: code migrates and something obligated ends up documented lightly. One standard taxes every change and degrades into mechanical form-filling, weakening the evidence exactly where it mattered. State the trigger that would make you switch.
code
pseudocode · 16 linesOBLIGATED_SET = closure of:
behaviours named in the external obligation
+ components those behaviours run through at request time
+ datasets those behaviours read or write
+ deployment units carrying any of the above
+ configuration selecting which path executes
RULE every member of OBLIGATED_SET keeps the heavier evidence standard
RULE a component entering OBLIGATED_SET changes standard in the SAME change
RULE a dependency from OBLIGATED_SET onto a lighter component is refused
FLOOR components outside still keep by-product links, never nothing
EACH RELEASE:
recompute OBLIGATED_SET
if size(OBLIGATED_SET) / size(system) > agreed_share:
revisit the two-standard decisiongo deeper
Know that some parts of some products must produce evidence for outsiders, and that this changes how carefully the links between requirements and verification are kept in that area.
Explain what the heavier standard actually adds — named evidence, versions, attributable performers, retention — and why applying it to everything is not automatically the safer choice.
Show how you would find the true reach of an obligation: shared components, shared data and shared deployment carry obligated behaviour much further than a module diagram suggests.
Own the trade-off across years — a boundary that erodes under two standards against a permanent tax and mechanical compliance under one — and state the trigger that would make you switch.
## Find where the obligation actually reaches This sounds like a policy choice and is really a scoping problem. Before deciding how much ceremony to apply, establish what the external obligation reaches, and expect it to reach further than the module boundary that appears to contain it. An obligation attaches to *behaviour* — a calculation whose result must be defensible, a record that must be retained, a decision affecting a person that must be explainable. The obligated set is therefore a closure rather than a folder: - the components those behaviours run through at request time, shared libraries and shared services included; - the datasets they read from and write to, including anything that feeds the calculation; - the deployment units carrying them, because a change to a shared unit changes the obligated behaviour; - the configuration that decides which path executes. Compute that closure once, honestly, and the argument usually resolves itself. Where the closure is a small stable island — one service, its own data, its own release cadence — two standards are viable. Where it runs through the shared identity path, the shared data platform and the shared release pipeline, "only part of the system" was never true, and one standard is what you already have whether you admit it or not. ## One standard against two | | One standard everywhere | Two standards with a boundary | | --- | --- | --- | | Cost profile | A permanent tax on every change, paid by everyone | Cheap on the light side, full cost on the obligated side | | Failure mode | Ceremony becomes mechanical and stops carrying meaning | The boundary erodes and obligated behaviour ends up documented lightly | | Onboarding | One rule to learn, applied everywhere | Every engineer must always know which side they are on | | Reacting to change | A boundary move needs no decision | Every boundary move is a decision someone must notice and make | | Best when | The closure is broad, or moves every release | The closure is small, stable and structurally separated | Neither column is the safe one, and saying so is most of the answer. The instinct to apply the strictest standard everywhere reads as caution and behaves as risk: ceremony that most people cannot connect to a purpose gets filled in mechanically, and mechanical evidence is weak evidence precisely where it was supposed to be strong. A team producing a hundred meaningless links a week does not produce the one meaningful link any better. The two-standard option is not free either, and its cost is not the ceremony — it is the vigilance. A boundary between standards is a boundary entropy attacks. Code moves. A shared component gets reused inward. A dataset grows a new consumer. A team reorganises and the tribal knowledge of which side is which evaporates with the people who held it. ## Making a two-standard split survive If you choose two, the split has to be held by something other than memory: 1. **Write the obligated set down as a derivable rule** rather than a list of team names, and recompute it every release. Growth in the closure is the signal you are watching for. 2. **Make the dependency direction a review rule.** Obligated behaviour may not come to depend on a component kept at the lighter standard. That single check catches most erosion. 3. **Make entering the set a same-change event.** When a component joins the closure, its standard changes in the change that brought it in, not in a cleanup afterwards. 4. **Give the light side a floor rather than nothing** — enough by-product linking that promotion is possible without archaeology. Over a few years, that fourth point separates teams who can move the boundary from teams who cannot. Promotion from the lighter standard to the heavier one is only cheap if the lighter standard was not zero. ## Owning the decision What a lead actually owns here is a defensible position plus a trigger to revisit it. State the closure you computed and when you computed it. State which choice you made and the conditions that would flip it: the closure growing past some share of the system, a second obligation arriving on a different area, a reorganisation dissolving the structural separation the split relied on. Then name the residual risk you accepted, because both options carry one. Under two standards, the risk is that something obligated ends up documented lightly and you learn it from an outsider. Under one, the risk is that uniform ceremony degrades into form-filling, and the evidence that mattered ends up no better than the evidence that did not. The answer that fails an interview is the one with no cost on either side — *we apply the highest standard everywhere, to be safe*. It is not safe, it is expensive, and it quietly assumes that the amount of evidence and the quality of evidence are the same variable.
- What would make you move from two standards to one part-way through a product's life?The closure growing until the light side is a minority of the system; a second obligation landing on a different area, so the split is now three-way; or a reorganisation dissolving the structural separation the boundary relied on. Any of those turns the boundary into something re-adjudicated every release, and at that point uniform ceremony is cheaper than the arguments — provided you also cut the ceremony down to what genuinely carries weight.
- How do you stop the lighter side becoming a back door into the obligated side?Make the dependency direction a review rule: obligated behaviour may not come to depend on anything kept at the lighter standard, and any change creating such a dependency either fails review or promotes that component in the same change. Recompute the obligated closure each release and watch its size. Keeping a real floor on the light side matters too, because promotion is only affordable when the lighter standard was not nothing.
saying these in an interview costs you the question
- Applies maximum ceremony everywhere to be safe
- Assumes the module boundary equals the obligation boundary
- Never revisits the split once it has been set
- Treats ceremony as free because it is not code
- Lets shared components stay light while carrying obligated behaviour