TECHNOLOGY

Claude plans. Tools execute. People approve.

The core of Arcarix is a project engine, not a chat window. Claude understands requirements and plans the work, engineering tools connected over MCP do the execution, and every result lands in one revision history. This is the architecture under development.

LiveBrowser demo (presets)
Next milestoneClaude API · ESP32 + SHT31 workflow
PlannedMCP tool servers · Virtual boards · Plugin

ARCHITECTURE

Three layers, one project.

There are several ways in, but one place for project state and approval rules. Tools are exposed through the MCP standard and permissions stay with Arcarix, so a project is never tied to one client or model.

PLANNED ARCHITECTUREPlanned
Web workspaceReview and approve
Claude Code pluginSame tools in your editor
APIConnect team systems
Claude agent
  1. Understand
  2. Ask
  3. Plan
  4. Call tools
  5. Check
  6. Explain
Project graph

Requirements · Parts · Connections · Firmware · Mechanics · Evidence in one revision

catalogParts catalog
rulesCircuit rules
vboardVirtual board
buildFirmware build
cadParametric CAD
supplySourcing & quotes
deviceDevice flashing
Evidence + human approval → Device flashing · Supplier quotes

Claude agent

Clarifies requirements in conversation, plans, calls tools and explains the results in plain language.

Project graph

Binds requirements, parts, connections, firmware, mechanics and evidence into one revision and tracks dependencies.

MCP tool servers

Expose the parts catalog, rule checks, virtual boards, builds, CAD and sourcing through a standard interface. Heavy jobs run in isolated workers.

AGENT LOOP

Ask, run, check, then report.

  1. 01

    Understand

    Extract function, environment and constraints from your description.

  2. 02

    Ask

    Ask about missing details such as power, installation and quantity. Never fill them in by guessing.

  3. 03

    Plan

    Decide which tools to run in which order, and record the plan in the project graph.

  4. 04

    Call tools

    Run parts search, rule checks, builds, simulations and CAD jobs over MCP.

  5. 05

    Check results

    Read logs and check results; on failure, find the cause, fix and rerun.

  6. 06

    Explain & ask

    Explain what changed and what risk remains, and request approval for anything external.

MCP TOOLS Planned

The model gets a fixed set of tools.

No unrestricted shell or file-system access. Only purpose-built tools on an allowlist, and tools with external effects run only after human approval.

ToolWhat it doesAccess
catalogParts catalogCandidate search with datasheet source and revisionRead
rulesCircuit rulesLogic levels, pin conflicts, I²C addresses, supply pathsRead
vboardVirtual boardRun firmware on an emulator with sensor models and logsJob
buildFirmware buildPinned toolchain, isolated container, reproducible recordJob
cadParametric CADEnclosure generation, fit and clearance checks, drawingsJob
supplySourcing & quotesStock and lead times; sends approved packages onlyApproval
deviceDevice flashingLocal companion app; one-time approval per exact binaryApproval

WAYS IN

The same project, from the web or Claude Code.

Web workspace

The primary workspace for requirement conversations, design review and approvals.

Planned

Claude Code plugin

Use the same MCP tools and project record from Claude Code, running builds, simulations and checks right inside a firmware repository.

Planned

API

Exchange revisions and validation results with your issue tracker, CI and parts systems.

Planned
Concept drawing of a virtual ESP32 board connected to an SHT31 sensor model over I²CESP32virtualSDASCLSHT31model
  1. $ vboard.run esp32 + sht31.model
  2. boot ................ ok
  3. i2c 0x44 ............ ack
  4. inject: sensor power off
  5. read ................ timeout
  6. retry 1/3 ........... ack
  7. status: recovered
Concept drawing · Planned virtual board simulation

VIRTUAL HARDWARE Planned

Catch it virtually. Confirm it physically.

On a virtual board

  • Boot and initialisation order
  • I²C and SPI traffic
  • Injected faults such as sensor dropouts
  • Retry and timeout logic

On the bench

  • Real measurement accuracy
  • Power quality and noise
  • Heat and airflow
  • Enclosure fit and connector access

VALIDATION STATES

Only as done as the evidence says.

A successful compile does not make a circuit safe, and a correct render does not prove an enclosure fits. Each state needs its own evidence, a changed dependency reopens later approvals, and a bench result is a separate record that requires real measurements.

  1. draft

    Draft

    Claude’s proposal, with its sources attached.

  2. tool_checked

    Tool-checked

    Build, rule-check and simulation logs exist.

  3. engineer_reviewed

    Engineer-reviewed

    Reviewer and reasoning are recorded.

  4. approved

    Approved

    Explicit approval bound to exact artifact hashes.

  5. bench_tested

    Bench-tested

    A separate record with conditions, measurements and operator.

SECURITY & CONTROL

Decide first what the model may do.

  • Allowlisted tools

    Only purpose-built tools; no arbitrary shell, file or HTTP access.

  • Data is not permission

    Instructions found in datasheets, downloads or tool output never grant any permission.

  • Isolated execution

    Builds, simulations and CAD jobs run in resource-limited containers with outbound network denied by default.

  • Approvals bound to artifacts

    An approval is tied to exact artifact hashes and a recipient, and is single-use.

  • Keys stay server-side

    Model API keys never ship in browser bundles or downloadable files.

Official referencesModel Context Protocol Anthropic MCP connector Claude Code plugins

These references inform the design; they do not mean the integrations are already built. Mentioning a product does not imply partnership or endorsement.

START A PROJECT

Tell us what you want to build.

An early idea, a design in progress or a part you need to find. Tell us where you are, and we’ll discuss the work and next steps.