zerowithdot — AI for CAD, manufacturing and design

Text-to-Diagram for AI Systems: Designing a DSL an LLM Gets Right

Oleg Żero — Thu, 22 Oct 2026 00:00:00 GMT

Introduction

I have worked on sensor design, e-commerce, airlines, medicine and CAD software, in several countries. The domains could not be more different, yet one problem kept coming back: people do not understand each other. Not because they are careless. Everybody simply looks at the same system from a different side. Legal sees data, the CEO sees cost, DevOps sees uptime.

Take one sentence from a kick-off meeting:

“We are building an agent to fix invoices.”

What does fix mean? Who uses it? Does it see customer data? Where does it run, and who owns it? Nobody asks, because everybody thinks they know. A year later the project has five different answers to each of those questions.

Large language models make this more urgent, not less. Anybody can now describe a system in a paragraph, and a model will happily draw it. The open question is whether that drawing is the architecture, or just an architecture.

Gnomon is my attempt at an answer. It is a small language, gnomocode, and a compiler that checks every statement against an ontology. A language model translates what people say into gnomocode; the compiler decides what is allowed; and the result can be drawn, queried and read back as prose. The compiler is written in Python, on top of Lark, rdflib and pySHACL.

I presented it as a keynote at DevAI by Data Science Summit in Warsaw on 20 October 2026, under the title of this article. This is the written version of that talk: why I built Gnomon, how it works, and what the measurements say about it.

Motivation

Draw the invoice agent and you are done in five seconds: invoices go in, an agent does something, fixed invoices come out. The box is easy. The questions around it are the architecture: who owns the data, where the model runs, whether personal data is involved, who reviews the edge cases. That gap between words and a diagram somebody can be held to is what I wanted to close.

It has to work in both directions. Forward, from a conversation to a model that a developer, or an agent, can build from. Backward, from existing code and diagrams to text that people can read. The forward direction is the harder one, and it is what this article is mostly about.

Before writing any code, I wrote down what a language sitting in the middle has to offer:

unambiguous terms;
native words for what we build today: language models, memory, tools, MCP [15], A2A [16];
easy to read and write, by people as well as by models;
one model, many views, one per reader;
versions, diffs and references;
a way to say “I am not sure”.

The last one turned out to matter more than I expected.

Approach

I did not start with a language. I started with the cheapest option and let it fail.

Just ask the model. “Draw an architecture for an agent that fixes invoices.” The answer is fluent, plausible and different every time. It invents words, gives no errors and no line numbers, and there is nothing to diff. When it is wrong, nothing tells you where.

Objects. Pydantic [12] classes, filled in by the model through structured output. Validation is real and every provider supports it. But an architecture is a graph, not a tree. A missing fact is either an error or a null, and a conversation with a client is mostly missing facts. Two statements cannot be merged, nor can they contradict each other, and every new term means a new class and a new release. The vocabulary ends up cemented in code.

Existing notations. UML, BPMN, C4 [10], ArchiMate and SysML v2 [11] are standards, and people understand them. They come with fixed symbols and a fixed depth, none of them has a “maybe”, and only some of them check whether a diagram makes sense, as opposed to whether it is drawn correctly.

A language of my own, with a compiler. This is the one that stayed. The idea is old and boring, which is how I like my ideas: let the model talk, let the compiler decide.

Fig. 1 — The language model translates; it never gets the last word. Compiler errors go back to it for up to three rounds of repair.

The translator, text2gnc, turns natural language into gnomocode. The compiler, which is plain rules with no model inside, checks each statement and builds a graph. When it finds errors, it sends them back to the translator with line numbers and hints. Everything else, diagrams for different audiences, recommendations, even prose, is drawn from the graph.

Two consequences matter to me. The script is the source of truth, not a single call to a model: the same script always compiles to the same graph. And errors are located and readable, so a person and a model can both act on them.

The ontology is the key

Before designing a single keyword, I went looking for who had already described this world. Plenty of people had. A taxonomy says what is a kind of what: a language model is a machine learning model. An ontology goes further and adds relations and rules: an agent uses a model, a model runs on an environment, and a dataset cannot run on anything at all. Such vocabularies have been written in RDF [1] for years, and some are widely used: SKOS [3] for taxonomies, PROV-O [2] for provenance, DCAT [4] for data catalogues, DPV [7] for privacy, QUDT [8] for units and schema.org [9] for the web. OWL [6] defines the classes and SHACL [5] checks the graphs.

So the rule became: take terms, relations, types and hierarchy from what exists, and add the minimum. The result is a kernel of 57 terms and twelve modules (systems, deployment, integration, data, ML, agents, processes, operations, security, legal, cost and service levels) that a script imports only when it needs them. From day one there was also a licence rule: nothing copyleft goes in, so that the whole thing can later be distributed freely and commercially.

Fig. 2 — Many sources in, one small vocabulary out.

Why call the ontology the key? Because every other part of Gnomon is generated from it or checked against it. Take a single word that a script writes, runs_on. In the ontology it has three layers: a lexicon entry that gives the word and its inverse reading, a property with a definition, and a shape that says what may stand on either side of it.

ontology (abridged)

gnlex:runs-on a skos:Concept ; skos:prefLabel "runs on"@en ;
    gn:inverseReading "hosts"@en ;
    gn:denotes gn:runsOn .

gn:runsOn a owl:ObjectProperty ;
    rdfs:label "runs on"@en ;
    skos:definition "The subject executes in or on the object."@en ;
    gn:acyclic true .

gnsh:runsOn-subject a sh:NodeShape ;
    sh:targetSubjectsOf gn:runsOn ;
    sh:or ( [ sh:class gn:System ]
            [ sh:class gn:Model ]
            [ sh:class gn:Activity ] ) ;
    sh:message "only a system, a model or an activity can run on something" ;
    gn:diagnosticCode "type/signature" .

That one definition feeds the whole tool chain. The lexicon decides which words a script may use, and therefore which words a model may generate. The shape becomes the compiler’s error message, word for word. The labels become the English sentences in which a script is read back. The concerns attached to each term decide which audience sees it on a diagram. And because Gnomon’s classes are declared as subclasses of the borrowed ones (a gn:Dataset is also a dcat:Dataset and a prov:Entity), the compiled graph is readable by tools that have never heard of Gnomon.

The language

Why not let the model write RDF directly and validate it with SHACL? RDF is precise, but it is not something I want to read in a review. Here is the invoice agent as gnomocode, 23 lines:

fix-invoices.gnc

---
gnomon: 0.2.2
as_of: 2026-10
state: TARGET
import: systems, deployment, ml, agent, process
---

finance_team: Team
erp: Application
    owned_by = finance_team
    runs_on = CloudEnvironment() ~0.5        # "in the cloud, I think"
