One of the most consistently expensive bottlenecks in EA practice is the gap between people who need answers about the architecture and the small number of people who can actually read the model that holds those answers. Today we're closing that gap.

Plain language Q&A means anyone in the organization can ask the architecture model a question in their own words, and get back a structured, accurate answer with citations to the underlying model elements. No ArchiMate fluency required. No query syntax. No "let me file a ticket with the architecture team."

You ask in English. The model answers — and shows you the path through itself that produced the answer.

That last part is the difference between this and a chatbot. More on that below.

The unlock we've been working toward

Our first milestone was auto-discovery — point DesignFoundry at a folder of PDFs, Word documents, integration specifications, system inventories, and it extracts the entities, maps the relationships, and gives you back a complete ArchiMate model. We built that because most architecture documentation lives in unstructured documents that no one has time to model by hand. Auto-discovery solved the building problem.

But it left a different problem in place.

Once you had the model, you still needed an architect to use it. The model is in ArchiMate. ArchiMate has a notation, a syntax, a way of asking questions. If you wanted to know "which systems handle customer PII," you couldn't just ask. You had to know that "system" in ArchiMate-speak is "application component," that "handle" means traverses a "data flow relationship" to a "data object," that "customer PII" is a property tag you needed to filter on. You had to translate your question into the model's grammar before the model could answer.

In practice that meant every question was a meeting. The product owner has a question. They open a ticket. The architect translates it. The architect runs the query. The architect interprets the result. The architect writes it up. The product owner reads the writeup three days later and asks a follow-up question. Another ticket. Another translation. Another three days.

For a function that's supposed to make decisions faster, that's a brutal cycle.

What plain language Q&A handles

The kinds of questions this is designed for — the ones that used to be tickets and are now seconds:

"Which systems would be affected if the customer master goes down for two hours?"

Returns the downstream applications with their dependency criticality scores, recovery time objectives where known, and the integration touchpoints involved.

"What's our exposure to vendor X across the application landscape?"

Returns every component that depends on the named vendor, plus the business capabilities those components support.

"Show me everything in the integration layer that touches GDPR-classified data."

Returns the relevant integration points, their owners, their last-reviewed dates, and any compliance flags from the model.

"Which decisions are documented as 'temporary' but are older than 18 months?"

Returns the architecture decisions where the model has both a "temporary" marker and a decision date past the 18-month threshold. (Most organizations are surprised by how many they find when they ask this.)

None of these questions require typing in ArchiMate syntax. None require knowing which property tag holds which classification. None require composing a query. You ask in English. The model answers.

Why this isn't just a chatbot

This is worth being careful about. Plenty of products have "AI chat" today. Most of them are wrappers around a general-purpose language model that's been pointed at some documentation. They're often impressive in a demo and unreliable in production, because the model is guessing from text rather than reasoning over structured architecture data.

What we built is different. Three things specifically:

The answers come from the model, not from text. Every response is grounded in the actual entities and relationships in your architecture model. When the system says "five applications handle customer PII," it's listing five specific application-component nodes that have a documented data-flow relationship to a data-object node tagged with the PII classification. We can show you the path through the model that produced the answer.

Every answer is citable. When you get a result, you can click through to the underlying model elements. You can see the source documents that the auto-discovery extracted those elements from. There's no "trust me, the AI said so." There's "here are the specific decisions and here are the documents they came from."

The model knows what it doesn't know. This was the hard part. When a question can't be answered from the model — because the data isn't there, or the question requires assumptions, or the relationship isn't documented — the system says so. It tells you what's missing rather than hallucinating an answer. We spent more time on this than on the answering part.

What this changes operationally

For the architects on your team, plain language Q&A doesn't replace what they do. It removes the bottleneck where they're the only people who can ask basic questions of the architecture model. They go back to doing strategic architecture work — designing, deciding, planning — instead of being a query service.

For everyone else — product, compliance, security, operations, the CFO — it means you can interrogate your own architecture without scheduling a meeting. You ask. You get the answer. You make the decision. Same day.

A few specific changes:

Decision velocity goes up. Questions that used to take three days now take three seconds. Compounded across an organization, that's significant.
Architecture becomes a shared resource. When more people can use the model, more people contribute to keeping it accurate. The model gets healthier, not stale.
Architects stop being a bottleneck and become an amplifier. Their judgment is still the scarce resource. Now it's deployed on the strategic work where judgment matters, not on translating queries.

What it doesn't do

Plain language Q&A doesn't make architects redundant. It doesn't fix bad architecture data. It doesn't decide what your strategy should be. It doesn't replace human review for compliance-grade decisions.

What it does is remove a specific, painful, well-documented bottleneck: the inability of non-architects to ask the architecture model basic questions.

That's all. That's enough.

How to try it

Plain language Q&A is live for early-access customers. If your team uses DesignFoundry and you haven't seen this yet, log in and ask your model something. If you're not on early access yet, we're still letting people in — apply through the link in our profile.

Architecture should answer to you, not the other way around. We just made that easier.