Pursuit Intelligence

“I know we’ve done something like this. Where was it?” That question is familiar in proposal work. A team may have the experience, but the story is buried in years of past proposals, fact sheets, résumés, and response documents. Finding it can depend on remembering a project name or knowing which colleague to call.

I started Pursuit Intelligence to make that search less dependent on memory. The point was never to let AI write a claim and have the team accept it. I wanted a research workflow that could surface a promising experience, show where it came from, and leave the decision to the person responsible for the proposal.

Public note: Client, project, and source identifiers are omitted. The local proof of concept has informed national development; that version is still in development. No aggregate time savings, adoption rate, or proposal win impact has been measured.

The hard part was remembering the right evidence

A construction proposal is a response to a particular owner, project, delivery method, and set of evaluation criteria. Generic capability language can establish that a firm does the work. A specific project story can show how the team handled a constraint, coordinated people in the field, worked with the owner and architect, or kept an occupied campus operating.

Those examples do not live in one tidy library. The details are distributed across documents created for different pursuits and organized for the needs of the proposal that originally used them. A project résumé row might tell you that a person worked on a school. A fact sheet might list the square footage and delivery method. An old response might contain a paragraph about phasing construction around students. Those pieces are related, but they are not interchangeable.

When a new pursuit asks for an unusually specific example, keyword search can miss it because the old document used different language. A broad search can also return a project name, biography, or scope description that looks relevant but does not answer the question. The user has to do two jobs at once: find a lead and decide whether it actually supports the claim.

The opportunity I saw was to move the effort from “which file or person might remember this?” toward “what happened, where is the evidence, and does it fit this pursuit?”

A project record is not the same thing as a story

The most important information architecture decision was to define what a useful result means. A project name, team résumé, square footage, or list of services can be a helpful lead. None of those, on its own, is a reusable story.

A project story is a grounded account of an experience: what constraint or need arose, what the team did, how it coordinated with the owner, architect, superintendent, project manager, and trades, and what the experience may demonstrate for a new pursuit. The relevant people, business unit, market, delivery method, and source document provide context around that account. They help a proposal writer judge whether a story from one job truly maps to another.

This distinction matters because a system can return a technically related fact and still fail the user. If a query asks how a team handled work on an occupied campus, “renovated a 90,000 square foot school” does not answer it. The useful evidence would describe phasing, communication, or another action taken to keep the school operating. The record needs to help the user move from a project that might fit to the specific experience that proves why it fits.

There is a further distinction between a story that exists and an authorized story. A large project portfolio may contain thousands of project records while only a smaller set of narratives has been reviewed and cleared for reuse. Treating every mention as ready to publish would erase an important review boundary. The system should help people find candidates; the source and the organization's review process determine what is safe to reuse.

The library was organized around three connected kinds of information

This was more than a search box over proposal PDFs. I designed canonical People and Project records, then connected them to Reference records that pointed back to proposal sources. The goal was to make people, projects, stories, and evidence easy to find together without treating every mention as proof.

The relationships let me move from a person to linked projects, then into the stories and source records associated with that work. A project could lead back to its people and to the proposal material, client, municipality, state, or other context connected to it. I no longer had to guess at those connections or reconstruct them by hand across files.

Before trusting a person to project link, I looked for an associated story or a proposal source marked WON. Proposed teams rarely changed after award, so that label was a useful confidence signal. It was not proof of every individual’s work. If neither a story nor a WON source supported the connection, I called to check. That manual fallback was rare because the system already had extensive project and people information.

The diagram shows People, Projects, and Reference records as connected information types. References point back to proposal sources; the implementation did not provide standalone Reference pages.

A research workflow with a person in the loop

The workflow is deliberately a sequence of research decisions, not a one click answer. A search result is a starting point. It has to survive a source check and a fit check before its language is adapted for a live pursuit.

1. 01
   Translate the pursuit question

   Start with the actual need in the owner’s request: a type of experience, constraint, relationship, delivery approach, or project context. Preserve the important qualifiers instead of searching only for a broad building type.

2. 02
   Search for candidate experiences

   Look across prior proposal material for accounts that may answer the need, even when the older document describes the work in different words. A candidate is a lead to investigate, not an approved claim.

3. 03
   Read the result in context

   Understand what the source was answering and what surrounding details qualify the passage. A résumé listing or project description may help identify a job without showing that the team performed the specific work being requested.

4. 04
   Open the original evidence

   Compare the proposed wording with the original source page. Check the language, context, and limitations before carrying anything forward.

