RoboPolMath(Beta)ONLINE MATHEMATICAL WORKSPACE
Open RoboPol Math (Beta) ↗

RoboPol Math (Beta) / Adapter handbook

Online handbook

Prepare your data, understand the online limits, run a calculation and interpret its checked result.

ModelSpec v1 · Program SDK v1 · Rust SDK v1 · RoboPol Math (Beta) 0.7

A complete, importable example

Create your first adapter and run a calculation

Start with a working example in RoboPol Math (Beta), then adapt it to your own problem. This online handbook explains how to choose an adapter, prepare data, import a task, run a calculation and understand the answer. It also covers reusable adapters, search settings, history, source inspection and custom operator code.

The example below uses math-model, the installed mathematical adapter. You declare variables, fixed data, conditions and an objective; the application checks the model and selects supported search operations. You can prepare these files yourself or use an AI assistant to help write them.

Calculations run on the service's CPU. Your browser prepares inputs and displays results; this edition uses neither the server GPU nor your computer's GPU.

The workflow: describe the problem → prepare the model and data → import → validate → calculate → inspect and export.

The problem: assemble a field equipment kit

Select exactly four of eight items. Each item has a cost, mass and benefit. Stay within a budget of 30 and a mass limit of 16. Include at least one item from each required group, and never select both items in the incompatible pair. Maximize total benefit.

Item12345678
Cost978654103
Mass34524162
Benefit18162013149248
  1. Save or export any unfinished task that you want to keep. Download the adapter profile above, then choose Import adapter or task in the application and select the JSON file. You can also open the handbook panel, paste the document into Structured JSON input and choose Open adapter or task.
  2. Review the variables, data, conditions and objective. Choose Validate input to check that the application supports the formulation. Validation does not calculate the answer.
  3. Keep the default settings for your first calculation, then choose Calculate. Read the returned selection and objective value, check the conditions and inspect any chart. Open Statistics for the work actually performed.
  4. Use Export task to save the input and calculation settings. Export the result separately to keep the returned answer, checks and measurements.

Keep the adapter, data and calculation separate

PartWhat it containsExample
AdapterThe rules for representing, evaluating and changing candidate solutions.Select items subject to conditions and maximize their benefit.
DatasetThe input values for one task.Eight item costs, masses and benefits, with budget 30.
CalculationThe saved input, settings, returned result and measured work.Run the equipment task with seed 42 and a three-second search limit.

For math-model, a ModelSpec document defines the mathematical formulation. Changing a variable, condition or objective changes that formulation. Changing item costs or the budget creates a new dataset for the same formulation.

An adapter profile, refined.math.adapter, contains explanatory text, an editable defaultTask and a reference to a supported execution binding. Importing it opens the default task and adds a reusable definition to My adapters. A definition has its own name and revisions. Its description and schema do not grant capabilities that its execution binding does not support.

Choose an installed adapter when its input and result contract matches your problem. Choose math-model when you can express the problem in the supported mathematical language. To write your own search operations, use the Program SDK or Rust SDK.

Choose calculation settings

Open Run before calculating. Start with Normal. Fast reduces the search effort; Strong allows more runs and broader or deeper search. Profiles change the amount and organization of work, while the time and resource limits still apply. A stronger profile does not guarantee a better answer within the same short time limit.

The settings include learning, CPU execution mode and advanced search controls. Learning uses information gathered during the search; it does not require an AI service. Support for optional controls depends on the selected adapter. Inspect the effective settings and measured counters after the calculation rather than assuming that an enabled option was used.

This online edition uses server CPUs only. CPU proposal generation remains available where an adapter supports it, alongside learning and other supported search controls. GPU-required and automatic GPU backend requests are rejected; the current backend value is cpu_only.

For parameter groups, supported CPU controls and the distinction between configured and actual work, read the search-settings guide. Finite counting and symbolic mathematics use their own methods and do not use Refined search profiles.

Online Free limits and the calculation queue

Free allowanceCurrent boundary
SearchUp to 30 seconds. An adapter can finish earlier because it finds an answer or reaches another work limit.
Complete dispatched job45 seconds including preparation, calculation and final validation. Waiting in the job queue does not use this execution allowance.
Worker memory512 MiB for the complete worker process, including the engine and adapter. Imported Rust/Wasm has a separate smaller guest-memory limit.
Your browser sessionOne active calculation and two queued calculations. The service currently runs at most two calculations at once and selects waiting owners fairly.
Daily CPU creditOne CPU-hour per UTC day, with no separate hourly quota. The allowance resets at 00:00 UTC; the interface displays the reset in your local time.
New finished historyUp to 100 records, retained for up to 30 days, with additional byte and service-capacity limits.

CPU credit measures actual native worker and descendant CPU use. A ten-second calculation using two CPUs can consume more credit than ten seconds using one CPU. Waiting in the queue consumes no CPU credit. Accepted jobs temporarily reserve credit; unused reservations and jobs cancelled before execution release it. Import checks and input validation that execute native code also consume credit. Retrying the same acknowledged submission does not charge that calculation twice.

The header shows remaining and reserved credit. A calculation can still consume CPU when its model or executable fails. If exact consumption cannot be recovered after a supervisor interruption, the service can conservatively charge its reservation; this is labeled separately from measured CPU use. When credit is exhausted, wait for the displayed daily reset.

These limits belong to the current signed browser session. It is not a registered customer account or a cross-device recovery service. Export important work as described under online storage. Admitted calculations share capacity with other visitors; being connected to the site does not reserve a computation slot.

The long scientific factorization backend requires a separately bounded execution pool and is not dispatched by the current Free short-job service. A request needing that backend is rejected before launch. The guarded small-integer factorization route can use the short pool when available. Increasing a task's requested time does not enable a missing backend or bypass the plan.