invoices: Dataset
    stored_in = erp
    contains_personal_data = true

invoice_agent: AIAgent
    uses = LanguageModel()
    classifies(invoices, frequency = 200/DAY)

fixing: Process = check >> ("amount > 10k" => review | post)
review.performer = finance_team
invoices -> check -> checked_invoices
checked_invoices: Dataset

It compiles to 76 lines of RDF. Three forms carry almost everything: name: Type declares an element, property = value states a fact about it, and action(object) says what it does. Flows connect steps (>>) and data (->). The notation borrows from places people already know: front matter from Markdown, indented blocks and assignments from Python, arrows from graph query languages. Even the case of a word tells you its kind: Type, property, CONSTANT.

The front matter pins the release of the ontology the script was written against, says whether it describes the current state or a target, and imports only the modules the text needs. An old script therefore compiles against the same release, or gets migrated to a new one on purpose.

Look at the ~0.5 on the runs_on line. It means “I think so, but I am only half sure”, and it is part of the language. Confidence has a few reference points: 1 is confirmed in a system or a document, 0.8 is stated by someone who does the work, 0.5 is second-hand, 0.2 is a guess. Below 0.7 a fact is not an error, but it is reported as a finding. In the graph it becomes an annotated statement, so you can query for everything that still needs confirming:

fix-invoices.trig (excerpt)

    rdf:subject :erp ;
    rdf:predicate gn:runsOn ;
    rdf:object minted:cloud-environment-0 ;
    gn:confidence 0.5 .

The syntax at a glance

The invoice script uses only part of the language. Here is most of the rest in one script that compiles, with a comment on what each line does:

support.gnc

---
gnomon: 0.2.2
as_of: 2026-10
state: CURRENT
import: systems, deployment, ml, agent, process
---

sales_team: Team                             # declares an element
support_team: Team
cloud_account: CloudEnvironment
tickets: Dataset
product_catalogue: Dataset

crm: Application
    runs_on = cloud_account ~0.8             # a fact and its confidence
    owned_by = sales_team                    # inverse reading of owns
    search_tool: Tool                        # a part of crm

support_agent: AIAgent
    uses = search_tool, LanguageModel()      # two values, one unnamed
    reads(product_catalogue)                 # an action: a new activity
    summarises(tickets, frequency = 50/DAY)  # with its own properties

LanguageModel[0] is gpt_4o                   # two names, one element
gpt_4o: LanguageModel
    name = "GPT-4o"

triage: Process = sort >> ("urgent" => call_back | answer)
sort: Classification
    performer = support_agent
    duration = 3 MIN                         # a quantity with a unit
call_back.performer = support_team
tickets -> sort -> sorted_tickets            # data flows through a step
sorted_tickets: Dataset

A few things are worth noticing. A declaration inside a block makes the element a part of its parent, so nesting is how you say “consists of”. An action such as reads(product_catalogue) does not need a name: the compiler creates an unnamed activity of the right kind, with the agent as its performer and the catalogue as its input, and numbers it so that later lines can refer to it. And | in a flow means exactly one branch is taken, while & means all of them are.

A compiler in Python, built on Lark

The compiler is plain Python 3.14, managed with uv. Parsing is done by Lark [20], a parsing toolkit for Python under the MIT licence. The grammar is not written by hand: gnomon grammar generates it from the kernel of the ontology, with one slot per class of words. A new module adds words, never grammar rules. An excerpt:

gnomocode.lark (excerpt)

declaration: NAME ":" type_ref confidence? assigned_flow? _NEWLINE block?
block: _INDENT member+ _DEDENT
own_property: NAME "=" values _NEWLINE
own_action: NAME "(" [arguments] ")" confidence? _NEWLINE
step_flow: step_term (">>" step_term)+
data_flow: reference ("->" reference)+
group: "(" branch ("|" branch)* ")" -> one_of
     | "(" branch ("&" branch)+ ")" -> all_of
confidence: "~" NUMBER

TYPE: /[A-Z][A-Z0-9]*[a-z][A-Za-z0-9]*/
CONST: /[A-Z][A-Z0-9_]*(?![A-Za-z0-9_])/
NAME: /[^\W\dA-Z]\w*/

Indentation works exactly as in Python, because Lark ships a post-lexer for it. Subclass Indenter, name the tokens, and the LALR parser receives _INDENT and _DEDENT like any other token:

syntax.py (abridged)

from lark import Lark
from lark.indenter import Indenter


class GnomocodeIndenter(Indenter):
    NL_type = "_NEWLINE"
    OPEN_PAREN_types = ["LPAR", "LSQB"]
    CLOSE_PAREN_types = ["RPAR", "RSQB"]
    INDENT_type = "_INDENT"
    DEDENT_type = "_DEDENT"
    tab_len = 4


parser = Lark(
    grammar,
    parser="lalr",
    postlex=GnomocodeIndenter(),
    propagate_positions=True,
)

LALR keeps parsing fast and deterministic, which matters when the studio rechecks the script after every pause in typing. propagate_positions keeps the line and column of every node, so each diagnostic can point at the exact span of the source. A Lark Transformer turns the parse tree into statements; rdflib [21] builds the graph from them; the rules of the release derive further facts; and pySHACL [22] validates the result against the shapes of the ontology. Every violation is mapped back to the line it came from.

What the compiler says

Mistype a word and the compiler answers like a linter, with the line, a caret and a suggestion taken from the lexicon:

typos.gnc

---
gnomon: 0.2.2
as_of: 2026-10
state: TARGET
import: systems, ml, agent
---

finance_team: Team
erp: Application
invoices: Dataset
    stored_at = erp
reviewer: HumanRol

gnomon check typos.gnc

typos.gnc:11:5: error type/vocabulary: unknown property `stored_at`
   |
11 |     stored_at = erp
   |     ^^^^^^^^^
   = hint: did you mean `stored_in` or `stores`?
typos.gnc:12:11: error type/vocabulary: unknown type `HumanRol`
   |
12 | reviewer: HumanRol
   |           ^^^^^^^^
   = hint: did you mean `HumanRole` or `HumanReview`?
typos.gnc: blocked (2 errors, 0 warnings, 0 infos)

Syntax errors look the same. Indent a block by three spaces instead of four and you get:

gnomon check

syntax.gnc:9:1: error syntax/indentation: an indentation of 3 spaces
  |
9 |    owned_by = finance_team
  | ^^^
  = hint: indent with four spaces per level

A script that compiles still gets its findings. For support.gnc above the verdict is compiles (0 errors, 12 warnings, 18 infos), starting with lines such as:

gnomon check support.gnc