5. 05
   Make the reuse decision

   The proposal writer decides whether the experience fits the new pursuit, what it supports, and how to express it accurately. If the source does not substantiate the claim, the result should not be used as proof.

The local proof of concept supported this research loop. This description does not imply that every step is automated or that the national platform already implements the full model.

A small, specific search made the idea concrete

One live pursuit needed a story about a career fair that matched a specific community context. The local system surfaced a story from an earlier proposal that was an exact fit. A broad list of school projects would not have answered the question; the useful result was the specific event and experience.

I opened the original proposal and checked the source, then pasted the story into the proposal I was working on. I changed the project title to the one we were pursuing and shortened the passage. The story itself needed no substantive rewriting.

This is what made the result useful: the system found a story at the right level of detail, and the original proposal let me verify it before reuse. The source check stayed part of my work, but the content was already specific enough to carry forward.

The public version intentionally withholds the client, project, and source page details. This preserves the structure of the problem without exposing proposal material.

Trust came from making evidence inspectable

Proposal language can represent the firm on a multimillion dollar project. A claim that sounds plausible but is not supported can create reputational risk and put the pursuit team in a bad position during an interview. That made source visibility a product requirement, not an optional citation treatment.

I did not want an answer that merely sounded confident. I wanted to know which prior page it came from and to be able to compare the claim with that page. In the local workflow, I asked for screenshots of the exact source pages behind promising results. I could then check whether a summary preserved the original meaning or introduced something the source did not say.

The difference between “related” and “supported” became central:

This approach keeps the human role concrete. People do not just approve an AI answer in the abstract. They inspect a source, interpret its limits, and decide what claim it can carry.

Wrong matches showed what the system misunderstood

One search mixed two similarly named facilities and pulled in related projects as if they were the same. I corrected the project identity and clarified what “collaboration” meant in the pursuit question. The available material supported a factual project summary, but not the incident and response story the question asked for. The right result was to expose that gap rather than force a narrative.

A separate correction changed what the library counted as a story. Project descriptions had been included as narratives even when they did not describe an event or response. I set a stricter threshold, removed descriptions from the story count, and added stronger proposal derived accounts.

The same feedback loop improved local retrieval fixtures. In a paired test for “occupied campus phasing,” the result changed from one all term match plus three partial matches to the all term match alone. The saved fixture checks went from 9 of 12 to 12 of 12. Those checks covered routing and evidence boundaries, not overall semantic accuracy or proposal productivity. Some sampled searches also became slower.

The tradeoff was clear: broader retrieval could surface more leads, but it also added noise. The local work favored a smaller, more specific result set while keeping source checks and manual follow up available when evidence was thin.

Why I started with a local evidence library

The source material can include proposal responses, project details, and information about the people who worked on jobs. I built the proof of concept around a private local corpus on disk rather than treating sensitive material as ordinary content for a cloud search product. That was a practical trust boundary while exploring how the workflow should behave.

Local first also kept the experiment appropriately scoped. It let me test the core question on real proposal work: could an AI assisted workflow help surface a specific story, and could I inspect enough of its evidence to decide whether it belonged in a response? It did not turn the prototype into a shared team platform, and I do not describe it as one.

There is a meaningful product boundary here. A local research tool can help one person find and examine material. A national system has to support broader information flow, ownership, review, and reuse across the organization. Lessons from the first workflow can inform that design, but they do not mean the larger system is already deployed.

The work now informs a national effort

I initiated the project and directed its development: the original problem, research workflow, definition of a useful story, information architecture, evidence expectations, and iterative review were mine. I used AI to help implement the local proof of concept, then evaluated its output against actual proposal work.

I used the local system on real proposal work. When the team saw it finding specific stories in older proposals, they began developing a national version. The new system is being built as a ChatGPT plugin with source material organized in SharePoint. It is still in development; I have not used the plugin yet.

My upcoming role is to test it with genuine proposal questions, comparing its answers with the local tool I already trust. I will check whether it gives the exact RFQ snippets supporting an answer and the exact date the proposal was submitted. If it cannot confidently find evidence, it should say it does not know rather than guess. I want the snippet and date so I can verify the claim and retrieve the source myself when needed.

The pilot has not happened, so these are evaluation criteria, not results. I continue to contribute to architecture and information flow discussions and share learning from the local system. I do not claim measured organization wide adoption, time savings, proposal wins, or national rollout.