How we look at upstream decisions.

The aim is to match specific field behavior to the decision points that made it likely, not to re-litigate every design choice.

What we look at

1. Where risk was consciously parked. Design reviews, trade-off notes, and “non-blocking” concerns that were accepted to keep the program moving.
2. Interfaces nobody fully owned. Mechanical joints, electrical boundaries, thermal paths, and software-hardware seams where assumptions span teams.
3. Field reality that diverged from models. How the system is actually operated, maintained, and misused versus what the early models assumed.
4. Paths where variability piles up. Tolerance chains, supplier spread, assembly steps, calibration, and control loops that quietly widen the state space.

What we intentionally ignore

• Generic “best practices” checklists that do not explain your specific failures.
• Superficial claims that a single supplier, part, or firmware revision is “the” cause.
• Cosmetic changes that reduce embarrassment but do not change the failure surface.
• Arguments about abstract architectures that do not move a measurable risk boundary.

When we say “do not change this”

There are parts of a system that look awkward but are now load-bearing in ways nobody expected. We call out these areas explicitly when:

• They are compensating for deeper issues that are not yet ready to be addressed.
• They anchor a fragile equilibrium that would collapse if “cleaned up”.
• The cost of disturbing them exceeds the value of making them more elegant.

In those cases, we document why they must remain fixed while other changes are explored around them.

When we say “this will bite you later”

We flag decisions that are not yet failing in the field but are already structurally fragile. Typical patterns include:

• Loads or duty cycles that are safe only under optimistic operator behavior.
• Calibration or maintenance steps that depend on rare discipline from busy teams.
• Interfaces where nobody is clearly responsible for what happens in the corner cases.
• Architectural choices that make future variants significantly harder than they appear.

These are written down plainly so leadership can decide whether to defer, accept, or address them now.