Powell's Law: Time, Progress and the Cost of Interruption in Resilient Systems

Abstract

Resilience is commonly evaluated through availability, fault tolerance, recovery time and the frequency of failure. These measures describe whether service remains operational and how quickly execution can be restored, but they do not fully describe the fate of work already in progress when an interruption occurs.

This paper proposes that preservation of valid committed progress is a fundamental property of resilient systems. It introduces an interruption profile comprising additional elapsed time, loss of valid progress and additional recovery effort. Progress is not assumed to be a universal scalar. It is treated as a domain-specific set or partial ordering of valid outcomes that remain identifiable and safely reusable after the execution context that produced them has disappeared. The paper also distinguishes a recovery knowledge deficit from the effort required to resolve it and from recovery debt that persists when recovery obligations are repeatedly externalised to operators.

The model is applied comparatively to restart, checkpointing, idempotent activities, transactional messaging, saga coordination and durable workflow execution. The comparison shows that rapid restoration of execution does not by itself preserve business outcomes or establish the next safe action. The paper further identifies limitations involving rollback, expiring outcomes, planned suspension, irreversible side effects and the ongoing cost of resilience mechanisms.

From this analysis, the paper derives the following progress-preservation principle:

In a resilient system, interruptions should cost time, not progress.

The principle is an architectural objective rather than a claim that interruption can be made cost-free or a prescription for a particular technology.

Keywords: resilience, durable execution, progress preservation, recovery debt, idempotency, distributed systems, workflow orchestration, interruption cost

1. Introduction

Every non-trivial system is eventually interrupted. Processes terminate, containers restart, workers are replaced during deployment, networks become unavailable and external dependencies fail. Long-running business processes may also suspend for hours or days while awaiting human decisions, regulatory checks, customer responses or events from other systems.

Software engineering offers many responses. Retry policies address transient dependency failures. Replication and failover restore execution capacity. Checkpointing limits repeated computation. Transactions constrain partial state changes. Idempotency and request identifiers make repetition safer. Sagas represent partial completion and compensation. Durable workflow systems preserve orchestration state beyond the lifetime of a worker.

These techniques address different problems. A service can restart in seconds while the business process it was executing remains unrecoverable. A handler can be invoked again while nobody can determine whether its previous invocation completed an external write. A workflow may appear ready to retry while database records, inventory reservations, payment authorisations and downstream systems represent incompatible or uncertain outcomes.

Service recovery and process recovery are therefore not equivalent. Restoring execution answers the question, “Can some worker run?” Recovering progress answers different questions: “What valid outcomes survive? What is known about external effects? What may safely happen next?”

This paper develops a conceptual model for answering those questions. Its contribution is not a new recovery mechanism. It is a common architectural frame that:

1. separates elapsed delay, progress loss and recovery effort;
2. treats progress as valid committed outcomes rather than completed instructions;
3. makes uncertainty about continuation an explicit recovery concern;
4. distinguishes immediate recovery work from accumulated recovery debt;
5. provides a repeatable method for reviewing interruption boundaries.

The model is intentionally implementation-independent. Its purpose is to make differences between recovery designs visible and to expose costs that availability and restart-time measures can conceal.

2. Definitions and Scope

2.1 Interruption

An interruption is an event that prevents a process from continuing through its current execution path without a discontinuity. Causes include process failure, infrastructure replacement, dependency unavailability, network partition, deployment, preemption and loss of execution context.

An interruption is not necessarily a platform-wide outage. A single workflow instance may be interrupted while the service continues accepting other work. Conversely, an entire service may become unavailable while its persisted processes remain recoverable.

Planned suspension, human waiting and cancellation are related but distinct. A planned suspension is designed to preserve a continuation point. Cancellation intentionally changes the required terminal outcome. They are included in analysis only where they expose the same architectural question: whether the process retains enough valid state and knowledge to continue or conclude safely.

2.2 Execution

