Glossary¶

Quick definitions of Validibot terminology. For detailed explanations, follow the links to the relevant documentation.

A¶

Action Step A workflow step that performs an action other than validation, such as sending a notification, generating a certificate, or triggering an external system. Compare with Validator Step.

Admin A role that can manage organization members, invite new users, and edit all workflows. Admins cannot delete organizations or manage billing. See Collaboration.

Assertion A rule that must be true for validation to pass. There are two tiers: default assertions are defined by the validator author and run automatically whenever the validator executes; step assertions are defined by the workflow author on individual workflow steps. Default assertions are always evaluated first, then step assertions. Both tiers produce findings and contribute to assertion statistics. Assertions often use CEL expressions.

Author A role that can create and edit workflows, manage validators, and run validations. Authors can only edit workflows they created, unlike Admins who can edit any workflow. See Collaboration.

C¶

CEL (Common Expression Language) A simple expression language used to write validation rules. CEL expressions evaluate to true or false and can reference fields in your data.

Custom Data Path A dot-notation expression that navigates into submitted data, used to target specific values in assertions. For example, p.building.thermostat.setpoint or p.results[0].value. Custom data paths are used when a validator doesn't declare Step Inputs or Step Outputs, or when you need to reference raw payload data directly. See Signals, Step Inputs, and Step Outputs.

E¶

Executor A role that can run validations on active workflows and view results. Executors cannot create or modify workflows. This role is typical for team members who submit data but don't configure validation logic. See Collaboration.

F¶

Finding A single issue discovered during validation. Each finding has a severity (ERROR, WARNING, INFO), a message, and often a path indicating where in the data the issue was found. Findings are the primary output of validation runs.

O¶

Organization The top-level workspace in Validibot. Each organization has its own members, workflows, projects, and settings. Users can belong to multiple organizations and switch between them using the organization selector.

Owner The highest-privilege role in an organization. Owners have full control including the ability to delete the organization and manage billing (Pro edition). Every organization must have at least one Owner. See Collaboration.

P¶

Project A way to group related workflows within an organization. Projects help organize your validation library by topic, team, or data type. All organization members can access all projects based on their role.

Promotion The action of lifting a Step Input or Step Output into the workflow's Signal vocabulary. Triggered by clicking "Copy to Signal" on a step's inputs or outputs panel and giving the value a workflow-wide name. After promotion, the value is accessible everywhere as s.<promoted_name> while still existing in its original step-local namespace (i.<name> or o.<name>). Promotion is symmetric — works the same way for both step inputs and step outputs. See Signals, Step Inputs, and Step Outputs.

R¶

Result The terminal outcome of a validation run, separate from State: PASS, FAIL, ERROR, CANCELED, TIMED_OUT, or UNKNOWN. FAIL means the user's data had problems; ERROR means the platform itself had a problem (a validator crashed, ran out of memory, etc.). The split lets CI pipelines distinguish "fix your data" from "try again". See Reviewing Results.

Role A permission level assigned to organization members. Validibot has five roles: Owner, Admin, Author, Executor, and Viewer. Higher roles include all permissions of lower roles. See Collaboration.

Rule An Assertion defined on a validator library item rather than on a workflow step. Because rules belong to the validator itself, they run automatically every time that validator is used in any workflow — workflow authors cannot skip or override them. Rules let validator authors encode domain knowledge (for example, "site EUI must be positive") that applies universally. In the code and database, rules are stored as the same RulesetAssertion model as step-level assertions; the difference is purely which ruleset they belong to.

Run See Validation Run.

S¶