The application header also provides appearance and sound controls. Your browser remembers these preferences. A completion sound marks the end of a calculation; read the result status to determine whether the mathematical task succeeded.

Translate a problem into a model

  1. Decisions: pick is a vector of eight binary values. A value of 1 selects an item; 0 excludes it.
  2. Parameters: vectors cost, mass and benefit describe items in the same order. Scalars budget and massLimit set capacities.
  3. Hard conditions: exactly four selections, two capacity limits, two required groups and one incompatible pair.
  4. Objective: maximize dot(pick,benefit).
  5. Independent check: recompute totals from the selected indices and verify every condition.
sum(pick) == 4
dot(pick,cost) <= budget
dot(pick,mass) <= massLimit
pick[1] + pick[2] >= 1
pick[3] + pick[4] >= 1
pick[2] + pick[7] <= 1

Put mandatory requirements in constraints and preferences in the objective. If you combine several quantities, explain their weights and units. Express the budget and item costs in the same units. Define the meaning of zero and decide whether negative values are valid before preparing the data.

Begin with a small task that you can check by hand or enumerate independently. Add a typical case, a case with tight limits and a case whose conditions cannot all be met. These examples help reveal errors in the model before you try larger inputs.

Create the import files

The complete baseline task is shown below. Save it as UTF-8 text with a .json extension. JSON requires double quotes around field names and strings; comments and trailing commas are not allowed.

{
  "format": "refined.math.task",
  "schemaVersion": 1,
  "adapterId": "math-model",
  "title": "Field equipment kit — budget 30",
  "payload": {
    "model": {
      "schemaVersion": 1,
      "title": "Field equipment kit — budget 30",
      "numericPolicy": "exact",
      "variables": [
        {
          "name": "pick",
          "kind": "binary",
          "shape": [
            8
          ],
          "lower": 0,
          "upper": 1
        }
      ],
      "data": [
        {
          "name": "cost",
          "values": [
            "9",
            "7",
            "8",
            "6",
            "5",
            "4",
            "10",
            "3"
          ]
        },
        {
          "name": "mass",
          "values": [
            "3",
            "4",
            "5",
            "2",
            "4",
            "1",
            "6",
            "2"
          ]
        },
        {
          "name": "benefit",
          "values": [
            "18",
            "16",
            "20",
            "13",
            "14",
            "9",
            "24",
            "8"
          ]
        },
        {
          "name": "budget",
          "values": [
            "30"
          ]
        },
        {
          "name": "massLimit",
          "values": [
            "16"
          ]
        }
      ],
      "constraints": [
        "sum(pick) == 4",
        "dot(pick, cost) <= budget",
        "dot(pick, mass) <= massLimit",
        "pick[1]+pick[2] >= 1",
        "pick[3]+pick[4] >= 1",
        "pick[2]+pick[7] <= 1"
      ],
      "goal": {
        "mode": "maximize",
        "expression": "dot(pick, benefit)"
      }
    }
  },
  "options": {
    "seed": 42,
    "timeLimitMs": 3000,
    "maxEvaluations": 200000,
    "maxWorkUnits": 50000000
  }
}
FieldMeaning
format, schemaVersionSelect the current task format and version.
adapterIdThe supported execution binding, here math-model.
payload.modelThe complete mathematical model and its data.
optionsSeed and bounded calculation settings. Omitted settings use application defaults.

Installed native adapters use payload.input, with fields defined by the selected adapter. Symbolic tasks use payload.symbolic. Keep the payload type consistent with adapterId. For a native task, start by exporting the selected adapter's profile and reviewing its input contract and examples.

