Model inputs and constraints
Separate facts, decisions, hard requirements and preferences in a reusable problem model.
Inputs describe the world
Supply stable identifiers and explicit units. In rostering, employee records describe the people available to work and shift records describe the work that needs coverage.
Counts alone are not production records. Ten employees and twenty shifts do not specify availability, eligibility, hours or coverage. The solver should not invent those facts.
Constraints define an acceptable plan
A hard requirement constrains feasibility. A soft preference changes how candidate plans are ranked. Keep their meaning visible to the people who own the policy.
Some manifests expose configurable tiers. Treat any move from hard to soft as an explicit policy change and evaluate the consequences before release.
- Availability: who can work when.
- Eligibility: which people or resources can serve a task.
- Capacity: how much work a resource can accept.
- Pinned decisions: assignments that must be retained.
Objectives express trade-offs
Choose the objective terms the selected model can compute. Document the units and the meaning of weights. Compare candidate plans on the same input and configuration.
Do not interpret a lower objective value across different models as a universal improvement. A changed constraint tier or weight changes the problem being solved.
Version the model with the integration
Keep a versioned bundle of the manifest, input mapping, engine settings and acceptance rules. Test model changes with representative feasible and infeasible instances.
Custom problem families should extend supported manifests and extension contracts. A new label does not automatically create an executable engine.