Execution is the transient performance of work by a runtime context, including a process, thread, container, worker, function invocation, agent or human operator. Execution state held only in memory is temporary. A resilient process cannot depend indefinitely upon the continued existence of the worker that produced its state.

2.3 Valid committed outcome

A valid committed outcome is a result that:

1. is recognised by the relevant domain as having taken effect;
2. satisfies the invariants applicable at the time it is considered;
3. is sufficiently established that continuation may rely upon it;
4. remains identifiable after the execution context is lost.

The term committed is used in a broader sense than a database commit. A payment authorisation confirmed by a provider, a recorded human approval, a shipment accepted by a fulfilment service or a calculation stored with its input version may each be committed outcomes. Whether an outcome is valid and reusable is defined by the domain, not by persistence alone.

Tentative computation is not necessarily progress. A price calculated from expired market data may have been expensive to produce but may no longer be usable. A message buffered only in volatile memory is not committed merely because an API call returned. A local record asserting success is not sufficient when an externally visible effect remains contradictory or unknown.

2.4 Continuation knowledge

Continuation knowledge is the information required to distinguish:

• valid completed outcomes;
• pending work;
• failed work;
• effects whose outcome remains uncertain;
• the next actions permitted by domain invariants.

Continuation knowledge may be represented through workflow history, checkpoints, event logs, correlation identifiers, idempotency records, state machines, transaction records, acknowledgements, human-task records or queryable external operation status.

2.5 Safe continuation point

A safe continuation point is a state from which the next permissible action can be selected without violating domain invariants, discarding a valid committed outcome or unintentionally repeating an externally visible effect.

It need not reproduce the exact instruction or call stack at which execution stopped. Recovery can continue through a replacement worker, an alternative workflow branch, compensation or a human decision. What matters is that the system can establish which outcomes remain valid and which action is safe next.

2.6 Durable progress

Durable progress is the accumulation of valid committed outcomes and continuation knowledge that remain identifiable and safely reusable after the execution context that produced them has been lost.

This definition distinguishes progress from elapsed time, CPU effort and physical storage. A process may run for hours without establishing durable progress. Another may run briefly, record a durable continuation point and be safely resumed by a different worker.

Progress is domain-specific and need not be scalar. Two process states may be incomparable. An order with payment authorised but inventory expired is not obviously ahead of an order with inventory reserved but payment pending. A useful model must therefore avoid assuming that every state can be placed on one universal numerical scale.

2.7 Recovery knowledge deficit, effort and debt

A recovery knowledge deficit is the set of facts required for safe continuation that cannot be established automatically after interruption. For example, a system may know that a shipment request was sent but not whether the fulfilment provider accepted it.

Recovery effort is the additional automated or human work required to remove that deficit and establish a safe continuation point. It may include reconciliation, replay, compensation, log inspection, external-system verification, database correction and repair scripts.

Recovery debt is the unresolved or recurring obligation created when an architecture repeatedly fails to preserve sufficient continuation knowledge and externalises the resulting recovery work, uncertainty or risk to operators. Recovery effort is paid during an incident. Recovery debt is an architectural liability that persists across incidents until the underlying recovery capability is improved.

The phrase has also been used in restoration ecology to describe accumulated shortfall during recovery [13]. The present use is domain-specific: it describes accumulated operational obligation arising from missing continuation knowledge in software-supported processes.

3. The Interruption Profile

Let $I$ represent an interruption affecting a process. Rather than immediately reducing its consequences to one cost, the model first represents them as an interruption profile:

The three components describe delay, loss of valid progress and additional recovery effort. They may use different units and should remain separate unless a particular domain supplies a defensible way to combine them.

3.1 Additional elapsed time

Let:

where $T_I$ is completion time in the presence of interruption and $T_0$ is the counterfactual completion time without it, for the same intended terminal outcome and comparable execution conditions.

In ordinary recovery scenarios, $\Delta T>0$: detection, worker replacement, dependency recovery, reconciliation or replay takes time. The counterfactual is not directly observable, so practical use requires estimation from service objectives, historical baselines, simulations or matched executions. The model therefore treats $\Delta T$ as an analytical quantity rather than a claim of exact measurement.

