List available ProSuite quality conditions.

Returns condition names and their one-line description. Use search to filter by keyword (matched against name and description). Pass a result name to describe_condition to get full parameter details before building a run_verification call.

Describe the parameters of a ProSuite quality condition.

Returns the full docstring and parameter list with types. Dataset parameters expect a dataset name string (must match a name in the datasets list you will pass to run_verification). Primitive parameters take their direct value (number, bool, string).

Parameters marked optional may be left out of run_verification's params: ProSuite applies its own default. Everything else must be supplied.

Describe the loaded QA spec file: available specifications, workspace definitions, and per-specification summary of conditions, workspace IDs, and dataset names.

Call this before run_xml_verification to learn:

• Which specification_name values exist in the spec (pass one to run_xml_verification)

• Which workspace_id values need to be replaced with real paths

• Which datasets each specification expects (useful for sanity-checking the workspace)

Describes whichever spec is active: the one load_spec was last called with, otherwise PROSUITE_SPEC_PATH. Returns 'status': 'ok' or 'error'.

Search the loaded QA spec for conditions matching a natural-language query.

Returns up to max_results conditions whose name, description, or category contains the query string (case-insensitive, literal substring match, not semantic). Spec content may be in English, German, French, or Italian -- query in the same language as the spec to find matches.

Each result includes:

• name: the full condition name (human-readable rule statement)

• category: domain grouping from the spec

• allow_errors: False means a hard failure, True means tolerated

• condition_request: ready to pass directly into run_verification's conditions list (includes condition method name and pre-filled params)

• required_datasets: dataset names and filter expressions to include in run_verification's datasets list

A result carrying 'unsupported': True has neither of those last two: the programmatic path cannot rebuild it (transformer preprocessing, or no factory method). It is listed so browsing sees the whole spec, and it still runs normally under run_xml_verification, which reads the spec as written.

Searches whichever spec is active: the one load_spec was last called with, otherwise PROSUITE_SPEC_PATH. Returns 'status': 'ok' or 'error'.

Load a .qa.xml spec file at runtime.

Replaces any previously loaded spec, and takes precedence over PROSUITE_SPEC_PATH, so every subsequent spec tool (search_spec, describe_spec, add_condition_to_spec, run_xml_verification) uses the new file. Use this when the spec path is only known at conversation time (e.g. a file on OneDrive or a network share) instead of pre-configuring PROSUITE_SPEC_PATH.

Args: path: Absolute path to the .qa.xml spec file on the local machine.

Returns 'status': 'ok' with 'conditions_loaded', or 'status': 'error'.

Preview adding a new QualityCondition to a spec, reusing an existing descriptor.

Builds the condition through the same prosuite factory as run_verification, resolves a matching (never synthesizes one), and returns the full updated spec XML with the condition appended and wired into target_specification_name. Preview only: never writes to a file. Call describe_spec first for valid specification/workspace/dataset names.

Args: target_specification_name: QualitySpecification to wire the condition into. name: Human-readable condition name; must not already exist in the spec. condition_request: {condition: method name from list_conditions, params: dict}. datasets: Feature classes/tables used by condition_request, each with 'name' and an optional 'filter_expression'. workspace_id: Logical workspace id to bind datasets to (e.g. "DATA_OSM"). allow_errors: Whether issues from this condition are tolerated. description: Optional description element. spec_xml: Spec XML text; defaults to reading the active spec (the one load_spec was last called with, otherwise PROSUITE_SPEC_PATH). category: Which category to file the condition under. Only needed when the spec nests QualityConditions under more than one.

Returns 'status': 'ok' with 'spec_xml' holding the updated spec, ready to review and persist yourself, or 'status': 'error'.

Run a ProSuite quality verification.

Build an ad-hoc condition-list specification and run it against the given workspace. The ProSuite service (prosuite-qa-microservice) must be reachable at the host/port configured via PROSUITE_HOST / PROSUITE_PORT environment variables (default: localhost:5151).

Args: model_catalog_path: Workspace path on the server, e.g. 'C:/data/mydb.gdb' or a .sde connection file. model_name: Logical name for the data model (arbitrary, used in generated condition names). datasets: Feature classes or tables to make available for conditions. Each entry has a 'name' (feature class name) and an optional 'filter_expression' (SQL WHERE clause). conditions: Conditions to run. Each entry has: - condition: method name from list_conditions (e.g. 'qa_min_length_0') - params: dict mapping parameter names to values. Dataset parameters take a string matching a name in 'datasets'; primitive parameters take their direct value. output_dir: Optional server-side directory for Issues.gdb and HTML report; the service process must have write access. Omitted, a local runs/ directory is used only when PROSUITE_HOST is local, since the path is resolved on the service's machine. envelope: Optional spatial filter {x_min, y_min, x_max, y_max}. Omit for full-extent verification.

Returns a summary with status, total_errors, and per-condition breakdown. Check 'status': 'error' for connection or parameter failures.

Run a single proposed condition ad-hoc and show what it actually flags.

Tier-2 confirmation for spec authoring: add_condition_to_spec only confirms a condition builds and references an existing descriptor. This runs it for real against model_catalog_path and returns the same engine-confirmed summary as run_verification (engine_confirmed, total_errors, sample_features with the actual flagged issues), so a proposed condition can be judged by what it flags before it's merged into a spec. Scope envelope to a small extent to keep this a preview, not a full run.

Args: model_catalog_path: Workspace path on the server, e.g. 'C:/data/mydb.gdb' or a .sde connection file. condition_request: {condition: method name from list_conditions, params: dict}. datasets: Feature classes/tables used by condition_request, each with 'name' and an optional 'filter_expression'. workspace_id: Logical name for the data model (arbitrary, used in generated condition names). output_dir: Optional server-side directory for Issues.gdb and HTML report. Omitted, a local runs/ directory is used only when PROSUITE_HOST is local, since the service resolves the path. envelope: Optional spatial filter {x_min, y_min, x_max, y_max}.

Run a ProSuite quality verification directly from the loaded XML spec file.

Unlike run_verification, this tool sends the XML spec to the ProSuite service as-is, without decomposing it into individual conditions and datasets. This preserves per-condition dataset filters, default scalar values, and all other spec details exactly as configured.

Use search_spec (with empty query) to discover available specification_name values and workspace_id keys that need to be replaced.

Args: specification_name: Name of the QualitySpecification element inside the XML file to run (e.g. 'Copy of DATA_OSM_10_Demo'). data_source_replacements: Maps each workspace_id in the XML to the actual workspace path on the ProSuite server. Example: [{"workspace_id": "DATA_OSM", "workspace_path": "C:/data/osm.sde"}] output_dir: Optional server-side directory for Issues.gdb and HTML report. Omitted, a local runs/ directory is used only when PROSUITE_HOST is local, since the service resolves the path. envelope: Optional spatial filter {x_min, y_min, x_max, y_max}.

Returns a summary with status, total_errors, and per-condition breakdown. Runs whichever spec is active: the one load_spec was last called with, otherwise PROSUITE_SPEC_PATH.