When the principles pull in different directions

Two sound principles can recommend different actions. Keeping a complete history may help the next person understand a decision and also expose information they should not receive. Calling both principles important leaves the person doing the work with the same unresolved choice.

The examples below are hypothetical. They show how a team could make the decision explicit without pretending that one rule settles every case.

A usable handoff without a copy of everything

A researcher is handing over a project. The folder includes a report, interview notes and a participant’s request to stop retaining particular material. The successor needs to understand why the report’s conclusion changed.

One tempting response is to copy the whole folder. It preserves context and feels safer than deciding what matters. It also gives another person information whose retention or access may be inappropriate. At the other extreme, deleting the folder without examining it could lose the report and the non-sensitive record of the decision.

The researcher should first establish what can be retained and who may receive it. Within those limits, a handoff can preserve the current report, its approved sources and the fact that a source was removed from consideration. It need not preserve the source’s private contents. Where duties conflict or the applicable retention rule is uncertain, the responsible data owner needs to resolve that question before copying or deleting the disputed material.

Continuity is continuity for an authorized successor. Archiving needs a legitimate purpose and appropriate access. Neither principle gives a team permission to keep everything indefinitely.

A failed check during urgent work

Imagine a service needs an urgent repair, but the automated test that normally checks access permissions is unavailable. Users are already experiencing disruption.

Silently skipping the test would turn an unknown result into apparent permission to release. Stopping all work would prevent the team from investigating, preparing a repair or considering a previously authorized recovery procedure.

The team can continue those activities while the protected release waits. If it has an established emergency procedure, the designated person can assess whether an alternative check provides the required protection and whether a limited recovery action is authorized. The decision needs evidence about the actual risk, including the harm of waiting. Urgency alone is not a substitute for that evidence.

An improvised bypass approved by someone without the relevant authority does not become sound because it is recorded. Conversely, a system in which every failed check stops every activity has confused the protection with the whole workflow. The safeguard chapter makes the scope of the blocked action explicit.

Containment before the complete repair

A billing export is producing duplicate rows. The team can stop the faulty export immediately, but finding and fixing the cause will take longer. It must also determine which outputs have already been affected.

Waiting for the complete repair would allow more bad exports. Turning the export back on after changing one line without checking earlier outputs could leave people relying on incorrect data.

The responsible sequence is to contain the problem, describe what the containment does and does not accomplish, and then finish the bounded repair. In this example, that includes correcting the cause, checking the affected outputs and deciding what evidence permits restart. The temporary action is useful work with a declared limit.

The complete-fix principle should prevent an unresolved problem from disappearing behind a success claim. It should not prevent urgent containment or expand a repair into an unlimited redesign.

A specialized tool that earns its cost

A designer can produce a more useful interactive model in a specialized tool than in a broadly readable document. Some of its behavior will not survive export.

Rejecting the tool solely because another tool cannot reproduce every feature may sacrifice the work’s purpose. Accepting it without examining the consequences may leave the team unable to continue when access changes.

The designer and team can decide which parts must remain usable elsewhere: source data, important assumptions, approved decisions and a representation another person can inspect. They should try that handoff, including the features it loses, before claiming the work is portable. If the losses are acceptable for this task, using the specialized tool can be a considered choice.

The aim of portability is to retain meaningful control of the work. Perfect interchangeability is not always available or worth its cost.

A decision record someone can use

When principles conflict, a short record can answer five questions:

1. What action are we deciding about, and who could be affected?
2. What rights, permissions or obligations constrain the choice?
3. What do we know from current evidence, and what is still uncertain?
4. Which option gives us the best justified result within those constraints, including the cost of waiting?
5. Who owns the decision, and what would cause us to reconsider it?

That record does not require a new committee or a long template. It requires enough reasoning for the responsible person to make a decision and for the next person to understand it. If no available option is acceptable, saying so is more useful than stretching a principle until it seems to authorize one.