support.gnc:11:1: warning finding/missing-owner: no owner: `tickets`
support.gnc:11:1: warning finding/missing-personal-data-marker: personal data not marked: `tickets`
support.gnc:19:1: warning finding/missing-owner: no owner: `support_agent`
support.gnc:28:52: warning finding/missing-performer: no performer: `answer`
support.gnc:19:1: info finding/missing-runs-on: where it runs is not stated: `support_agent`
support.gnc: compiles (0 errors, 12 warnings, 18 infos)

With --format json the same diagnostics come as records. This is what the translator receives in the repair loop:

gnomon check --format json typos.gnc (first record)

{
  "file": "typos.gnc",
  "line": 11,
  "column": 5,
  "end_line": 11,
  "end_column": 14,
  "severity": "error",
  "code": "type/vocabulary",
  "message": "unknown property `stored_at`",
  "hint": "did you mean `stored_in` or `stores`?",
  "rules": []
}

From a sentence to a line to a picture

Each line of the script answers something somebody said. Suppose the kick-off meeting went on a few minutes longer. This is how its sentences map onto the script, and how the compiler reads each line back, in its own controlled English (gnomon explain, no model involved):

What was said	Gnomocode	What the compiler reads back
”We are building…”	`state: TARGET`	This description is of the target state, as of 2026-10.
”…an agent…”	`invoice_agent: AIAgent`	Invoice agent is an AI agent.
”…that uses an LLM…”	`uses = LanguageModel()`	Invoice agent uses the unnamed language model 0.
”About 200 invoices a day.”	`classifies(invoices, frequency = 200/DAY)`	Invoice agent classifies invoices (classification 0). The frequency of the unnamed classification 0 is 200 per day.
”Invoices hold customer data.”	`contains_personal_data = true`	Invoices contains personal data.
”The ERP is in the cloud, I think.”	`runs_on = CloudEnvironment() ~0.5`	Possibly (confidence 0.5): erp runs on the unnamed cloud environment 0.
”Anything over 10k goes to review.”	`check >> ("amount > 10k" => review \| post)`	After check comes exactly one of these: review when “amount > 10k”; post.
”Finance does the review.”	`review.performer = finance_team`	The performer of review is finance team.

The read-back matters more than it looks. A person who will never learn gnomocode can still check, sentence by sentence, whether the script says what they meant. And a language model that turns the script into prose works from these sentences, so it has nothing to guess.

The same lines are also a picture. The process line becomes the process view, with the branch, its condition and the performer of the review:

Fig. 3 — One line of gnomocode, check >> ("amount > 10k" => review | post), drawn as the process view in Gnomon Studio.

Vague is valid, contradictions are not

This is the principle I am most attached to. A real conversation is full of gaps and guesses. A language that rejects every incomplete statement will never be used; a language that accepts everything is useless. So the compiler draws a different line: it accepts vagueness and rejects contradictions.

invoice_agent: AIAgent is valid. It is vague, but it is true. The statements below are not, and the compiler says why, with the line and the reason taken straight from the ontology:

invalid.gnc

---
gnomon: 0.2.2
as_of: 2026-10
state: CURRENT
import: systems, deployment, process
---

finance_team: Team
erp: Application
invoices: Dataset
    runs_on = erp
check: Activity
    automation_level = MANUAL
    automation_level = AUTOMATED
erp: Dataset
module_a: System
    part_of = module_b
module_b: System
    part_of = module_a

gnomon check invalid.gnc

invalid.gnc:9:1: error inconsistency/disjoint-kinds: disjoint kinds: `erp`
invalid.gnc:11:15: error type/signature: only a system, a model or an activity can run on something: `invoices`
invalid.gnc:14:24: error inconsistency/single-value: two values of a single-valued term: `check`
invalid.gnc:17:15: error inconsistency/cycle: partOf cycle: `module_a`
invalid.gnc:19:15: error inconsistency/cycle: partOf cycle: `module_b`
invalid.gnc: blocked (5 errors, 8 warnings, 5 infos)

The compiler talks back

Diagnostics have three levels. Errors block; warnings and infos pass. The useful side effect is that the missing information turns into questions. The invoice script compiles, with 11 warnings and 15 infos, and those read like the agenda for the next meeting:

The compiler says	The question it is asking
`no owner: invoices`	Who owns the invoices?
`no tool: invoice_agent`	What can the agent actually do?
`where it runs is not stated: invoice_agent`	Where is it hosted?
`personal data not marked: checked_invoices`	Does the output fall under GDPR too?
`a fact below the confidence threshold: erp runs on`	Is the ERP really in the cloud?

These are the questions nobody asked at the kick-off. The same messages, with their line numbers and hints, are what the translator receives in the repair loop. In practice that is what makes a language model usable here: it gets an error it can act on, not a shrug.

One model, many pictures

A diagram is a projection of the graph, not the model itself. Gnomon draws three views of a script (architecture, process and data lineage), filters them for an audience (executives, architects, legal and compliance, security, operations) and folds them to a level of detail. A lawyer sees the personal data and where it is kept; an architect sees every part.

The drawing itself is replaceable too. The same compiled graph goes to Gnomon’s own isometric canvas, to Mermaid, or to LikeC4, and nothing in the script changes:

Fig. 4 — The architecture view of fix-invoices.gnc, drawn by Gnomon's canvas (left), Mermaid (top right) and LikeC4 (bottom right). One model, three renderers.

Each renderer makes its own choices. The canvas sets the ERP on the slab of the cloud it runs on and marks personal data with a red lock. Mermaid labels every edge. LikeC4 stacks the same edges top-down. The facts underneath are identical, which is the point: you can argue about the picture without arguing about the system.

From the same graph, the rules of the ontology also recommend where an agent could take over work, ranked by effort, with the facts still missing to decide.

Evaluation

I did not want to show only a demo, so I built a way to measure the translation.

Fig. 5 — The round trip: text to script to prose, judged against the original. A second path through a hand-written golden script shows what the language itself can carry.

There are three measures. Coverage says how much of the original the prose still says. Faithfulness says how much of the prose the original supports. Graph F1 counts the facts two graphs share, and it is computed by code, with no model involved. The first two use a language model as a judge [13]: it extracts claims from a text, each with a quote of the original that code then verifies, and gives a verdict per claim.

The test set is 54 texts about architectures, agent systems, data pipelines, processes and audits, all from public sources that allow reuse: 40 from the Azure Architecture Center [18], 5 from the GDS Way [17] and 9 algorithmic transparency records of the UK government [19]. Each has a golden script written for it.

Does it compile?

With Claude Sonnet 5.5 as the translator, all 54 texts ended up as scripts that compile. 29 compiled at once, 23 needed one repair round, and 2 needed two or three.

