Simultaneous resource planning development preview

The 0.71.0 development source now joins bounded simultaneous-resource search and resident repair to the existing compiled Planning owner. This is an unshipped development contract with native integration fixtures authored but not yet run. An activity can hold a machine, tooling and integer labor capacity during the same interval. Source admission, portable compiled formula, runtime results and native Frame/Table output retain every named requirement.

Scalar planningRegions remains dialect/payload v4 with its existing result and output schema. Selected simultaneousPlanningRegions uses dialect/payload v5 and the same Planning import/solve/emit operations. Mixed scalar/group fields and unknown fields refuse; do not add resourceRequirements to v4 input. The compiled v5 example is canonical structured source. The older synthetic preview file remains a standalone native input fixture.

The existing resolvePlanning RPC returns each region's full typed result. Scalar-only native definition/editor/patch and persisted scalar replay APIs refuse v5. V5 editing currently uses full typed native problem replacement or a new compiled source revision; it does not translate requirements into scalar patches. The scalar Calendar editor and care-priority workflow are not v5 product features.

Resource groups

Each activity declares named groups. A group has either one resource or an ordered eligibleResources list, and an integer demand that defaults to one. Every group holds its chosen resource over the same processing interval. Group IDs are unique within an activity. Eligible resource order expresses preference, matching the existing primary/alternative resource convention.

The example contains two activities, two chairs and one unit of nursing capacity. Choosing different chairs still requires the second activity to wait for nursing capacity. Increasing nursing capacity to two permits simultaneous processing when each activity chooses a different chair. Choosing the same physical resource for two groups adds their demands; it does not duplicate that resource's capacity.

Legacy resource, alternativeResources and demand fields can be admitted as one group in the new preparation contract. They cannot appear together with resourceRequirements on the same activity. The recognized v4 input and serialized result remain unchanged; scalar parsers now refuse unknown fields so group requirements cannot silently vanish.

Placement and refusal

Calendars, capacities, release times and completed predecessors all constrain joint placement. The primitive advances across calendar and occupied-interval boundaries until all selected resources can support the same processing time. If none exists before the deadline, it reserves nothing.

Existing non-anticipatory setup behavior applies independently to each occupied physical resource. Setup begins after release and predecessor completion, ends at the common processing start, and shares that resource's availability window with processing. Changeovers still require unary capacity. Two groups using the same resource incur one physical reservation and one setup.

Reservations are immutable once returned. Undo removes the complete last reservation, including every group's physical capacity. This is a search primitive, not proof that a whole plan is feasible or optimal. Missing predecessors, duplicate reservations and unknown choices are explicit errors. A well-formed activity may have zero jointly feasible resource choices.

Checking a complete assignment

The native validator accepts a proposed whole assignment and checks it against the exact admitted problem. Every required activity and every requirement group must be present exactly once. Optional omissions are derived from the problem; an included successor cannot depend on an omitted predecessor. Resource selections and demand must match the admitted groups. Shared-resource demands are added before checking physical capacity, including any setup time.

The validator reconstructs each resource's chronological setup sequence, checks release and predecessor readiness before setup, and checks the complete setup/processing interval against calendars and deadlines. It recomputes makespan, tardiness, omission costs and the generic weighted scalar objective using checked integer arithmetic. That scalar remains the ordinary Planning objective; the Care Operations priority-policy mapping is still unfinished. Delayed warm assignments receive fresh arithmetic checks even when they exceed the conservative active-placement bound calculated during admission.

A successful result owns canonical, immutable assignments and retains a borrow of the admitted problem. Caller edits cannot change that result. It establishes feasibility for the currently implemented resource contract, not optimality, review approval, a fixed-assignment/freeze policy or a new solver status. Search and resident replacement now validate each accepted complete assignment through this same owner. Native host integration fixtures still require execution.

Current preparation bounds

The selected contract permits 4,096 activities and physical resources, up to 16 groups per activity, 64 options per group, and 4,096 Cartesian choices per activity. Total Cartesian expansion is capped at 65,536 choices before capacity-incompatible combinations are discarded. Predecessor entries, eligibility entries, calendar windows and changeover entries each have a 65,536-entry bound. Identifiers contain 1–128 UTF-8 bytes without control characters or outer whitespace. Search and repair budgets are each limited to 1,000,000 nodes. Search uses bounded lazy traversal of the admitted choices; repair has a separately accounted budget and validates retained warm assignments against the candidate problem before reuse.

Admission rejects unknown or duplicate typed fields, duplicate resource-map keys, ambiguous resource forms, invalid graphs and calendars, impossible individual demands, and arithmetic overflow. It computes a conservative active-schedule objective bound with checked integer arithmetic. Whole-assignment validation rechecks arithmetic for its actual times. The common compiled-artifact and operation byte limits remain owned by their existing ingress; the native library entry accepts an already-decoded bounded typed value.

Native result and publication

SimultaneousScheduleResult retains status, canonical activity assignments, resourceAssignments with requirement ID/resource/demand/setup for every group, an optional checked objective, omitted activity IDs, explored nodes, incumbent reuse and separate repair-node evidence. A feasible incumbent without complete proof reports feasible; exhausted search without an incumbent reports budget_exhausted, while fully explored infeasibility reports infeasible. Invalid input refuses admission rather than relaxing constraints.

resultsFrame and resultsTable produce one row per requirement, including multiple groups sharing the same physical resource. Columns are assignment_id, activity_id, requirement_id, resource, demand, setup_start, setup_duration, start, end and duration. The unique assignment ID encodes the exact activity/requirement pair. The typed native result remains authoritative for status, objective, omissions and search evidence. The immutable compiled formula payload retains all input constraints; output rows do not replace that definition.

Full native replacement admits and solves a candidate before its supplied commit callback. Refused admission or commit preserves the resident owner and published schedule. After an accepted commit, publication uses the existing model-local Frame/Table owners. Reload/unload discards the mutable companion and reads the full immutable v5 source definition again. This API does not invent a second scenario store or authorize outbound manufacturing/clinical effects.

This preview supplies the common planning foundation, not a complete Care Operations workflow. Care Operations still requires the shared enterprise controls, FHIR/SMART import, governed scenarios, separate review, export and recovery. No healthcare product availability or clinical validation follows from these component tests.