The inequality is not universal. Speculative execution, faster failover infrastructure or an alternative valid outcome could produce $\Delta T\leq0$. The architectural principle does not depend upon time loss being mathematically inevitable. It accepts that interruption commonly adds time while focusing attention on consequences that architecture can prevent.

3.2 Preservation rather than a universal progress scalar

Let $V(s)$ denote the set of valid committed outcomes and continuation facts available in process state $s$. Define the preservation relation:

This relation holds when every valid reusable outcome in $V(s_a)$ remains identifiable and reusable in $V(s_b)$.

If $s_i$ is the state immediately before interruption and $s_r$ is the state when safe continuation becomes possible, progress is preserved when:

This is a partial ordering. It permits alternative valid paths and does not require every state to have a single numerical score. Outcomes that expire, are superseded or are intentionally compensated are evaluated according to current domain validity rather than simply counted as lost.

For a particular domain, reviewers may still define a weighted measure of lost valid outcomes:

where $\mu$ is a domain-specific measure. It might count repeated workflow milestones, compute time, financial exposure or weighted business outcomes. In qualitative reviews, $P_{\mathrm{loss}}$ may instead be classified as none, bounded, material or unrecoverable.

The earlier shorthand $\Delta P$ remains useful when a domain has a meaningful scalar progress measure. In that restricted case:

The preservation relation is primary because it remains meaningful when process states are multidimensional or incomparable.

3.3 Additional recovery effort

Let:

where $R_I$ is recovery effort with the interruption and $R_0$ is the effort required without it. Measurement may use automated recovery actions, operator minutes, specialist hours, financial cost or an ordinal scale.

Recovery effort is not the same as elapsed delay. Two systems may remain paused for the same period while one resumes automatically and the other requires a developer, an operator and a domain specialist to reconstruct events. Conversely, an automated reconciliation may consume substantial computation while requiring no human intervention. Practical assessments should therefore record both human and automated effort and state the chosen unit.

3.4 Optional scalar cost

Where an organisation has defensible conversion factors, it may calculate:

The weights convert heterogeneous quantities into a common organisational cost such as money, risk-adjusted loss or utility. Without such conversion, the vector $K(I)$ is the more honest representation.

The components can share causes and should not be interpreted as causally independent. Repeated work can simultaneously increase elapsed time, represent lost progress and require recovery effort. Keeping the profile dimensions separate exposes these consequences; it does not assert that their costs can always be added without overlap.

Figure 1 summarises the three dimensions of the interruption profile and shows how an optional domain-specific cost function may combine them. The diagram also distinguishes the commonly unavoidable loss of elapsed time from the architectural objectives of preserving progress and minimising recovery effort.

4. Worked Example: A Customer Order Process

Consider a customer order process:

1. the order is received;
2. the order is validated;
3. inventory is reserved;
4. payment is authorised;
5. a shipment is created;
6. confirmation is sent.

Each step may interact with a different system and create an externally observable effect. Inventory may be managed by a warehouse platform, payment by a payment provider and shipment by a fulfilment service.

Suppose execution is interrupted after payment authorisation while a shipment request is in flight. The order and inventory reservation remain available, and the payment provider confirms the authorisation. The local process does not know whether the fulfilment service accepted the shipment request before the connection was lost.

Several outcomes are possible. No shipment may exist. A shipment may have been created while its acknowledgement was lost. Processing may still be underway. A repeated request may create a second shipment if the provider cannot deduplicate it.

Restarting from the beginning is unsafe. Repeating inventory reservation may reduce available stock twice. Repeating payment authorisation may create multiple holds. Repeating shipment creation may dispatch duplicate goods. Sending confirmation before shipment status is known may misinform the customer.

At this point:

