Repair & Reuse · Question 03
Delay register
Where do reporting, approval and handoff delays create wrong decisions, and what should we change?
Make the age and authority of each signal visible before committing work. First address the seven-day grant decision and five-day supplier confirmation queues; require acceptance at each hub handoff; separate when daily work was observed from when its report arrived. Faster messages help only if they carry a usable answer.
Fictional what-if workspace. Changes stay in this tab and reset on reload; no record is saved and no external system is changed.
Four delays, four different decision risks
The fixtures supply delay lengths and suggested changes, but no event history, approval outcomes or critical-path links. The consequences below are plausible failure mechanisms for this fictional two-hub launch, not observed failures.
| Signal and supplied delay | How a wrong decision arises | Concrete operating change | Timestamp and escalation policy |
|---|---|---|---|
| Supplier confirmation 5 days [L1] | Equipment is assumed ready on an old promised date, so fit-out or integration staff are committed before delivery is credible. The case gives four weeks of equipment lead time after design; confirmation delay is not an additional lead time by definition. | Delivery owner confirms the current promised date directly with the supplier and records the affected equipment. Keep the previous promise and show the change. Proposed target: a usable response within 1 day. | Keep request_sent_at, supplier_reply_at, received_at, promised_delivery_at and promise version separately. Chase after 1 day; recheck before any date-dependent commitment. A reply without a promised date remains unresolved. |
| Grant approval 7 days [L2] | The team treats a submission or silence as funding authority, or waits unnecessarily when an authorised decision already exists. Grant amount, conditions and decision authority are not supplied. | Agree an approval service level and a completeness check with the authorised forum. Proposed target: 2 days from complete submission to a decision or a named unresolved issue. Escalation routes to an authorised delegate; it never grants authority by timeout. | Keep submitted_at, complete_at, decided_at, communicated_at, named authority, conditions and decision version. Display gross age from submission as well as service-level age from completeness; log every pause. Chase the forum after 2 days without a usable answer. |
| Cross-hub handoff 3 days [L3] | The sending hub marks shared kit or work complete while the receiving hub lacks it, has a different version or cannot use it. The next team is scheduled against an unaccepted dependency. | Use a named receiver and a handoff packet identifying item, version, condition and acceptance criteria. Proposed target: 1 day to acknowledge acceptance or reject with an owner and reason. Sender remains accountable for unresolved delivery. | Keep ready_at, sent_at, received_at, accepted_or_rejected_at, packet version and receiver. Escalate at 1 day; a transport receipt is not acceptance. Changed items require a new version and acknowledgement. |
| Daily status 1 day [L4] | A freshly published report carries yesterday's observation. Staff or shared equipment are allocated using a state that may have changed; a risk looks current merely because it was reported today. | Stamp observation time separately from report time. Proposed target: report within 0.25 day (6 hours); re-observe before allocation if older than 1 day. Route time-critical safety exceptions directly under the applicable safety process. | Keep observed_at, reported_at, received_at and source/observer. Display both transport delay and current observation age. Flag age >1 day; a repost must not reset observed_at. Corrections retain the old observation and name what supersedes it. |
[L1–L4] are taskFixtures.lags, in supplied order. Owners, targets, timestamp fields and escalation rules are proposed policies. Use ISO 8601 timestamps with a timezone, retain source timestamps, and show the local display zone. If a source time is missing, label it unknown rather than substituting receipt time.
Would the decision have the evidence in time?
Compare the existing reporting delay with a proposed target at the same decision moment. Each signal is generated on the chosen event day. Its content below is an authored scenario; it is not extra fixture evidence. For grant approval, event day represents complete submission and the displayed response may still be pending.
Day 0 = 5 January 2026, the supplied baseline date. This illustration uses elapsed 24-hour days, not working-day calendars. A decimal day is allowed; 0.25 = 6 hours. The four delays are parallel comparison cases and must not be added together.
Decision review · simulation
| Signal | Supplied delay result | Selected-policy result | Decision implication |
|---|
When each signal becomes visible
Teal length = time from scenario day 0 until selected receipt. Gold line = decision review. Read the exact dates and delays below each bar; bar colour does not indicate approval.
This receipt exists only in the page. Correct the controls and simulate again to replace it, or reset to the original scenario. Refresh discards all changes. No finding here is an actual grant approval, supplier commitment, safety release or accepted handoff.
Rules you can inspect
The simulator compares arrival only. A received signal may be pending, negative or incomplete. For daily status, a faster report does not refresh the underlying observation. Exactly at the freshness limit, the observation passes this illustrative age check; a real material change should trigger re-observation earlier.
Supplier replies must still be checked against the current promise and equipment scope. Grant approval requires the actual authorised decision, its conditions and sufficient funds; this model contains none of those records. Handoff acceptance applies only to the named packet version. None of these four signals releases a safety gate.
At the default review on day 2, only daily status has arrived using supplied delays (1 of 4), and its day-0 observation is older than the proposed one-day freshness limit. With all proposed targets, 4 of 4 replies arrive, but the grant can remain pending and the daily observation remains stale. These are deterministic scenario calculations, not measured improvements.
Change the operating routine, then measure it
- At each decision: show the evidence version, source/event time, receipt time, current age, named owner and unresolved state. A blank is unknown; silence is not consent.
- Before the next two-hub handoff: agree receiver acceptance and assign one owner for an unresolved packet. The sending hub's completion and receiving hub's acceptance remain separate events.
- During a short trial: keep request-to-response duration and source-to-receipt duration separate. Inspect the distribution and the longest waits, the proportion of decisions using stale evidence, handoffs reopened, and decisions changed after late evidence arrived.
- Before claiming improvement: compare like-for-like decisions and volumes, including adverse outcomes and the administrative cost of chasing. The four synthetic lags provide no historical distribution, causal effect or measured benefit.
Agree the suggested 1 / 2 / 1 / 0.25-day targets with the people who own each queue. These are starting assumptions for a trial, not contractual service levels. Preserve original event times and correction history so apparent improvement cannot be manufactured by resetting the clock.
Evidence and limits
- Case: Repair & Reuse: two-hub launch; benchmark 1.0.0; 12 weeks, £240,000, six cross-trained staff. Those constraints explain why shared dependencies matter; they do not quantify delay impact.
- Supplied records: [L1] Supplier confirmation / 5 days / “Confirm promised date directly”; [L2] Grant approval / 7 days / “Agree an approval service level”; [L3] Cross-hub handoff / 3 days / “Require receiver acknowledgement”; [L4] Daily status / 1 day / “Stamp observation time separately from report time”.
- Interpretation: the fixture calls these “source delay days”. Here they mean elapsed time to a usable reply or report. Actual start/end definitions, working calendars and approval clock pauses are unknown. The grant policy therefore makes completeness and gross submission age explicit.
- Not inferred: no probability of error, lost revenue, total launch slippage, grant amount or safety authority. Delay lengths alone cannot establish those effects. Do not sum 5 + 7 + 3 + 1 into a launch delay.
- Acceptance: four consequential delays are identified; each has a concrete intervention, accountable role, timestamp policy and escalation rule. Interactive comparisons preserve the supplied delays and label every new numerical target as an assumption.
Run configuration and observed author checks
Model: gpt-6-astra; reasoning: ultra; date: 25 October 2026. One independent author worker used the assigned question JSON, shared brief and common styling. Tools: local file operations and local JavaScript calculations; no network requests, external models or connected systems. Coordinator review and browser verification are recorded separately in the run review.
Author checks: default arrival count; all-target arrival count; pending grant remains unresolved; faster daily reporting does not change observation age; fresh observation at the limit; future and negative numeric values rejected. Browser verification is not asserted by this author receipt.