Inspect the complete importable adapter profile
{
  "format": "refined.math.adapter",
  "schemaVersion": 1,
  "adapterId": "math-model",
  "version": "0.6.0",
  "name": {
    "en": "Field equipment selection",
    "sk": "Výber terénnej výbavy"
  },
  "description": {
    "en": "Select equipment that meets cost and mass limits, group requirements and compatibility rules.",
    "sk": "Vyberte výbavu, ktorá spĺňa cenový a hmotnostný limit, požiadavky na zastúpenie skupín a pravidlá kompatibility."
  },
  "help": {
    "en": "Define the model in defaultTask.payload.model. Put item costs, masses, benefits and resource limits in its data field.",
    "sk": "Matematický model zapíšte do poľa defaultTask.payload.model. Ceny, hmotnosti, prínosy a kapacitné limity vložte do jeho poľa data."
  },
  "runtime": {
    "binding": "math-model",
    "coreRevision": "d2c02f944772b7f7a586c4f3357fc90e480349ad",
    "inputKey": "model"
  },
  "inputSchema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "title": "Refined Math ModelSpec v1",
    "description": "Importable mathematical model. Native validation additionally checks names, shapes, finite domains, numeric policy and checked arithmetic. Use strings for exact decimal, fraction or large integer data.",
    "type": "object",
    "additionalProperties": false,
    "required": [
      "schemaVersion",
      "title",
      "variables",
      "data",
      "constraints",
      "goal"
    ],
    "properties": {
      "schemaVersion": {
        "const": 1
      },
      "title": {
        "type": "string",
        "maxLength": 120
      },
      "numericPolicy": {
        "enum": [
          "auto",
          "exact",
          "real"
        ],
        "default": "auto"
      },
      "tolerance": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "absolute": {
            "type": "number",
            "minimum": 0,
            "maximum": 0.1,
            "default": 1e-8
          },
          "relative": {
            "type": "number",
            "minimum": 0,
            "maximum": 0.1,
            "default": 1e-8
          }
        }
      },
      "variables": {
        "type": "array",
        "minItems": 1,
        "maxItems": 16,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": [
            "name",
            "kind",
            "shape",
            "lower",
            "upper"
          ],
          "properties": {
            "name": {
              "$ref": "#/$defs/name"
            },
            "kind": {
              "enum": [
                "integer",
                "binary",
                "permutation",
                "real"
              ]
            },
            "shape": {
              "type": "array",
              "minItems": 1,
              "maxItems": 2,
              "items": {
                "type": "integer",
                "minimum": 1,
                "maximum": 512
              }
            },
            "lower": {
              "$ref": "#/$defs/bound"
            },
            "upper": {
              "$ref": "#/$defs/bound"
            }
          }
        }
      },
      "data": {
        "type": "array",
        "maxItems": 32,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": [
            "name",
            "values"
          ],
          "properties": {
            "name": {
              "$ref": "#/$defs/name"
            },
            "values": {
              "type": "array",
              "minItems": 1,
              "maxItems": 512,
              "items": {
                "$ref": "#/$defs/number"
              }
            }
          }
        }
      },
      "constraints": {
        "type": "array",
        "maxItems": 64,
        "items": {
          "$ref": "#/$defs/expression"
        }
      },
      "goal": {
        "type": "object",
        "additionalProperties": false,
        "required": [
          "mode"
        ],
        "properties": {
          "mode": {
            "enum": [
              "find",
              "minimize",
              "maximize",
              "count"
            ]
          },
          "expression": {
            "type": "string",
            "maxLength": 4096
          }
        },
        "allOf": [
          {
            "if": {
              "properties": {
                "mode": {
                  "enum": [
                    "minimize",
                    "maximize"
                  ]
                }
              }
            },
            "then": {
              "required": [
                "expression"
              ],
              "properties": {
                "expression": {
                  "$ref": "#/$defs/expression"
                }
              }
            }
          }
        ]
      }
    },
    "$defs": {
      "name": {
        "type": "string",
        "pattern": "^[A-Za-z_][A-Za-z0-9_]{0,31}$"
      },
      "expression": {
        "type": "string",
        "minLength": 1,
        "maxLength": 4096
      },
      "bound": {
        "description": "Discrete bounds must be integers within +/-1e9; real bounds within +/-1e12. Binary domains are 0..1.",
        "oneOf": [
          {
            "type": "number",
            "minimum": -1000000000000,
            "maximum": 1000000000000
          },
          {
            "$ref": "#/$defs/numberString"
          }
        ]
      },
      "numberString": {
        "type": "string",
        "minLength": 1,
        "maxLength": 100,
        "pattern": "^[-+]?(?:[0-9]+(?:\\.[0-9]*)?|\\.[0-9]+)(?:[eE][-+]?[0-9]+)?(?:/[-+]?(?:[0-9]+(?:\\.[0-9]*)?|\\.[0-9]+)(?:[eE][-+]?[0-9]+)?)?$"
      },
      "number": {
        "oneOf": [
          {
            "$ref": "#/$defs/numberString"
          },
          {
            "type": "number",
            "description": "Exact mode accepts safe integer JSON numbers only. Prefer strings for portable exact data."
          }
        ]
      }
    }
  },
  "contract": {
    "state": {
      "en": "Eight binary values in the same item order as the parameter vectors.",
      "sk": "Osem binárnych hodnôt, ktorých poradie zodpovedá poradiu položiek v dátových vektoroch."
    },
    "score": {
      "en": "Six hard conditions; maximize total benefit among feasible candidates.",
      "sk": "Šesť povinných podmienok a maximalizácia celkového prínosu prípustných kandidátov."
    },
    "operators": {
      "en": [
        "Supported proposals for binary changes and exchanges, selected by the model compiler."
      ],
      "sk": [
        "Návrhy podporovaných binárnych zmien a výmen, ktoré vyberá prekladač modelu."
      ]
    },
    "output": {
      "en": "The pick vector, objective value, condition checks, numeric policy and available calculation statistics.",
      "sk": "Vektor pick, hodnota cieľovej funkcie, kontroly podmienok, numerická politika a dostupné štatistiky výpočtu."
    }
  },
  "defaultTask": {
    "format": "refined.math.task",
    "schemaVersion": 1,
    "adapterId": "math-model",
    "title": "Field equipment kit — budget 30",
    "payload": {
      "model": {
        "schemaVersion": 1,
        "title": "Field equipment kit — budget 30",
        "numericPolicy": "exact",
        "variables": [
          {
            "name": "pick",
            "kind": "binary",
            "shape": [
              8
            ],
            "lower": 0,
            "upper": 1
          }
        ],
        "data": [
          {
            "name": "cost",
            "values": [
              "9",
              "7",
              "8",
              "6",
              "5",
              "4",
              "10",
              "3"
            ]
          },
          {
            "name": "mass",
            "values": [
              "3",
              "4",
              "5",
              "2",
              "4",
              "1",
              "6",
              "2"
            ]
          },
          {
            "name": "benefit",
            "values": [
              "18",
              "16",
              "20",
              "13",
              "14",
              "9",
              "24",
              "8"
            ]
          },
          {
            "name": "budget",
            "values": [
              "30"
            ]
          },
          {
            "name": "massLimit",
            "values": [
              "16"
            ]
          }
        ],
        "constraints": [
          "sum(pick) == 4",
          "dot(pick, cost) <= budget",
          "dot(pick, mass) <= massLimit",
          "pick[1]+pick[2] >= 1",
          "pick[3]+pick[4] >= 1",
          "pick[2]+pick[7] <= 1"
        ],
        "goal": {
          "mode": "maximize",
          "expression": "dot(pick, benefit)"
        }
      }
    },
    "options": {
      "seed": 42,
      "timeLimitMs": 3000,
      "maxEvaluations": 200000,
      "maxWorkUnits": 50000000
    }
  },
  "samples": [
    {
      "id": "field-kit-budget30",
      "name": {
        "en": "Budget 30",
        "sk": "Rozpočet 30"
      },
      "expected": {
        "en": "Independent reference: items 1, 3, 7, 8; cost 30; mass 16; benefit 70.",
        "sk": "Nezávislá referencia: položky 1, 3, 7, 8; cena 30; hmotnosť 16; prínos 70."
      },
      "task": {
        "format": "refined.math.task",
        "schemaVersion": 1,
        "adapterId": "math-model",
        "title": "Field equipment kit — budget 30",
        "payload": {
          "model": {
            "schemaVersion": 1,
            "title": "Field equipment kit — budget 30",
            "numericPolicy": "exact",
            "variables": [
              {
                "name": "pick",
                "kind": "binary",
                "shape": [
                  8
                ],
                "lower": 0,
                "upper": 1
              }
            ],
            "data": [
              {
                "name": "cost",
                "values": [
                  "9",
                  "7",
                  "8",
                  "6",
                  "5",
                  "4",
                  "10",
                  "3"
                ]
              },
              {
                "name": "mass",
                "values": [
                  "3",
                  "4",
                  "5",
                  "2",
                  "4",
                  "1",
                  "6",
                  "2"
                ]
              },
              {
                "name": "benefit",
                "values": [
                  "18",
                  "16",
                  "20",
                  "13",
                  "14",
                  "9",
                  "24",
                  "8"
                ]
              },
              {
                "name": "budget",
                "values": [
                  "30"
                ]
              },
              {
                "name": "massLimit",
                "values": [
                  "16"
                ]
              }
            ],
            "constraints": [
              "sum(pick) == 4",
              "dot(pick, cost) <= budget",
              "dot(pick, mass) <= massLimit",
              "pick[1]+pick[2] >= 1",
              "pick[3]+pick[4] >= 1",
              "pick[2]+pick[7] <= 1"
            ],
            "goal": {
              "mode": "maximize",
              "expression": "dot(pick, benefit)"
            }
          }
        },
        "options": {
          "seed": 42,
          "timeLimitMs": 3000,
          "maxEvaluations": 200000,
          "maxWorkUnits": 50000000
        }
      }
    },
    {
      "id": "field-kit-budget27",
      "name": {
        "en": "Budget 27",
        "sk": "Rozpočet 27"
      },
      "expected": {
        "en": "Independent reference: items 2, 3, 4, 5; cost 26; mass 15; benefit 63.",
        "sk": "Nezávislá referencia: položky 2, 3, 4, 5; cena 26; hmotnosť 15; prínos 63."
      },
      "task": {
        "format": "refined.math.task",
        "schemaVersion": 1,
        "adapterId": "math-model",
        "title": "Field equipment kit — budget 27",
        "payload": {
          "model": {
            "schemaVersion": 1,
            "title": "Field equipment kit — budget 27",
            "numericPolicy": "exact",
            "variables": [
              {
                "name": "pick",
                "kind": "binary",
                "shape": [
                  8
                ],
                "lower": 0,
                "upper": 1
              }
            ],
            "data": [
              {
                "name": "cost",
                "values": [
                  "9",
                  "7",
                  "8",
                  "6",
                  "5",
                  "4",
                  "10",
                  "3"
                ]
              },
              {
                "name": "mass",
                "values": [
                  "3",
                  "4",
                  "5",
                  "2",
                  "4",
                  "1",
                  "6",
                  "2"
                ]
              },
              {
                "name": "benefit",
                "values": [
                  "18",
                  "16",
                  "20",
                  "13",
                  "14",
                  "9",
                  "24",
                  "8"
                ]
              },
              {
                "name": "budget",
                "values": [
                  "27"
                ]
              },
              {
                "name": "massLimit",
                "values": [
                  "16"
                ]
              }
            ],
            "constraints": [
              "sum(pick) == 4",
              "dot(pick, cost) <= budget",
              "dot(pick, mass) <= massLimit",
              "pick[1]+pick[2] >= 1",
              "pick[3]+pick[4] >= 1",
              "pick[2]+pick[7] <= 1"
            ],
            "goal": {
              "mode": "maximize",
              "expression": "dot(pick, benefit)"
            }
          }
        },
        "options": {
          "seed": 42,
          "timeLimitMs": 3000,
          "maxEvaluations": 200000,
          "maxWorkUnits": 50000000
        }
      }
    }
  ]
}