• order validation, inventory reservation and payment authorisation are valid committed outcomes;
• shipment outcome is a recovery knowledge deficit;
• the process has no safe continuation point until the deficit is resolved;
• an operator may incur recovery effort even though no stored record has been physically lost.

Figure 2 locates the interruption at the boundary between payment authorisation and shipment creation. It distinguishes the outcomes already confirmed by the process from the shipment request whose external result remains uncertain.

5. Why Restart Is Not Necessarily Retry

Restart describes restoration of execution. Retry describes repetition of an intended operation. Neither establishes whether previous externally observable work occurred.

A pure calculation with deterministic inputs can often restart safely. A distributed business process usually cannot. Once inventory is reserved, payment authorised or shipment created, re-execution is not equivalent to repeating a side-effect-free calculation.

A safe retry requires one or more of the following:

• the operation has no externally observable effect;
• repetition is intrinsically idempotent;
• a request identifier enables deduplication;
• operation status can be queried;
• a transaction makes the relevant changes atomic;
• compensation is defined and valid;
• workflow history records enough information to choose the next action.

Without these properties, a timeout changes a dependency failure into uncertainty about business state. Recovery becomes an investigation rather than a restart.

6. Recovery Knowledge Deficit and Recovery Debt

In the order example, an operator may inspect workflow logs, query the order database, verify inventory, check the payment provider, search the fulfilment platform and compare timestamps across systems. The operator may then release inventory, cancel a duplicated shipment, retry a request or select compensation.

The unknown shipment result is the recovery knowledge deficit. The investigation and repair are recovery effort. If this pattern recurs because the architecture provides no stable request identity or queryable operation status, the organisation carries recovery debt.

This distinction matters because immediate recovery work ends when the incident is resolved. The underlying debt remains. It is paid repeatedly through on-call effort, specialist interruption, customer support, repair scripts, operational risk and delayed completion.

Recovery debt may exist without conventional data loss. Every physical record may remain present while its relationship to the wider process and its temporal meaning cannot be established with sufficient certainty. The debt results from missing evidence, not necessarily missing bytes.

Figure 3 represents the effect of that missing evidence on durable progress. The process has preserved its confirmed outcomes, but it cannot advance while the shipment result remains uncertain. Elapsed time continues to increase during investigation, and recovery effort is incurred even though the progress already confirmed by the system has not necessarily been lost.

The interval shown in Figure 3 as manual investigation and repair is not a single recovery action. It is an operational process through which people reconstruct the continuation knowledge that the system failed to preserve. They inspect workflow history, query participating systems, verify externally observable effects, reconcile conflicting records and determine which continuation action is safe.

Figure 4 expands this interval into its constituent activities. It shows how a technical interruption becomes a manual recovery path when the architecture cannot establish the next safe action automatically.

The two figures therefore describe complementary views of the same interruption. Figure 3 shows its effect on progress over time, while Figure 4 shows the human work required to resolve the resulting knowledge deficit. Repeated reliance on this path is what converts incident-specific recovery effort into architectural recovery debt.

7. Comparative Analysis of Recovery Designs

The interruption profile can be used to compare designs without claiming precise universal measurements. Table 1 applies six representative approaches to the same interruption during shipment creation.

The comparison reveals three points. First, checkpointing is highly effective for deterministic computation but insufficient when a checkpoint and an external side effect do not share an atomic boundary. The process may know that it attempted shipment creation without knowing whether shipment exists.

Second, idempotency protects the meaning of repetition but does not independently preserve the structure of a multi-step process. A deduplicated shipment request is safer to retry, yet the system still needs to know whether payment, inventory and confirmation steps are complete.

Third, durable workflow execution preserves orchestration knowledge but does not manufacture guarantees absent from dependencies. If a fulfilment API supplies neither request identity nor status enquiry, workflow history can accurately record uncertainty but cannot eliminate it.

The model therefore does not rank one technique as universally superior. It identifies which element of the interruption profile each design changes and where uncertainty remains. Table 1 summarises these distinctions.