Fig. 6 — The repair loop earns its keep: without it, nearly half of the texts would not compile.

Where do the facts go?

Of 100 claims in an original text, 58 survive the round trip. The interesting part is where the other 42 go. Splitting the loss into layers shows that about 40 are lost because the language, and my golden scripts, cannot say them yet. The translator loses only 7.

Fig. 7 — Where 100 claims of an original go. The language and the golden scripts lose about 40, the translator 7. The prose restores 4.5 that its controlled sentences do not state.

I find this the most useful result of the whole project. The bottleneck is the language, not the translator. That is a very different to-do list from “use a bigger model”, and it tells me which words to add next.

How far to trust the judge, and the graph?

Not blindly. The judge finds every claim of a text in the text itself, and 99.7 of 100 in a text with a fifth of its sentences removed. But when asked to notice the removed claims, it caught only 57 of 100. Two different judges (gpt-oss-120b and Claude Haiku 4.5) gave the same verdict on 73% of 6,054 claims, a Cohen’s kappa of 0.55, which counts as moderate [14].

The graph measure needs no judge. Against its own golden graph, a generated graph scores an F1 of 0.56 on average; against the golden graph of a different text, 0.29.

Fig. 8 — Each text twice: against its own golden graph (gold) and against another text's (grey, the chance level). The graph is about the right text, but only about half of its facts match.

So the graph is clearly about the right text, and only about half of its facts match. Part of that is the translator choosing different relations and levels of detail for the same fact: two translations of one text agree with each other at an F1 of 0.74. This is enough for a demo, not yet proof, and I would rather say so here than have you find out.

What it looks like

All of this sits behind a local web page, Gnomon Studio: the chat on the left, the script in the middle with live diagnostics and its description in plain English, and the diagram on the right. You describe a system, a script appears, compiles or repairs itself, and the picture updates. Every later message extends the script instead of starting again.

Fig. 9 — Gnomon Studio after two messages: the chat, the script with its diagnostics and description, and the architecture view.

Conclusions

Everyone sees a different system. This is a people problem before it is a technology problem.
A shared language beats a better drawing. A drawing can be nicer; only a language can be checked, diffed and versioned.
The ontology carries the weight. Vocabulary, rules, error messages, read-back and views all come from one place. Borrowing it from existing standards made it smaller and more trustworthy than anything I would have invented.
Let the model talk, let the compiler decide. Models are excellent at turning messy words into structure and poor at being consistent. Put the determinism somewhere else.
Measure the layers separately. “58%” alone would have told me to improve the model. Splitting the loss showed me where the loss really was.
Allow “I don’t know” in the language itself. It changes what people are willing to write down.

What is next: separating the public repository (the ontology, the compiler and the studio); conventions that narrow the ways of writing one fact, since the same text still gives different scripts; words for the 40% the language cannot say yet; and the backward direction at scale, from existing code and diagrams to text.

If you work on architecture descriptions, agent systems, or on making language models and rules cooperate, I would be glad to hear from you. Gnomon is also meant as a working tool for audits: mapping the processes and data of a company before anyone builds an agent for them. The project page collects the scenarios I have translated so far.

References

W3C, RDF 1.1 Concepts and Abstract Syntax, Recommendation, 25 February 2014.
W3C, PROV-O: The PROV Ontology, Recommendation, 30 April 2013.
W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 18 August 2009.
W3C, Data Catalog Vocabulary (DCAT), Version 3, Recommendation, 22 August 2024.
W3C, Shapes Constraint Language (SHACL), Recommendation, 20 July 2017.
W3C, OWL 2 Web Ontology Language Document Overview (Second Edition), Recommendation, 11 December 2012.
Data Privacy Vocabularies and Controls Community Group, Data Privacy Vocabulary (DPV), W3C Community Group report.
QUDT, Quantities, Units, Dimensions and Types.
Schema.org.
S. Brown, The C4 model.
Object Management Group, Systems Modeling Language (SysML) 2.0, 2025.
Pydantic documentation.
L. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 Datasets and Benchmarks Track.
J. R. Landis, G. G. Koch, The Measurement of Observer Agreement for Categorical Data, Biometrics 33(1), 1977, pp. 159–174.
Model Context Protocol.
Agent2Agent (A2A) Protocol.
Government Digital Service, How GDS provides user support, The GDS Way, Open Government Licence v3.0.
Microsoft, Azure Architecture Center, CC BY 4.0.
GOV.UK, Algorithmic transparency records, Open Government Licence v3.0.
Lark, a parsing toolkit for Python, MIT licence; documentation.
rdflib, a Python library for working with RDF.
pySHACL, a SHACL validator in Python.

GPT-6 Astra's impact on CAD

Oleg Żero — Thu, 10 Sep 2026 00:00:00 GMT

Introduction

I get uneasy when every new model release arrives with an AGI announcement attached. In engineering the bar sits somewhere else: things either work or they don’t, and when they don’t, it gets expensive, and occasionally it gets dangerous. So one distinction is worth holding on to. “It looks like it did the job” is not the same as “it did the job”.

AI is evolving quickly and will probably keep evolving. But a model release adds options. It does not, on its own, decide whether a class of engineers gets replaced. My guess runs the other way: they will be needed more.

This article asks a narrow question: what does Astra actually change in CAD-related work? The situation is fresh, since the model was released very recently, and I treat the evidence accordingly. I look at three areas that match my own interests: architecture, product design, electronics and hardware. Everything outside them is out of scope here. For each area I collected references to projects where people tried the model in practice and set them next to the official releases, then added my own reading of where we stand given current experience and understanding. If only one of those domains interests you, jump straight to it.

What Astra is and what it is not

GPT-6 Astra is OpenAI’s general multimodal model, released on 2026-09-03 under the model ID gpt-6-astra. It is proprietary: there are no open weights, and the only way in is the API (API documentation). The context window is about 1 050 000 tokens, max output 128 000, and the knowledge cutoff is 2026-04-30 (scalevise). It is available through the OpenAI API, ChatGPT Pro/Business/Enterprise, Microsoft Azure Foundry and AWS Bedrock (Azure). One parameter matters more than the rest for anything agentic: reasoning.effort, which runs from low to max. Going from low to max costs roughly 10× more and takes roughly 8× longer (Artificial Analysis).

One naming note, because it otherwise wastes time. This is not Google Project Astra, which is a completely different product: a multimodal assistant in Gemini Live. The shared name clutters every search (Android Central).

Multimodality does not change the mechanism underneath. Astra’s understanding of a problem, of space, of an engineering task rests on the classic LLM machinery: a context window, tools, and a large number of parameters. Its ability to work with CAD tools comes down to two things: understanding what is displayed on the screen, and formulating the code that goes through the API.