Severity The importance level of a finding: ERROR (blocks validation from passing), WARNING (informational but doesn't block), or INFO (purely informational). See Reviewing Results.

Signal A named value in a workflow's vocabulary, available to every step as s.<name>. Signals are author-defined — created either through Signal Mapping on the workflow's settings page or by Promoting a step input or step output. Use signals when you want a named value to be visible across multiple steps. See Signals, Step Inputs, and Step Outputs.

Signal Mapping A workflow-level configuration that defines a Signal by giving it a name and a data path. Once mapped, the signal is resolved from the submission payload once before any step runs, and is available to every step's assertions as s.<name>. See Signals, Step Inputs, and Step Outputs.

Slug A URL-friendly identifier for workflows and organizations. Slugs are generated from names and are unique within their scope. For example, "Product Schema Validation" might have the slug product-schema-validation.

State The simplified, public-facing lifecycle of a validation run: PENDING, RUNNING, or COMPLETED. Use state to decide whether to keep polling. The granular terminal outcome lives in Result, not State.

Status The model-internal lifecycle value: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELED, or TIMED_OUT. Status captures both lifecycle and terminal outcome in a single field, which is convenient for the orchestrator but ambiguous for API consumers — that is why the API exposes State and Result instead. See also Result.

Step See Workflow Step.

Step Input A step-local named value that a step's validator has at the start of its work, before the main process runs. Accessed in CEL as i.<name>. Step inputs come from the validator's parser (e.g., parsed facts from an uploaded IDF), from resolved bindings (e.g., FMU model variable values), or from configured template variables. Step inputs only exist for validators that have a transformation process — schema validators (JSON Schema, XML Schema, Basic) have no step inputs. To make a step input visible across multiple steps, use Promotion. See Signals, Step Inputs, and Step Outputs.

Step Output A step-local named value that a step's validator produces after running. Accessed in CEL as o.<name>. Common examples include simulation results (EnergyPlus, FMU) and parser/evaluator output (SHACL, THERM). Step outputs only exist for validators with a transformation process and are only available in output-stage assertions (input-stage assertions cannot reference o.* because the validator hasn't run yet). To make a step output visible across multiple steps, use Promotion. See Signals, Step Inputs, and Step Outputs.

Submission The data payload submitted for validation. A submission can be a file upload, pasted content, or data sent via API. Submissions are stored and associated with validation runs for audit and rerun purposes.

Submission Metadata Free-form key-value tags attached to a Submission at launch time (via the web form's "Extra data" tab, the API's metadata field, or the CLI's --meta flag). Read in assertions as submission.metadata.<key> (use bracket notation for non-identifier keys, e.g. submission.metadata["deliverable-type"]). Metadata is submitter-provided, so treat it as advisory unless a trusted setter (e.g. a CI pipeline) supplies it. See Using submission metadata.

Submission Namespace (submission.*) The sixth CEL namespace, carrying the submission envelope — submitter-provided fields (submission.name, submission.short_description, submission.metadata.*) plus server-stamped facts (submission.file_type, submission.size, submission.uploaded_at). Unlike p.* (the file's contents), the envelope lives beside the file, so it works for any format — including non-JSON like RDF. Long-only (no short alias). Only the server-stamped facts are trustworthy for gating. See CEL Expressions.

V¶

Validation Run A single execution of a workflow against a submission. Each run processes the submission through the workflow's steps and produces findings. Runs are immutable records that can be reviewed, shared, and rerun.

Validator An engine that performs a specific type of validation. Simple validators run inline: JSON Schema, XML Schema, Basic (CEL assertions), and THERM. Advanced validators require dedicated compute resources: container-based simulation or compute-intensive services (AI-assisted validation). Validators can be system-provided or custom.

Validator Step A workflow step that runs a validator against the submission to check for issues. Most workflow steps are validator steps. Compare with Action Step.

Viewer A read-only role that can view workflows and validation results but cannot make changes or run validations. Useful for stakeholders and auditors. See Collaboration.

W¶

Workflow An ordered sequence of validation steps owned by an organization and assigned to a project. When you submit data for validation, it runs through each step in order. Workflows can be active (accepting runs), inactive (visible but not accepting runs), or archived (hidden but preserved for history).

Workflow Step A single action within a workflow. Steps execute in order and are typically either validator steps (checking data) or action steps (performing other tasks like notifications). Each step produces its own findings.