Enforcing system contracts for modern hardware

Architecture verification for hardware systems

Define and enforce system contracts across power, interfaces, and components. Detect integration failures before hardware is built.

Deterministic. CI-friendly. Built for modern robotics and embedded systems.

Try the open-source CLI Deep dive

Deterministic output

Explainable root causes

CI-friendly exit codes

Power and supply windows Battery voltage vs driver limits, regulator headroom, peak current capacity and brownout risk.

Logic-level compatibility Catch 3.3V to 5V mismatches early. Enforce thresholds, not just connectivity.

Shared bus integrity Duplicate I2C addresses, bus loading risk, and protocol-level conflicts that show up as “random bugs”.

Deterministic reports Stable findings for humans and machines. No probabilistic scoring. No ambiguity.

Why Architon exists

ERC, DRC, and SPICE are essential, but they are not designed to enforce system integration contracts across components. Robotics and embedded systems fail on the gaps between parts: supply limits, logic thresholds, shared buses, and power budgets. Architon makes these contracts explicit and CI-enforceable before boards are ordered and bring-up begins.

Inputs

YAML today. BOM and CAD ingestion in progress.

DesignIR

Normalized system model: components, rails, interfaces.

Rule engine

Deterministic contract checks across domains.

Findings

Explainable findings + CI-stable exit codes.

Architon complements

ERC, DRC, and SPICE validate schematics, layout, and circuit behavior. Architon validates system integration contracts between components.

Architon does not replace

Architon does not replace ERC/DRC or simulation. It targets architecture correctness: integration constraints that traditional checks do not systematically enforce.

Deterministic by default

Same input yields the same output. Findings include root cause and remediation hints. Deterministic gates for humans and CI.

Example architecture finding

Deterministic output format, designed to be read by humans and pipelines.

Supply windows Logic thresholds Shared-bus constraints Power budgets

Loading architecture analysis...

Failures Architon catches

These are the integration bugs that waste weeks: they pass CAD checks, then fail in bring-up.

Power

Supply range mismatch

Typical outcome: dead motor driver or unstable behavior under load.

Battery: 14.8V
Driver max: 13.5V
Build fails after assembly

DRV_SUPPLY_RANGE

Logic

3.3V to 5V mismatch

Typical outcome: flaky comms, overheating, undefined behavior.

MCU IO: 3.3V
Peripheral VIH: 4.5V min
“Works on bench” then fails

LOGIC_LEVEL_MISMATCH

Buses

I2C address conflict

Typical outcome: intermittent faults misdiagnosed as firmware bugs.

Two devices share 0x68
Random startup failures
Days lost debugging “noise”

I2C_ADDRESS_CONFLICT

Start verifying your architecture today

Use the open-source CLI for deterministic checks. Request private preview for expanded capabilities.

Open-source 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.

Is this AI?

The open-source core is deterministic. Private preview may add optional assistants, but deterministic checks remain the gatekeeper.

How do teams adopt this?

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