Three recovery plans finish at the same hour. They do not restore the same lives along the way.
In a fictional civic-service network, one team wants the public counter restored first because more households use it. Another wants the outreach route restored first because it can become useful sooner. A manager points to the final completion date and says the difference is unimportant: the whole recovery programme finishes at hour thirteen either way.
The households waiting for service would disagree. One schedule leaves a smaller group waiting until hour twelve. Another restores that group’s service at hour five while delaying the larger group’s service. A third performs worse under the chosen waiting-time measure than either. The final date hides the path.
Essential-service restoration, recovery sequencing and critical-path planning are therefore not simply exercises in ranking valuable assets. They require an executable order that respects prerequisites, skilled-resource limits, safety conditions and the consequences experienced while work is still incomplete.
This guide builds and checks a small recovery model step by step. Every task, duration, household count and deadline is fictional. The example concerns administrative service continuity, not instructions for restarting utilities, conducting clinical triage or repairing hazardous infrastructure. Actual recovery work requires the relevant professional authority and local procedures.
A 50-second route through the case
Start with the functions people need back. Identify the work that enables each function, its prerequisites, its qualified resources and the evidence required before use. Calculate the dependency-only schedule, then add the real resource constraint. Compare not only final completion time but also when each group receives service. Apply mandatory conditions before optimising optional objectives. Finally, update the schedule as work produces new evidence.
The central distinction is between a high-priority outcome and the next task that makes that outcome possible. They can be different. A seemingly modest verification or coordination task may need to happen first because nothing useful can proceed without it.
Choose a reading route
Part I — Define the recovery function and its prerequisites
Part II — Build the six-task dependency model
Part III — Add the scarce specialist and compare schedules
Part IV — Compare waiting, deadlines and legitimate constraints
Part V — Turn the model into a revisable recovery record
The broader question of which functions deserve continuity protection is developed in How Civilisations Decide What Must Never Fail. This case begins after that judgement: how should the necessary recovery work actually be ordered?
Part I — Define the recovery function and its prerequisites
Restoring an asset and restoring a service are different events
A building can reopen while the records needed to serve residents remain unavailable. A database can be restored while staff lack verified access. A communication channel can function while the message it carries gives the wrong location. Counting repaired objects will not reveal whether the public service has returned.
NIST’s community-resilience planning material connects the performance of buildings and infrastructure with social and economic functions. It treats dependencies and cascading consequences as part of the planning problem and links recovery goals to community needs. That provides a useful reason to begin with functions rather than isolated assets. The numerical model here is original, not a calculation taken from the NIST guide. [1]
For the fictional case, the two outcomes are a usable counter service and a usable outreach service. Each requires enabling tasks. The recovery team should therefore ask what must be true before a resident can receive the intended service, not merely which department has completed its own repair.
This changes the meaning of progress. A completed prerequisite can be important even before it produces visible public benefit. An impressive asset repair can be insufficient if another required link remains broken.
Distinguish mandatory prerequisites from convenient habits
A prerequisite is something that must be completed before another task can proceed under the defined model. It might concern safety, information integrity, access, physical availability or authorised ownership. It should not be added merely because an organisation has always preferred that sequence.
For example, the counter service may genuinely require verified records. A ceremonial meeting may not genuinely need to occur before those records can be checked. Treating both as identical dependencies can lengthen recovery without protecting anything important.
The reverse mistake is more dangerous: deleting a dependency because it appears to slow the schedule, without understanding the function it protects. Verification is not optional simply because the final date looks better without it.
A useful recovery record states the reason for each dependency. Another competent reviewer can then challenge an unnecessary constraint or defend a necessary one. The model becomes a description of the work, not a collection of unexplained arrows.
Acceptance belongs inside task duration
If a restoration task is defined as putting a system back online, the schedule may omit the work needed to establish that the restored system is correct and usable. The apparent finish time then occurs before the function is ready for responsible use.
For this case, each task duration includes the relevant local checks required for that task to count as complete. We do not prescribe what those checks would be in a real sector. We simply refuse to treat unverified output as an accepted prerequisite.
NIST’s cybersecurity incident-response guidance gives a domain-specific example: it connects recovery order with essential services and confirmation by system owners, rather than treating technical activity alone as sufficient. That principle is used here only as an analogy about verification and ownership. [2]
A task can therefore be physically finished but not yet accepted. The schedule should show that distinction instead of allowing the next team to assume the prerequisite is usable.
Keep public benefit separate from final programme handback
Our model contains a final joint acceptance task after both services have been restored. This needs careful interpretation. The model assumes that each service may begin useful operation after its own local restoration and checks are complete. The final task closes the combined recovery programme and hands it back to ordinary management.
That assumption is essential to the waiting-time comparison later. If neither service were permitted to operate until the final joint check, all households would wait until the same final hour and the intermediate completion times would not produce the modelled benefit.
There is no universal rule about which arrangement is correct. Some actual systems require joint validation before any public operation; others can restore independently verified functions in stages. The decision depends on the real service and its authority.
Stating the assumption prevents the mathematics from quietly claiming benefits before they are actually available. A model should count usable service, not merely a task marked complete.
Part II — Build the six-task dependency model
The task record
The fictional recovery begins at hour zero. Durations are fixed for the initial calculation. Tasks cannot be interrupted midway, and completing a task makes its accepted output available immediately to dependent tasks. These simplifying assumptions allow the logic to be checked before uncertainty is added.
| Task | Accepted result | Hours | Must follow |
|---|---|---|---|
| A | Required public-access clearance confirmed | 2 | None |
| B | Communication channel verified | 3 | None |
| C | Civic registry restored and verified | 4 | B |
| D | Counter service restored for use | 3 | A and C |
| E | Outreach service restored for use | 2 | A and B |
| F | Joint recovery acceptance and handback | 1 | D and E |
The labels are deliberately ordinary. A represents an authorised clearance, not instructions for evaluating a damaged building. C represents accepted registry work, not a technical recovery procedure. The educational task is scheduling accepted capabilities, not teaching unqualified readers to perform specialist work.
Already we can see why “restore the counter first” is incomplete. D cannot start until A and C finish, while C itself must follow B. The outcome’s importance does not remove the work required to enable it.
Calculate earliest finishes without a resource shortage
Initially assume that every task has its own appropriately qualified team. A and B can start together at hour zero. A finishes at hour two; B finishes at hour three. C can then run from hour three to hour seven.
E needs both A and B, so it can start at hour three and finish at hour five. D needs A and C, so it cannot start until hour seven; it finishes at hour ten. F waits for both D and E, then runs from hour ten to hour eleven.
The governing calculation for each task is simple: its earliest start is the latest accepted finish among its prerequisites. Add its duration to obtain its earliest finish. Tasks without prerequisites can start at zero in this simplified model.
The longest dependency chain is B → C → D → F, with duration 3 + 4 + 3 + 1 = 11 hours. It limits completion under the initial assumptions. This is the dependency-only critical path; it is not yet proof that the real organisation can execute that schedule.
Check the result against the prerequisites
Verification can be mechanical. For each task, compare its start with the finish of every prerequisite. E starts at three, after A finishes at two and B finishes at three. D starts at seven, after A at two and C at seven. F starts at ten, after D at ten and E at five.
The arithmetic passes that check. A second question remains: do the assumed parallel teams exist? A schedule can respect every arrow and still require one person to perform two tasks at once.
This is a common distinction between a logically ordered plan and an executable one. Dependencies tell us which tasks must wait for accepted outputs. Resource constraints tell us which otherwise eligible tasks cannot run simultaneously.
The eleven-hour result is therefore a useful lower-bound scenario for comparison, not an unconditional restoration promise. Its value depends on keeping the resource assumption visible.
Do not confuse critical-path work with all valuable work
E finishes at hour five in the initial schedule and is not on the longest dependency chain. That does not make the outreach service unimportant. It means E does not determine the final programme finish under these particular durations and resource assumptions.
Likewise, A finishes before it becomes limiting for D or E. Its early completion is still necessary. A non-critical-path task can become critical if delayed sufficiently or if another assumption changes.
The critical path answers a specific timing question. It does not rank the dignity of users, determine legal duties or decide which function deserves the greatest public investment. Confusing a scheduling property with a moral hierarchy would misuse the model.
This is why priority-setting and recovery scheduling need to remain connected but distinct. Priorities shape constraints and objectives; the schedule shows what those choices make possible.
Part III — Add the scarce specialist and compare schedules
The missing person changes the answer
Now replace the unlimited-resource assumption with a specific constraint. One qualified specialist must perform C, D and E. Those three tasks cannot overlap. A and B still have separate teams and can proceed in parallel. F uses a separate acceptance role.
The specialist cannot start C or E before B finishes at hour three. D must still follow C. Consequently, the specialist must perform nine hours of work after hour three: four hours for C, three for D and two for E.
All that work cannot finish before hour twelve. F then needs one additional hour, so the whole programme cannot finish before hour thirteen under these assumptions. The shortage adds two hours to the dependency-only result.
This is not evidence that the specialist is slow. It is a capacity constraint. Demanding the eleven-hour schedule without changing resources or legitimate task requirements would require an impossibility in the model.
Enumerate the feasible specialist orders
Because C must precede D, there are three feasible orders without unnecessary idle time: C–D–E, C–E–D and E–C–D. Each respects the prerequisite that the registry must be accepted before the counter service can be restored.
| Order | Specialist’s work intervals | Counter D ready | Outreach E ready | Joint finish |
|---|---|---|---|---|
| C–D–E | C: 3–7; D: 7–10; E: 10–12 | Hour 10 | Hour 12 | Hour 13 |
| C–E–D | C: 3–7; E: 7–9; D: 9–12 | Hour 12 | Hour 9 | Hour 13 |
| E–C–D | E: 3–5; C: 5–9; D: 9–12 | Hour 12 | Hour 5 | Hour 13 |
A and B retain their original intervals. F runs from twelve to thirteen in each case. Every plan reaches the lower bound imposed by the specialist’s total workload, so all three are equally fast if the only objective is final completion time.
The service-restoration paths remain different. A dashboard displaying only “complete by hour thirteen” would erase precisely the choice residents care about.
Adding staff helps only when it relaxes the actual constraint
Suppose management offers another general administrator. That person can help with communication and records, but is not qualified or authorised to perform C, D or E. The additional worker may be useful elsewhere; the modelled specialist constraint remains.
Suppose instead another appropriately qualified specialist becomes available. The schedule may then approach the earlier parallel arrangement, depending on which tasks the second person can perform and what coordination is required. Their title alone is insufficient evidence of interchangeability.
This distinction links recovery to work, skill and specialisation. Capacity is not headcount in the abstract. It is available capability matched to the particular task and its conditions.
Before requesting more resources, identify the binding constraint. Before promising that extra resources will shorten recovery, show which overlapping work they make feasible.
Do not shorten the plan by deleting verification
The team could make the schedule look faster by removing local checks from C or D. That would change the task definition. It would no longer be a schedule for the same accepted capability.
This is not a legitimate efficiency gain unless the revised verification is demonstrably adequate and authorised. A comparison should hold the required outcome constant. Otherwise the faster plan may simply deliver less assurance.
A genuine improvement might reduce duplicate data entry or prepare documentation before the specialist is available. It could remove waiting that serves no protective function. Those changes deserve investigation because they may shorten duration without weakening the acceptance condition.
The right challenge is therefore specific: which part of the duration creates necessary evidence, which part performs restoration, and which part is avoidable delay? Treating all elapsed time as equally removable invites unsafe shortcuts.
Part IV — Compare waiting, deadlines and legitimate constraints
A simple measure of service absence
Assume eighty households depend on the counter service D and fifty different households depend on outreach E. The groups do not overlap. All are affected from hour zero. Each receives useful service as soon as its own task is complete, and neither receives a partial service earlier.
For this teaching calculation, count one household waiting one hour as one household-hour of service absence. Total loss is therefore eighty multiplied by D’s completion time, plus fifty multiplied by E’s completion time.
This is an original illustrative objective, not a universal measure of welfare. It treats every hour and household equally, ignores differences in urgency and assumes the two service types are comparable for this limited calculation. These assumptions must be stated because changing them can change the preferred schedule.
The measure is still useful. It exposes a difference that final completion time conceals and lets us inspect how a proposed objective influences the choice.
Calculate the three outcomes
For C–D–E, D becomes usable at hour ten and E at hour twelve. Total service absence is 80 × 10 + 50 × 12 = 1,400 household-hours.
For C–E–D, D becomes usable at hour twelve and E at hour nine. The result is 80 × 12 + 50 × 9 = 1,410 household-hours.
For E–C–D, D becomes usable at hour twelve and E at hour five. The result is 80 × 12 + 50 × 5 = 1,210 household-hours.
| Order | Counter group | Outreach group | Total household-hours |
|---|---|---|---|
| C–D–E | 800 | 600 | 1,400 |
| C–E–D | 960 | 450 | 1,410 |
| E–C–D | 960 | 250 | 1,210 |
Under this objective and these assumptions, E–C–D is best. Restoring the smaller group earlier reduces total waiting enough to outweigh the later restoration of the larger group. Relative to C–D–E, it removes 350 outreach household-hours while adding 160 counter household-hours, a net reduction of 190.
The largest group is not automatically the best first choice
The calculation explains why “serve the largest group first” is not a complete scheduling rule. Duration and prerequisites matter. The outreach route can become useful after only two specialist hours, while the counter needs seven specialist hours across C and D.
It also shows why a compromise can be worse than either clear sequence. C–E–D delays the counter relative to C–D–E but does not restore outreach as early as E–C–D. Compromise in task order is not automatically compromise in consequences.
None of this establishes that smaller groups should generally come first. The result follows from the chosen durations, dependencies and objective. Change those inputs and another order may be better.
The civilisational value of the model is therefore explanatory. It makes a trade-off inspectable. Decision-makers can accept the objective, reject it for a stated reason or add a constraint that captures an omitted obligation.
A hard service deadline changes the feasible choice
Now introduce a mandatory condition for the fictional scenario: the counter service D must be restored no later than hour eleven. The source of that condition is assumed for the exercise; it is not a legal rule or universal service standard.
C–D–E restores D at hour ten and meets the condition. C–E–D and E–C–D restore D at hour twelve and do not. The lower household-hour total of E–C–D cannot compensate for violating the mandatory deadline.
This separates feasibility from optimisation. First identify schedules that satisfy required conditions. Then compare their desirable outcomes. A weighted score that allows enough convenience elsewhere to cancel an essential requirement would answer a different question.
The relevant discussion now concerns the constraint itself and possible alternatives. Is the deadline genuinely mandatory? Can a safe, authorised temporary counter service meet the underlying need? Can another qualified specialist be obtained? Those are legitimate questions. Pretending the deadline has been met is not.
What the household-hour measure leaves out
The toy objective omits vulnerability, urgent individual cases, substitution, unequal travel burdens and future consequences. It also assumes households experience complete service absence until restoration. In practice, some may use an alternative while others cannot.
Adding those distinctions requires evidence, not invented precision. A planner might introduce separate minimum conditions for particularly consequential needs, or evaluate several outcomes side by side instead of forcing all harm into one number.
UNDRR’s recovery definition is broader than restoring physical assets: it includes livelihoods, health and social, cultural, economic and environmental systems, with attention to reducing future risk. That breadth is a reminder that a service timetable is one part of recovery, not a complete account of human wellbeing. [3]
The arithmetic should remain visible precisely so people can challenge its assumptions. A transparent limited model is more useful than an opaque comprehensive score whose value judgements are hidden.
Part V — Turn the model into a revisable recovery record
Distinguish known durations from estimates
The example used fixed times. Real recovery estimates may be uncertain, especially before inspection reveals the extent of a problem. A four-hour task could take longer if an assumed input is unavailable.
A practical schedule should therefore label estimates and record what could change them. It can present a current working plan without claiming that every finish time is certain. Where possible, early inspection should resolve uncertainties that could materially change the sequence.
Do not simply add every worst-case duration and call the result a realistic forecast. Nor should averages be treated as guarantees. The appropriate treatment depends on the evidence about durations, their dependence and the consequences of overrunning a service window.
The important discipline is to revise the plan when observations change, rather than pressuring teams to preserve an outdated estimate. A schedule is a representation of the recovery process, not an authority capable of making unavailable resources appear.
Track remaining work, not only percentage complete
A report that C is 90% complete may sound reassuring. If the final 10% contains the unresolved verification issue, D still cannot start. Percentage complete can hide whether the task’s accepted output exists.
A more useful record distinguishes work performed, evidence still required, remaining duration estimate and blocking conditions. That gives downstream teams information they can act on. They may prepare non-dependent work while waiting, but should not assume acceptance has occurred.
Likewise, a completed repair can require rework if later evidence reveals a defect. The schedule must bring that obligation back into view. A closed task is not immune to new information.
This is how recovery planning becomes a feedback process. Each completed observation updates the state of the network. The next feasible action follows from that state, not merely from the order printed at the beginning.
Expose circular dependencies instead of drawing impossible arrows
Our six-task example has no cycle. Real plans can reveal one: one team says it needs a communication service before it can restore an information service, while another says communication cannot be restored without information held in the unavailable service.
A circular dependency means the proposed sequence cannot start as written. It does not prove that the whole system is unrecoverable. There may be an approved independent information source, an alternative communication route or another legitimate way to break the dependency.
The planning task is to identify that capability before relying on it. It should not invent a workaround or assume permission to bypass safeguards. Where no authorised alternative is known, the unresolved cycle is a real blocker that must be escalated.
A useful dependency map can therefore reveal something more valuable than a completion date: the specific missing capability required for recovery to become executable.
Restore safeguards as well as visible service
A service may resume using a temporary arrangement while its normal redundancy is depleted. Residents can complete requests again, but the system is more vulnerable to another interruption. Calling that state fully recovered without qualification would hide residual fragility.
The recovery programme should record which safeguards remain unavailable and who owns their restoration. Some may be conditions for ordinary operation; others may be managed temporarily with explicit limits. The distinction requires responsible judgement in the actual domain.
In the fictional case, F includes checking that remaining obligations have accepted owners and that the service’s actual operating state is understood. It does not erase those obligations by closing the programme.
This leads to the next question: How do civilisations know when recovery is complete? Restoration order and recovery acceptance are connected, but they are not the same decision.
A public explanation should describe the sequence honestly
Residents do not need every technical detail of the model. They do need an intelligible account of what is available, what remains unavailable and why the next step cannot occur immediately.
A useful explanation might state that the counter requires verified registry information, that the outreach route can operate independently once its local checks are complete, and that one qualified team is currently shared between the remaining tasks. It should distinguish confirmed progress from estimated finish times.
This is not an invitation to publish sensitive system vulnerabilities or private records. It is a way to explain consequence and responsibility without hiding behind the word complex.
When the order changes, explain what changed in the evidence or constraints. The public can disagree with a trade-off; they should not have to guess whether the institution has abandoned its earlier promise or discovered a genuine new limitation.
A classroom reconstruction of the full case
Start with the six-task table. Calculate each earliest start and finish under the separate-team assumption. Check the eleven-hour critical path. Then impose the one-specialist condition and show why thirteen hours is a lower bound for the combined programme.
Enumerate the three feasible specialist orders and reproduce the household-hour calculations. State why the groups must be non-overlapping for that simple addition. Explain why F’s role as final handback, rather than a gate preventing any earlier service, matters to the result.
Add the hour-eleven deadline for D. Identify which schedules remain feasible before choosing among them. Finally, change one assumption: allow partial outreach service, add a second qualified specialist or alter one duration. Recalculate rather than simply repeating the original preference.
The exercise teaches a useful habit: when a conclusion changes, identify the assumption responsible. That is stronger reasoning than memorising one preferred recovery order.
Recovery order is a promise about who waits
All three specialist schedules finished at hour thirteen. Their public consequences differed because services became usable at different moments. The lowest waiting-time total was not automatically acceptable once a mandatory deadline was introduced.
That is the central lesson. Recovery needs a dependency model, a resource model and a consequence model. It also needs conditions that cannot be averaged away. None of these alone supplies the whole answer.
A civilisation restores services intelligently when it can explain not only what will be repaired, but why the next task comes next, which people it helps sooner, what it makes possible afterwards and which requirements the sequence refuses to sacrifice.
Sources, assumptions and limits
[1] NIST, Community Resilience Planning Guides. Used for the function-centred connection between infrastructure performance, community needs, dependencies and recovery planning. The six-task model is not an official NIST schedule.
[2] NIST, SP 800-61 Revision 3, 2025, recovery recommendations RC.RP-04 and related guidance. Used as a cybersecurity-specific example of restoring essential functions in an appropriate order with confirmation by responsible owners. No technical incident-response procedure is reproduced.
[3] UNDRR, Recovery, Sendai Framework terminology. Used to distinguish community recovery from repair of physical assets alone.
All task times, capacity limits, household counts and deadlines are invented. Durations are deterministic in the worked calculation; tasks are non-preemptive; households do not overlap; D and E become usable after local acceptance; F closes the combined programme. The household-hour objective is illustrative and cannot replace professional safety requirements, rights or legitimate public decision-making.
Continue through the Civilisation Atlas
Return to the Civilisation Atlas, examine dependency and fragility, or move to the project-scale treatment in Project Bottleneck Management.