Use the current ModelSpec schema, task schema and adapter-profile schema when authoring files. A schema checks document structure. Application validation also checks names, dimensions, types, arithmetic and compatibility with the selected adapter.

Choose the file for the job: a task saves a calculation setup, a definition saves a reusable adapter revision, and a data document supplies values for that revision. An executable Rust adapter package additionally contains the compiled Wasm module; its import workflow is described under advanced adapters.

Use the supported mathematical language

Model names must begin with an ASCII letter or underscore, contain only ASCII letters, digits and underscores, and be no more than 32 characters long. Names must be unique and must not use reserved names or supported function names. ModelSpec indices start at 1 and must be literal integers: use pick[3] or M[2,1]; pick[i] is unsupported. Installed adapters may use a different index base, which their input contract specifies.

PurposeSupported forms
Arithmetic and comparison+ - * / % ^; == != < <= > >=; parentheses and unary signs.
Logic and branching&& || !; if(predicate,yes,no), with numeric branches.
Collectionssum, product, sumSquares, mean, norm, allDifferent; dot requires equally sized vectors.
Matrix selectionrow(M,1), column(M,2), diagonal(M,0) or diagonal(M,1) for a square matrix.
Scalar functionsabs sqrt sin cos tan exp ln log10 floor ceil round sign gcd lcm factorial choose; min and max accept a collection or multiple scalars.

