Systems Architect — AI → Capital

The wall

Neither the importer nor the plugin API could create the architecture

The tedious part of Systems Architect is exactly the part that matters: creating components and connecting pathways. We tried every sanctioned automated route into the platform layer, and each one hit a wall — confirmed three ways:

File → Import Project silently drops "bare" clusters — a component with no graphics is discarded as an orphan, so an import brought in functions, carriers and signals but zero components. With pathway topology added it fails outright (unable to find graphical node); with pathway graphics added it fails differently (parent diagram not loaded).

The plugin API is attribute-only. Capital's custom-plugin API (IXWriteableObject.getAttributeSetter()) can modify attributes of objects that already exist — it exposes no create-cluster / create-interconnect call. The vendor docs confirm it.

That is precisely why the components in a real hand-built project were placed by hand. The interface didn't need to get easier to click — the work needed to route around it entirely.

The seam

One contract, two halves — only one needs an AI

Everything splits along a sharp line, with a neutral exchange-format bundle as the contract between them. The left half (intent → bundle) is where design judgement lives. The right half (bundle → Capital) is pure, deterministic code — it can't hallucinate a wrong identifier.

[ design intent / requirements ] ← left half: needs an AI │ ▼ natural language → structured JSON ┌───────────────────┐ │ BUNDLE │ the exchange-format contract (stable, versioned) └───────────────────┘ │ ▼ deterministic, pure code — done & proven [ Capital XML → import → full platform ] ← right half: no AI anywhere

Because the bundle is the seam, the AI is a pluggable front-end. The deterministic generator is the durable IP; the model behind the bundle is swappable.

The breakthrough

Components survive import only with their graphics — so we synthesize them

The one thing the importer demands is that every cluster carry a full <graphicalcluster> — a box rectangle, a name label, an interface stub per port, and a colour dictionary — placed on a real platform diagram. Give it that, and the component is retained and rendered. So the generator synthesizes that graphics layer per component from the bundle, and each connection becomes a routed pathway (topology + graphics).

The detail that took five clean numbered test imports to nail: Capital's identifiers follow a strict grammar — UID<6 hex>-<11 hex>-<32 hex>. Any generated id that breaks it dies at parse time (Invalid UID format). Once the ids matched, all 13 components and 21 pathways imported and rendered.

The result is the QX-250 platform — batteries, OR-ing controller, 4-in-1 ESC, four motors, dual flight controllers, receiver, VTX, buzzer — drawn as boxes and wired with green pathways, generated entirely from the bundle. No canvas touched.

The whole model

Not just boxes and wires — the full data model

Every layer of the bundle is materialized and lands in the right place in the tool.

Layer	From the bundle	Where it shows in Capital
Components (boxes)	components	Platform diagram — a rendered box per part, one interface stub per port
Pathways (wires)	connections	Platform diagram — routed green interconnects
Functions	functions	A Functional Architecture design (functions + funcconds)
Carriers / networks	networks	Carriers panel
Signals	signals	Signals panel
Allocations	allocations	Function → component links (functional sync)

Every reference chain is validated to zero dangling before import. A pathway's ports must belong to the right components; a carrier routes to a real signal; a signal cross-references a real funccond; an allocation resolves to a real function. The generator checks all of it up front — so the import doesn't fail halfway.

The digital thread · flow-down

Function → platform → wired schematic, one continuous thread

Materializing the platform isn't the finish line. From one AI bundle we now emit three linked designs in a single Capital project — a Functional Architecture (functions + signal flows), the platform (components + pathways, allocated to those functions), and a logical design (devices with real pins + conductors). Every schematic device carries Component_Base_ID = its platform component — Capital's native flow-down link — so the thread is traceable end to end: function → platform component → schematic device.

Functional Architecture in Capital — 15 functions with signal flows — **Functional Architecture.** 15 functions — Store Electrical Energy, Convert to Rotation, Stabilize & Control, Drive Motor, Distribute Power, Receive Command Link… — with the signal flows between them, generated in-tool.

Detailed electrical schematic in Capital — devices with pins and routed wires — **Detailed Electrical Schematic.** Every device with real pins; routed wires labelled by net — DShot ×4, CRSF, VBAT/current sense, BEC 5V/9V, and the twelve 3-phase motor lines — flowed down from the platform and drawn by Capital's Generate Diagrams.

Why this is the real schematic, not the synthesis output: the platform's Generate → synthesize logical designs places a device per component but draws no wires — even the hand-built reference schematic has none. The wired schematic comes from a logic design carrying device pins + conductors, then right-click → Generate Diagrams, which auto-places and auto-routes it. One bundle produces all three linked designs; one Generate Diagrams pass draws the schematic.

Wired in-tool 13 devices · 56 pins · 21 nets one project · three linked designs

Generalized · productionized

Any design, one tool call

The generator is design-agnostic. It fills a content-free scaffold — no dependency on any exported copy of the target design — with whatever a bundle contains. To prove it isn't secretly tuned to the quadcopter, we ran a net-new, unrelated design through it:

AMR-100 delivery rover — a ground robot: battery, BMS, dual BLDC controller, two hub motors, a navigation computer (six interfaces), 2D LiDAR, GNSS, stereo camera and an LTE modem — 10 components, 12 pathways, 3 networks, 7 functions. Authored as a bundle, materialized into Capital in one shot, every box and wire correct. Nothing quadcopter about it.

And it's a first-class capability, not a script: a single call — materialize_platform(bundle, project_name) — validates the design and writes an importable Capital project. The tedious slog that opened this page is now a one-liner.

Toward autonomy

A pluggable authoring loop — and an offline path

With the right half done and deterministic, the only open piece is the left half: brief → valid bundle. We stood up a model-agnostic authoring loop around it. It asks a backend for a bundle, runs the referential validator, and on failure feeds the exact errors back for repair — iterating until the bundle is valid.

[ design brief ] │ author_bundle(brief, backend) ▼ LLMBackend.complete(system, user, schema) ← schema-constrained decode │ ▼ validate(bundle) ──fail──► repair prompt ──┐ (loop, ≤ N) │ ok │◄─┘ ▼ materialize → importable Capital project

Two things make even a modest local model reliable here: schema-constrained decoding means it can't emit malformed JSON, and the validate-repair loop guarantees referential integrity. Swap the backend — cloud today, a small bundled model later for air-gapped, IP-sensitive work — and nothing else changes.

Next Library-part grounding. The highest-value add is a retrieval step that grounds component choices in the real Capital catalog — so the model picks an actual "4-in-1 ESC 45 A" with electrical characteristics, not a generic box. That's what carries the design past the picture and into the calculation.

One domain of three

Electrical first — software and electronics next

What's materialized here is the electrical architecture. The method is domain-independent: an AI-authored bundle rendered into the domain's authoring tool with zero manual placement. The same pattern extends to the other two architectural domains, which are next on the roadmap. (The QX-250's own flight-control software and FPGA gateware — the compute content those domains produce — is now documented on the Flight Computer page.)

Electrical · E/E

Done — proven in-tool. Components, pathways, functions, carriers, signals and allocations materialized in Capital Systems Architect from an AI-authored bundle.

Software

Next. The software architecture — components, interfaces and message flows — into its authoring tool through the same bundle contract.

Electronics

Next. The electronics architecture — boards, parts and nets — materialized the same way.