Skip to main content

​
Overview

Every time you change a model, ProDex runs a validation pass that checks the model against a set of correctness rules. The result is visible as the green/red play button in the Modeler: green means the model is valid and ready to run; red means there’s something blocking simulation. Validation happens continuously while you build, which means you catch problems as you introduce them rather than discovering them hours later when a simulation fails. Clicking the red play button (or hovering it) shows you the specific errors.

​
What Gets Validated

Validation covers six broad categories. Understanding what each catches helps you diagnose errors when they appear.

​
Structural Integrity

  • Every required field on every component is filled in
  • Entities referenced by Sources, Transformers, Separators, and BOM nodes are defined in the library
  • Sources have no incoming connections; Sinks have no outgoing connections
  • Connection endpoints reference flow components, not stations (stations hold components; they don’t participate in flow directly)
Note that Sources do not require arrival logic. Event-only Sources deliberately omit arrival configuration and generate entities solely via release_entity actions triggered by Event Hooks or schedule material releases — the validator will not flag a source without arrival logic as an error. This category catches the class of error where you added a component but forgot to configure one of its fields. The error will name the field that’s missing.

​
Graph Connectivity

  • The model forms a reachable graph from Sources to Sinks
  • No disconnected subgraphs (orphaned components that nothing flows to)
  • No dead ends (components whose outputs go nowhere, if the component type requires an output)
  • No unintended cycles that would cause entities to loop forever
If your model has an orphan component left over from an edit, validation catches it here. Either delete the orphan or connect it into the flow.

​
Entity Type Safety

  • Flows between components carry compatible entity types
  • Transformers map from a source type to a target type that exists in the library
  • Combiners produce an output entity type that exists
  • Routers can’t emit an entity type downstream components don’t accept
This is how ProDex prevents silent type mismatches — you can’t accidentally route a raw_material entity into a process expecting finished_good.

​
DSL Expression Validation

  • Every DSL expression parses correctly
  • Every expression runs in a context where its identifiers are available (no referencing entity attributes in a no-entity context, etc.)
  • Aggregation functions appear only in multi-entity contexts (Combiner output assignments and conditions; Separator on_batch_created hooks)
  • Lookup table and constant names referenced in expressions actually exist
  • Type correctness: numeric expressions produce numbers, boolean expressions produce booleans, etc.
This is the most common source of red-button errors. The Expression Contexts model determines what’s valid where — if you hit a “identifier not available here” error, consult that section.

​
Schedule Bounds

  • Every schedule has a defined start_time
  • All schedule event times are timezone-aware ISO datetimes that fall within the schedule’s bounds (between start_time and end_time if provided)
  • Material releases target Sources or BufferNodes that exist and produce entity types that exist

​
Size Limits

  • Simulation duration — at most 365 days
  • Estimated simulation output size — at most 300 MB per run
  • Model size — total components, connections, and schedules per model
  • Library size — total entity types, constants, and lookup tables
  • Individual expressions don’t exceed length limits
If your model is close to a size limit, validation surfaces it so you can trim before running.

​
When Validation Fails

When the play button is red, click or hover it to see the specific errors. Each error includes:
  • The component, expression, or schedule element that failed
  • What the problem is
  • Usually a suggestion for how to fix it
Errors are listed in priority order — fix the ones that block other validations first (structural and connectivity errors often hide expression errors until the structure is valid).

​
Validation and Dexter

Validation applies to changes Dexter makes, too. When Dexter modifies your model, the same rules run. If Dexter tries to configure a component that would fail validation, the platform rejects the change and Dexter has to retry or ask you to clarify. This is one of the mechanisms that keeps Dexter from silently corrupting a working model. If Dexter is repeatedly failing to apply a change, check the validation errors — often the fix is a small correction Dexter couldn’t infer on its own (a missing constant, an attribute name that doesn’t exist on the entity type) and telling Dexter the specific fact unblocks it.

​
Tips

  • Fix structural errors first. Validation runs top-down; expression validation can’t run on components that aren’t connected yet.
  • The error messages are specific. If an error is confusing, search the message text in the docs — most validation errors map directly to concepts covered in the reference.
  • Validation is fast. You can make sweeping edits and let validation check them — you don’t need to be surgical.
  • Red play button is your friend. It’s a forcing function that prevents you from wasting time on a simulation that was going to fail. Treat each red state as information, not an obstacle.