Write multiplication explicitly as 2*x. Use ^ for exponentiation and == to test equality. The expression language supports the listed mathematical forms. It does not support loops, comprehensions, assignments, user-defined functions or Math.* calls.

Variable kinds are binary, integer, permutation and real. Shape [1] declares a scalar; [8] a vector; [3,3] a matrix. A permutation's interval must contain exactly as many integers as there are positions in its declared shape.

Goals are find, minimize, maximize and count. Use find when any candidate satisfying the conditions is sufficient. Minimization and maximization require a scalar objective. Counting uses finite-count and requires finite discrete domains and exact predicates.

Write exact decimals, fractions and large integers as JSON strings, for example "0.125" or "1/8". Numerical policies are auto, exact and real. Real variables and functions such as sin, exp and sqrt require approximate arithmetic and explicit tolerances. Exact calculations also have limits on intermediate values; an overflow is an error, not an approximate answer.

Change data while reusing your adapter

Import a definition once, then reuse it with separate datasets. My adapters stores the definition's name, description, contract and revisions in this browser. Choosing one of these saved definitions opens its model and data.

  1. Import field-kit.definition.json using Import adapter or task. Open the saved definition under My adapters.
  2. Import field-kit-budget27.data.json. Review the preview, which compares the current values with the imported values before applying them.
  3. Choose Apply dataset, then validate and calculate. The model is unchanged, but its budget is now 27. The independent reference selects items 2, 3, 4 and 5: cost 26, mass 15 and benefit 63. The baseline reference benefit is 70.
  4. Use Saved datasets to reopen either set of data. Earlier calculations retain their original input and adapter revision.

A definition uses format: refined.math.definition, schemaVersion: 1, an ID, revision, digest and the adapter profile. A data file uses format: refined.math.data, schemaVersion: 1, a title, the exact definition reference and a payload. Model parameters belong in payload.modelData; native inputs use payload.input and symbolic inputs use payload.symbolic.

A mathematical data file supplies every declared parameter group with the existing name and length. It changes parameter values while preserving variables, conditions and the objective. When the model structure changes, choose Save adapter revision, export the new definition and use its exact reference in subsequent data files.

When authoring changed values, omit the data file's optional id and digest; the application calculates them after validation. Preserve definition.id, definition.revision and definition.digest. Never invent a definition checksum. A complete task is still supported as a self-contained alternative.

See the definition schema and data schema. Convert CSV data or a bare JSON array into the required document and payload before importing it. Draft recovery opens an unsaved copy. Use Save project as a copy when you want to keep an existing saved project unchanged.

Remove saved adapters or datasets

In My adapters, choose Remove on the adapter's card or in Adapter and datasets. The confirmation covers that adapter's revisions and saved datasets. Saved projects, calculation history and the current editor input remain available. You can also remove an individual saved dataset from the adapter details. Removing a library entry does not remove the installed adapter implementation.

Keep and manage online calculation history

Open Calculations to revisit the original input, result and measurements of a completed calculation. Server calculations belong to your private browser session and are stored on the server. Projects, saved adapter definitions, datasets and drafts are stored in this browser. These are separate stores; they are not a synchronized account or cross-device backup.

New Free calculations carry a policy of at most 100 finished records retained for up to 30 days. A separate job-storage ceiling is 384 MiB per private session, with additional service-wide byte, record and structural limits. A byte or capacity limit can be reached before the record count. The history view shows 20 records per page and displays capacity. Older records without the new Free retention policy keep their original handling; active work and paused scientific checkpoints are protected.

Export important tasks, adapter definitions, datasets, executable packages and results before relying on a different browser or device. Browser-local projects and drafts are not uploaded backups. A private server session can recover its owned jobs after an ordinary reconnect, but losing its session cookie does not provide an account-based way to recover those records. Removing history does not reset the daily CPU ledger.

Export important results before deleting them. Use a finished calculation's removal control, or choose Clear finished calculations, to free storage after confirmation. Clearing history preserves active calculations, saved projects and adapter definitions. Archiving a record hides it but does not free its storage.

Give an AI a precise authoring brief

Give your AI assistant this handbook, the current schemas, a working task and the mathematical requirements. Specify units, valid ranges, mandatory conditions and preferences. Include a small case whose answer you can verify, and ask the assistant to identify unsupported requirements before it creates files.

Require a complete refined.math.task and, if useful, an adapter profile containing that task and a reference to the correct installed adapter. Ask for a second data instance and an independent candidate check. Generated files still need to be imported, validated and calculated in Refined Math.

Download the AI authoring prompt

Copy the current-format AI prompt
Create a declarative adapter profile and a data task for the current version of RoboPol Math (Beta).

This brief covers mathematical models and data for installed adapters. If the problem needs customer-written initialization, operators or local search, identify that requirement first and use the separate Customer Program SDK v1 or Rust adapter SDK v1 contract. Do not place executable code inside ModelSpec or present an ordinary Rust source file as an importable adapter.

Online execution contract:
- Calculations run on server CPUs. Neither the server GPU nor the visitor GPU is available. If the exported engine settings contain acceleratorBackend, use only cpu_only; do not request auto or require_gpu.
- The Free search allowance is at most 30,000 ms, inside a 45,000 ms whole-job limit including preparation and validation. Keep the first reference task at the default 3,000 ms unless a justified change is requested.
- The full worker has at most 512 MiB. A browser session may have one active calculation and two queued calculations; waiting is free of CPU charges. One CPU-hour per UTC day is shared across native calculations and executable validation, without a separate hourly quota. Actual consumption can differ from elapsed wall time.
- This is private browser-session ownership, not a registered account or automatic cross-device synchronization. Definitions/projects/datasets/drafts are browser-local; owned jobs/results and admitted executables have private server storage. New finished Free records are bounded to 100 and up to 30 days, with additional capacity bounds. Include export/reuse instructions.
- The scientific long-factorization backend needs a separate bounded pool and is not admitted through the current Free short-job service. Do not promise that a large factorization runs simply because its number syntax is valid.
- These are service-enforced ceilings. Do not invent task fields to change the plan, CPU allocation, memory, daily credit or whole-job deadline. A stronger search profile does not bypass them.

