OptimizationManifest-driven configuration makes the problem model explicit: inputs, supported constraints, objective settings and execution choices. People and agents can author that configuration against the same contracts, while shared engines perform the solve.
Explore the modeling guide ↗People, shifts, tasks, orders, resources and relationships.
Requirements that define feasibility. Preferences that rank plans.
Assignments, execution status and problem-specific diagnostics.
Your model is an explicit, versionable configuration. Give an agent the supported schema, an example manifest and your requirements, and use it to draft changes you can inspect and validate.
Use your preferred assistant to map domain concepts, draft supported constraints and objective settings, and explain configuration changes. Keep the same manifest and review process whichever authoring tool you choose.
Get the authoring workflow and prompt →Validate the draft against the correct schema and supported engine capabilities. Test representative cases, review the diff and approve a version before activation. New solver behavior still needs a supported extension.
Understand the extension boundary →A guided assistant could ask domain-specific questions, map requirements to supported capabilities and prepare a candidate configuration with tests and a reviewable diff. This is a proposed capability; the workflow today uses your chosen assistant and your deployment’s validation tools.
Explore the proposed design →Use packaged problem families or supported extension packs. Keep the problem definition explicit as your requirements evolve.
A manifest describes the inputs and constraints the execution policy can consume. It creates a shared vocabulary between domain experts and application developers.
Modeling guide →Submit work to a separate solver service or use a supported Python entry point locally. Select compute and dependencies to suit the engine and workload.
Compare deployment →Inspect the returned status, feasibility checks and diagnostics. Distinguish a useful candidate from a result your application is ready to apply.
Interpret a result →Extend supported problem policies through versioned packs. Validate the model and execution contract together before enabling a new capability.
Extension concepts →A plan may satisfy every modeled requirement without proving it is the best possible plan. Helix integrations should preserve that distinction and use the evidence returned by the selected engine.
Learn what the results tell you →