Benchmarks

What they say

Fig. 1 —

BenchCAD Vision2Code, September 2026. Every one of these numbers was submitted by the vendor that scored it. Data: benchcad.com/leaderboard. Chart: author’s own.

The loudest voice regarding CAD is BenchCAD: a benchmark from May 2026, authored at the University of Virginia (Zhang, Liu, Chen, Li, Yang, Peng, Chen). It holds 17 900 execution-verified CadQuery programs across 106 families of industrial parts, with parameters tied to 47 standards (ISO/DIN/EN/ASME/IEC) (arXiv 2605.10865, GitHub).

What it measures: the main metric is Voxel IoU at 256³ resolution, plus Chamfer Distance, Hausdorff Distance and Feature-F1. The tasks are Vision2Code, CodeEdit, Vision-QA and Code-QA. Scoring is execution-grounded, computed by a CAD kernel rather than an LLM judge. That is a good construction (arXiv).

It also deserves credit for going past visual similarity. This benchmark tests parametric operations such as sweep, loft, twist, not to mention sketch+extrude. And here is how Astra compares to other models: Astra 95.9%, Claude Fable 5.1 84.3%, GPT-5.6 Sol 83.3%. If you’d like to know more, here is the link to the BenchCAD leaderboard.

What they don’t say

Fig. 2 —

The same model on the same benchmark, 37.2 points apart, because of two API settings. Data: ARC Prize and OpenAI. Chart: author’s own.

The result is, so far, self-reported and not independently verified. The BenchCAD leaderboard explicitly distinguishes results “re-graded from submitted predictions” from “vendor self-reported voxel IoU, not re-graded”. Both OpenAI’s 95.9% and Anthropic’s 84.3% fall into the second category (leaderboard, confirmed by direct check).

Furthermore, the result applies to the model operating as an agent, one that can render, measure and make corrections before answering. So far, nobody has published a study of how it performs there (The New Stack, Vellum).

A high IoU metric does not guarantee that a designed part is error free. The BenchCAD team themselves report an example of a part whose geometric similarity reached 96.1% despite being faulty: a follow-up operation closed an opening which was supposed to be left open (IBTimes).

Finally, what is compared is not always “apples to apples”. To give you the context, here are some other benchmarks.

Benchmark	Astra	Predecessor / rival	Source
BenchCAD Vision2Code	95.9%	Sol 83.3% · Fable 5.1 84.3%	leaderboard
OSWorld 2.0 (computer use)	72.6%	Sol 65.7%	officechai
GPQA Diamond	96.0%	Sol 94.6% · Gemini 3.8 95.3%	vellum
FrontierMath Tier 4 v2	97.6%	Fable 5.1 87.8%	officechai
Humanity’s Last Exam	57.2%	Fable 5.1 65.0%, Astra loses	emergent.sh
ARC-AGI-3	62.7% (ARC harness) vs 99.9% (OpenAI harness)	n/a	ARC Prize

How to read the numbers?

ARC-AGI-3 is the textbook example of how to read numbers like these. The same Astra, the same attempt: 62.7% on the standard ARC Prize harness and 99.9% on OpenAI’s own harness. The 37-point difference comes from two API settings (“retained reasoning” and “compaction”) that OpenAI did not disclose in the main announcement (ARC Prize, OpenAI, The New Stack).

Independent measurement is less enthusiastic. On the Artificial Analysis Intelligence Index: Astra 61.2, GPT-5.6 Sol 60.9, Claude Fable 5.1 65.7, higher than Astra. Astra is 2.5× more expensive than Sol, and the total cost per task is about 75% higher (Artificial Analysis).

OpenAI’s system card has no section on CAD, 3D or geometry. It focuses on safety. There is also no public model card with architecture and training data (deploymentsafety.openai.com).

Key takeaway

The jump on BenchCAD is real and large (+12.6 pp over the predecessor), but it is a jump in generating CAD code from views in a loop with tools, confirmed by the vendor alone. That is something other than “the model understands design”.

So let’s dive in to see how well it does in specific engineering areas.

Architecture and BIM

Capabilities demonstrated so far

OpenAI’s official demo, verified directly, runs from an architectural brief to an editable Blender scene to a walkthrough in Unreal Engine 5. Astra writes scripts through the Blender Python API (bpy) and also opens and inspects the scene through computer use (OpenAI Developers).

What OpenAI admits in that same demo is worth reading closely; the quotes below are verified. The geometry consists of “modeled mesh objects”: meshes, not a parametric model. Pillows and bedding are “authored shapes”, chosen so that nobody has to run a cloth simulation. “Some shader behavior was approximated”, so the look needed manual inspection. Mirrors in Unreal show reflection artifacts. And the closing caveat is OpenAI’s own: “the concept plan still needs professional review of the site, structure, and building requirements before it could inform construction”. What OpenAI did not publish is execution time or token cost. I checked directly; those numbers are not there.

Outside the vendor demo the picture is mixed. A reconstruction of the Palace of Fine Arts in Blender holds architectural detail against the reference photos (X/tomkrcha, via awesome-gpt-6-astra). A pavilion test (courtyard, plinth, three walls, colonnade, roof) produced 6 columns on one run and 11 on another, so the model does not consistently hold a specified number of elements (blendermcp.org). And three hours of work on a house model with interior layout ended with wardrobes turning into windows and a manual correction (Lenny’s Newsletter).

What is not quite there yet

As I mentioned earlier, the “understanding” of CAD is largely based on reasoning over existing CAD tools’ APIs and utilising MCP servers and plugins, whenever they exist. For Revit, Autodesk has officially stated that the Revit 2027 MCP server is to be integrated with Autodesk Assistant and supports an arbitrary MCP-compatible LLM.

Until then there is the community layer: RevitCortex (github.com/LuDattilo/RevitCortex) with 173 tools, Revit 2023–2027, supporting Claude/Codex/Gemini and any MCP client; revit-mcp-server from the same author, with 80+ tools; and revit_mcp (PiggyAndrew) plus RevitMCP (oakplank, pyRevit).

Although none of these projects explicitly mentions GPT-6 Astra, they act via the MCP standard, so there is no reason to assume that Astra would, for some reason, be excluded. This means more powerful assistance, fewer mistakes, an accelerated workflow, but not necessarily less time spent.

Why?

First of all, BenchCAD tests the code. It does not, however, deal with regulatory issues, quality control, clash detection or code-checking. To realise a complete BIM project, dozens of steps beside drawing exist, executed by entire teams and departments. Given just a few days, it is natural that no complete and fully Astra-based project has been executed and documented. Despite a more powerful model, these steps are not eliminated, and any mistake that can inevitably happen has to be found and corrected. Parametric-architecture describes an “architect’s workflow with Astra”, but it is a speculative scenario (“at 9

the designer opens…”), so it is safer to treat that kind of AI-based work as marketing content rather than engineering truth.

