Configure optimiser parameters

In this article

Before you start

• You are signed in with Harbor Demo Group selected; for the location flow, Harbor Soho must also be selected.
• An editable `optimization_config` exists in the active organisation or location scope. System templates can be viewed or copied, but not edited directly.
• You have `optimization:manage` for the active scope. Users with only `optimization:view` can inspect the form but cannot save changes.
• The operational values are known before saving, especially slot length, buffer policy, split behaviour, risk, saturation, kitchen capacity, and solver limits.

Instructions

1. 1.

   Open the optimiser list

   In Harbor Soho, open `Reservas > Optimizador` and review the optimisation configuration table. The location route needs both organisation and location context; the organisation route only needs the organisation context.

2. 2.

   Open an editable configuration

   Select an existing configuration owned by the active scope. System templates, inherited profiles, and configurations from another scope may be visible, but they cannot be updated from this form.

3. 3.

   Review the general details

   Check the name, description, and `Predeterminada` switch. Use a name that operators can recognise, and mark default only when this profile should become the automatic choice for the same organisation or location scope.

4. 4.

   Set service and buffer rules

   Set `delta_min` for the optimiser slot size, then choose `buffer_policy`. Constant, Piecewise, and Affine each reveal only their matching buffer fields, so operators only edit the values relevant to the selected policy.

5. 5.

   Set objective, solver, and split behaviour

   Adjust standard duration, objective weights, solver time, workers, diagnostic options, movement penalties, and whether assigned reservations stay locked. In Splits, `mode_label = OFF` hides the split minimum duration and fallback controls.

6. 6.

   Tune risk and saturation

   Use Risk to control how tight gaps are treated and how risk is aggregated. Use Saturation to set kitchen capacity, load weights, aggregation, optional veto values, and diagnostic output; the quantile alpha field appears only for quantile aggregation.

7. 7.

   Set optional and alternative limits

   Use Optional and Alternatives to control candidate generation, dominated-resource filtering, callback solution count, no-good solution count, and weight variants. CSV and textarea values are trimmed before saving.

8. 8.

   Save and confirm history behaviour

   Select `Guardar` once the form has changes. Antylogic trims name and description, builds the full `settings` object, preserves unknown keys, sends the update to the same scope, refreshes the list and detail, and keeps past materialised services linked to their previous snapshot when needed.

Validations and limits

• `selectedOrgId` is required; in the location flow, `selectedLocationId` is also required.
• `optimization:manage` is required to save. Without it, the UI is read-only and the backend rejects the `PUT`.
• System configurations, inherited configurations, and configurations outside the active writable scope cannot be edited directly.
• `name` is trimmed and required in both frontend and backend validation.
• `buffer_policy`, `mode_label`, `risk_aggregation`, and `saturation_aggregation` are limited to the values exposed by the form selectors.
• Numeric fields are parsed as numbers; integer fields are rounded, and required numeric fields fall back to default optimiser settings when parsing fails.
• Optional risk, saturation, and kitchen capacity list fields are sent as `null` when left empty.
• `kitchen_capacity_list` accepts a JSON array or CSV-like list; values that cannot be parsed are discarded.
• Time fields are normalised to `HH:MM`, validated between `00:00` and `23:59`, and snapped to the minute step derived from `delta_min`.
• `start_time` and `end_time` are not editable in this form. Runtime optimisation derives them from the service occurrence.

Expected result

The optimisation configuration stays in the same organisation or location scope, shows `Configuración actualizada`, refreshes the related data, and uses the revised settings for future optimisation while preserving previous settings for past materialised services when a snapshot is required.