Solver as a Service
Sign Up Now →Sign Up Now
Solver as a Service Tutorial

Milestone 10: integrate with the Solver UX

Preview

The generic UX should follow a deterministic lifecycle:

  1. GET /api/v1/manifests populates the problem-type selector.

  2. GET /api/v1/manifests/{problem_type} loads one versioned UI contract.

  3. problem_inputs, categories, constraint definitions, objectives, and presets initialize controls.

  4. The data loader accepts manual records, JSON/CSV, a stored dataset, or an explicit demo scenario.

  5. The UX shows the normalized problem before submission.

  6. The UX builds one ApiSolveRequest{problem, solver, options} and submits it.

  7. A completed response renders both the domain view and the constraint certificate.

  8. A typed refusal renders corrective actions from the server envelope.

Input visualization for retail scheduling#

Before solving, visualize the data the rules will read:

Panel Primary view Required diagnostics
Employees Rows for employees; columns for skills, max hours, and availability Duplicate IDs, missing skills, missing bounds, malformed availability
Shifts Calendar or timeline grouped by day and store location Required skill, required staff, duration, uncovered demand
Eligibility Employee-by-shift matrix Why each disabled cell is ineligible: skill, availability, overlap, or data
Capacity Demand hours versus eligible employee hours by skill and location The exact field and record that creates a shortfall

The matrix is not a second rule engine. Its disabled cells and explanations must come from normalized problem data and the same declared contracts the solver uses.

Solution visualization#

For retail_rota, use the existing rostering result shape and rostering solution component as the first domain adapter:

  • calendar grid: employee rows, day/shift columns;

  • coverage badges on every shift: assigned versus required;

  • hours summary per employee: assigned, maximum, and remaining;

  • skill and availability evidence on each placement;

  • a violation overlay keyed by affected_groups and affected entities;

  • a certificate panel showing eligibility, hard, soft, and objective bands;

  • technical details containing job ID, solver version, engine, timings, and the raw response.

Always provide a generic fallback table for an installed problem type whose domain adapter is not present. The fallback can render placements and the certificate; it must say that no specialized visualization is installed.

What ui.surfaces can and cannot do today#

ui.surfaces declares where a problem type should appear and which surface is primary:

ui:
  hidden: false
  surfaces:
    solve:
      enabled: true
      primary: true
      label: "Build a retail rota"
      description: "Create and inspect an employee schedule."

It does not yet define result-field bindings, chart grammar, interaction commands, or a component package. The present Solver UX chooses specialized solution components from a code registry keyed by problem type. Therefore a pack can make retail_rota discoverable and form-renderable, but it cannot yet install a complete new visualization using manifest data alone.

The next reusable contract should describe, at minimum:

  • input datasets, identities, field labels, types, and relations;

  • one or more view declarations such as table, matrix, timeline, map, or chart;

  • field bindings into normalized problem and solution envelopes;

  • certificate overlays and drill-down keys;

  • empty, unsupported, failed, pending, and partial states;

  • versioned component capabilities when a declarative view is insufficient.

Do not put executable JavaScript or Python in the manifest. Add new generic view capability to the shared UX engine, then let manifests bind their domain fields to it.