Table 1. Comparative interruption profiles for representative recovery designs.

8. Derivation of the Progress-Preservation Principle

The analysis supports four observations.

First, interruption commonly introduces elapsed delay. Even automated recovery requires detection, rescheduling, dependency restoration or replay.

Second, interruption does not inherently require valid committed outcomes to disappear. If continuation knowledge and relevant outcomes outlive the worker, another execution context can proceed from a safe state.

Third, substantial recovery effort is not intrinsic to interruption. It often arises because an architecture failed to preserve evidence about completed work, side effects or the next permissible action.

Fourth, progress preservation is not free. Checkpoints, durable histories, idempotency records, reconciliation and transactions impose ongoing cost. Resilience shifts cost from unpredictable loss and manual reconstruction towards deliberate preventative mechanisms.

The architectural objective is therefore:

while recognising that:

will often remain.

This produces the progress-preservation principle:

In a resilient system, interruptions should cost time, not progress.

The statement is deliberately concise. Progress means valid committed outcomes and continuation knowledge that remain safely reusable. It does not include tentative computation that has expired, been superseded or must be discarded to restore correctness.

9. Progress, Rollback and Alternative Paths

The original intuition can be illustrated by plotting a domain-specific measure of valid progress over time. In a progress-preserving system, execution pauses and later continues without losing reusable outcomes. Figure 5 shows this pause as a plateau rather than a regression: elapsed time is lost, but confirmed progress remains available.

In a restart-based system, valid work may need to be repeated because the continuation point was not preserved. Figure 6 contrasts this case with Figure 5 by showing the progress curve falling to an earlier continuation point before execution resumes.

These diagrams are explanatory, not universal measurement models. Several cases require more careful interpretation.

9.1 Safe rollback

Rollback can intentionally discard tentative or inconsistent work to restore a valid state. That is not necessarily progress loss. A resilient rollback preserves valid committed outcomes and removes work that continuation must not reuse. If rollback destroys a valid committed outcome only because the architecture cannot recover it, then it is progress loss.

9.2 Compensation

Compensation does not restore history. It creates a new valid business outcome that semantically offsets an earlier one. Cancelling a shipment or releasing a reservation may represent continued progress along an alternative path. The preservation relation therefore permits valid compensated states rather than assuming that every reverse-looking transition is regression.

9.3 Expiry and supersession

Some outcomes cease to be valid while execution is interrupted. Market prices expire, leases lapse, inventory reservations time out and policies change. Recalculation in such cases is not caused solely by forgotten progress. Time changed the domain conditions. Reviews should record expiry risk separately from architectural loss.

9.4 Irreducible uncertainty

External systems may provide weak guarantees. An irreversible operation with no request identifier, deduplication, status query or compensation may remain unknowable after connection loss. The principle cannot eliminate this uncertainty. It exposes the dependency as an architectural constraint and makes the associated risk explicit.

10. Architectural Implications

10.1 Progress must outlive execution

State required for continuation must be represented independently of the current worker. This does not require persisting every local variable. It requires enough information to distinguish completed, pending, failed and uncertain work.

10.2 Partial completion must be explicit

Distributed work rarely completes atomically across every participant. “Payment authorised, shipment pending” is a recoverable state. A model containing only “started” and “completed” conceals the boundary at which recovery decisions must be made.

10.3 External outcomes must be identifiable

Correlation identifiers, idempotency keys, receipts and queryable status allow a replacement worker to distinguish completed intent from work still required. Without them, a lost acknowledgement becomes business uncertainty.

10.4 Retry boundaries must align with effect boundaries

A retryable unit should contain externally observable effects that are repeatable, deduplicated, transactional, compensatable or individually identifiable. An activity that performs several unrelated writes before failing exposes a larger ambiguous surface than one with a controlled effect boundary.

An activity-level discipline supporting this objective is WOWL: Write Once, Write Last. WOWL places repeatable reads, validation and calculation before a controlled write at the end of a retryable activity. “Write once” means one controlled externally observable write boundary within that activity, not that the wider process writes only once. “Write last” means no fallible repeatable work should follow the write inside the same retry unit when that work can be moved before it.

