That's a reasonable model to work from. My observations: First, "Anticipating and preventing problems ahead of time" is of a manifestly different character to

That's a reasonable model to work from. My observations: First, "Anticipating and preventing problems ahead of time" is of a manifestly different character to either "Preventing a problem that has already occurred from getting worse" (sometimes called stabilization) or "Recovering to a good state after a problem has occurred" (sometimes called remediation). Another model we use that emphasizes the difference is to divide the work into "proactive" and "reactive" categories. Everything we do that is not during an incident is proactive, everything that happens during an incident is "reactive." It's a simpler model than the three categories you presented, but it can be helpful to highlight the fact that companies often under-invest in proactive processes and end up paying the "robustness and resilience debt" in reactive activities. Second, I suggest that proactive work such as "Anticipating and preventing problems ahead of time" applies to both resilience and robustness. If there is an incident that is resolved by rebooting a service that has some kind of memory leak, that's reactive. If the postmortem identifies a bug in the code causing the leak and a bug fix is deployed to prevent that incident from happening again, the system has become more robust. Whereas, if no bug fix is made, but the runbook is updated to suggest rebooting the service when it runs out of memory, this is going to increase resilience. Proactive activities drive better outcomes in both cases.