Repair & Reuse · Question 14

Evidence and constraints

Which requirements constrain this launch, and which supporting records need refreshing?

Keep North opening, the electrical pilot and integration conditional on their named evidence. Establish when all six records were last checked, then refresh them against the event they govern. A recent document is not proof that its requirement has been met.

Fictional what-if workspace. Changes stay in this tab and reset on reload; no record is saved and no external system is changed.

A 12-week plan with no schedule margin

The supplied case limits the launch to 12 weeks, £240,000 and six cross-trained staff. The calculated baseline reaches opening at day 84. Its illustrative cost is £218,400, leaving £21,600 within the budget. Unresolved prerequisites can consume time even when money remains.

Design · days 0–14Fit-out + equipment · 14–42Integration · 42–56Pilot · 56–70Readiness · 70–84
Calculation, fixture basis and timing assumptions
Fit-out = 24 staff-weeks ÷ 6 staff = 4 weeks Integration starts = 2 + max(4, 4) = week 6 / day 42 Electrical pilot starts = 6 + 2 = week 8 / day 56 Opening = 2 + max(4, 4) + 2 + 2 + 2 = week 12 / day 84 Cost = £120,000 + (6 × 12 × £1,200) + £12,000 = £218,400 Budget room = £240,000 − £218,400 = £21,600

Source: supplied benchmark v1.0.0 case fixtures. The calculation assumes all six staff are available to fit-out, parallel equipment procurement, then sequential integration, pilot and readiness. It is not a resource-levelled guarantee. E01 and E03 use these calculated stage dates. E04 is triggered when integration is scheduled, which can precede its start: its scheduling decision is assumed at day 14, while integration itself starts at day 42. E02 grant claim at day 84, E05 bookings at day 42 and E06 capacity commitment at day 14 are also authored, editable timing assumptions; their event dates were not supplied. Stage dates here do not automatically reschedule when a record target is edited.

Review evidence at its point of use

The fixture supplies valid values but no units, issue dates, review dates, actual handover, sign-off or delivery evidence. This workspace interprets valid as a maximum review age in calendar days. Confirm that interpretation before real use. The default is “unknown”, not “expired”. Staleness does not establish that a lease, award or obligation has legally expired.

Day 0 is 5 January 2026. These scenario dates are separate from the authoring date. The day-0 preset only supplies hypothetical review dates; all requirements remain unverified.

6applicable records
6need freshness verification or refresh by their trigger
6scenario gates without fresh, assumed-verified evidence
Every rule has a one-step link to its named supplied record
Supplied recordApplicability and planned triggerFreshness: now → at triggerConsequence if requirement is unmet

“Within review window” is a date calculation only. “Scenario verified” is an input assumption, never an approval. Unknown actual evidence remains unknown after any simulation.

Inspect the complete supplied record


Change this record’s scenario
This changes the in-tab model of this record. It does not refresh the source, grant authority, amend a plan elsewhere or satisfy a safety gate. Reopen the same row to correct it, or reset everything above.


No scenario edits applied. Select a source row to inspect its rule.


The refresh conversation, in trigger order
    A failed gate has a specific consequence. E01 blocks North opening; it does not itself prohibit South opening. E03 blocks electrical work entering the pilot; a narrower pilot needs an explicit scope decision. E02 affects claim eligibility, not an automatic shutdown. None of the six fixture records is proof that South has all its own opening permissions. Do not infer overall launch approval from this register.
    

    Rules, uncertainty and evidence boundary
    Assumed freshness-through date = assumed last review date + valid calendar days
Within window at event = review date ≤ event date ≤ freshness-through date
Refresh needed = applicable AND (review date unknown OR event after freshness-through date)
A later review cannot prove that an earlier gate was met.
Scenario-covered gate = applicable + within review window at trigger + assumed verified evidence
Actual approval / actual compliance = not established by this workspace
    Boundary convention: the last day is included; the next day is stale. The earliest review date that covers a planned trigger is trigger − valid, but factual change can require an earlier recheck. The record’s owner must verify the underlying condition at the relevant event. A future review date is invalid as evidence at the chosen assessment date. If the event is already past, the page calls for a historical check; it cannot determine whether the event occurred.
    All six exact rules, effects, owners and valid values come from the supplied constraints fixtures E01–E06. Applicability defaults to all six triggers being in scope, an authored planning assumption. Deselecting one only removes it from this scenario. Revisit it whenever scope changes. Missing records, evidence versions, actual dates, approvals and real regulations have not been invented.
    Acceptance and authoring disclosure
    • Each rule is traced to its named fixture in one click; the full source object is exposed beside the editor.
    • Each row gives applicability, a planned trigger, calculated or unknown freshness and its exact plan consequence.
    • The narrow date-window calculation supports review planning. It is not a legal expiry, compliance or safety determination.
    Actual authoring configuration: gpt-6-astra, ultra reasoning, 25 October 2026. Built as a delegated fresh-context answer, using the assigned JSON, local file tools and local JavaScript checks. No external search, model API, real supplier lookup or system write is used. Parent review and browser QA are recorded separately in run conditions; this page does not claim measured improvement over another model.