Question 10 · Repair & Reuse: two-hub launch
Skills and capacity
How can we redeploy people while preserving certifications, capacity and resilience?
Protect certified checking time, move general work to cross-trained colleagues, and allocate every person’s week once. Trial a certified/generalist borrowing pair only with a funded duration and a clear return plan. Neither the current six nor an eight-person team meets 140 jobs a week under the conservative, separate-check-time interpretation below.
Resolve the time-accounting ambiguity before committing. The fixtures give 22 jobs per staff-week and 18 checks per certified staff-week, but do not say whether checks are already included in repair time. This planner treats checks as additional work. Its continuous pooled upper bounds are 96.6 jobs with six people and 128.8 with eight. If checks are already included, the respective upper bounds are 132 and 176. These are alternative interpretations, not measured performance.
Fictional what-if workspace. Changes stay in this tab and reset on reload; no record is saved and no external system is changed.
Build one weekly deployment
Set the demand and availability, fill a balanced proposal, then move repair or check time between hubs. Each row is one person’s whole week. North and South allocations must use different time blocks; this weekly model does not validate actual shift overlaps or travel.
Absence removes certified people first, as supplied. Within equal qualifications, this authored scenario uses C1 → C2 → C3 → B1 → G1 → G2 → G3 → B2. Existing allocations remain visible and will be rejected if assigned to someone unavailable; fill a new proposal or clear those cells.
| Person / qualification | North repair % | North check % | South repair % | South check % | Total / unallocated |
|---|
C1–C3, G1–G3 and B1–B2 are authored anonymous slots, not supplied employee identities. “Certified” is a synthetic eligibility flag only: no certificate scope, expiry, supervision or independence evidence is supplied. Real assignments remain conditional on those checks.
Simulation receipt and evidence trail
Result lifecycle: simulated weekly proposal only. Location: this page in this tab. Attribution: fictional fixture rates plus your current inputs and allocations. No file is created, no staffing record is saved, no authority is delegated and no approval or notification is sent. Correct inputs and simulate again, or Reset. Reload discards everything; there is no History or durable record.
Rules that a redeployment must survive
Eligibility and time are hard gates
- Any check allocation to G1, G2, G3 or B2 is rejected.
- Any person’s four allocations summing above 100% is rejected as double-booked weekly capacity.
- Any positive booking for an absent or unborrowed person is rejected.
- Missing, negative, non-finite, out-of-range or incorrectly stepped inputs are rejected. No feasible result is issued while a gate fails.
A pass means only that these stated weekly rules hold. It does not establish certificate validity, safe work, independent inspection, daily coverage or readiness approval.
Capacity follows the workload mix
The per-hub calculation assumes the requested electrical mix is maintained. Selective refusal of electrical jobs, cross-hub transport, queue priorities and overtime are outside this model. Fractional jobs are planning rates; round down and check the actual job mix when rostering.
Try the rejection rules
Each example replaces the draft with the default six-person proposal, inserts one error and runs the simulation. Reset restores a valid default.
What if checks are already included in normal jobs?
Then an alternative pooled bound is min(staff × 22, certified staff × 18 ÷ electrical share): at the supplied 30% mix, six staff give min(132,180) = 132, and eight give min(176,240) = 176. The current team still falls eight jobs short. The borrowed team could cover 140 only under that integrated-work assumption and a workable hub schedule.
This alternative is not applied to the roster above. It needs evidence that the same repair-rate observations included all checking work. A short time study should record repair, check, waiting, travel and rework time separately, by qualification and hub. If independent sign-off is required, add a distinct checker/repairer constraint before using either result.
Five reusable capability patterns
Certified anchors at each hub
Allocate named certified checking time against each hub’s electrical workload before distributing general work. Require current scope and expiry evidence in the real roster. Do not treat a certified name on a list as usable checking capacity.
Trigger: a hub has electrical demand but no allocated certified checks. Response: hold those jobs, move eligible checking time, or route work through an explicitly approved arrangement.
Generalists release scarce specialist time
Move repair preparation and other permitted general work to cross-trained colleagues so qualified people can check. Log repair and checking as separate duties unless observed rates prove that checking is already included.
Trigger: certified time is consumed by transferable work. Boundary: cross-training for general work never grants electrical certification.
A scheduled certified floater
Let a qualified person support both hubs in distinct, visible blocks. Allocate travel and handover time from the same week. Keep a competent anchor or a safe hold arrangement at the hub the floater leaves.
Trigger: unequal demand or a short absence. Boundary: a shared person is one resource; fractional weekly coverage is not evidence of simultaneous coverage.
Borrow a complementary pair
Borrow one certified person with one generalist, preserving a useful skill mix rather than adding interchangeable headcount. Agree duration, induction, equipment access and return conditions before any real move.
Fixture effect: six becomes eight, three certified becomes four. Separate-duty pooled capacity rises to 128.8 jobs, still below 140. Twelve weeks of borrowing adds £28,800 and breaches the £240,000 launch budget by £7,200.
Protect reserve and throttle intake
Leave explicit unallocated time for absence, rework and handovers, and limit intake to the surviving feasible capacity. The 10% reserve control is an authored illustration, not a supplied resilience standard.
Trigger: the single-certified-absence result falls below committed work. Response: reduce commitments or secure a validated backup; do not spend reserve twice by counting it as current output and recovery capacity.
Evidence, uncertainty and acceptance
| Source field | Supplied value | How used |
|---|---|---|
| case.fixtures.staff / skills.certifiedStaff | 6 / 3 | Baseline staff slots and eligibility flags. |
| weeklyJobsPerStaff / skills.checksPerCertified | 22 / 18 per week | Repair and check rates; separate time is an explicit conservative interpretation. |
| weeklyDemand / skills.electricalShare | 140 / 0.30 | Requested volume and mix; editable as what-ifs. |
| skills.borrowStaff / borrowCertified | 2 / 1 | The only modeled external capacity option. |
| skills.absencePolicy | Remove certified staff first as a conservative stress case | Availability scenario; equal-skill order is authored. |
| durationWeeks / budget / fixedCost / staffWeeklyCost / contingency | 12 / £240,000 / £120,000 / £1,200 / £12,000 | Illustrative full-duration staffing affordability; absence does not reduce contracted cost. |
What remains unknown: job-time distributions, certificate details, shift calendars, travel, independent sign-off requirements, task-specific competency, equipment contention, check failure/rework rates and actual borrowing availability. Equipment and launch-stage dependencies can further reduce usable output. This is a steady-state weekly capacity view, not a validated 12-week launch schedule.
Acceptance checks: five transferable patterns are above. Uncertified checks and oversubscribed individual time produce explicit rejection, with no feasible capacity result. The examples and editable roster make both rules inspectable. A valid allocation still has a separate demand and absence result.
Implementation: gpt-6-astra, ultra, 25 October 2026. Authored by a delegated Codex worker with parent review. Plain inline JavaScript and shared CSS; local shell/Node used for arithmetic and interaction checks. No external API, model call, contact or system integration. Local author checks and any later browser review are recorded separately in the run receipt; no comparative performance improvement is claimed.