For example, an activity that reads an order, creates a shipment and then performs address validation can fail after shipment creation. Retrying the activity may create another shipment. Under WOWL, address validation and other repeatable preparation occur first. Shipment creation is last and uses an idempotency key. If interruption occurs before the write, the activity is safe to repeat. If it occurs during the write, the request identity or operation-status query resolves the outcome.

WOWL does not provide atomicity, idempotency or durable orchestration. It reduces the number of effect boundaries inside a retryable unit and makes the remaining boundary explicit. It complements, but cannot replace, the guarantees described elsewhere in this paper.

10.5 Recovery should be a system capability

Manual judgement is sometimes legitimate. Routine reconstruction of technical state is different. Repeated database corrections, payment checks, message replays and one-off scripts indicate that recovery behaviour has been delegated to people rather than designed into the system.

10.6 Process health must be observable

Service availability and process recoverability should be measured separately. For each interrupted process, the system should be able to report confirmed outcomes, uncertain effects, pending actions, the current safe continuation point and whether human intervention is required.

11. Techniques and Their Trade-offs

Retries and failover primarily reduce $\Delta T$. Checkpointing and message logging bound repeated computation and preserve recoverable state [3], [9]. Transactions protect local invariants. Idempotency protects repeated intent. Transactional outbox and inbox patterns preserve the relationship between committed state and messages awaiting publication or consumption [6]. Sagas represent partial completion and compensation [4]. Durable workflows persist orchestration state independently of workers [7], [8].

Figure 7 maps the primary and secondary contributions of these techniques to the three dimensions of interruption cost. It makes explicit that restoring execution quickly addresses elapsed time, while preserving progress and reducing recovery effort require additional guarantees.

These mechanisms impose preventative cost. Checkpoint frequency trades repeated work against storage and runtime overhead. Idempotency records require retention and clear intent identity. Workflow history increases persistence and versioning complexity. Transactions can reduce concurrency or availability. Reconciliation detects divergence but consumes resources. Compensation requires domain design and may not restore the original outcome.

Resilience therefore reallocates cost rather than eliminating it. A rational design compares predictable preventative cost with expected interruption loss, recovery effort, customer harm and risk exposure.

12. Relationship to Existing Work

The mechanisms that preserve progress are well established. The proposed contribution is a synthesis: an interruption profile, a preservation relation for valid outcomes, an explicit account of continuation knowledge and a practical review method.

12.1 Recovery objectives

Recovery Time Objective describes an acceptable duration of recovery, while Recovery Point Objective identifies the point in time to which data must be recovered [1]. They correspond approximately to elapsed delay and one component of progress loss. A process can nevertheless have an RPO of zero for its databases while remaining unable to determine whether an external shipment or payment occurred. Process recoverability therefore requires more than recoverable data state.

12.2 Recovery-Oriented Computing and microreboots

Recovery-Oriented Computing makes recovery performance, operator experience and total ownership cost primary system concerns [2]. Microreboot research separates process recovery from data recovery and shows that execution can be restarted without disturbing durable application state [10]. The present model builds on this distinction by asking whether the valid outcomes and knowledge of a particular process survive restoration of execution.

12.3 Checkpointing, rollback recovery and snapshots

Checkpointing and rollback-recovery protocols preserve recoverable computational state and bound repeated work. Message logging addresses consistency between process state and messages exchanged before failure [9]. Distributed snapshots establish a consistent global state across interacting processes [3]. These mechanisms directly inform the preservation relation, although business processes often include external systems outside a shared checkpoint protocol.

12.4 Atomicity, sagas and compensation

Atomic actions and transactions prevent observers from seeing invalid partial updates within a protected boundary [11]. Sagas extend reasoning to long-lived work through sequences of smaller transactions and compensating actions [4]. The distinction between valid committed outcomes, tentative work and compensation is necessary because resilient recovery does not always continue monotonically along one path.

