Architecture verification for hardware systems

The architecture verification layer for hardware systems.

Architon catches deterministic integration failures between components, before PCB bring-up. Verify power budgets, voltage domains, logic levels, and shared buses with explainable findings and CI-friendly exit codes.

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

Software has compilers and static analysis. Hardware has ERC, DRC, and SPICE. What’s missing is system-level verification: checks that validate whether connections make sense for the system’s physics and logic.

Inputs

YAML today, BOM and CAD ingestion in progress

DesignIR

Normalized architecture model

Rule engine

Deterministic checks across domains

Findings

Explainable output + CI exit codes

Architon complements

ERC, DRC, and SPICE. Those validate schematics, layout, and analog behavior. Architon validates system integration logic between components.

Architon does not replace

Electrical rule checks, board-level design rules, or simulation. Architon focuses on architecture correctness: failures that show up during bring-up.

Deterministic by default

Same input yields the same output. Findings include root cause and remediation hints. No hallucination. No scoring roulette.

Example architecture finding

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

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.

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.

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.