What is the problem your project solves?

Hardware is the last industry where the tooling actively fights you

Every physical product starts as a schematic — the electrical blueprint of a circuit board. Drawing one is slow, expert-only work in CAD tools whose interaction model has barely moved in twenty years. A competent engineer spends days placing parts, wiring nets, checking rules and building a bill of materials before a single board is fabricated. That cost is why hardware iterates in months while software iterates in hours.

The obvious answer is "let AI draft the circuit." The reason nobody has shipped it is that a schematic is not text, and it is not a picture — it is a graph with electrical meaning. A wire that looks connected but isn't produces a board that fails silently in fabrication. An LLM that free-hands CAD geometry produces something that renders beautifully and is electrically wrong. Nothing about a plausible-looking schematic tells you it is correct.

The specific wall we hit

We built Tokito as an AI-native desktop EDA studio: you describe a board in chat, and it produces a real, editable schematic you own.

Then we hit the constraint that caps the entire category. An AI can only design with parts it can actually draw. Symbol libraries are community-maintained and cover roughly 22,700 parts. The real world has millions of manufacturer part numbers. So the agent constantly reasons about a component that has no symbol — and every tool in this space silently substitutes the nearest match.

We watched it happen: a request for a 16-pin USB-C receptacle resolved to a 2-pin generic. The schematic looked fine. The netlist was wrong. Power and the CC pins collapsed onto ground. That is a bricked board and a lost fabrication run, and the user gets no warning at all.

Every pinout, every package drawing, every pin-function table needed to fix this already exists — in the manufacturer's PDF datasheet. But it exists as pictures. Text search misses them entirely; feeding a 400-page PDF to a model does not scale and cannot be audited.

So the problem is: the world's component knowledge is locked in datasheet figures, and no design tool can read it. Unlock it and AI hardware design stops being a demo, because the agent can finally work with any real part — and every pin it draws can be traced back to the manufacturer's own document.

How you are solving it?

Prior-work disclosure (read this first)

Tokito, the desktop studio, existed before today — it is our ongoing product and is the project being submitted. What we built during this hackathon is DS-ViRe and the complete datasheet-to-symbol pipeline: the capability that lets Tokito generate a real schematic symbol for a part that exists in no library. That work landed today across five repositories and is verifiable in public commit history (2026-08-08). Nothing in it was written before today, and none of it has been submitted to another hackathon.

What Tokito is, end to end

A native desktop studio (Rust + egui) that takes a board from a sentence to fabrication-ready outputs:

1. Chat — you describe the board. Claude produces an engineering plan, then a typed, reviewable proposal of schematic and BOM edits. Every AI change is a diff you accept or reject per-operation. Nothing touches the canvas unapproved.
2. Schematic capture — pin-anchored wiring, orthogonal auto-routing, multi-sheet hierarchies with typed ports, real bus semantics (vectors, rippers, member-wise nets), automatic junction inference, full undo/redo. Connectivity is derived from stable anchors, never from "these lines look like they touch" — so a schematic cannot be quietly wrong.
3. Parts — symbols stream from our own hosted MCP catalog and get embedded into the design, so it renders identically forever even if the catalog changes.
4. ERC — live and on-demand electrical rule checks with a pin-conflict matrix (output driving output, undriven input, etc).
5. BOM — synced from the schematic, AI-editable, enriched with distributor procurement hints and web-grounded pricing.
6. Outputs — KiCad .kicad_sch, netlists, SVG/PDF plots, BOM CSV, MCAD handoff JSON.
7. Cloud + mobile — accounts, plans and metering behind our own LLM gateway, plus a phone Companion that lets you approve AI proposals away from the desk.

What we built today

The governing rule: models interpret evidence, deterministic code constructs symbols. An LLM emitting CAD geometry is unshippable — unreproducible and unauditable. So we split the problem in half.

DS-ViRe (new, open source, Apache-2.0) — figure-level retrieval over datasheets. It scores and verifies figure/table regions in a PDF and emits typed evidence: page number, normalized bounding box, cropped image, content hash, under a frozen dsvire.symbol-evidence.v1 contract. It fails closed — it never guesses manufacturer, MPN or package, and abstains unless it can independently verify both a pinout and a pin-function table. Bounded to 64 MiB / 2000 pages.