If a custom Rust adapter is needed, request the current Rust SDK and its fixtures rather than guessing an ABI from this declarative brief. Its current executable profile accepts an author-built Wasm module of at most 512 KiB inside a 4 MiB package, with up to 64 source files / 2 MiB attached source. Guest memory is 32 MiB per instance (up to four search instances), not the entire 512 MiB worker. A state is at most 64 KiB; request/response messages and the complete runtime task are at most 128 KiB including wrappers/metadata. Package default data and each sample are at most 64 KiB; they are not a blanket 64 KiB limit on every runtime dataset. Guest responses allow 8,192 counted values/keys and depth 40; common JSON arrays allow 4,096 elements. Call fuel is 50 million units, shared search fuel 500 million and fresh final-validation fuel at most 250 million; these limits can stop before the time allowance. Fuel units are not CPU seconds or a raw instruction count. The profile supplies no host imports/WASI, filesystem, network, process, native-library or GPU access. Rust is compiled by the author outside the service. A standalone author-checker pass is conformance evidence, not service security acceptance or independent mathematical proof.

Problem: [Describe the decisions, units, input data, mandatory conditions and objective.]
Small reference case: [Provide a feasible case with values that can be checked independently.]
Attachments: a profile exported from the current application in refined.math.adapter format, plus model.schema.json, task.schema.json and adapter.schema.json. Use the exported profile as the basis for compatibility.

Deliver two separate JSON files encoded in UTF-8:

1. my-problem.adapter.json
Choose a compatible installed adapter first, then copy its supplied profile. Use math-model for mathematical search, finite-count for exact counting, symbolic for symbolic transformations, or the registered ID of a suitable native adapter. If the correct profile is missing, ask for an export.
Update the descriptive fields name, description, help and contract so that they accurately describe the model and selected adapter. Put the complete example task in defaultTask. Keep format set to refined.math.adapter and schemaVersion set to 1. Retain the source profile's values for adapterId, runtime.binding, runtime.inputKey and runtime.coreRevision. Every task in samples[].task must use the same registered adapter. Metadata describes behavior; it does not implement executable operators.

2. my-problem.task.json
Create a complete, self-contained task with format set to refined.math.task, schemaVersion set to 1, the same adapterId, a title, the appropriate payload and bounded run options. Mathematical and counting tasks use payload.model; native tasks use payload.input; symbolic tasks use payload.symbolic. For ModelSpec, place the complete model in payload.model and its parameter values in payload.model.data. Do not use external file references. Separate data imports require the refined.math.data format and an exact reference to a saved adapter definition.

The following ModelSpec instructions apply to math-model and finite-count. Native and symbolic inputs must follow their own exported contracts.

ModelSpec v1 contains schemaVersion, title, variables, data, constraints and goal. Set numericPolicy to exact for supported exact arithmetic. For approximate numerical calculations, use auto or real and specify the tolerance.
Declare decision groups of kind integer, binary, permutation or real, with shape, lower and upper. Bounds must be fixed numeric values. A permutation's interval must contain exactly as many integers as there are positions in its declared shape.
The data field contains named parameter groups, each with a values array. A single-element values array represents a scalar parameter. Write fractions, decimals and large exact integers as JSON strings.

Use one-based indices written as integer literals, such as pick[1]. For vectors, use dot, sum, product, sumSquares, mean, min, max and allDifferent. Matrix selectors include row(M,1), column(M,1), diagonal(M,0) for the main diagonal and diagonal(M,1) for the secondary diagonal of a square matrix. Other supported functions include abs, sqrt, sin, cos, tan, exp, ln, log10, norm, floor, ceil, round, sign, gcd, lcm, factorial, choose and if. Some functions require approximate arithmetic.
Expressions support + - * / % ^, == != < <= > >=, and && || !. Write multiplication explicitly. Do not use loops, comprehensions, variable indices, JavaScript or Python syntax, Math.*, eval or uploaded source code.
Use math-model for the goals find, minimize and maximize. Counting requires finite discrete domains with exact predicates and the finite-count binding throughout the profile and task. Symbolic transformations use the symbolic binding and payload.symbolic. Explain any proposed change to the requested execution path.

Keep the first verification case small. ModelSpec limits are 1–16 variable groups, 512 decision values in total, 32 data groups with at most 512 values each, 64 conditions, 4,096 UTF-8 bytes per expression and 120 characters per title. Use unique ASCII names of at most 32 characters, beginning with a letter or underscore. Avoid reserved names, including function names. Each ordinary JSON import document requested by this brief must be no larger than 131,072 bytes (128 KiB). Executable Rust packages have their own format and limits; they are outside this declarative workflow.
For a ModelSpec search task, start with these options:
{"seed":42,"timeLimitMs":3000,"maxEvaluations":200000,"maxWorkUnits":50000000}
Do not invent unsupported fields, functions, runtime bindings, renderer code or compiled adapter packages.
For other adapter types, retain their exported run-option contract. Do not copy model-specific options into another binding without checking support.

