Parameter sets
A parameter set is a versioned definition of the filters a person fills in: typed text and number inputs, dropdowns and multi-selects, their defaults, their validation and the choices that depend on other choices. The server evaluates the whole form, so every dashboard that pins the set gets the same rules.
What a set holds
A date, an amount, a name. It has a type, an optional default and optional constraints such as a minimum or a pattern. A value that breaks a rule is refused, never rounded or trimmed: an amount with two decimal places will not accept a third.
One choice or several. Each option is a value, the label a person reads and whether it is the default. Options are written into the set for lists that rarely change, or read from your database by a pinned SQL template for lists that do.
{
"name": "state",
"label": "State",
"type": "STRING",
"kind": "SELECT",
"cardinality": "SINGLE",
"required": true,
"source": { "template": { "id": "acme/sales/states_of_country.sql", "version": 3 },
"datasource": "warehouse" },
"depends_on": ["country"],
"presentation": { "control": "dropdown" }
}One parameter from the engine's own example set: the state list depends on the chosen country.
Cascading filters
The state list comes from a pinned template version, so the query behind a dropdown is reviewed and released like any other SQL. It returns a value, the text to show and the default flag, in a declared order.
The chosen country reaches the state query as a bound parameter, never pasted into the SQL text. A city list can depend on the state the same way, as long as the chain has no cycle.
The client sends every control's current value; the server answers with fresh options, the resolved value of each control and any errors. A choice that no longer exists falls back to the default and says it was reset.
POST /api/v1/parameter-sets/{id}/evaluate
{ "version": 4,
"selections": { "country": "USA", "state": "NY", "city": null, "min_order_amount": 250.00 } }The evaluate request from the REST contract. A first render sends empty selections and gets the whole form back.
Versions and review
An agent creates or edits a set as a draft over the MCP tools. A person releases it, and can discard, restore or switch versions with the same lifecycle templates use.
A dashboard pins one exact set version. That version cannot be discarded or purged while it is pinned; the server names the dashboards that hold it.
The Parameter Sets page renders the form and evaluates it as you change values, and its History tab lists every evaluation of the set: when, from which surface, by whom, its status and how long it took.
Current limits
TODAY and YESTERDAY on a schedule are bindings of the scheduler, separate from sets.Asked before
No. A pipeline declares its own typed parameters, and a published endpoint or a schedule supplies values for those. A parameter set is a separate, versioned form definition. Today its consumer is a dashboard, which pins one set version and maps the set's values onto its source pipelines' parameters. The contract is docs/dashboards.md §2.2.
No. The client submits every control's current value and the server evaluates the whole set again: it runs each pinned selector template with the parent values bound as parameters and returns fresh options, resolved values and per-field errors. The client runs no SQL and no dependency logic. The contract is docs/rest-api.md §21.3.
Nothing until someone moves the pin. An edit opens a new draft version, and the dashboard keeps the exact version it pinned. A version a dashboard pins cannot be discarded or purged: the server refuses with parameter.in_use and names the dashboards. The contract is docs/rest-api.md §21.2.