What existed before Astra and continues to exist

Just for the reference, let me present a few tools that have already been developed and offer commercial help in the CAD process for architecture. These dedicated tools are more mature and BIM-native.

Autodesk Forma covers the early phase: massing options, wind/sun/noise analysis, embodied carbon (Autodesk). Finch3D generates floor plans from massing and integrates natively with Rhino/Grasshopper/Revit at €49–1000/month, without structural or MEP coordination and without construction documentation (illustrarch). WiseBIM turns PDF/CAD/image input into a native Revit model for $29/month (myarchitectai). Glyph is a Revit plugin driving sheets, tagging and dimensioning with natural-language commands, at $600/year.

Clash detection has mature non-AI solutions: ifcclash (IfcOpenShell, AGPL-3.0) and Clash-Detection-Matrix-Automation. ArchiCAD 29 beta ships a built-in AI Assistant, but it cannot do numerical analysis (average heights, counting); it only filters and describes elements, with MCP announced for after release (Architosh).

The manual baseline is worth keeping in view: LOD 200 (plans, roof, walls, windows) takes 5–10 working days, LOD 300 two to three weeks, LOD 350 with structure and MEP three to five weeks (CAD Crowd).

Entry level shifting

Again, so little time has passed since the release of the model that it is hard to find professional documented cases that would tell the real price of tokens consumed. For reference, a rough calculation: at 10 million input tokens per day with a 70% cache hit rate, the bill lands around $4110/month (Sol: $1644) (Yotta Labs).

Three integration paths, ordered from the easiest:

Python + bpy / IfcOpenShell. The fastest one: the model writes the script, you run it. It requires nothing beyond an API key. My read: this is the realistic entry threshold today.
Responses API + MCP. For Rhino/Grasshopper a proof of concept exists (Rhino/GH MCP v0.1.6); for Revit it does not.
Computer use (driving the Revit GUI). Works without an API, but slow and brittle.

There is also a regulatory blocker that is easy to miss: Astra has no compliance certification (HIPAA, SOC 2), no built-in audit logging, no legal hold and no data retention controls. For a design office working on client documentation, that is a problem in itself (layer3labs).

Product Design and Mechanical CAD

Capabilities demonstrated so far

The AI gateway to CAD is the code. So far this is CadQuery, build123d, OpenSCAD, KCL: the model writes Python, the CAD kernel executes. This is where the whole BenchCAD result lies. The key difference is the feedback loop that lets the model verify its own results. build123d-mcp raises the CADGenBench score from 0.360 to 0.457, and the share of correct models from 88% to 100%, purely because the model sees a render of what it built and corrects it (build123d-mcp).

A few things stand around it. OpenSCAD comes out better than build123d for LLMs at plain generation: about 3 errors versus 40 (33 with help), so 3–4× fewer repair loops, because the syntax is simpler (grandpacad). Onshape has an official MCP server for FeatureScript since 2026-08-13, with Claude/ChatGPT/Gemini generating FeatureScript code (PTC). FreeCAD MCP exists in several independent open source implementations, free of charge; it handles primitives, booleans and patterns, and does noticeably worse with constrained sketches and fillet chains (freecad-mcp, mcp.directory).

What is not quite there yet

Fig. 3 —

Every closed-source model handles the single block. None handles the hinge assembly: missing mounting holes, misaligned leaves, a missing pin, parts that interfere or come apart. Figure from ASSEMCAD, CC BY 4.0 — the lower band is the authors’ own method, so read the upper band for the evidence.

This is the heart of the question “does it understand design”. The answer is: not in the places where it hurts. The evidence, all peer-reviewed:

Assembly constraints. The LLM generates code bolting screws into gear meshes and creates “phantom features” in places where an operation failed. When satisfying constraints it hallucinates edges that do not exist, which cascades into logical errors, even with a complete set of input data. The authors state it outright: this is a limitation of the transformer architecture, not a gap in knowledge (ASSEMCAD, arXiv 2607.05123).
Coordinate systems and face selection. A milled feature in the wrong reference frame, a stale local face selection, holes shifted, components piled up at the origin: invisible at the level of the code, fatal in the CAD kernel (arXiv 2508.00843).
Tolerances and GD&T. The model can read a standard, but not infer its consequences. A full GD&T evaluation for LLMs does not exist as a public benchmark, which makes it a gap, not a result.
Design intent. The 96.1% IoU case with the closed opening, quoted above, is exactly this class of error.
DFM/DFA. Draft angles, wall thicknesses, pocket depths, undercuts, assembly order: parts look good and cannot be made.

To give you more context: a benchmark from April 2026 recorded 10 professional design engineers (8–13 years of experience) at work and captured their natural change requests, giving 192 requests, 384 edits and 28.4 hours of work (arXiv 2604.16170). The best model (GPT-5.2) landed 53 percentage points below the experts in a human acceptance test (verified). One caution against over-reading it: the paper is from April, Astra is not in it and cannot be. Verified directly. It shows how deep the gap was just before Astra, not how deep it is now — and the version of this figure that circulates with Astra’s name attached to it is one of the claims I throw out further down.

My read: the absence of an Astra result on neuralCAD-Edit is itself information. OpenAI shows BenchCAD, which is generation from scratch out of views. Editing an existing model according to an engineer’s intent, it does not show. And the second one is closer to a design engineer’s real work.

What existed before Astra and continues to exist

Again, a few reference examples that show the capability level prior to Astra.

cadrille (ICLR 2026): DeepCAD IoU 92.2, Fusion360 84.6, share of invalid outputs below 0.2%, from a 2B-parameter model on Qwen2-VL (arXiv 2505.22914).
CAD-Recode: a fine-tune of Qwen2-1.5B on 1 million scripts, 10× better than its predecessors (arXiv 2412.14042).
Backflip AI (August 2026): scan/mesh to editable CAD with a feature tree. Digitizing a part drops from about $1500 to about $10, and the time to 1–5 minutes, as an add-in for Fusion 360, with automotive deployments. It is optimized for turned and 3-axis milled parts, not universal (3D Printing Industry, BusinessWire).
SolidWorks 2026: BREP to parametric conversion (beta), PDF drawing to 3D part (beta), 255+ commands in natural language (SolidWorks).
The research direction that works is grounding in a solver: Embodied CAD (arXiv 2606.31252), AIDL (arXiv 2502.09819), ASSEMCAD. All of them say the same thing: an LLM plus a verifying solver, not an LLM alone.
The manual baseline: a simple part takes 3–5 working days; a sand casting study (part, pattern, cavity, simulation) 20–40 hours. Freelance rates in the US run $75–130/h (CAD Crowd).