Before delivering the files, explain the candidate representation, fixed data, every mandatory condition, the objective and one independent check. Check vector dimensions, units, bounds, feasibility, denominators, function domains and arithmetic ranges. When removing symmetries, confirm that the alternatives are equivalent in the original problem. Explain how to replace the data values while retaining the same formulation.
Name the answer a user should look for: the selected items, assignment, values or formula. Explain the objective's meaning and units separately from the decision vector. If you provide a custom result presentation, follow the current outputs.schema.json and use only its declarative projections; do not include rendering code.
If a requirement cannot be expressed with the supported operations, identify the limitation and ask for a reformulation. Do not substitute plausible-looking unsupported syntax.

Do not fabricate runtime output, engine statistics, certificates or claims of completed tests. A feasible result or best_found status does not prove global optimality; no_solution_found does not prove infeasibility. Distinguish independent mathematical reference values from results produced by the actual application.
The best_found status alone does not establish feasibility. Check the feasible field and the returned condition checks. A recomputed score is not by itself an optimum certificate.

If you cannot create files, provide a separate, clearly named fenced JSON block for each file. Each block must contain complete, valid JSON without comments or omitted sections. The user will load the profile or task through Import adapter or task, then choose Validate input and Calculate.

For reusable adapters, first import the profile and export its refined.math.definition document. For a second instance, create refined.math.data v1 with title, the exact definition object (id, revision, digest), and payload.modelData containing all named parameter groups with unchanged lengths. Native datasets instead contain payload.input; symbolic datasets contain payload.symbolic. Omit the data document's optional id and digest when authoring changed data; never invent the definition's digest. The app validates a change preview before applying the dataset. Model-structure changes require a new definition revision.

Review the model rather than judging it by a plausible-looking answer. Check the direction of every inequality, the difference between “exactly” and “at most”, vector ordering and the treatment of mandatory conditions. Require the assistant to distinguish a predicted reference from a result actually returned by Refined Math. AI assistance is optional; calculations execute the supplied model or adapter without an AI service.

Read the answer and its evidence

Read the answer in this order: the returned values or assignment, the objective and its units, the condition checks, then the mathematical status. In the equipment example, the selected items are the solution and their total benefit is the objective. A technical search score, an error value and a solution vector describe different things.

Validate input checks whether the formulation is supported. A compiled plan explains how it can execute. Calculate performs the calculation and returns its measured work. A passing score check confirms consistency of the evaluation; it does not by itself prove that every condition is satisfied or that the result is optimal.

Result informationHow to interpret it
feasible: trueThe returned candidate satisfies the checked requirements under the adapter's stated numerical rules.
best_foundThe calculation reports its best candidate within the admitted limits. Check feasibility separately; this status supplies no optimum proof.
optimal_provenA supported certificate establishes the optimum for the declared problem and objective.
no_solution_foundThe calculation did not find an acceptable solution within its limits. This does not prove that no solution exists.
count_exact / count_partialAn exact count is complete. A partial count is only a lower bound on the final total.

For numerical problems, read the reported residuals, tolerances and acceptance checks. A small residual is numerical evidence. Checking a finite grid does not establish an analytic identity throughout a continuous domain. For symbolic results, also inspect domain conditions, completion information, arbitrary constants and any truncated series terms.

Check measured work and stopping

Open Statistics for elapsed time, evaluations, stopping information and available counters. Requested controls and actual learning updates or CPU proposal work are shown separately. New online calculations use CPUs only. Historical results from another edition can retain recorded GPU counters; those describe their original execution and do not enable GPU execution here. The adapters that recognize a supported certificate can share the verified solution with their other search runs, avoiding further domain search. The core may still finish run and learning bookkeeping; this is why a certified result need not return at the exact instant its witness is found.

Finite counting and symbolic transformations use their own methods. Their measurements describe those methods rather than a Refined search. A completed calculation is a lifecycle state; it can still contain an unsuccessful mathematical result.

Inspect, compare and export

Read chart labels and index bases alongside the returned tables. Enlarge a chart when necessary. A plot illustrates the returned values; it is not an optimality proof. JSON preserves the full returned result and its context. Available table and chart exports include CSV, SVG and PNG. Keep the input task as well as the result when you need to reproduce a calculation.

Comparisons must use the same problem, data and objective units. The application retains the original task and settings with each result, so editing today's workspace does not relabel yesterday's answer. Opening an earlier calculation lets you inspect its saved result and, when available, the source package used by that calculation.

Fix import and calculation problems

SymptomWhat to inspect
Invalid request or unsupported adapterCheck the format/version, registered adapterId, matching payload key and profile core revision. Start from a fresh application export.
Parse, type or unknown-symbol errorCheck spelling, explicit multiplication, ==, function arguments and literal one-based indices. Each condition must return a Boolean.
Numeric policy, range or domain errorWrite exact fractions, decimals and large integers as JSON strings. Check denominators, function domains and intermediate values for overflow. Use approximate arithmetic for functions that require it.
No feasible solution foundManually check the model and a candidate, then inspect violated conditions and stopping limits. Increase the budget only after checking the formulation.
Engine unavailable or calculation waitingInspect the queue state and use Reconnect when the connection is interrupted. Waiting does not spend CPU credit. A missing compatible runtime or isolated executor needs service support; importing descriptive metadata cannot install it.
Calculation storage is fullOpen Calculations, export results you want to keep and remove finished calculations. Archiving alone does not free storage.
GPU setting in an imported taskOnline execution is CPU-only. Start from a current task export with acceleratorBackend: "cpu_only"; unsupported GPU backend requests are rejected rather than silently changed.
Daily credit exhausted or credit reservedRead the header's remaining credit, reservations and local reset time. Unused queued work can be cancelled to release its reservation; already consumed CPU is not refunded by deleting history.
Executable adapter isolation unavailableThe service will not execute the package without its required isolation. Keep the package and diagnostic information for support; there is no unconfined execution option.
Rust/Wasm fuel or message limitCheck the SDK limits, batch sizes and actual stopping reason. A VM work limit can end a run before the search time expires. A partial answer exists only if the returned result passed fresh validation.
Long factorization pool unavailableThe scientific backend is separate from the current Free short-job pool. It is not started by increasing maxSeconds or the ordinary search allowance.
Imported Rust task refers to a missing packageImport its original executable .adapter.json package. A task or definition containing only its reference does not carry the compiled module.

