The AI assistant
A natural-language assistant that works over your design's structured circuit state — components, pins, routes, hierarchy and physical constraints — so editing and exploration stay grounded in the real layout.
The AI assistant lives in the workspace's right panel, alongside the properties and parameter-sweep views. You can ask it to add components, route connections, restructure a subcircuit or check how a change affects loss, in plain language. Crucially, it does not operate on a transcript of your conversation — it operates on the design itself.
This distinction is the whole point. The assistant is not a chatbot bolted onto a canvas. It reads and writes the same structured circuit state the rest of the workspace uses, so its actions are real edits to your layout — checkable against geometry and physics, not free-text suggestions you then have to translate by hand.
Grounded in structured circuit state
Everything in a Qfactr design is represented explicitly: components with real footprints and pin positions in micrometers, waveguide routes as concrete S-bend and Manhattan geometry, hierarchical blocks with external pins, and the physical constraints that connect them. This is the same representation layer described in Core concepts.
Because the assistant reads and edits that state directly, a request like "place a ring resonator" becomes an actual component at actual coordinates, with pins that render red until they are connected and green once they are. There is no ambiguous middle layer of prose to interpret — the instruction lands on the model as a structured change.
- Components carry physical pin positions and S-matrix (S-parameter) data, so the assistant manipulates real devices, not placeholders.
- Routes are real geometry between pins; when the assistant connects two pins it produces an S-bend or Manhattan waveguide path, exactly as routing by hand would.
- Hierarchy and constraints are part of the state too, so edits respect block boundaries, external pins and the physical feasibility of where things can go.
Editing in natural language
You describe the change you want; the assistant makes it on the design. The examples below are illustrative — they show the kind of request the assistant handles and how it maps onto concrete layout actions.
Add a ring filter on the lower arm at 1550 nm.
Route the output of the phase shifter to the combiner and report loss.
Group the splitter and its two arms into a reusable block with external pins.Take the first prompt concretely. Asked to "Add a ring filter on the lower arm at 1550 nm," the assistant places a ring resonator (r = 10 µm) on PS2.out, routes it to CMB.in2, and re-checks loss for the affected path. The result is a finished edit you can inspect, adjust or undo — not a description of an edit.
Why grounding matters
A language model that only saw a picture or a chat history could confidently propose a layout that is physically impossible to route, or quote a loss figure it has no way to verify. Working over structured state closes that gap.
| Property | What it means for you |
|---|---|
| Edits are real | Every assistant action changes the actual circuit model, so what you see on the canvas is what was done — no manual transcription. |
| Edits respect physics | Placements and routes honor real pin positions, footprints and constraints, so the assistant cannot hand you an unroutable arrangement. |
| Results are checkable | Transmission and loss derive from the actual path geometry, so a claimed improvement is something you can verify, not take on faith. |
| Hierarchy-aware | Because blocks and external pins are part of the state, edits compose cleanly into larger systems instead of breaking abstraction boundaries. |
This is what "physics-informed" means at the assistant level: the model's actions are constrained by the same physical reality the workspace enforces everywhere else. It can be wrong, but it cannot be wrong in a way that silently corrupts your layout — its edits are visible, measurable and reversible.
Toward physics-informed generation
Today the assistant is a grounded editor: you direct it, and it carries out scoped changes on the structured design. That same grounding is the foundation for a larger direction — moving from per-instruction edits to proposing whole arrangements that are routing-aware from the start.