Hardware and PCB Design

Fig. 4 —

One PCB project. The drafting time collapses; the verification burden does not. Data: Station X. Chart: author’s own.

This area has by far the best documented criticism from all three areas. To discuss it, let’s discriminate three levels, as they differ rather significantly.

Level	State	Evidence
Schematic + component selection	Works best	prompt → editable schematic with real parts in minutes, protoflow
Placement + routing	Weak, geometry hurts	see below
DRC / manufacturing / Gerber	Stays with deterministic tools	”deterministic rule checkers must make the final call”, protoflow

Let’s start with a few failures

All four come from one project, documented by Nathan House in AI PCB Design: My AI Tried to Make Itself Physical. His numbers, his words in quotation marks.

The AI placed a via 0.0285 mm from an LED solder pad — “a copper via I had placed 0.0285 millimetres from an LED pad”.
The AI board: 168 design rule violations. The human board: 0. “The AI’s had 168 design-rule violations. The human’s board had zero”.
Courtyard zone collisions: two components placed “a comfortable-looking distance apart” that violated their keep-out boundaries twice.
The same project: a 428-hour layout came down to about 38.5 hours of human input, roughly 11× less human time — but with those 168 violations left to fix.

What has been proven

OpenAI claims that Astra carries out placement and routing in KiCad, from schematic to a finished board (OpenAI), with a thread about it on the KiCad forum.
Astra has NO EEBench result. The circulating figure of 69.3% is false. The EEBench blog says plainly “We do not have a GPT-6 Astra result yet”. The leader is Claude Opus 5 at 61.6% (as of 2026-09-01) (EEBench, verified).
A conflict of interest around EEBench: the benchmark was built by the atopile team, the authors of a language for describing circuits as code. Worth remembering while reading their results.
The most interesting real signal is a Hackaday comment (author: Em): three PCBs “vibe coded”, all three worked on the first send to production, but “The routing can look a little wonky (which started me down the rabbit hole of making a rust fork of freerouting), but its really wild how well it works.” (Hackaday, verified).
The second real signal: the Protoflow case study. The AI made small mistakes (missed through-holes, an undersized central pad), the API cost was $50, and the boards worked after fabrication (Protoflow).

Entry level shift

PCB design has the best open source landscape comparing to the other two areas. That’s perhaps why things will be verified much faster. Thanks to the community of all nerds world wide.

Let’s bring on some summary of currently existing tools.

KiCad + MCP: several independent servers built on the official IPC API, kicad-mcp on PyPI, Seeed-Studio, mixelpixx. Adafruit wrote about it (Adafruit blog).
atopile describes a board in declarative .ato code, with native KiCad integration, open source. For an LLM this is the same advantage CadQuery brings in mechanical work: text instead of clicking (atopile).
Flux.ai is an AI-native EDA in the browser, with a library of 750 000 components carrying datasheets (grounding that limits hallucination) and a public MCP server (Flux).
Non-LLM autorouting is more mature than the LLM kind: Quilter (physics, “millions of synthetic boards”) and DeepPCB (reinforcement learning, InstaDeep) (Quilter vs DeepPCB vs Flux).
For context: EAGLE ends support on 2026-06-07, with migration to Fusion Electronics (Autodesk forum).

Takeaways

Money facts

Fig. 5 —

What the edits actually look like — “convert to window frame”, “make the cutout shallower by 10mm but keep the spanner the same” — plotted against what they cost. Note the x-axis tops out around $30 per edit. Figure from neuralCAD-Edit, CC BY 4.0.

Let’s wrap up the cost. After all, Astra isn’t cheap, but so aren’t engineers.

API pricing: $10 per million input tokens, $50 per million output, cached input $1 per million, cache writes $12.50 per million. Above 272 000 input tokens: $20/$75 (Yotta Labs).
2.5× more expensive than GPT-5.6 Sol, with cost per task about 75% higher (Artificial Analysis).
A real reference point for agentic work: completing the game Portal autonomously took 3336 tool calls and $571.18 in API cost (Tom’s Hardware).
Work in 3D generates millions of output tokens through self-correction loops (Neural4D).
The reference point for PCB: $50 of API for a board that worked.
NOT FOUND: the token cost for a real architectural project, for a typical mechanical assembly (say a 5-part mechanism), or for complete documentation.

Hype…?

Checked directly, worth listing separately, because these circulate around the web:

“Astra scores 69.3% on EEBench (PCB)”: FALSE. EEBench states plainly that there is no Astra result. EEBench
“Astra lands 53 pp below experts on neuralCAD-Edit”: garbled. That number refers to GPT-5.2, in an April 2026 paper that does not include Astra. To be clear about what I am rejecting here: the measurement is sound and I lean on it earlier in this article, where it shows how wide the gap was immediately before Astra. What is wrong is the attribution, not the number. arXiv 2604.16170
“BenchCAD 95.9% is verified”: no. Self-reported by OpenAI, not re-graded by the BenchCAD team. leaderboard
“Astra models CAD in Blender”: a conflation of terms. In Blender, Astra generates meshes through bpy. BenchCAD is a separate test of generating CadQuery code. Two different things glued into one narrative. Kingy, Neural4D
“91 projects made with Astra”: the catalogue exists, but its entries carry notes like “ongoing; no completed board”, “may not be usable”, “render pending”. gist phuaky

The impact of Astra on CAD work

Can a noob in CAD do the CAD work?

Partially. Whenever a task is simple and well defined, models such as Astra significantly lower the entry level of getting (some)thing done. Be it a prototype, a simple part, a PCB with known components or a conceptual visualization, prompting and patience is often more than enough to get to the first sketch. The difficulty, however, is the lack of ability of a freshman to spot errors that simply appear as job well done. This observation isn’t limited to CAD, but it is often more challenging to test.

With Astra, a layman gets access to the first approximation of the result, but not to the final result. The biggest impact, therefore, appears where mistakes costs are low. That means DIY work, home 3D printing, single proof of concept, etc. As you may notice, not much has actually changed.

Should CAD professional know AI?

Not really. The days of needing to know machine-learning principles and frameworks to get anything started are gone. With API keys and python scripts, MCP servers (e.g. KiCAD, FreeCAD, Onshape, Blender) or plugins, the cost of adding AI to workflows is largely determined by LLM providers and tokens.

The key skills, however, are not “prompt engineering”, but the ability to build verification and an iterative approach. The evidence: +27% on the score and 88%→100% correctness from adding nothing but a render to the loop (build123d-mcp). The fundamental strength of a CAD professional is the ability to describe what a correct solution means in a way that is doable by machines. For these people, getting access to better models is like giving faster cars to people that already know how to drive.

