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.