Extend a problem family
Use versioned manifests and supported extension packs to model new operational requirements.
Start with an existing execution policy
Find the closest supported problem family and identify which input, constraint or objective differs. An extension pack can provide a manifest and map a custom problem type onto an existing engine policy.
A custom manifest must be executable by the selected policy. Adding a field or constraint name does not create new runtime semantics.
Keep the contracts distinct
The runtime SolverManifest describes a backend-neutral problem contract. The richer authoring manifest adds schema and authoring metadata. They are not interchangeable.
Validate the extension, its input mapping and its result expectations together. Keep custom policy meanings in the extension rather than scattering branches across a shared runtime.
Validate before enabling
Use the supported pack validation and activation process for your deployment. Keep a compatible versioned artifact and the prior version needed for rollback.
Test missing records, invalid constraints and known infeasible inputs alongside the successful cases. Treat activation permissions as part of the operational boundary.