Architecture knowledge mining with LLMs: How to turn meeting transcripts into living architecture and automated fitness functions

Architecture knowledge mining has always been a crucial and unsolved problem. Teams make their most important decisions in meetings, but the gap between what they decided and what they documented keeps widening. Writing decisions down is tedious, so many teams eventually stop trying. That gap snowballs into larger organizational visibility and documentation problems, where the longer a team goes without recorded decisions, the more these problems compound:

• Tribal knowledge takes over and critical context lives in a few people's heads, so every departure takes a piece of the architecture with it.
• Engineers relearn old trade-offs the hard way and burn sprints re-debating settled questions and repeating past mistakes.
• Legacy code becomes untouchable and teams build workarounds around it, because nobody remembers why it works the way it does.
• Tech debt piles up and engineers lose their precious deep work hours to fixing bad code and swelling budgets.

LLMs can finally close that gap. They can turn meeting transcripts directly into living architecture knowledge, then use it to catch violations before they ship. Each extracted decision becomes a plain-language rule, and on every pull request an LLM checks the diff against the relevant rules and flags changes that contradict them, along with the decision they break and the reasoning behind it.

This article shows how, using architecture harvesting, a system design agent, and LLM-powered fitness functions.

The need for knowledge mining: Why architecture knowledge gets lost in meetings

Architecture knowledge disappears for a handful of predictable reasons:

• Architects spend most of their time in meetings, design discussions, team syncs, incident reviews, and “quick 15-minute calls” that run for an hour are where architecture takes shape, yet almost none of it reaches the documentation since it lives in people's heads.
• Teams skip Architecture Decision Records (ADRs) and the /docs/adr folder goes quiet after a few entries in the first month, because writing up the context, options, and consequences always loses to the next ticket in the sprint.
• Decisions change in meetings people miss, like a Postgres-to-DynamoDB migration or an OAuth flow swapped for SSO, and anyone who wasn't there keeps building against outdated service boundaries and API contracts.
• Non-functional requirements come up once in passing and vanish, so p99 latency targets, SLOs, RTO/RPO, and threat-model assumptions never land in a place where a team can find them.
• Recordings go unwatched, so architectural decisions stay buried in hours of Zoom and Teams video that nobody will ever rewatch or search.
• Contradictions surface late, when someone ships a change that breaks an undocumented decision and the problem appears in code review, a failed deploy, or a production incident with a rollback.

The solution: Architecture harvesting and knowledge discovery with AI

The tedious part of architecture documentation is listening, extracting, structuring, and keeping knowledge current. That is exactly the kind of work we can now delegate to LLMs. Instead of asking architects to write up decisions after the fact, AI turns the meetings that already happen into a source of structured knowledge.

We built an architecture harvesting agentic harness to store meeting transcripts and extract architectural knowledge. It's built on GitHub Copilot CLI and guided by a rule file for each knowledge bucket. Each rule file defines what should be extracted and, just as important, what doesn't qualify. The workflow includes:

• Harvesting architecture knowledge from meetings: The harness listens to meeting transcripts from the past day and extracts architectural knowledge automatically, sorting it into five buckets: system design changes, guideline updates, non-functional requirements, technical debt and improvements, and attention items.
• Grounding system design in real decisions: A system design agent generates new designs with the harvested knowledge base as context, so they align with existing ADRs and constraints from the start instead of failing review later.
• Reinventing fitness functions: Classic fitness functions only worked for things we could express in code, such as dependency rules, layering, and performance thresholds. LLMs extend the concept to natural-language rules like "services don't share databases" or "this ADR supersedes that one," and check them against designs and code.

Architecture knowledge mining with LLMs: A step by step guide

Step 1: Extract architecture knowledge from meeting transcripts into five buckets

The harness sorts what it finds into five buckets:

• System design changes: new designs and modifications to existing ones
• Architecture guideline updates: new or revised rules the teams should follow
• Non-functional requirements: performance, security, availability, and other quality attributes
• Technical improvements: tech debt and improvement ideas worth tracking
• Attention items: anything that needs an architect's eyes, even when nobody explicitly labeled it as architectural

The knowledge is stored as markdown files in a Git repository. More so, every proposed update is reviewed by an architect before it's merged (yes, there is still a boring part). The agent proposes changes, and a human reviews them and commits markdown.

Step 2: Build an architecture harvesting control plane

Build an architecture harvesting control plane as created in our Product Development Lifecycle guide. It builds an agenda of the knowledge elements found in past day meetings that are waiting for review. Once we had a living architecture knowledge base, the next question was obvious: what else can we do with it besides having engineers read it?

A system design agent will use the knowledge base as context, so new system designs start out aligned with existing decisions, guidelines, and constraints instead of discovering them in review.

Step 3: Define architecture fitness functions

Neal Ford, Rebecca Parsons, and Patrick Kua described the concept well in Building Evolutionary Architectures:

In simple words,

It's a unit test for your architecture. Traditionally, fitness functions have been limited to what you can express in code, such as dependency rules, layering checks, and performance thresholds. But much of real architecture lives in natural language. Rules like "services don't share databases," "external traffic goes through the gateway," or "this ADR supersedes that one" are hard to turn into a traditional test.

LLMs can evaluate natural-language rules against natural-language designs and against code. That gives the concept a new implementation, one that is much broader and far cheaper to maintain.

Step 4: Run automated architecture checks at three stages

We run architectural checks at three stages:

1. Validate system design documents

Major features require a system design. When a new design document is created, a bot validates it against the knowledge base and leaves architecture review comments directly in the document.

2. Validate technical tickets in Jira

Smaller technical changes usually start as Jira tickets. The same idea applies here: the bot validates the ticket and highlights anything that doesn't comply with an ADR or an architecture guideline before work begins.

3. Validate code with an architecture review bot

Once code is written, an architectural review bot runs alongside the regular code review bot and validates the changes against the architecture. This is the last chance to catch drift before it reaches production.

Benefits of continuous knowledge mining and discovery with LLMs

For years, keeping architecture documentation current was a persistent challenge. LLMs ensure documentation is no longer extra work squeezed into spare time at the cost of deep work. It becomes a byproduct of continuous improvement and work. The meetings happen anyway, and LLMs capture the knowledge at the point of discovery. Where keyword search and rule-based extraction break on messy conversation, LLMs pull out the decision, context, rejected alternatives, and reasoning, then draft an ADR from them. LLMs also:

• Enable semantic discovery by connecting a March decision to move to event-driven with a May decision to use Kafka for order updates, and by flagging a June design that adds a synchronous REST call between the same services.
• Ensure checks shift left, so a problem gets caught in a design document instead of flowing downstream into production incidents, rollbacks, and rework.
• Make documented architecture checkable by validating every pull request against the ADRs and guidelines, and by understanding intent, not just syntax. A rule like "services never share a database" catches a new cross-service schema dependency that no linter would flag.

What's next: Architecture mining with EPAM

EPAM helps engineering organizations build architecture harvesting pipelines, system design agents, and LLM-powered fitness functions tailored to their stack, tooling, and governance needs.

Talk to our experts about piloting architecture knowledge mining on your own meeting transcripts, and see how living architecture knowledge can reduce tech debt, speed up onboarding, and catch drift before it ships.

Read more: ⁠Introducing AI/Run- Your End-to-End Infrastructure for Enterprise AI Adoption