The effort now shifts

True CAD professionals are quick to draft first versions and modifying existing drawings. Tools that they use have also been evolving “UX-wise”. Therefore, despite shortening the time to create first versions of drawings and writing scripts, this aren’t the biggest wins. However, finding documentation, converting scan to mesh and mesh to CAD is where significant portion of time gets saved.

On the flip side, the biggest dangers and hence time thieves are the verification and testing, especially against quiet mistakes. Defining acceptance criteria and responsible design matter much more now, putting more emphasis on deriving a thorough design conceptual plan and review.

What follows is my personal view rather than anything I can hand you a citation for. These are the conclusions I draw:

The direction is already visible: LLM plus solver, not LLM alone. Embodied CAD, AIDL, ASSEMCAD, build123d-mcp: four independent pieces of work say the same thing. The next real jump will come from better coupling with the kernel, not from a bigger model.
Dedicated models will not disappear. cadrille (2B parameters) holds DeepCAD IoU 92.2 at a fraction of Astra’s cost. Narrow tasks will keep escaping to small models.
The bottleneck stops being geometry and becomes unstructured data: BOMs, DFM rules, standards, the history of design decisions. That is already visible in the Fusion and Onshape tooling.
What I would not expect within a year: autonomous design of safety-critical parts. The blocker is architectural (ASSEMCAD) and regulatory (no certification, no auditability), not “not enough data”.

References

Source	Type	Credibility	Note
dokumentacja API	vendor blog / doc	`OFFICIAL`	—
scalevise	trade press / blog	`PRESS`	—
Azure	vendor blog	`OFFICIAL`	—
Artificial Analysis	independent measurement	`PAPER`	—
Android Central	trade press	`PRESS`	clarifies this is not Google Project Astra
arXiv 2605.10865	paper	`PAPER`	authors from UVA, no OpenAI funding trace
BenchCAD GitHub	repo	`OFFICIAL`	—
arXiv (HTML)	paper	`PAPER`	—
BenchCAD leaderboard	leaderboard	`OFFICIAL`	clearly separates self-reported from re-graded results
The New Stack	trade press	`PRESS`	—
Vellum	trade press	`PRESS`	—
IBTimes	news report	`PRESS`	quotes verified verbatim
officechai	trade press	`PRESS`	—
emergent.sh	trade press	`PRESS`	—
ARC Prize	benchmark blog	`OFFICIAL`	shows harness impact on the score
OpenAI (ARC-AGI-3 settings)	vendor blog	`OFFICIAL`	—
The New Stack (ARC-AGI)	trade press	`PRESS`	—
Artificial Analysis (benchmarking Astra)	independent measurement	`PAPER`	only independent price/performance measurement
System card	vendor document	`OFFICIAL`	no CAD/3D section
OpenAI Developers (architecture demo)	vendor blog	`OFFICIAL`	honestly lists limitations; interested party
X/tomkrcha, via awesome-gpt-6-astra	community repo	`FORUM`	—
blendermcp.org	trade press	`PRESS`	—
Lenny’s Newsletter	newsletter / anecdote	`FORUM`	—
parametric-architecture	industry blog	`PRESS`	speculative scenario, not a documented pilot
Autodesk (Forma)	vendor blog	`OFFICIAL`	—
illustrarch (Finch3D)	trade press	`PRESS`	—
myarchitectai	trade press	`PRESS`	—
ifcclash	repo	`CODE`	—
Clash-Detection-Matrix-Automation	repo	`CODE`	—
Architosh	trade press	`PRESS`	—
CAD Crowd (LOD timelines)	trade press	`PRESS`	—
Yotta Labs	trade press	`PRESS`	—
Rhino/GH MCP v0.1.6	repo / MCP listing	`CODE`	proof-of-concept only
layer3labs	trade press	`PRESS`	notes lack of compliance certification
build123d-mcp	repo	`CODE`	hard numbers on feedback-loop value
grandpacad	trade press	`PRESS`	—
PTC (Onshape MCP)	vendor press	`OFFICIAL`	—
freecad-mcp	repo	`CODE`	—
mcp.directory	trade press	`PRESS`	—
ASSEMCAD, arXiv 2607.05123	paper	`PAPER`	strongest evidence of an architectural limitation
arXiv 2508.00843	paper	`PAPER`	—
neuralCAD-Edit, arXiv 2604.16170	paper	`PAPER`	10 professional engineers, real edit requests; no Astra result
cadrille, arXiv 2505.22914	paper	`PAPER`	—
CAD-Recode, arXiv 2412.14042	paper	`PAPER`	—
3D Printing Industry (Backflip AI)	trade press	`PRESS`	vendor numbers, independent coverage
BusinessWire (Backflip AI)	press release	`OFFICIAL`	—
SolidWorks	vendor page	`OFFICIAL`	—
Embodied CAD, arXiv 2606.31252	paper	`PAPER`	—
AIDL, arXiv 2502.09819	paper	`PAPER`	—
CAD Crowd (freelance rates)	trade press	`PRESS`	—
protoflow (PCB design guide)	trade press	`PRESS`	—
Nathan House, AI PCB Design: My AI Tried to Make Itself Physical	case study	`PRESS`	168 DRC violations vs 0, concrete numbers; quotes verified against the source
OpenAI (Astra launch)	vendor blog	`OFFICIAL`	—
forum KiCad	forum thread	`FORUM`	—
EEBench	benchmark	`PRESS`	built by atopile team, conflict of interest
Hackaday + comments	outlet + forum	`FORUM`	best real-world signal from practice
Protoflow (case study)	trade press	`PRESS`	$50 API cost, boards worked after fab
kicad-mcp on PyPI	repo	`OFFICIAL`	—
Seeed-Studio	repo	`CODE`	—
mixelpixx	repo	`CODE`	—
Adafruit blog	trade press	`OFFICIAL`	—
atopile	repo	`OFFICIAL`	—
Flux	vendor blog	`OFFICIAL`	—
Quilter vs DeepPCB vs Flux	vendor comparison	`OFFICIAL`	—
Autodesk forum (EAGLE EOL)	vendor forum	`OFFICIAL`	—
Tom’s Hardware (Portal run)	trade press	`PRESS`	—
Neural4D	industry blog	`PRESS`	sober mesh/CAD distinction
The Hacker News (ExploitBench)	trade press	`PRESS`	confirms 100% on standard ExploitBench only
Kingy	blog test	`PRESS`	the only detailed Blender test
gist, 91 projects	community catalogue	`FORUM`	most entries unfinished