Then the pipeline:

• Extract — Claude reads the verified crops twice, independently (pinout vs pin-description table), constrained by a strict JSON schema. A reconciliation pass compares pin counts, numbers, names, aliases, NC/reserved pins and exposed pads. Conflicts stay explicit; below threshold it abstains rather than inventing a pin.
• Compile — a deterministic Rust compiler turns the reconciled SymbolSpec into canonical geometry: power in on top, ground and outputs on the bottom, inputs left, outputs right, body sized from pin count and label widths. Same spec in produces a byte-identical symbol file out — enforced by a golden test.
• Publish — authenticated ingestion as an immutable versioned revision, idempotent on (source hash, extractor version, compiler version), so the same datasheet never creates duplicate catalog entries.
• Resolve — two new MCP tools, resolve_by_mpn and get_symbol_provenance.
• Place — the desktop resolves by part number, places the symbol, and embeds that exact revision into the document.

The result: every generated pin traces back to a cropped rectangle on a numbered page of the manufacturer's own PDF. You can select a placed part and ask where it came from, and get the evidence — not a confidence score.

We proved it on a real 41-page Texas Instruments TPS5430 datasheet: both required evidence classes verified on page 3, crops hash-pinned, committed as a reproducible example.

We shipped it by freezing the shared contracts first, then building the compiler, MCP resolver, ingestion service and desktop wiring in parallel across five repos.

What's next

PCB layout (placement, copper, planes, interactive and batch routing), fab DRC/DFM with failures explained in plain language, footprint and 3D model linkage per part, assembly variants, background agents for routing passes and BOM scrubbing, and cost/lead-time-aware part suggestions under user policies.

How Did You Use Claude?

Claude is the intelligence layer of the product, not a feature bolted onto it. Tokito does not work without it.

1. Claude Opus 5 is the design agent

The entire chat-to-schematic path runs on claude-opus-5, routed through our own gateway at api.tokito.dev (we removed bring-your-own-key today — users never hold provider credentials).

It runs as a planner/editor split, which we adopted because one model splitting attention between reasoning and emitting byte-exact JSON measurably underperforms two specialised passes:

• a planner agent with free-text reasoning, read-only tools and web search, which produces the engineering plan the user sees;
• editor agents that emit only typed operations through propose_* tools and end with a commit_batch.

Every mutating tool call is validated at invocation time against a projected document — so a conflict surfaces as a fixable tool error the model self-corrects from, rather than a broken schematic. The output is a typed batch the user approves per-operation.

2. Claude Sonnet 4.6 is the datasheet extractor (built today)

The new pipeline uses claude-sonnet-4-6 to read verified datasheet crops into a strict SymbolSpec schema. Two independent extractions per part — one from the pinout figure, one from the pin-description table — then a reconciliation pass that compares them. Temperature 0, deny_unknown_fields, reprompt once on schema failure, then abstain. Claude is deliberately confined to the one job it is genuinely better at than code — reading a picture of a pinout — and is never allowed to draw the geometry.

3. MCP as the integration fabric

We run our own MCP server (mcp.tokito.dev, streamable HTTP JSON-RPC) as the parts catalog: search_symbols, get_symbol, find_compatible, part_offer_query, and today's resolve_by_mpn and get_symbol_provenance. The desktop is the MCP client. It is also usable from Claude Desktop or any MCP client directly.

Security was designed in: every tool result is wrapped in an <untrusted> envelope and size-capped before it reaches the model, MCP tool names are namespaced so they cannot shadow built-ins, TLS is mandatory, and bearer tokens live in the OS keychain.

4. Claude Code built it

The hackathon work itself was written with Claude Code across five repositories in parallel — including adversarial review passes that caught a per-frame blocking call and a data-loss regression before they shipped.

This submission was drafted and filed through the Devfolio MCP server.

What is the deployed URL for this project?

https://mcp.tokito.dev/mcp