12.5 Idempotency and exactly-once effects

Idempotent operations and caller-provided request identifiers distinguish repeated delivery from repeated business intent [5]. Data-processing systems similarly combine replay, durable state and idempotent or transactional output to approximate exactly-once effects [12]. These mechanisms reduce uncertainty at individual effect boundaries but do not independently describe the position of a larger process.

12.6 Transactional messaging

The transactional outbox records a business change and intent to publish in one local transaction, converting an ambiguous dual write into explicit pending progress [6]. It reduces both progress loss and recovery effort, although end-to-end consumers still require deduplication, inbox state or idempotent handling.

12.7 Durable workflow execution

Durable workflow systems persist orchestration history, timers, retries and external events independently of a worker [7], [8]. They provide a contemporary implementation of progress preservation, but their guarantees end at activity boundaries. Workflow durability cannot determine the outcome of an external operation that supplies no stable identity or queryable status.

12.8 Recovery debt

The phrase “recovery debt” has an established ecological use for accumulated shortfall during recovery [13]. In this paper it denotes recurring architectural obligation arising from missing continuation knowledge. The concepts share an emphasis on costs that persist beyond the initiating disturbance, but the quantities and domains are different.

13. Scope, Limitations and Threats to Validity

This is a conceptual position paper, not an empirical theory. The interruption profile organises reasoning but does not establish universal measurement units. $T_0$ is counterfactual, progress is domain-specific and recovery effort may be recorded in incompatible units.

The comparative analysis is illustrative. It is derived from documented semantics of recovery patterns rather than implemented systems subjected to controlled faults. Actual outcomes depend on checkpoint frequency, dependency guarantees, workload, organisational practice and implementation quality.

The preservation relation depends upon explicit domain invariants. Poorly specified validity rules can cause an architecture to preserve outcomes that should expire or discard outcomes that remain valuable. Human judgement cannot always be eliminated, particularly where the next action is a business decision rather than reconstruction of technical facts.

The model does not require preservation of every intermediate computation. It concerns valid committed outcomes and the knowledge needed to use them. Security policy, legal obligations, user cancellation or changed market conditions may intentionally invalidate earlier work.

Finally, minimising incident recovery effort can increase steady-state complexity. A system that preserves extensive history may be harder to evolve, operate or audit. The model should therefore be used alongside cost, security, privacy, performance and maintainability considerations.

14. Practical Evaluation Method

An architecture review begins by selecting a process, its domain invariants and its valid terminal outcomes. Reviewers then identify each boundary at which execution may be lost, repeated, suspended or transferred.

For every boundary, determine:

1. Which valid committed outcomes already exist?
2. Where is each outcome recorded?
3. Which externally observable effects can be proven?
4. Which effects remain uncertain?
5. Which operations are repeatable, deduplicated, transactional or compensatable?
6. Which outcomes may expire during interruption?
7. What facts are required to select the next action?
8. Can those facts be established automatically?
9. Which work would be repeated or discarded?
10. What human and automated recovery effort is required?
11. What preventative mechanism currently pays for resilience?
12. What residual uncertainty cannot be removed?

The result should record an interruption profile rather than force premature numerical precision:

For qualitative reviews, each dimension may be graded on an agreed scale and accompanied by evidence. The preservation test should be stated explicitly:

Do all valid committed outcomes established before interruption remain identifiable and safely reusable when continuation begins?

The operational companion question is:

What continuation knowledge is missing, what effort resolves it, and who repeatedly pays that cost?

Applying the method at every effect boundary exposes risks that service-level availability and restart-time measurements do not reveal.

15. Research Agenda

Further work should evaluate whether the interruption profile improves architecture decisions in practice. Suitable studies include:

