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.
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.
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.
Failures Architon catches
These are the integration bugs that waste weeks: they pass CAD checks, then fail in bring-up.
- Battery: 14.8V
- Driver max: 13.5V
- Build fails after assembly
- MCU IO: 3.3V
- Peripheral VIH: 4.5V min
- “Works on bench” then fails
- Two devices share 0x68
- Random startup failures
- Days lost debugging “noise”
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.