Find common-cause and sequential dependencies

The first lesson's node map describes dependencies; this lesson tests how a shock propagates over time. Distinguish a direct dependency, a conditional sequence and a common cause. If electricity fails for a water pump and a cold store at the same moment, it would be wrong to claim that low pump water caused the cooling failure; electricity may be their common cause. Washing stopping after its water tank empties is a sequence conditional on tank capacity and replacement supply. Label each arrow with its activation condition and time. Separate what a log observed from what the case assumes. The resulting diagram should reveal verification needs rather than manufacture certainty.

Start from a defined final function and work backward. If the decision concerns ready vegetable boxes reaching the market for the next 48 hours, ask about suppliers, washing water, power, cooling, transport and stock. The nodes need not belong to one committee; the map must make responsibility and alternatives visible. Give each buffer its own time and unit: stored water lasts operating hours, stocked boxes last a quantity of demand, and a cooling generator lasts fuel hours. The buffers cannot be added directly because they protect different functions. 'We have two days of resilience' is untestable unless it names the service and consumption rate. Ask which buffer is actually available, not merely installed or listed in an asset register.

Trace a disruption in four stages: initiating event, affected function, buffer or alternative, and final consequence with evidence confidence. Do not leap from event to household consequence while skipping market supply and demand. Households may receive unequal shares even when the total boxes suffice. At each stage, write a verification question: did the pump stop, what was the tank level after ten hours, was the generator running rather than simply present, and is stored food fit for sale? If evidence is missing, show a range or two scenarios rather than one precise result. FAO food-system guidance supports mapping actor and process links; local continuity times require local records and stakeholder checks, not a global average.

Ask whether a single alternative resolves both paths. One generator could power the pump or the cold store but might lack capacity for both; moving it to the pump could expose food stock sooner. Do not recommend a larger generator without load data and qualified electrical design. In this program, record the functional trade-off and refer the design question to specialists. Ready-box deliveries are another possible buffer, but they depend on an open road and supplier capacity. Thus an alternative can reduce one risk while increasing another. Record its owner, decision condition and review time rather than listing it as an unconditional solution.

Make an event table linking time, condition and unresolved fact. At 09:00, electricity is out while water and cooling continue through buffers. At 17:00, washing water ends, but the number of unavailable boxes still depends on output rate. At 19:00, assumed generator fuel ends, but the boxes' condition depends on safe storage requirements and cannot be read from the event table alone. This ordering shows why the action at 17:00 may differ from the action at 19:00. Household allocation comes after checking stock and arrivals. A shared time axis allows the two paths to be compared; combining quantities from different intervals conceals the turning point.

Do not treat stock as a magical buffer. Forty boxes counted at 09:00 are not necessarily forty usable boxes at 17:00: some may have been sold, could be inaccessible or allocated elsewhere. Use a stock identity: closing stock equals opening stock plus receipts minus releases minus verified loss. If releases or loss are unknown, keep the result conditional. Ask the market steward to reconcile the count with dispatch records and the utility to document outage and restoration times. If the two records conflict, do not smooth them into a convenient midpoint. Show the distinct decisions implied by each credible scenario and set a time to resolve the missing fact. This prevents a diagram from substituting for operational verification.