Manifest format
A manifest declares a problem type: its objectives, inputs, constraints, checks and presets. The solver validates every manifest against this schema before it admits it.
Top-level keys#
| Key | Type | Required | Description |
|---|---|---|---|
domain | string | Yes | Problem domain identifier (e.g., FieldService, VehicleRouting, Rostering) |
version | string | Yes | Manifest version (semantic versioning recommended) |
description | string | No | Human-readable description of the problem domain |
objectives | object | No | Optimization objectives for the problem |
problem_inputs | object | No | Tuning parameters for this problem - time limits, weights, horizons - and the UI form generated from them. These are NOT preconditions: a default here is a real answer, so the surface is permissive by design. The precondition contract is data_schema. |
input_categories | array of | No | Categories for organizing problem inputs in the UI |
categories | array of | No | Categories for organizing constraints in the UI |
constraints | object | No | Constraint definitions for the problem |
validation_rules | array of | No | Cross-constraint validation rules |
feasibility_checks | array of | No | Pre-solve sanity gates that determine whether data is inside the solver's feasible input envelope |
presets | object | No | Pre-configured constraint combinations for quick setup |
defaults | object | No | Default values for problem parameters |
ui | No | ||
fractal | object | No | Hierarchical/fractal structure for multi-scale optimization |
defaultContract | object | No | Default contract configuration (for rostering) |
inrc2 | object | No | INRC-II competition specific configuration |
data_schema | No | ||
spatial_lattice | No |
See the problem types for manifests in use, and the tutorial for writing one step by step.