Skip to main content

​
Call Signature

function cover<T, R>(
   timeName,
   target,
   count,
opts?): CoverageEntry<T, R>;
Defines a staffing requirement for a semantic time period.

​
Type Parameters

​
T

T extends string

​
R

R extends string

​
Parameters

​
timeName

T
Name of a declared semantic time

​
target

R | \[R, ...R[]\]
Role name (string), array of role names (OR logic), or skill name

​
count

number
Number of people needed

​
opts?

CoverageOptions Options: skillIds (AND filter), dayOfWeek, dates, priority

​
Returns

CoverageEntry<T, R>

​
Remarks

Coverage always defines a lower bound that applies throughout the scoped semantic time, with strength controlled by priority. If the requirements also state an upper bound or productive cap, model that separately in rules, for example with maxConcurrentAssignments. Scope answers where the floor applies. Priority answers how strictly the solver should preserve that floor when trade-offs are necessary. Attach coverage to the narrowest semantic time that actually carries that minimum. Avoid layering a broad parent coverage window on top of narrower windows unless the same lower bound truly applies throughout the full span. If the requirements talk about hitting full occupancy at the busy point, prefer targetPeakConcurrentAssignments over turning that into a whole-window minimum. Do not infer a synthetic “peak” semantic time just to attach cover(..., 5) unless the requirements really define a sustained window that needs that minimum throughout. Overlapping entries for the same time and role produce independent constraints; the solver enforces the max count, not the sum. An unscoped entry acts as a floor that scoped entries cannot reduce. Use mutually exclusive scopes when different days need different coverage.

​
Call Signature

function cover<T, R>(
   timeName,
   target, ...
variants): CoverageEntry<T, R>;
Defines a staffing requirement for a semantic time period.

​
Type Parameters

​
T

T extends string

​
R

R extends string

​
Parameters

​
timeName

T
Name of a declared semantic time

​
target

R | \[R, ...R[]\]
Role name (string), array of role names (OR logic), or skill name

​
variants

…[CoverageVariant, ...CoverageVariant[]]

​
Returns

CoverageEntry<T, R>

​
Remarks

Coverage always defines a lower bound that applies throughout the scoped semantic time, with strength controlled by priority. If the requirements also state an upper bound or productive cap, model that separately in rules, for example with maxConcurrentAssignments. Scope answers where the floor applies. Priority answers how strictly the solver should preserve that floor when trade-offs are necessary. Attach coverage to the narrowest semantic time that actually carries that minimum. Avoid layering a broad parent coverage window on top of narrower windows unless the same lower bound truly applies throughout the full span. If the requirements talk about hitting full occupancy at the busy point, prefer targetPeakConcurrentAssignments over turning that into a whole-window minimum. Do not infer a synthetic “peak” semantic time just to attach cover(..., 5) unless the requirements really define a sustained window that needs that minimum throughout. Overlapping entries for the same time and role produce independent constraints; the solver enforces the max count, not the sum. An unscoped entry acts as a floor that scoped entries cannot reduce. Use mutually exclusive scopes when different days need different coverage.