# Can the work still fit? Method and boundaries

[Open essai 01](index.html) · [Keeping construction methods open](../) · [Essai 02](../essai-02/)

This first essai of Foray 230 compares ways to schedule supplied work for one fictional bridge between two peaks. Its coloured columns show which individual resource units are occupied and when. Its calculation is a small resource-constrained project scheduling model, with a separate check of every result. It does not discover the required work or derive it from a Petri net, symmetric monoidal category, or WBS.

## The declared model

1. There are six mandatory jobs, each performed once. Completion means finishing all six.
2. Each job has one fixed integer duration, editable from one to five days. Work runs without interruption and holds its stated resources for the whole duration.
3. Riggers, installers and carriers are renewable, interchangeable units within their own pools. Each pool has a constant integer capacity from zero to five. A person cannot serve two jobs at the same time.
4. The supplied acyclic dependencies are finish-to-start, with zero lag. They describe this fictional construction method; priority choices cannot remove them.
5. There are no calendars, release dates, access or weather windows, uncertain outcomes, travel or setup times, or alternative methods. A day is a model time unit.
6. The recovery kit occupies a separate prepared staging ledge at the west peak. It needs the bridge kit haul but not the completed span. This explicit fictional assumption allows recovery-kit work to compete with span work for the riggers. Calling it a recovery kit does not establish that a change of construction method is possible.

| Job | Default days | Riggers | Installers | Carriers | Must finish first |
|---|---:|---:|---:|---:|---|
| A: Bridge kit haul | 2 | 2 | 0 | 3 | — |
| B: Peak anchor preparation | 3 | 1 | 2 | 0 | A |
| C: Span frame assembly | 3 | 1 | 3 | 0 | B |
| D: Deck panels | 2 | 0 | 2 | 1 | C |
| E: Guardrails and utility line | 3 | 2 | 2 | 0 | C |
| F: Recovery kit at west peak | 2 | 2 | 0 | 1 | A |

Default capacity is two riggers, three installers and three carriers. Deck panels and the guardrails/utility line may proceed separately after the span frame if resources permit; neither job is a prerequisite of the other in this model. These are declared fictional rules, not engineering validation of a real bridge.

The retained-crew and unavailable-rigger presets compare capacities that are constant for the entire proposed schedule. They do not model a disruption during work, interrupted jobs, completed construction, recovery actions or switching to another method. Those changes need an explicit new state model and fresh checks. This essai contributes a checked resource-feasibility ingredient to the foray End; it does not establish the End.

## Generation and the exact claim

The chosen priority is read from highest to lowest. Whenever a job is selected, all its predecessors must already have been scheduled. The selected job receives the earliest integer start after predecessor completion for which the required aggregate capacity is available throughout its duration. A later-selected independent job can occupy an earlier gap: selection order is not necessarily chronological execution order.

The exact solver repeats this procedure for every topological priority order, removes duplicate start-time vectors, and chooses minimum completion time. There is no sampled or truncated search. The interface has six jobs; the engine accepts at most eight, bounding enumeration by 8! = 40,320 orders. Invalid models and insufficient capacity produce an explained failure rather than a fabricated placement.

The serial schedule generation scheme and its active-schedule coverage are described by [Karapetyan and Vernitski (2017), §1, Algorithms 1–3](https://arxiv.org/html/1708.07786). An optimum for makespan exists among active schedules, and a suitable precedence-feasible permutation produces each active schedule. Therefore complete enumeration establishes the optimum under this app's assumptions. It does **not** enumerate every schedule with inserted waiting, nor every interchangeable-person assignment.

The finite horizon is the sum of all durations. When the graph is acyclic and every job individually fits the pools, executing the jobs one at a time in a topological order is feasible within that horizon. Thus no shorter optimum can require a larger horizon. Integer durations and zero-lag constraints let the generator produce integer earliest starts.

Two lower bounds help explain a result: the longest dependency-chain duration, and the greatest rounded-up resource-work/capacity ratio across pools. Neither bound alone proves attainability. “Best finish for this model” comes from the completed search, not from calling a preset optimal.

## People, pieces and the independent witness

Individual columns are assigned **after** aggregate scheduling, in chronological start order. A job takes the lowest-numbered available units of each pool and retains them until it ends. Jobs ending at a boundary release their units before new jobs start there. Capacity feasibility guarantees enough free units in this chronological assignment. Fixing particular people while inserting jobs in a nonchronological priority order could create avoidable fragmentation and invalidate the scheduling argument.

The verifier checks complete job coverage, duration, prerequisites, every interval's cumulative resource load, assignment counts and unit ranges, and each person's non-overlap. The test suite separately audits those witnesses and compares optimum values against a unit-time breadth-first search. That oracle branches over every capacity-feasible subset of ready jobs, including choosing to wait while other jobs run; it does not use priority-order generation. With no calendars or release dates, waiting when no work runs cannot improve completion time, and a later visit to the same completed/running state is dominated.

In the source repository, run the independent model checks with `node tests/methods-open-resource.test.cjs` and the interface checks with `node tests/methods-open-resource-ui.test.cjs` (the interface suite requires jsdom). They include every forward-edge DAG on four jobs, varied resource pools, seeded five-job examples, bridge capacity and duration variations, impossible inputs, the API bound, and intentionally damaged schedules. Their terminal output reports the comparisons and witnesses actually checked. These checks establish properties of the declared model and implementation, not real-world suitability or human-use benefits.

## What “heap” means here

[Gaubert and Mairesse, *Task Resource Models and (max,+) Automata* (1995), §§2.1–2.3](https://www.cmap.polytechnique.fr/~gaubert/PAPERS/GM95-BRISTOL.pdf) gives a precise heap construction: a task uses a fixed subset of identifiable resources; pieces are added in a word order and rest above those resources' prior releases. Its upper contour records latest release times, not the full utilisation history.

This app borrows the resource-column geometry. Its pool-based, gap-filling scheduler is **not** that max-plus product. The visual is a concrete interval-allocation witness. A fixed assignment and order could support a separate heap reconstruction with explicit prerequisite guards, but that construction is not claimed here. No categorical translation or general heap theorem is inferred from the picture.

## Place in the enquiry and lineage

This is essai 01 of **Keeping construction methods open**, whose End concerns preserving or recovering a viable construction method after irreversible partial work and disruption. Here, the jobs are supplied in advance and none has started. [Essai 02](../essai-02/) asks whether an alternative method remains reachable from a committed state. An allocation witness and a permitted method-change route answer different questions.

This essai refactors **Gimmer 27, Resource Heaps**. The six-job prerequisite graph, durations, demands and capacity comparisons are retained with explicit bridge names: climbers become riggers, builders become installers, and porters become carriers. The original resource geometry, priority controls, all-order enumeration, independent checker, schedule alternatives, lower bounds, duration/crew edits, reduced-motion reveal, URL replay and JSON export with visible fallback remain. The standalone page loads no external scripts, styles or fonts.

The original [A Tetris for project resourcing decisions](https://experimentinai.substack.com/p/eia129-a-tetris-for-project-resourcing) supplies the geometric intuition. This transfer makes no claim to complete the Gimmer Petri → SMC → WBS investigation or to demonstrate real engineering feasibility, reader benefit, or the wider foray End.