Current ModelSpec limits are 16 variable groups, 512 decision values in total, 32 parameter groups, 512 values per parameter group and 64 conditions. An expression can contain up to 4,096 UTF-8 bytes and 64 levels of nesting. Discrete bounds lie within ±109; real bounds lie within ±1012. Ordinary task, profile, definition and data documents are limited to 128 KiB. Executable Rust adapter packages have a separate limit of 4 MiB, including a Wasm module of at most 512 KiB.

Depending on the selected method, admitted calculation settings include 100–30,000 ms, 16–1,000,000 evaluations, 1–200,000,000 work units, 1–2,000,000 enumerated states and 16–100,000 candidate states. A seed is an integer from 0 to 4,294,967,295. Each installed adapter or SDK may impose additional limits. Increasing limits does not guarantee a better result or remove numerical restrictions.

Use Stop calculation to stop a selected active calculation. Its input and recorded events remain available. A stopped job has a result only if a validated result was actually returned; the application does not invent a partial answer. For a connection interruption, use Reconnect and reopen the existing entry in Calculations.

Inspect source or create your own adapter code

Inspect an installed adapter

Use an installed adapter when its mathematical contract fits your task. In the workspace, choose Adapter source to inspect the published implementation and download its source package. For a completed calculation, Source used by this calculation opens the source identity recorded with that result. Older results without a recorded source identity cannot establish which current source they used.

Installed Rust source packages show the domain representation, scoring and operators compiled by the worker. They do not contain the private Refined core. Editing a downloaded .rs file does not update the installed adapter. To import your own executable implementation, use the separate Rust SDK workflow below.

Write a bounded operator program

Customer Program SDK v1 lets you define initialization, evaluation, validation and state-changing operators for bounded integer, binary and permutation vectors. Import a complete program definition with its reference data. The supplied program performs the actual operations used during the search.

The Program SDK guide includes importable definitions, separate datasets, a cardinality-preserving exchange and a permutation operator that uses a cost matrix. The program language has bounded instructions and no filesystem, network or process access. Follow its supported operations and limits.

Build and import a Rust adapter

Rust SDK v1 supports custom states, integer or real objectives, initialization, moves, full local search, perturbation and optional guidance, repair and recombination. Start at Build and import your own Rust adapter, or download the complete Rust authoring project. It includes QAP and weighted-fitting examples.

  1. Edit an example in the authoring project. Its README specifies the public interface and limits.
  2. Build the Wasm module in your own development environment and create the executable .adapter.json package with the provided packaging script.
  3. Choose Import adapter or task in RoboPol Math (Beta) and import the resulting package. After validation, open it from My adapters.
  4. Enter or import data, validate the task and calculate. Reuse the adapter with separate datasets.
  5. When you change the code, rebuild and import the package to create a new revision. Export the executable package as well as the task if you need to transfer it to another installation.

The current Rust profile runs on the server CPU in an isolated, bounded Wasm runtime. It provides no host imports, WASI, GPU services, native libraries, filesystem, network or process access. The service refuses executable operations if the required isolation is unavailable. Compile Rust in your own development environment; a source file, EXE or DLL is not an executable import package for this workflow.

Imported Rust/Wasm limits

SDK boundaryCurrent limit
Compiled Wasm module / complete package512 KiB / 4 MiB. The package ceiling includes its metadata, encoded module and any attached source.
Attached sourceAt most 64 files and 2 MiB in total. These files are author material and are not compiled or executed by importing them.
Package default data and each sample64 KiB each.
Runtime task and dataThe complete task must fit within 128 KiB, and each framed guest request within 128 KiB. Metadata and framing reduce the bytes available for the dataset.
Decision state / guest response64 KiB per state / 128 KiB per response, including all batched states and its envelope.
Guest memory32 MiB per Wasm instance, with at most four search instances. This is separate from the 512 MiB complete-worker ceiling; a single guest does not receive all 512 MiB.
Response structure8,192 counted values/object keys and depth 40. Common JSON arrays have at most 4,096 elements.
Operator batchesAt most 256 guidance or move hints, and at most 24 candidate states in one batch. The requested batch bound can be smaller.
Private executable library32 packages/versions and 64 MiB per browser session, subject to service-wide capacity.

A callback has at most 50 million fuel units. Search and its instance initialization share 500 million; independent final validation has a separate ceiling of 250 million. Fuel meters VM work and is neither an exact raw-instruction count nor CPU seconds. Fuel, message size, state size or other SDK limits can stop a calculation before its 30-second search allowance. Fresh final validation still has to fit within the whole-job deadline.

The profile supports at most eight objective metrics and 32 operator families, with additional structural and stack limits checked during admission. Plan within the supplied README and current executable examples rather than assuming arbitrary Rust crates or every private engine hook are supported.

Executable imports allow one active check per browser session and two across the service. Each session may attempt 12 imports per ten minutes, including unsuccessful attempts. A package is bound to its checked executable identity; a runtime or security update can require reimport before it runs again. Keep an exported executable package as well as any task that references it.

A custom package may include author-provided source. Package and module identities identify the executable, but do not prove that the attached source was used to build it. Installed adapter publication separately checks the published source against the worker build. Neither SDK includes the private core implementation.