Platform model
Corvus separates the concerns that usually get tangled together in test-station software. Hardware integration lives in Python plugins, orchestration and pass/fail logic live in the Rust engine, and the desktop UI exposes workflows for operators and engineers.
Key rule: plugins return raw data. Corvus owns validation. That keeps spec logic centralized, reviewable, and versionable across stations and labs.
Main components
| Component | Role | Why it matters |
|---|---|---|
Rust Engine | Scheduling, orchestration, validation, state, reporting | Owns run lifecycle and test outcomes |
Python Workers | Plugin execution and hardware I/O | Keeps hardware-specific logic isolated from the engine core |
React/Tauri UI | Operator and engineer workflows | Provides the station-facing surface for running and reviewing work |
Reporting / GRR | Run traceability and study analysis | Turns execution data into usable engineering evidence |
Core config files
config/station_config.json
Defines the station identity and trigger context.
config/system_config.json
Holds engine-level settings such as report storage and runtime behavior.
config/production/routing.json
Maps part or revision context into a stable routing snapshot.
config/sequences/*.json
Defines sequence steps and the validation rules applied to plugin output.
Typical setup flow
- Define the station identity and trigger mode.
- Create or select the sequence file that represents the validation flow.
- Configure routing so the right part and revision context is captured at trigger time.
- Install or develop the Python plugins required for hardware actions and measurements.
- Run the sequence, inspect reports, and refine validations as measurement data comes in.
Station trigger → routing snapshot → plugin execution → raw measurement
→ Corvus validation engine → report export → Cortex analytics