Architon — Deterministic Architecture Verification

Where Architon fits

Architon runs after schematic design but before PCB fabrication and firmware bring-up, enforcing system compatibility between components before hardware exists.

Runs before firmware and runtime stacks like ROS 2. Think: KiCad/Altium → Architon → PCB → STM32/ESP32 firmware → ROS bring-up.

Inputs Hardware definition

YAML BOM CAD

Declare components, rails, and interfaces.

Architon Architecture verification

Supply compatibility Interface constraints Power budgets

Enforces system contracts before hardware is built. Runs during design and CI, before PCB fabrication.

CI gates • Stable exit codes • No heuristics

Output Build and bring-up

Fewer revisions Predictable bring-up Lower risk

Catch system-level failures before they become hardware.

The verification loop

A deterministic pipeline: ingest → normalize → verify → report.

1. Define architecture (input)

Describe components and constraints in simple YAML.

# robot-v1.yaml
components:
  battery:
    voltage: 14.8
    max_current: 11.0
  mcu:
    logic_level: 3.3
  motor_driver:
    supply_range: [4.5, 13.5]
    logic_range: [4.5, 5.5]

Inputs: YAML today · BOM & CAD ingestion in progress

2. Run analysis (output)

Explainable findings with remediation hints.

$ rv check robot-v1.yaml

HARD STOPS
[X] DRV_SUPPLY_RANGE
battery 14.8V outside driver [4.5, 13.5]V
Fix: Align battery voltage or choose compatible driver.

[X] LOGIC_LEVEL_MISMATCH
MCU 3.3V outside driver [4.5, 5.5]V
Fix: Add level shifter or choose 3.3V driver.

exit code: 2

What Architon verifies

Connectivity is necessary. It is not sufficient.

Power analysis

Validate peak and continuous current against regulator, battery, and driver limits. Detect headroom, dropout, and brownout risk.

Signal logic

Detect logic-level mismatches by comparing IO voltage levels and thresholds. Prevent “works sometimes” failures.

Bus integrity

Scan shared buses for protocol-level conflicts such as duplicate I2C addresses and loading risk.

Architon vs. Traditional EDAs

Architon complements your existing workflow by filling the "System-Level Gap."

Verification Type	Traditional ERC/DRC	Architon Logic
Electrical Connectivity	Validates pin-type compatibility (input, output, power). Detects floating or illegal connections.	Validates that power sources can safely drive loads (voltage ranges, current capacity).
Logic Compatibility	Does not verify logic thresholds or voltage-level compatibility.	Detects logic-level mismatches (VOH/VOL vs VIH/VIL).
Power Capacity	Does not validate current consumption vs regulator, battery, or driver limits.	Validates peak and continuous current against component ratings.
Bus Integrity	Ensures electrical connectivity of shared buses.	Detects protocol-level conflicts such as duplicate I2C addresses.

Bring verification into CI

Make architecture checks fail fast. Prevent regressions before ordering boards.

Try the CLI Request Private Preview

FAQ

Short answers. No hype.

Don’t ERC, DRC, and simulation already catch these issues?

ERC and DRC validate schematic connectivity and PCB layout. Simulation validates circuit behavior under specific conditions. These tools do not systematically enforce system-level compatibility constraints across components, such as supply limits, interface compatibility, and power budgets. Architon verifies these architecture-level constraints before hardware is built.

Does this replace ERC, DRC, or SPICE?

No. Architon complements them. It targets the system-level integration failures that occur between those tools.

When should Architon run?

Architon runs during design, before hardware is built, and in CI to prevent invalid architecture changes from merging.

What inputs are supported?

YAML architecture profiles today. BOM and CAD ingestion are in progress, starting with KiCad BOM import.

How do teams adopt this?

Start in CI: run rv check on every change to prevent architecture regressions before boards are ordered.

Deterministic verification beyond the netlist.