Architecture Note · 04

I spent 14 years solving a document intelligence problem. I just didn't have the right tools yet.

BoardPath · May 2026 · Eric Tetzlaff

Every board meeting started the same way.

Board members would file in carrying three-inch binders stuffed with photocopies — not full governing documents, never the full corpus, but the sections they personally considered important. The most organized ones had tabs. The less organized ones had coffee stains and dog-eared corners and the particular confidence of someone who had been on this board for eleven years and therefore believed they already knew where everything was.

Nothing was electronic. Nothing was searchable. And nothing was complete.

At some point in nearly every meeting, an issue would arise — a roof repair that might actually be a replacement, a fence dispute that sat exactly on the line between homeowner and association responsibility, a rental restriction that two board members remembered differently from the last time it came up. Someone would flip to a section of the Declaration. Someone else would flip to the Bylaws. A third person would suggest that Rules and Regulations had something to say about it too. Definitions would be read aloud. Discussion would follow.

And then, almost without fail, someone would ask: Well, when this came up with so-and-so a few years back — how did we handle it then?

The moment that happened every meeting

If there was a board member present who'd been there for that prior decision, they'd give their best recollection. The board would discuss from there.

If there wasn't — if institutional memory had retired, moved, or simply wasn't in the room — everyone looked at me. I would speak in generalities. Ohio law. What the documents appeared to say, based on what I had in front of me, which was never everything. My best professional judgment, assembled in real time from incomplete information, competing document sections, and memory that may or may not have accurately reflected what had actually happened.

I did this hundreds of times across dozens of associations over fourteen years.

I was good at it — not because the process was sound, but because I had developed an unusually detailed mental model of how governing documents are structured, how authority flows between them, how amendments interact with original language, and where the gaps tend to live.

What I did not understand then was that I had spent over a decade manually performing a document intelligence and hierarchy resolution task. I just didn't have that vocabulary for it yet.

The Problem Has a Name

Here is what was actually happening in those board meetings, stated plainly:

Retrieval failure
Document intelligence problem
No complete corpus in the room. Partial documents, personal selections, missing amendments. The source material required to answer the question authoritatively wasn't available at query time.
Authority hierarchy failure
Hierarchy resolution problem
Multiple documents with overlapping and sometimes conflicting scope. No system for determining which controls. Declaration vs. Bylaws vs. Rules vs. Board Motion — applied by intuition, not by rule.
Knowledge gap failure
Corpus completeness problem
The corpus didn't address the question. Nobody knew this until the question was asked. The gap was filled with tribal memory, professional judgment, and inference — not with authoritative source material.
What everyone called it
Wrong diagnosis
An administrative problem. Better binders. Better managers. Better minutes. These things helped at the margins. They didn't solve the underlying architecture.

The administrative framing is seductive because it's actionable. Buy better binders. Hire a better manager. Take cleaner notes. The underlying architecture requires something different: knowing, at query time, which document controls, whether any amendments modify the controlling language, whether the corpus actually addresses the question at all — and being willing to say so when it doesn't.

The Earliest Version of the Answer

When Google NotebookLM became available in early beta, I saw something immediately. It was rough. It was limited. But the core capability — a siloed corpus, query-driven, with explicit source grounding — was exactly the shape of the problem I had been manually solving for years.

I built a version for each association I managed. Every governing document I had — Declarations, Bylaws, Rules and Regulations, recorded amendments, relevant board minutes — went into a dedicated corpus. I configured it to stay within that corpus. No web access. No inference from external sources. No filling in gaps with general knowledge.

And I gave it explicit permission to say: The corpus does not address this item.

Board members hated that answer. These systems were supposed to be all-knowing. What do you mean it can't tell us what to do?

"The system isn't failing you. Your governing documents are failing you. And that's actually something we can fix."

Most boards listened. Because when I said it that way, it wasn't a technology problem — it was a governance problem with a clear path to resolution. What followed was the feedback loop that changed everything:

01
Retrieval
System queries the corpus. Returns citation-grounded answer — or surfaces the gap: the corpus does not address this.
System
02
Gap characterization
Gap is identified, flagged, and categorized. Legal and operational risk is surfaced. Board understands what's missing and why it matters.
System + Human
03
Remediation
Amendments drafted. Board motion language written. New rule sections authored — specifically targeting the gaps the system revealed. Attorney review. Ratification.
Human
04
Corpus improvement
New documents ingested. Corpus strengthened. Next time the question arrives, the system has something authoritative to cite.
System

The AI didn't just find the gaps. It created a legal remediation workflow. The retrieval layer surfaced what was missing. The human layer closed it. The corpus improved. And the next query arrived into a better system than the last one had.

What This Built in Me

I want to be precise about what I'm claiming here, because I think the temptation is to read this as a story about how domain expertise makes someone a better AI developer. That's true but it's not the point.

The point is that the specific shape of this domain — fragmented authority, amendment inheritance, competing document hierarchies, the legal consequences of an incorrect answer, the operational cost of an uncertain one — forced me to develop a set of design instincts that I now consider foundational to any serious document intelligence system.

14
Years performing this task manually
34
Associations managed simultaneously at peak
100s
Of associations across the full tenure

Those instincts are: source authority must be explicit and ranked, not assumed. Answers must be grounded in citable material, not synthesized from general knowledge. Uncertainty must be surfaced, not papered over. And the system must be architected to say "I don't know" before it is architected to say anything else — because a hallucinated answer in a governing document context doesn't just fail the user. It can bind an association to a course of action that contradicts its own legal charter.

These are the design principles behind BoardPath. Not because I read them in a paper on RAG architecture. Because I learned them the hard way, in real board meetings, with real legal and financial stakes, over fourteen years of manually doing what the system now does.

Why I Keep Coming Back to This

The most common criticism of AI systems built by people with strong domain backgrounds is that they over-engineer for their specific context. That the solutions are too narrow, too particular, too shaped by one set of problems to generalize.

I think about this criticism seriously. And I think it's wrong in a specific way that's worth naming.

The principles that emerged from governing document intelligence — hierarchy-aware retrieval, honest uncertainty, corpus-bounded answers, human judgment at consequential junctures — are not HOA-specific principles. They are the principles of any system operating in a high-stakes, document-heavy environment where an incorrect answer has downstream consequences that outlast the conversation.

Legal document intelligence. Medical record analysis. Financial compliance review. Regulatory interpretation. Every one of these domains has the same underlying architecture: competing authorities, amendment-like modifications to original language, gaps the corpus doesn't cover, and users who need to trust the answer enough to act on it.

I didn't learn document intelligence despite spending fourteen years in property management. I learned it because of it. The binders were the training data. The board meetings were the evals. And every time someone asked me what to do when the documents didn't have an answer, I was being taught — slowly, manually, at human speed — exactly what I now teach the systems I build.

The tools changed. The problem didn't.

← Previous post All posts →