01
Product
Requirements, architecture, interfaces, risks, and decisions in one traceable system.
RequirementsArchitectureInterfacesRisk register
Foundation under active construction
Design the whole product.Not disconnected files.
Hardware Studio is an ambitious attempt to unify product requirements, mechanical design, electronics, PCB, firmware, validation, and manufacturing release around one connected product graph.
Not ready for production. The base engineering systems are incomplete. Current output must not be used for fabrication, certification, safety decisions, or production hardware.
product-graph / hardware-studio
linked
PRODUCT
Requirements
draft
MECHANICAL
Enclosure
Canonical product graph
One product. Every domain.
requirements → components → geometry → firmware → evidence → release
in progress
ELECTRONICS
PCB + Schematic
in progress
SOFTWARE
Firmware
foundation
VALIDATE
Evidence
future
RELEASE
Factory package
The long-term vision
An operating environment for complete physical products.
Today, product decisions are fragmented across CAD files, EDA projects, firmware repositories, spreadsheets, test documents, supplier portals, and release folders.
Hardware Studio is being designed around a different idea: every engineering representation should describe the same underlying product and remain connected as that product changes.
The target is broader than a single CAD or PCB tool: a unified layer inspired by the depth of Fusion, KiCad, Altium, Onshape, PlatformIO, and modern product lifecycle systems—built around one product graph, local-first control, and intent-driven operations.
Shared workbenches
Move through the product, not between disconnected tools.
Each workbench is intended to operate on the same durable product model. The current repository contains early foundations for these areas—not complete replacements for established engineering suites.
02
Mechanical
2D layouts, enclosure intent, assemblies, clearances, dimensions, and future parametric geometry.
Sketch & layoutEnclosureAssembly3D checks
03
Electronics
Component definitions, schematic connectivity, board layout, rules, and manufacturing drafts.
ComponentsSchematicPCBDRC / ERC
04
Firmware
Hardware mappings, state machines, source files, builds, upload workflows, and device logs.
Source workspaceState machinesBuildsHardware map
05
Validate
Evidence-backed EVT, DVT, PVT, factory QA, retests, and requirement coverage.
Test plansMeasurementsEvidenceRetest history
06
Release
Revisions, branches, approvals, blueprints, manufacturing packages, and immutable releases.
VersionsBranchesBlueprintsFactory handoff
Design principles
Built around engineering state, not screenshots.
The central architecture is intended to make every important change explicit, connected, reviewable, and reversible.
One product graph
A component should connect its requirement, symbol, pins, footprint, package, firmware mapping, tests, BOM, and release state.
Local-first direction
Projects should remain usable locally, with machine actions mediated by an explicit approval-based bridge.
Intent-driven workflows
Engineering operations should be expressed as meaningful commands—not fragile mouse automation or disconnected form edits.
Reversible by default
Changes should be versioned, reviewable, undoable, traceable, and safe to apply through both the UI and MCP tools.
Target change propagation
Replace one component and understand the effects across requirements, pins, schematic nets, PCB footprint, 3D package, clearances, firmware mappings, BOM, tests, and release outputs.
Component
Schematic
PCB
3D
Firmware
Validation
Release
Current development status
The vision is large. The foundation is still early.
This repository is public so the system can be built in the open. It should be evaluated as an active engineering experiment—not as finished CAD, EDA, PLM, firmware, or manufacturing software.
Foundations in the repository
Real early work, still evolving
A multi-workbench product workspace and canonical project model
Early product, mechanical, schematic, PCB, firmware, validation, and release surfaces
A WebGL product view and initial geometry and collision foundations
Local PlatformIO bridge foundations with explicit approval concepts
MCP server foundations for future direct engineering operations
Blueprint, manufacturing-draft, readiness, and project export foundations
Not ready yet
Known limitations—not hidden behind release language
The base engineering engines are not complete or fully integrated
PCB routing, connectivity, DRC, and manufacturing isolation need substantial work
Mechanical tools are not a production parametric CAD system
MCP does not yet safely control the complete live project workflow
Revision, release, validation, and firmware workflows are still under construction
Generated fabrication files must not be treated as production-ready outputs
Building in public
Follow the attempt to connect the entire hardware lifecycle.
Explore the development workspace, inspect the architecture, challenge the assumptions, and help turn the early foundations into a truthful engineering platform.