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.

Artifact A file or file-like input/output carried through a workflow step, such as an FMU, weather file, report, transformed document, or log. Artifacts use ports and bindings that preserve storage, authorization, hashes, retention, and lineage. An artifact is never a Signal, although a validator may expose small value facts about it. See How Data Flows Through a Workflow.

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.

Constant A fixed literal configured by the workflow author and exposed as c.<name> or const.<name>. Constants are part of the versioned workflow definition and do not come from run data, so they are not Signals. See How Data Flows Through a Workflow.

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 giving a value-port Step Input or Step Output an additional name in the workflow's Signal vocabulary. Triggered by clicking "Copy to Signal" and choosing a workflow-wide name. After the source stage completes, downstream execution can use s.<promoted_name> while the value retains its original step-local identity (i.<name> or o.<name>). Value inputs and outputs can both be promoted; artifacts cannot. See How Data Flows Through a Workflow.

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 An author-named CEL/JSON value in a workflow's vocabulary, exposed as s.<name>. Signal mappings exist before steps run; promoted value-port inputs/outputs become signals after their source stage and are available downstream. Use a signal for shared domain vocabulary rather than as a generic name for every validator value. Artifacts can never be signals. See How Data Flows Through a Workflow.

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 value or artifact consumed by one step. Small values are step-local and exposed in CEL as i.<name>; they can come from parser facts, resolved bindings, or configured variables. Artifact inputs use artifact bindings rather than becoming CEL values. A value-port step input can be promoted for downstream use. See How Data Flows Through a Workflow.

Step Output A value or artifact produced by one step. Small values are exposed in CEL as o.<name> after the validator runs. Artifact outputs remain in the artifact and lineage plane. A value-port output can be promoted for downstream use; an artifact cannot. See How Data Flows Through a Workflow.

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 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 A component that performs a specific type of validation. Simple validators run inline: JSON Schema, XML Schema, Basic (CEL assertions), and THERM. Advanced validators orchestrate dedicated compute resources, such as container-based simulation or compute-intensive services. 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.