The Plugin Request That Became an AI Knowledge Platform

"Can you just make our search better?"

That was the ask. A regional innovation ecosystem — a network of organizations, funding programs, startups, and the people who connect them — was sitting on a wealth of information that almost nobody could find. Resources lived in PDFs, on scattered partner websites, in program one-pagers. The plan on the table was the familiar one: bolt a search-and-filter plugin onto the existing site, sprinkle in a bit of "AI," and call it done.

We looked at what they were really trying to do and told them the plugin wouldn't get them there.

What they were describing — pulling trustworthy answers from a curated set of approved documents, attributing every answer to its source, powering a public map and directory from that same information, and keeping it all current without a staffer babysitting it — is not a search box. It's a custom knowledge platform. The cheap option would have quietly failed at the one thing they actually cared about, and they'd have been back a year later having spent the budget anyway.

So we built the real thing.

A search box vs. a knowledge platform

The difference matters more than it sounds. A plugin searches the words already on your website. What this client needed was a system that could ingest new material — upload a PDF or paste a link, and have the platform read it, understand it, summarize it, and fold it into a searchable body of knowledge that an AI could reason over.

That meant building, from the ground up:

• An ingestion pipeline that accepts PDFs and URLs, extracts the real content (stripping nav bars, ads, and boilerplate), and handles the messy reality of the web — including JavaScript-heavy pages that don't render their content until a browser runs them.
• A retrieval engine that finds the right passages for a given question.
• A grounded answer layer that uses a large language model to write a natural-language response constrained to the approved material — and cites it.
• A curation workflow so a human reviews and approves everything before the public ever sees it.
• A public directory and map of the ecosystem's organizations and programs, driven by the very same database.

One system. Two products. A whole lot of careful engineering in between.

The hard part: AI that tells the truth

Here's the thing most people get wrong about putting AI in front of customers. The impressive-demo version is easy. The version you can actually stand behind is not.

The number-one risk with AI answers is confident nonsense — the model inventing a program that doesn't exist or misattributing a fact. For an organization whose credibility is its whole value, that's not a glitch, it's a reputational liability. So trust was the design constraint, not an afterthought.

Three decisions made the answers trustworthy:

It only answers from approved sources. The AI never searches the open web. It draws exclusively from documents a human has reviewed and published. Ask it something outside that body of knowledge and it won't improvise.

Every answer points to its evidence. When the system retrieves information, it tracks the exact passage that matched your question and cites it — not a vague "this came from somewhere on the site," but the specific chunk of the specific document the answer rests on. Getting this right took real work: an early version cited the first part of each document instead of the part that actually matched. We caught it, traced it, and fixed it so the citation always points at the real evidence.

It knows when to say "I don't know." This is the feature we're proudest of. The system measures how strong its best match is, and if nothing in the library genuinely answers the question, it says so plainly instead of forcing an answer. An honest "we don't have a strong match for that yet" builds more trust than a fluent guess. The threshold for that decision is tuned and adjustable, calibrated against how the actual embedding model behaves on real queries.

Under the hood, retrieval combines two methods: semantic search (matching on meaning using vector embeddings stored in Postgres) and keyword search (matching on exact terms), fused together so the system catches both the question phrased a dozen different ways and the precise jargon a specialist would type. Hybrid retrieval is more resilient than either approach alone, and it's the difference between a search that feels clairvoyant and one that misses the obvious.

One data layer, two products

The most elegant part of the architecture is also the most economical. The same curated database that feeds the AI search also powers a structured public directory: approved organizations, their programs, locations for an interactive map, and category and audience filters.

That's not a coincidence, it's the whole point. Instead of maintaining one system for "AI search" and a separate one for "the directory," the client maintains a single source of truth. Approve an organization once and it shows up on the map, in the filterable directory, and as context the AI can draw on. Build the data model well once, and it pays off in every feature that touches it.

Software that keeps itself current — without erasing human judgment

A knowledge base is only as good as its freshness, and nobody wants a job that says "re-check forty partner websites every week." So the platform refreshes its published web sources automatically on a schedule.

The subtle, important detail: re-ingestion preserves the human curation. When the system re-reads a source, it updates the underlying content and embeddings but keeps the edited titles, the polished summaries, and — critically — the publish status. An early version of this destroyed editorial work on every refresh, silently yanking reviewed resources back into the review queue. We found that during a review and rebuilt the flow so automation and human judgment coexist instead of fighting. Curators can trust the auto-refresh because it never overwrites their decisions.

The part nobody sees: built and reviewed like it matters

A demo runs once on a developer's laptop. A product runs in front of real people, under real load, indefinitely. The gap between those two is where most AI projects quietly die.

This one was built to live in production:

• The public endpoints are rate-limited, so the paid AI calls can't be run up by a bot or a bad actor.
• The admin tools are secured with constant-time key comparison, and the system refuses to even start in production with a default password still in place.
• The ingestion pipeline retries on transient failures with exponential backoff instead of giving up on the first network hiccup.
• Errors return honest, specific responses — a 404 for something that doesn't exist, a clear validation message for bad input — instead of opaque 500s.

We also did something we think every serious build deserves: a full written review of the codebase against the client's actual stated goals, scoring each one and documenting what was met, what was broken, and what was missing. That review caught a critical bug where the grounded AI answer was never being generated at all — the system looked like it was working while silently falling back to canned responses every single time. Found, diagnosed, fixed, and verified end-to-end with a real browser driving the live app. That's the difference between "it compiles" and "it works."

If you're thinking about AI for your business

Most AI projects don't fail because the models aren't smart enough. They fail because they're wired up carelessly — ungrounded, unmaintained, impossible to trust, and quietly broken in ways no one notices until a customer does.

The value we bring is the opposite of that. We'll tell you when the cheap option won't actually solve your problem. We'll build AI that cites its sources, knows its limits, and stays current on its own. And we'll review our own work against your goals, not just against whether the code runs.

If you're sitting on information your customers can't find, weighing whether "add AI" is a real feature or a fantasy, or you've been burned by a demo that fell apart in the real world — let's talk. The interesting problems are the ones where AI has to be trustworthy, and those are exactly the ones worth building.