• controlled fault injection across implementations of the same workflow;
• case studies measuring repeated work and human recovery actions;
• practitioner studies testing whether the review method identifies previously unknown interruption risks;
• domain-specific definitions of valid progress and weighting functions;
• comparison with RTO, RPO, incident duration and availability metrics;
• analysis of how resilience cost shifts between prevention and recovery;
• methods for representing progress as vectors, lattices or sets of commitments.

Such work could determine whether the conceptual separation produces reliable measurement, predicts operational burden or improves design choices. Until then, the model should be treated as a structured architectural lens rather than a complete empirical law.

16. Conclusion

Availability, recovery time and recovery point remain valuable, but they do not fully describe the fate of interrupted work. Execution may restart quickly while valid business outcomes are repeated, external effects remain uncertain or people spend hours reconstructing a safe continuation point.

The interruption profile separates additional elapsed time, loss of valid committed progress and additional recovery effort. The preservation relation avoids assuming that every process has one scalar measure of progress. Distinguishing recovery knowledge deficit, recovery effort and recovery debt makes visible the operational consequences of architectures that preserve records but not the knowledge required to use them.

Powell’s Law summarises the resulting objective:

In a resilient system, interruptions should cost time, not progress.

The statement does not require uninterrupted execution or preservation of invalid computation. It requires that valid committed outcomes and the knowledge needed to continue safely should outlive the worker that produced them. A resilient system may pause, retry, compensate or transfer execution. It should not unintentionally forget what has already been validly achieved.

References

1. M. Swanson, P. Bowen, A. W. Phillips, D. Gallup and D. Lynes, Contingency Planning Guide for Federal Information Systems, NIST Special Publication 800-34 Revision 1, 2010. DOI.

2. D. A. Patterson et al., Recovery-Oriented Computing: Motivation, Definition, Techniques, and Case Studies, Technical Report UCB/CSD-02-1175, University of California, Berkeley, 2002. Online.

3. K. M. Chandy and L. Lamport, “Distributed Snapshots: Determining Global States of Distributed Systems,” ACM Transactions on Computer Systems, vol. 3, no. 1, pp. 63-75, 1985. DOI.

4. H. Garcia-Molina and K. Salem, “Sagas,” in Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pp. 249-259, 1987. DOI.

5. M. Featonby, “Making Retries Safe with Idempotent APIs,” Amazon Builders’ Library. Online (accessed 2 August 2026).

6. Microsoft, “Transactional Outbox Pattern,” Azure Architecture Center. Online (accessed 2 August 2026).

7. Microsoft, “Durable Functions Overview: Stateful Serverless Workflows,” Microsoft Learn. Online (accessed 2 August 2026).

8. Temporal Technologies, “Durable Execution,” Temporal Documentation. Online (accessed 2 August 2026).

9. E. N. Elnozahy, L. Alvisi, Y.-M. Wang and D. B. Johnson, “A Survey of Rollback-Recovery Protocols in Message-Passing Systems,” ACM Computing Surveys, vol. 34, no. 3, pp. 375-408, 2002. DOI.

10. G. Candea, S. Kawamoto, Y. Fujiki, G. Friedman and A. Fox, “Microreboot: A Technique for Cheap Recovery,” in Proceedings of the 6th Symposium on Operating Systems Design and Implementation, pp. 31-44, 2004. Online.

11. D. P. Reed, “Implementing Atomic Actions on Decentralized Data,” ACM Transactions on Computer Systems, vol. 1, no. 1, pp. 3-23, 1983. DOI.

12. A. Margara, G. Cugola, N. Felicioni and S. Cilloni, “A Model and Survey of Distributed Data-Intensive Systems,” ACM Computing Surveys, vol. 56, no. 1, pp. 1-69, 2023. DOI.

13. D. Moreno-Mateos, E. B. Barbier, P. C. Jones, H. P. Jones, J. A. Aronson, J. López-López, M. L. McCrackin, P. Meli, D. Montoya and J. M. Rey Benayas, “Anthropogenic Ecosystem Disturbance and the Recovery Debt,” Nature Communications, vol. 8, article 14163, 2017. DOI.