Schedule mapped runs in the order you specify

You have a curated list of experiments: a small baseline, a larger evaluation, and a more expensive candidate. Polyaxon mapping lets you express those exact parameter combinations and schedule them in the order you supplied.

This is useful when you want inexpensive configurations considered first, need to preserve the ranked suggestions from an external optimizer, or want a repeatable order for a set of evaluation slices. Mapping already supports explicit parameter combinations; Polyaxon v2.11 added preservation of their order when scheduling runs.

The order is a scheduling preference within the mapping. A run still needs its queue, resources, and container environment to become available. Parallel runs can start or finish in a different order.

Write down the exact combinations

A mapping is a list of dictionaries. Each dictionary becomes one execution of the component with those input values. It is a good fit when the desired combinations are already known, rather than every combination in a grid.

Save the following complete operation as ordered-evaluation.yaml. It requires an existing quick-start project, a configured Polyaxon CLI, and compute that can run the example image. The component prints the assigned inputs; replace that small demonstration with your evaluator when adopting the pattern.

version: 1.1
kind: operation
name: ordered-evaluation

matrix:
  kind: mapping
  concurrency: 2
  values:
    - case_id: baseline-small
      sample_count: 100
    - case_id: baseline-expanded
      sample_count: 1000
    - case_id: candidate-expanded
      sample_count: 1000

component:
  name: inspect-evaluation-inputs
  inputs:
    - name: case_id
      type: str
    - name: sample_count
      type: int
  run:
    kind: job
    container:
      image: python:3.11
      command: [python, -c]
      args:
        - |
          import json
          import sys

          print(json.dumps({
              "case_id": sys.argv[1],
              "sample_count": int(sys.argv[2]),
          }))
        - "{{ case_id }}"
        - "{{ sample_count }}"
      resources:
        requests:
          cpu: "0.1"
          memory: 64Mi
        limits:
          cpu: "1"
          memory: 128Mi

Submit the operation:

polyaxon run -p quick-start -f ordered-evaluation.yaml

The expected behavior is three child runs, each receiving one dictionary. The first listed combination is considered before the second and third, subject to the mapping's concurrency. These names identify the example cases; the program does not run a model or produce evaluation scores.

Keep a stable case_id in the inputs when the list changes. Reporting should join a result to its case identity, not assume the first completed run represents the first list entry. For repeatable workloads, use a pinned image digest and retain the dataset and application revisions with the inputs.

Choose how much work can overlap

The mapping specification exposes concurrency separately from values. With a concurrency of two, the first two eligible executions may overlap. If the second finishes first, a slot may become available for the third while the first is still running.

Changing concurrency to one limits the mapping to one active execution at a time. It is useful when you want to reduce simultaneous resource demand or inspect a sequence more easily. It does not express a success dependency: the next case should not be assumed to depend on a successful result from the previous one.

If the baseline must pass before expensive candidates become eligible, express that relationship through a DAG. Put the baseline in an upstream operation and the candidate mapping downstream. The dependency and trigger rules determine what happens after success, failure, or skipping; list position alone does not.

Keep queue priority and experiment order distinct

An ordered mapping determines which of its values Polyaxon schedules first. It does not reserve cluster capacity for the first entry or put the entire mapping ahead of other users' work.

In Polyaxon EE and Cloud, queues can route operations to compute agents and apply priority, concurrency, and quotas. Kubernetes placement then depends on the requested resources and scheduling rules. A GPU-heavy first entry can wait for capacity while another eligible run with smaller requirements progresses.

Use presets to keep environment and resource requirements consistent, and use priority controls when urgency needs an explicit policy. Reordering values is useful for organizing one experiment plan; shared-capacity policy belongs in its own configuration.

Keep the list and the results together

For a real evaluator, preserve the ordered list, dataset revision, application revision, and evaluator version with the workflow. Log each case's metrics and retain its report through Polyaxon tracking. Report failed, skipped, and missing cases explicitly before aggregating a score.

Start with the three-case input demonstration to inspect the generated child runs. Then replace the component with your evaluator, choose concurrency for its resource needs, and add dependencies only where one result is genuinely required by the next stage.