🚀
Joist AI is now Kantiv. Same team. Bigger vision. Read our story →
A comprehensive index of terms and phrases used in the architecture, engineering and construction industry, curated by Kantiv.
An AI agent is a software system that pursues a multi-step goal autonomously: selecting its own actions, calling external tools, and deciding when it has finished, rather than waiting for a human to direct each step.
Most AEC marketing teams have used AI as a question-and-answer interface: you write a prompt, you get output, you decide what happens next. Agents invert that model. Given a goal like "assemble a draft past-performance section for this SF-330," an agent might query a project database, pull relevant narratives from a content library, check personnel assignments, and stitch a draft together before a human ever reviews a line. The critical difference is that each intermediate decision compounds: if the agent misidentifies a project as relevant in step two, everything built on that selection is contaminated. In a proposal context, where an owner's evaluator may catch a mismatched project scope or a wrong contract value, that compounding error is not a minor inconvenience.
The practical risk in agentic systems is not that they fail completely; it is that they fail partially and confidently. An agent assembling Section H of an SF-330 might pull a project with the right keywords but the wrong client, or cite a team member who has since left the firm. Because the agent presents finished output rather than intermediate reasoning, a proposal coordinator under deadline pressure may not interrogate it the way they would a colleague's first draft. Hallucination compounds here: one fabricated detail in a past-performance write-up can invalidate an entire submission if it contradicts information the client already holds. Agentic systems benefit significantly from human-in-the-loop checkpoints at decision junctions, not just at final review.
An agent is only as trustworthy as the data it can reach. A system with no access to verified project records, accurate personnel data, or confirmed award history will manufacture plausible-sounding substitutes; that is the hallucination problem applied at scale and speed. Before any agentic workflow touches live proposal content, a firm needs clean, structured institutional knowledge that the system can actually retrieve and verify against. Kantiv addresses this by grounding retrieval in a firm's own verified pursuit history and project data, so that when agentic features execute multi-step tasks, they are drawing from confirmed records rather than generating from pattern alone.
The hours that disappear first are the retrieval hours. A proposal coordinator assembling a past-performance section for an SF-330 typically spends a significant portion of pursuit time not writing, but hunting: searching shared drives for the right project narrative, cross-referencing contract values against what was submitted last time, confirming which key personnel were actually on a given job. An agentic system with access to verified project records can execute that retrieval loop autonomously, surfacing the five most relevant past projects against a specific NAICS code and scope description before the coordinator has finished her first cup of coffee. The writing does not get automated; the archaeology does.
For BD managers, the decision that gets faster is go/no-go scoping. A well-grounded agent can pull the firm's win rate on similar project types, flag teaming conflicts from previous pursuits, and summarize relevant past performance gaps against a specific solicitation's evaluation criteria in the time it would previously take a BD coordinator to open three different spreadsheets. That shift moves the BD manager's attention from data collection to actual judgment: is this pursuit worth the cost of pursuit, and do we have the differentiators to compete on this scope?
In teaming scenarios, agentic systems address one of the more tedious coordination problems in AEC pursuit work. When a prime is assembling subconsultant past-performance contributions for Section F of an SF-330, the back-and-forth to collect, format, and verify each sub's project data can consume days. An agent that can ingest submitted project sheets, check for required data fields, and flag missing contract values or incomplete owner contact information before a human reviews the package cuts that cycle time substantially. The coordinator still makes the judgment calls; she is just not manually triaging every submission.
Personnel sections benefit similarly. Matching key personnel to project role requirements, confirming their hours on relevant past projects, and drafting their project-specific experience bullets for Section E are each individually small tasks that collectively consume hours per pursuit. An agent that can query a personnel database, match against solicitation requirements, and produce a first draft of experience bullets grounded in confirmed project assignments gives a proposal writer a meaningful head start rather than a blank page.
Talk to the people building it, not the people selling it. This is not a general preference; it is specific advice for evaluating agentic systems, where the meaningful decisions about how an agent handles intermediate errors, what it does when retrieval returns ambiguous results, and how it flags uncertainty are engineering and product decisions, not sales decisions. If a vendor cannot get you thirty minutes with a founder or a product lead before you commit, treat that as information about how the relationship will go after you sign.
Run a real pilot on an actual pursuit. Not a curated demo on synthetic data built to make the system look good. Pick a live proposal your team is currently working on, give the system access to your actual project records, and ask it to do something specific: assemble a draft past-performance section, flag personnel conflicts, draft project experience bullets for a named key person. What you are evaluating is not whether the output looks polished; it is whether the output is accurate and traceable to real records. If the system surfaces a project you do not recognize, or cites a contract value you cannot verify, that is the test surfacing a real problem before it reaches an owner's evaluator.
Ask specifically what the system retrieves from and how accuracy is verified. "AI-powered" tells you nothing useful here. You need to know whether the system is retrieving from your firm's own confirmed project data or generating from pattern. Ask the vendor to walk you through exactly what happens when you ask the agent to pull past performance for a specific project type: what data source does it query, how does it confirm a match, and what does it return if the match is uncertain? If the answer is vague, or if the vendor pivots to talking about model quality rather than data grounding, the system is likely generating plausible content rather than retrieving verified facts.
Ask what happens when the agent makes a wrong intermediate decision. This is the question that separates mature agentic systems from systems that are impressive in demos and dangerous in production. If an agent misidentifies a project as relevant in step two of a five-step assembly task, does it flag that uncertainty, does it proceed and note the assumption, or does it proceed silently and present finished output as if nothing were uncertain? You want a specific answer, not a general statement about the system being designed for accuracy. Ask for an example of how the system has handled a retrieval conflict or an ambiguous match in actual use.
Finally, ask about your firm's data specifically. Agentic systems that work well for large firms with structured CRM data and clean project records may produce unreliable output for a fifty-person firm with project information spread across email threads, PDFs, and a shared drive that nobody fully trusts. Before committing, be honest with the vendor about the actual state of your institutional knowledge, and ask directly whether the system will be useful given that reality or whether it requires a data cleanup effort before it adds value. A vendor who answers that question honestly is a vendor worth working with.
Related terms
AI slop is proposal content generated by large language models without verification against actual project history, real résumés, or documented client relationships: text that sounds plausible but contains no institutional truth.
AEC proposals live or die on verifiable specifics. An evaluator scoring SF-330 Section F wants square footages, delivery methods, and named subconsultants, not synthesized descriptions that could belong to any firm in any city. When a language model hallucinates a project scope or inflates a PM's role on a past job, that content can survive reviews and reach a selection panel, where it either fails the sniff test or, worse, creates a compliance problem. The risk compounds on IDIQ task orders and JOC contracts, where past performance narratives are cross-referenced against previously submitted documentation by the same agency.
Slop rarely appears because someone deliberately cut corners; it appears because a coordinator under deadline pressure runs a generic prompt against a generic model with no firm-specific data as input. The model fills gaps confidently, and those gaps are exactly where accuracy matters most: client names, construction costs, project durations, and subconsultant roles. On a typical two-week RFP response cycle, there is not always time to chase down a PM for corrections before page assembly begins. The draft gets refined but not verified, and polished slop is still slop.
The deeper issue is not the AI; it is that most firms lack a fast, reliable path from a prompt to verified project data. If the information architecture exists, meaning tagged project records, confirmed résumé details, and documented win themes tied to specific clients, a model can generate content that is actually grounded. Without that architecture, the model invents because it has nothing real to draw from. Kantiv addresses this at the source by giving pursuit teams a knowledge layer built from the firm's own proposals, project data, and personnel history, so generated content reflects what the firm has actually done rather than what sounds like what a firm might have done. The output of an AI working against verified institutional context is not slop; it is a first draft worth editing.
Related terms
Answer Engine Optimization (AEO) is the practice of structuring content so that AI-driven systems, including ChatGPT, Perplexity, and Google's AI Overviews, surface it as a direct answer rather than a ranked link.
Owner organizations increasingly use AI chat tools to research potential consultants before issuing an RFQ. When a facilities director asks an AI which firms specialize in JECFA-compliant laboratory design or P3 transit work in the Southeast, the answer draws from indexed web content, published case studies, and structured firm data. Firms that have invested in SEO but not in answer-optimized content may rank on Google and remain invisible in AI-generated responses entirely. The distinction matters because AI answers typically cite one to three sources, not ten blue links.
AEO is not a proposal tactic; it operates upstream of the RFQ. The content that trains AI answers includes project profiles, award announcements, published thought leadership, and structured data on firm capabilities. BD teams that treat website project pages as static archives are building nothing that feeds an AI answer engine. Firms with consistent, specific, experience-rich content across public channels are more likely to appear in the shortlist a potential client mentally assembles before any solicitation goes public, which is the moment that actually matters for single-award IDIQ pursuits and negotiated GC contracts.
Most AEC firms cannot execute AEO well because the underlying content does not exist in usable form. Project outcomes are locked in proposal PDFs, personnel expertise lives in people's heads, and client history never makes it to a published page. Writing specific, verifiable, AI-readable content requires pulling from that institutional knowledge systematically, not drafting marketing copy from scratch each time. Kantiv surfaces verified project data, client context, and staff expertise so that content teams have the substance to produce the kind of specific, credible material that AI answer engines actually cite. The firms that will win on AEO are not the ones with the largest marketing budgets; they are the ones that can convert internal knowledge into public-facing specificity faster than their competitors.
Related terms
An award submission is a formal entry package prepared by an AEC firm for a juried recognition program, presenting a completed project as evidence of technical, design, or delivery excellence.
Every project generates marketing value at three points: pursuit, delivery, and closeout. Award submissions are how firms capture the third phase. A juried win is a third-party-validated credential that carries weight in SF-330s, shortlist presentations, and teaming pitches that a self-authored case study cannot replicate. These credentials belong in the work history section of qualification packages, not on lobby walls. Firms that skip the submission process leave marketing value from completed work on the table permanently, with no path to recover it later.
Effective programs are planned at the portfolio level, not project by project. Map target programs and their deadlines at the start of each calendar year, covering relevant bodies across disciplines: AIA, ACEC, AGC, ABC, ENR, SMACNA, NECA, MCAA, and applicable regional chapters. Select programs based on BD goals, not prestige alone, because a regional AGC win recognized by a target owner carries more pursuit value than a national award they have never heard of. Assign a named owner to each target submission and prioritize entries where documentation is strongest. Do not submit weak entries to high-profile programs; a poor showing in a visible competition is not a neutral outcome.
Architecture submissions center on professional photography and design narrative, which means commissioning the photographer at substantial completion rather than waiting until after occupancy. Engineering programs require quantified technical outcomes: load data, energy performance against baseline, schedule impact, and measurable performance results that satisfy a technical jury. General contractors hold the richest raw documentation of any party on a project but rarely organize it for submission purposes, so someone must be designated during delivery to tag milestone photography and capture subcontractor performance data in real time. Specialty contractors in MEP, concrete, steel, and interiors qualify for discipline-specific programs through SMACNA, NECA, MCAA, and ACI that most firms in those trades do not know exist or actively pursue.
The most common failure point is timing: most firms begin assembling documentation after the project is complete, when the delivery team has dispersed, photography was never commissioned, and the performance metrics a technical jury would require were never recorded. The result is entries built from whatever can be reconstructed under deadline, which rarely competes against entries assembled from documentation captured in real time. Firms that win consistently treat award documentation as a delivery task with assigned owners and defined checkpoints, not a closeout task triggered by a program announcement. Kantiv structures project closeout so the documentation award programs require is captured during delivery rather than reconstructed after the fact.
Related terms
The word "bid" carries meaningfully different definitions depending on where you are in the world — and in U.S. construction specifically, it applies to a narrower slice of the competitive process than most international practitioners expect.
In the United States, a bid is a fixed-price offer submitted by a general contractor in response to 100% complete construction documents. It is a price-driven exercise owned by the estimating department, not the marketing or business development function. The GC reviews drawings and specifications, quantifies scope, and submits a lump-sum or unit-price number by a defined deadline.
On public work, this process is tightly regulated. The Federal Acquisition Regulation (FAR) Part 36 governs federal construction procurement, and individual state procurement codes govern state and municipal projects. The award goes to the lowest responsive and responsible bidder. There is limited room for qualitative differentiation; the number is the submission.
Design services operate under an entirely separate framework. The Brooks Act (1972) prohibits the federal government from competitively bidding architect and engineer services on price. Selection must follow Qualifications-Based Selection (QBS), initiated through an RFQ or RFP evaluated on qualifications, experience, and approach. Most states have adopted parallel statutes. The practical consequence: calling an RFP response for design services a "bid" is technically incorrect under U.S. law, even though the term is used casually in the industry. For AEC marketing and BD professionals pursuing design work, the hard-bid process is largely not their domain.
In the United Kingdom, Australia, Canada, and much of continental Europe, "bid" functions as the umbrella term for any formal competitive submission. What Americans call a proposal, an RFP response, or a pursuit is simply a bid in these markets, regardless of whether it is price-driven or qualifications-driven.
The terminology cascade follows accordingly. A bid manager in the UK holds a role equivalent to a proposal manager or pursuit lead in the U.S. Bid writing means proposal writing. A bid library is a content library. The Association of Proposal Management Professionals (APMP) is widely recognized in international markets as the professional body for bid and proposal management, and its certifications are common credentials for practitioners working under the broader definition.
This creates real friction when firms operate across borders or bring on internationally trained staff. A UK bid manager hired into a U.S. firm may find that the role they were recruited for does not map to the title they held, because the scope, the deliverable, and the internal ownership are structured differently.
Firms expanding internationally, acquiring UK or Australian practices, or integrating global talent encounter organizational structures and workflows built around the broader definition of bid. Team titles, reporting lines, and process documentation will reflect that framing, and reconciling them with U.S.-based structures requires deliberate alignment.
The distinction also shapes tool selection in a direct way. Hard-bid construction work requires estimating software built for quantity takeoff and cost modeling. QBS design pursuits require a different infrastructure: pursuit tracking, content management, institutional knowledge capture, and interview preparation. Kantiv is built for that second environment, supporting the qualifications-based pursuit process that governs design services in the U.S. and its equivalents in international markets.
Related terms
Boilerplates, go-bys, and narratives are reusable written assets that describe a firm's qualifications, approach, or experience: boilerplates are standardized passages used across many proposals, go-bys are prior submissions repurposed as structural templates, and narratives are the substantive project- or service-specific stories that do the persuasive work in a pursuit.
Most teams use these three terms interchangeably, which is where quality control breaks down. A boilerplate firm overview has a different update cycle and ownership than a project narrative written for a specific SF-330 Section F submission. Go-bys carry structural risk that boilerplates do not: a go-by pulled from a 2019 CMAR submission and dropped into a design-bid-build pursuit can introduce the wrong delivery language, wrong fee framing, and wrong evaluation criteria assumptions before anyone notices. The most experienced proposal managers keep these categories mentally separate even when the file system does not, because the failure modes are completely different.
In most firms under 500 people, boilerplates and go-bys live in a shared drive organized by whoever last touched them, which means freshness and accuracy are unknown at the moment of need. A two-week RFP timeline does not leave room to audit whether the firm overview still reflects current staff counts, office locations, or active licenses before it goes into Section B of the SF-330. Narratives are worse: they often exist only as PDFs of submitted proposals, making them hard to extract, harder to update, and nearly impossible to search by relevant attribute like project size, client type, or delivery method. The version a proposal coordinator pulls on day one may have been accurate for a 2021 shortlist submission and wrong for everything since.
Maintaining these assets is not an archiving task; it is a continuous editorial task. Boilerplates need assigned owners, a defined review cadence tied to real triggers (a merger, a licensing change, a rebrand), and a visible last-verified date. Go-bys should be tagged with enough context to make their source pursuit legible: client type, delivery method, project size, and whether the firm won. Narratives benefit most from structured metadata because they are the assets most likely to be retrieved under pressure and dropped in without review. Kantiv connects these assets to verified project records and personnel history, so when a narrative surfaces during a pursuit, the team can see what it was originally written for and whether the underlying facts still hold. Treating these three asset types as a single undifferentiated pile is one of the cleaner explanations for why shortlisted firms still submit proposals with stale data.
Related terms
Brand identity is the set of visual, verbal, and experiential signals a firm controls: its logo, typography, color system, imagery style, voice, and positioning language, all functioning together to create a consistent impression across every client-facing document.
In AEC, brand identity does real work at the shortlist stage. When three to five firms are presenting to the same selection committee, differentiation often comes down to how confidently and consistently a firm presents itself, not just what it has built. A firm whose SF-330, qualifications package, and interview materials all feel like they came from the same place signals organizational discipline. Evaluators notice inconsistency: a cover with one typeface, section dividers with another, and a project sheet pulled from a two-year-old template reads as a firm that does not have its act together. Brand identity is not decoration; it is a credibility signal.
The breakdown almost always happens at the content layer, not the design layer. A firm may have a polished style guide, correct logo files, and approved color palettes, and still produce proposals where boilerplate narratives use outdated positioning language, résumés use an old title format, and subconsultant pages look like they were designed by someone else entirely. Proposal coordinators working under a two-week RFP deadline rarely have time to audit every inherited asset for brand compliance. Over time, a content library fills with approved-looking materials that carry old messaging, superseded project names, or language that contradicts the firm's current market positioning. The gap between the brand guide and what actually ships in proposals widens pursuit by pursuit.
Treating brand identity as a static design document is the mistake. The firms that maintain it effectively treat it as a living knowledge system: positioning language is versioned and tagged, approved project descriptors reflect current narrative strategy, and staff résumés are updated on a schedule tied to project close-out rather than left to individuals. When a pursuit team pulls firm overview copy or a project narrative from a system that surfaces verified, current content, brand consistency follows naturally from the retrieval process rather than depending on whoever is managing the InDesign file that week. Kantiv connects proposal content directly to the institutional knowledge that should govern it, so what teams pull into a pursuit already reflects current positioning instead of requiring a manual audit before every submission.
Related terms
Brand voice is the consistent personality, tone, and word-choice patterns a firm uses across all written communications, from proposal cover letters to interview follow-up emails, that make its output recognizable as distinctly its own.
Most AEC firms produce written content through a rotating cast of contributors: seller-doers drafting project approach sections, subject matter experts annotating resumes, coordinators stitching it all together under a two-week deadline. Each person writes the way they write. The result is a proposal that reads like four different firms submitted it. Unlike a consumer brand with a dedicated copywriting team, AEC marketing staff are editors as much as writers, which means brand voice lives or dies in the redline pass, not the first draft. Firms that document voice at the level of specific sentence patterns ("We lead with outcomes, not with process descriptions") enforce it far more consistently than firms whose style guide stops at logo clearance and color palettes.
Voice governs more than adjective choice. It determines whether your firm writes in first person plural or third person, whether you name the client by name in every section or use generic pronouns, whether technical qualifications are stated as facts or framed as client benefits. On an SF-330, Section H is where voice does the most work: that is the one section evaluators read that has no required format, which means it reveals how a firm actually thinks. A firm with a disciplined brand voice uses Section H to establish a consistent point of view; a firm without one uses it to restate the same qualifications already listed in Section E and F.
Evaluators reading shortlist pools of three to five firms are pattern-matching, often without realizing it. A proposal that reads with a single, confident voice registers as more credible than one that sounds assembled, even when the underlying qualifications are identical. This is not a subjective preference; it affects how evaluators perceive organizational cohesion, which is a legitimate proxy for how a firm will perform on a project. The practical problem is that brand voice guidance typically lives in a PDF no one opens during a pursuit; Kantiv surfaces it as active context during drafting, so the voice standard is present when writers are actually writing, not archived where it cannot be found. Connecting voice guidance to a content library and to boilerplates and go-bys means brand standards operate as a workflow input, not an afterthought.
Related terms
Business development in AEC is the structured pursuit of new client relationships and project opportunities before an RFQ or RFP ever hits your inbox.
The distinction matters operationally. Proposals respond to solicitations; BD creates the conditions that make a solicitation winnable before it's issued. A firm with strong BD has already met the client, shaped their priorities, and positioned a key staff member as a trusted advisor by the time the procurement clock starts. Firms that treat BD and proposals as the same function often find themselves writing technically compliant submissions for opportunities they were never likely to win. The Brooks Act (1972) mandates qualifications-based selection for federal AEC services, but the groundwork that makes a firm's qualifications credible to a specific client happens months or years before SF-330 Section H gets drafted.
BD activity includes client entertainment, speaking engagements, industry conference presence, and deliberate follow-up after project close-out, but its core artifact is intelligence: who is planning what, when, with what budget, and through what procurement vehicle. Seller-doers carry much of this responsibility in mid-size firms, which means project managers and principals are simultaneously running active work and tracking future opportunities. The risk is that client intelligence lives entirely in individual heads and disappears when people leave or get overwhelmed. A BD director managing a pipeline of fifteen to thirty active opportunities needs documented context, not just contact records in a CRM.
When a pursued opportunity finally converts to an RFQ or RFP, the proposal team is supposed to inherit months of accumulated context: client preferences, previous conversations, competing firms, and relevant past project history. In practice, that handoff is almost always incomplete. The BD lead briefs the proposal coordinator verbally, the pursuit strategy is partially reconstructed from memory, and win themes get written without the specific client intelligence that would make them credible. Kantiv addresses this gap by capturing and surfacing the institutional knowledge that BD activity generates, so the pursuit team starts the proposal with verified context rather than a blank intake form.
Related terms
A business development director or manager at an AEC firm is the person accountable for identifying, qualifying, and advancing pursuits before an RFP ever hits the street.
Most BD directors operate in the 18-to-36-month window before procurement, when relationships are built, scopes are shaped, and the real intelligence about a project is still fluid. By the time a solicitation is published, a good BD director has already met the client, knows the evaluation criteria informally, and has positioned the firm against two or three likely competitors. The title varies: some firms use "Director of Business Development," others use "BD Manager" for a more tactical role that owns CRM hygiene and pipeline tracking rather than client strategy. In seller-doer firms, this work is distributed across principals and project managers, and a BD director functions as coordinator and coach rather than sole hunter. The distinction matters operationally because it determines who owns go/no-go authority and who controls pursuit budgets.
A BD director's core output is qualified opportunity pipeline, not proposals. They work closely with the proposal coordinator or proposal operations lead to hand off a pursuit with enough context that the marketing team isn't starting from zero: client priorities, competitor intelligence, fee sensitivities, and any past work the firm has done for this owner. The failure mode is a poor handoff, where BD captures relationship knowledge in someone's head or a loose email thread and the proposal team reconstructs it through internal interviews under a two-week deadline. BD directors at larger firms typically manage CRM platforms, coordinate with regional principals, and report pursuit metrics including hit rate to the CMO or CGO. At firms under 300 people, the BD director often writes, too.
BD directors are among the highest-concentration knowledge holders in any AEC firm: they carry client history, lost-pursuit debriefs, competitor patterns, and relationship context that rarely make it into a content library or project database. When a BD director leaves or transitions accounts, that context disappears unless it was captured somewhere structured. This is the specific gap that pursuit intelligence tools address; Kantiv pulls from proposal history, project data, and client records so that a pursuit handoff from BD to marketing starts with verified context rather than a blank intake form. Firms that treat BD knowledge as personal inventory rather than firm infrastructure consistently rebuild the same intelligence on every pursuit cycle.
Related terms
Chain of thought is a prompting technique that instructs a large language model to show its reasoning step by step before producing a final answer, rather than jumping directly to output.
In standard prompting, an LLM produces an answer with no visible logic behind it. Chain of thought changes that by forcing the model to externalize its intermediate steps, which creates checkpoints where a human reviewer can spot where the reasoning went sideways. For proposal teams, this distinction is not academic: a model that silently hallucinates a project scope or a client name gives you no trace to follow, while one that walks through its logic at least shows you where the error entered. The technique was formalized in a 2022 Google research paper and has since become a standard pattern in more sophisticated AI workflows. It is particularly useful when a task involves multiple variables, such as mapping personnel qualifications against SF-330 Section E evaluation criteria across a pool of fifteen resumes.
The most direct application is in complex go/no-go analysis, win strategy development, or project approach drafting, where the output needs to reflect conditional logic rather than retrieval alone. If you prompt a model to recommend a pursuit strategy, a chain-of-thought prompt asks it to first state what it knows about the client, then the competitive landscape, then the firm's relevant experience, and only then produce a recommendation. That sequence gives a proposal manager something to interrogate before the content reaches a writer or a principal. Without the visible reasoning chain, you are reviewing a conclusion without knowing what assumptions produced it, which is a significant liability when the output feeds a cover letter or an executive summary.
Chain of thought improves accuracy on reasoning tasks but does not fix bad source data. If the institutional knowledge feeding the model is incomplete, for instance if past project scopes are vague, personnel bios are outdated, or client history lives only in someone's memory, the model will reason coherently from a flawed foundation. Longer reasoning chains also increase token usage, which matters if your team is working through a system with volume constraints during a two-week RFP window. Kantiv structures the institutional knowledge that feeds chain-of-thought reasoning, so the model's visible logic steps trace back to verified project data, confirmed personnel records, and documented pursuit history rather than interpolated guesses. The technique only produces reviewable output when the inputs are worth reviewing in the first place.
Related terms
A chatbot is a software interface that accepts natural language input and returns a generated or retrieved response, using rule-based logic, a retrieval system, a large language model, or some combination of all three.
The term lumps together systems with radically different capabilities. A rule-based chatbot from 2015 follows decision trees and fails outside its scripted paths. An LLM-backed chatbot in 2024 generates novel text by predicting token sequences against a foundational model trained on billions of parameters. The distinction matters operationally: a rule-based system cannot interpret a question phrased in an unexpected way, while an LLM-backed system can, but it can also hallucinate a confident answer with no factual basis. In a proposal context, the failure mode shifts from "I don't understand" to "here is a plausible but fabricated project description," which is a harder error to catch.
Most AEC marketing teams encounter chatbots through one of three entry points: a general-purpose interface like ChatGPT used ad hoc by a seller-doer drafting a cover letter, a copilot embedded inside a CRM or proposal platform, or an internally deployed tool pointed at a firm's own content library. Each carries a different trust threshold. The ad hoc tool has no knowledge of your firm's past performance or client history; it invents plausible-sounding project details unless you supply them through careful contextual prompting. A copilot connected to structured firm data can surface real project data, but only as reliably as the underlying data is tagged, current, and scoped correctly. The gap between what a chatbot interface implies it knows and what it actually has access to is where proposal errors originate.
Chatbot quality in a pursuit context is almost entirely a retrieval problem, not a generation problem. The generation layer of any modern LLM is capable of producing fluent, well-structured prose; the constraint is whether the system has access to accurate, firm-specific context before it generates. Retrieval-augmented generation addresses this by pulling verified content from a vector database before the model writes anything, which replaces fabrication with grounded recall. Teams that skip this architecture and route queries directly to a base LLM will get polished language around hallucinated project scopes, wrong client names, and fee figures that bear no resemblance to actual history. Kantiv connects the chatbot interface to verified pursuit records, project data, and personnel history so that what gets generated reflects what the firm has actually done.
Related terms
A Chief Growth Officer (CGO) is a C-suite executive who owns the full arc from market positioning to signed contract, holding accountability for pipeline health, win rates, and the integration of business development and marketing into a single revenue-generating function.
Most AEC firms historically split growth functions between a marketing director who managed proposals and a BD director who managed client relationships, with neither owning revenue accountability end to end. The CGO role closes that gap. Where a CMO typically oversees brand, content, and proposal production, the CGO owns the number: total contract value pursued, hit rate by market sector, and the strategic decision of which clients and project types the firm should be chasing three years from now. At firms between 500 and 2,000 people, the CGO often inherits both functions and has to rebuild coordination between teams that developed separate workflows, separate data, and sometimes separate CRM instances. The non-obvious friction point is that proposal coordinators and BD managers rarely report through the same chain before a CGO arrives, which means pursuit data is fragmented by design.
A CGO rarely writes a single line of proposal copy, but their decisions shape every pursuit from go/no-go through debrief. They set the go/no-go criteria that filter which RFPs the team responds to, define the win themes that should run through every SF-330 Section H, and are often the executive who reviews debrief notes to recalibrate sector strategy. In QBS-governed public procurements under the Brooks Act, where price is off the table and qualifications carry everything, the CGO's job is to ensure the firm's positioning work happens before the RFQ drops, not after. They also own the relationship with practice area leaders and principals whose project work feeds the win rate data the CGO reports to the board or ownership group.
The most common failure mode for a newly installed CGO is inheriting a growth function with no reliable data underneath it: win rates calculated inconsistently, project experience scattered across individual hard drives, and pursuit histories that live in the heads of people who have since left the firm. Without a structured record of what was pursued, who worked on it, and why the firm won or lost, strategic decisions default to instinct and seniority rather than pattern. A CGO trying to make a data-backed case for entering a new market sector, or for dropping a sector where hit rate has been poor for four years, needs verified pursuit history, not anecdote. Kantiv gives CGOs that foundation by capturing pursuit context, outcome data, and personnel contributions across the full pursuit cycle, so growth strategy is built from what actually happened rather than what the team remembers. The firms that get the most out of a CGO hire are the ones that treat institutional knowledge as infrastructure, not an afterthought.
Related terms
A Chief Marketing Officer (CMO) in an AEC firm is the senior executive accountable for brand strategy, business development infrastructure, marketing operations, and the organizational systems that convert technical capability into competitive pursuit performance.
Unlike a CMO at a product company, an AEC CMO rarely owns a marketing budget that drives direct revenue. The firm's revenue runs through pursuits, relationships, and QBS-governed selection processes under the Brooks Act, not advertising campaigns or conversion funnels. That context shapes everything: the CMO's real mandate is building the operational infrastructure that lets seller-doers compete consistently, from go/no-go discipline to proposal production capacity to client relationship systems. At a firm of 500 or more, the CMO is typically managing a team that spans proposal coordinators, graphic designers, content managers, and sometimes a pursuit strategist or knowledge manager, each touching a different layer of the pursuit pipeline. The measure of marketing's performance is win rate and shortlist conversion, not impressions or click-through rates.
Most CMOs are not writing proposals. They are setting the conditions under which proposals get written well: standardizing go/no-go scorecards, establishing win strategy and theme development processes, and ensuring the content library stays current enough to be usable under a two-week RFP turnaround. In practice, the CMO is often the person negotiating with practice area leaders and principals over which pursuits deserve full investment and which should receive a lighter-touch response. They also own the debrief process, which is where hard data on selection criteria, evaluator feedback, and competitor positioning should feed back into the next pursuit cycle. Firms that treat debriefs as optional tend to have CMOs who haven't yet made them a required close-out step.
The persistent problem for AEC CMOs is institutional knowledge loss: a senior project manager leaves, a long-client relationship walks out with them, and the next pursuit team rebuilds context from scratch. Proposal teams default to boilerplates, go-bys, and narratives that may be years out of date, and no one in a two-week sprint has time to verify them against actual project records or current personnel expertise. The CMO who treats this as a staffing problem will keep hiring; the CMO who treats it as a systems problem will invest in infrastructure that captures and surfaces verified context before a pursuit starts. Kantiv functions as that infrastructure: it indexes proposals, project data, and personnel expertise so the team starts from current, confirmed information rather than reconstructed memory.
Related terms
Close-out, in AEC marketing, is the structured process of capturing pursuit data, recording outcomes, and organizing final deliverables after a proposal has been submitted so the institutional knowledge built during the pursuit is not lost when the team moves on.
A proposal effort generates more usable intelligence than most firms ever recover: refined project descriptions, negotiated fee structures, win themes that survived internal review, and client objections surfaced during interviews. When close-out doesn't happen, that material degrades inside email threads and local drives within weeks. The next team pursuing the same client or a similar scope rebuilds from scratch, often producing narratives that contradict what was submitted before. Debrief notes from an owner are especially perishable; a contracting officer's candid feedback about why a shortlist of four became three is exactly the kind of context that reshapes go/no-go thinking on the next pursuit, and it almost never makes it into a content library.
At minimum: the final submitted package with version control intact, the go/no-go scorecard used at pursuit entry, the win strategy themes as approved, any fee or scope data relevant to benchmarking, and the outcome with enough detail to be searchable later. For shortlisted pursuits, close-out should include interview prep materials and the questions asked. For losses, the debrief notes should tag the reason category: fee, qualifications, client relationship, scope misfit. Firms that track loss reasons by category over two or three years start to see patterns that no individual pursuit review surfaces on its own.
Most firms have a close-out checklist; far fewer have a place where closed-out information is actually retrievable during a future pursuit. A checklist filed in SharePoint satisfies the process requirement without solving the intelligence problem. The firms that get compounding value from close-out are the ones where outcome data, refined narratives, and client history feed back into something a pursuit team can query when they're under a two-week RFP timeline. Kantiv captures pursuit close-out data as structured, searchable context so that finalized project descriptions, approved win themes, and debrief notes surface automatically when a similar pursuit opens, rather than requiring someone to remember where last year's package was saved.
Related terms
Compliance, in AEC marketing, is the degree to which a proposal or qualifications submittal satisfies every explicit requirement in a solicitation document, including format, page limits, required forms, sequence, and submission method, where a single deficiency can trigger automatic disqualification before an evaluator reads one word of content.
Most public agencies run a separate administrative review pass before any technical scoring occurs. A proposal that exceeds the 15-page limit on Section C of an SF-330, omits a required subcontractor utilization form, or arrives via email when the RFP specified an online portal gets flagged at that first gate. Federal solicitations governed by FAR Part 36 and Brooks Act QBS procedures are particularly unforgiving because contracting officers have limited discretion to waive deficiencies that a competing firm satisfied correctly. State DOTs, transit authorities, and municipal clients often publish explicit compliance checklists in the RFP itself, and evaluators initial each line before the proposal enters scoring; if your team has never requested one of those checklists post-award through a public records request, the debrief language you received was almost certainly a summary, not the raw record.
The most common compliance failures are not careless omissions; they are version-control problems and late addendum misses. An RFP amendment issued ten days before submission that changes the page count, adds a required certificate, or modifies the submission portal URL can invalidate a submittal that was otherwise complete. Firms running two-week proposal timelines with four or five active pursuits simultaneously are most exposed because the person tracking addenda is often the same person assembling the InDesign file. A compliance matrix, built at go/no-go and updated at every addendum, is the mechanical fix, but it only works if it is reviewed by someone other than the writer during internal review, specifically because familiarity with the document creates blind spots.
A fully compliant proposal earns zero points for compliance. It simply survives to be evaluated on win themes, project approach, and the people you put forward. The strategic error is treating compliance review as a final step rather than a continuous one; by the time you are in close-out, fixing a compliance gap often means cutting content you spent days writing. Kantiv surfaces solicitation requirements alongside your draft content during assembly, so compliance gaps are visible against the actual RFP language rather than discovered during a midnight page count.
Related terms
Construction Manager at Risk (CMAR) is a project delivery method in which a construction manager joins the project during design, commits to a Guaranteed Maximum Price (GMP), and assumes financial responsibility for cost overruns above that ceiling.
Unlike design-bid-build, where the owner selects a contractor on price alone after design is complete, CMAR brings the builder into the owner's team early enough to influence constructability, phasing, and budget. This means the owner is selecting a construction partner on qualifications and relationship fit before a firm price exists. For BD teams, this shifts the competitive evaluation heavily toward preconstruction expertise, past GMP performance, and the perceived trustworthiness of the CM's cost estimating. A firm that cannot demonstrate a track record of GMPs that held is at a structural disadvantage regardless of its portfolio.
Proposal teams often underweight the preconstruction services section in CMAR submissions, treating it as boilerplate before the "real" project experience pages. This is a critical error: the owner's selection committee knows they will be working alongside this CM for months before a GMP is ever set, so evaluators scrutinize the proposed preconstruction team almost as carefully as the project executive. Staffing continuity commitments carry unusual weight here; if the person named as preconstruction manager will not stay on as the project superintendent or executive, make that transition explicit and justify it. Fee structure transparency also matters more than in lump-sum pursuits because the GMP hasn't been set yet and owners are nervous about cost exposure.
The intelligence that matters most in a CMAR pursuit is not the owner's published budget; it is whether the owner has used this delivery method before. First-time CMAR owners frequently do not understand the GMP negotiation process and may default to selecting the lowest proposed fee rather than the most credible cost manager, which changes how your firm should frame its value proposition. Experienced CMAR owners, by contrast, often have internal benchmarks for acceptable contingency percentages and preconstruction fees drawn from prior projects, so vague ranges in your proposal will read as a red flag. Tracking an owner's delivery method history across past projects, and flagging when they are piloting CMAR for the first time, is the kind of pursuit context that Kantiv surfaces so BD directors can adjust pursuit strategy before the RFQ drops.
Related terms
A content library is a centralized repository of pre-approved proposal assets, including project sheets, resumes, boilerplate language, and visual content, maintained so pursuit teams can retrieve and reuse materials without rebuilding them from scratch on every submission.
Most content libraries degrade within 18 months of creation because ownership is unclear and updating feels optional until a deadline forces the issue. The more insidious problem is stale win themes: a project narrative written when a building opened three years ago rarely reflects what the client actually valued or what your firm learned from delivery. AEC-specific libraries must account for the lifecycle of a project reference, from pursuit through construction close-out, because the most compelling proof points only become available after the work is done. Firms that treat the library as a filing system rather than a living asset base consistently produce proposals that feel generic even when the underlying experience is strong.
The practical distinction is between archival content and pursuit-ready content: archival content documents what happened, while pursuit-ready content is pre-framed around client problems and evaluation criteria. Pursuit-ready project sheets include quantified outcomes, named challenges, and transferable lessons, not just scope descriptions and square footages. Resumes belong in modular form, with accomplishment bullets that can be reordered by project type or client sector rather than presented in a fixed chronology. Past performance narratives, differentiator statements, and subconsultant profiles round out a library built for speed without sacrificing relevance.
A content library without an assigned owner and a review calendar is a liability, not an asset, because teams will raid it under deadline pressure and submit outdated claims without realizing it. The governance model should specify who approves new content, how frequently project sheets are reviewed (quarterly is a practical minimum for active pursuits), and what triggers an immediate update, such as a project reaching substantial completion or a key staff member departing. Version control matters more than most firms acknowledge: submitting a resume with a previous employer listed, or a project budget that has since changed significantly, creates credibility problems that no writing quality can fix. Kantiv connects content library activity to live pursuit data, so teams can see which assets are being pulled for active opportunities and flag materials that are overdue for review. A well-governed library shortens pursuit cycle time and raises consistency across offices, which matters most for firms pursuing work in multiple regional markets simultaneously.
Related terms
Context engineering is the practice of deliberately assembling and structuring the information a pursuit team receives before and during a proposal effort, so that decisions, writing, and positioning are grounded in verified facts rather than assumptions or memory.
Most proposal failures are not failures of writing. They are failures of context: the team did not know about the prior relationship with the client, missed a fee dispute from three years ago, or wrote to a project scope that had already shifted. The word "engineering" is intentional here. Assembling context is not passive retrieval; it requires deliberate selection, sequencing, and filtering of what information reaches the team, when, and in what form. In a two-week proposal timeline, a team that starts with structured context on the client, the project type, and the relevant firm experience compresses days of internal archaeology into hours.
Practically, it means pulling the right inputs before the kickoff call, not during it: past performance on comparable project types, the pursuit history with this specific client, which staff members have direct relationships, and any prior debriefs from losses on similar work. For federal pursuits requiring an SF-330, that means having Section F project examples pre-qualified against the NAICS code and evaluation criteria before anyone opens a draft. For QBS-governed work under the Brooks Act, it means surfacing qualifications data in a form the selection committee will recognize, not in the form it was originally filed.
AEC firms accumulate enormous amounts of pursuit-relevant knowledge across proposals, project closeouts, CRM notes, and the heads of senior staff. Almost none of it is findable under deadline. A BD director with 25 years at a firm may carry accurate, detailed client intelligence that exists nowhere in a system; when that person is traveling during a shortlist preparation sprint, the team improvises. Context engineering treats that institutional knowledge as infrastructure to be captured and surfaced systematically, not recalled on demand. Kantiv is built around this problem specifically: it captures context from proposals, project data, and client history, then surfaces the relevant subset when a new pursuit begins, so the team starts from a verified baseline instead of a blank page.
Related terms
Contextual prompting is the practice of supplying an AI language model with structured background information alongside a task instruction, so the output reflects the specific pursuit rather than a generic interpretation of the request.
In a proposal environment, context is not a paragraph of boilerplate about your firm. It is the specific information the model cannot infer: the client agency, the procurement vehicle, the evaluation criteria pulled from Section 00 21 00, the relevant project experience your team has already identified, and the name of the evaluator if you have it. A model prompted with "write a project approach for a water treatment plant" produces something publishable but generic. The same model prompted with the RFP's stated evaluation weight on O&M continuity, your firm's comparable project from a municipal client in the same state, and the SF-330 Section H page limit produces something a proposal writer can actually edit toward final. The gap between those two outputs is entirely a function of what context was supplied, not the capability of the underlying model.
Most AEC teams encounter this technique between shortlist notification and the interview prep sprint, when time compression is worst and the temptation to generate fast is highest. A well-constructed prompt for a cover letter might include the win theme from the go/no-go scorecard, two sentences about the client's stated priorities, and the page and tone constraints from the RFP. A poorly constructed one includes none of that and produces prose that has to be gutted before it is usable. Contextual prompting is also where compliance failures sneak in: if the evaluation criteria are not part of the context, the model has no way to weight its output toward them, and a proposal writer under deadline may not catch the misalignment until internal review.
Adding more text to a prompt is not the same as adding structured context. A 400-word paragraph of unorganized background information produces worse results than four labeled fields: client, procurement type, evaluation criteria, relevant experience. Structure signals hierarchy to the model; prose buries it. The practical constraint is that useful context has to come from somewhere verified: past proposals, project records, CRM notes, debrief summaries. If a team is manually hunting for that information at prompt-writing time, the technique breaks down under deadline pressure. Kantiv surfaces verified pursuit context from institutional records directly into the prompting environment, so the background a writer supplies to the model is accurate before the first draft is generated.
Related terms
A cover letter in an AEC proposal is a signed, one-to-two-page document addressed to the client that frames the firm's pursuit narrative before the evaluator reaches the technical content; it is the only section written entirely outside the RFP's required format, which makes it both the most flexible and most frequently wasted opportunity in the submission.
Federal procurement evaluators are instructed to score SF-330s on the sections defined in the solicitation, and the cover letter is technically outside that scoring matrix. That does not make it inconsequential. A cover letter tells the contracting officer who signed off on the submission, confirms the firm has read the scope, and establishes tone before a single scored page is read. On state and municipal procurements, where evaluation panels often include non-technical stakeholders like elected officials or city managers, a clearly written cover letter carries disproportionate weight because those readers may not advance past it. The non-obvious fact: a cover letter signed by a principal or named project manager signals organizational commitment in a way that a marketing-staff signature does not, and some clients notice the difference.
Cover letters are almost always written last, under deadline pressure, by whoever has capacity rather than whoever has client knowledge. The result is a recycled block of boilerplate that restates the RFP title, lists three things the firm does well, and closes with a call to contact the office. That structure fails because it treats the cover letter as a formality rather than a place to demonstrate that the firm already understands the client's specific constraints: budget pressure, a compressed schedule, a politically sensitive site, a relationship with a subconsultant the client specified. A well-executed cover letter names those conditions explicitly and connects them to the project approach waiting inside the document. Teams that finalize the win strategy theme before drafting the cover letter produce markedly more coherent submissions than those that treat the two as separate tasks.
The cover letter is the correct place to handle anything the RFP did not ask for but that the firm needs the evaluator to know: a recent award on a comparable project, a staff addition that directly addresses a gap from a prior debrief, or a subconsultant relationship that differentiates the team. Burying that information inside a project approach section means it competes with technical content for attention; stated in the cover letter, it shapes how the evaluator reads everything that follows. The common misconception is that brevity alone makes a cover letter effective; a one-page letter that says nothing specific is weaker than a two-page letter that names the client's problem and explains why this team has already solved a version of it. Kantiv surfaces prior pursuit data, past cover letters on similar project types, and relevant client history so the writer starts from verified context rather than a blank page and a deadline.
Related terms
Customer relationship management (CRM) software is a category of platform that records a firm's interactions with clients, prospects, and teaming partners, organizing contact history, opportunity tracking, and pipeline data across the business development lifecycle from first outreach through awarded work.
Most CRM platforms were designed around transactional sales cycles where a qualified lead converts to a closed deal in weeks. AEC operates on qualification-based selection, mandated for federal work under the Brooks Act since 1972, where relationships precede published opportunities by months or years and where the "sale" is a scored evaluation of qualifications, not a negotiated price. AEC-specific platforms like Deltek Vantagepoint and Unanet CRM (formerly Cosential) account for this by organizing pipelines around agencies, project types, and teaming partners rather than product lines. What they all still depend on is consistent data entry, and that is precisely where most AEC CRM deployments break down: the seller-doer model puts relationship ownership in the hands of principals and PMs who log calls at a fraction of the rate a dedicated BD rep would. A contact record that shows two touchpoints in eighteen months probably reflects data discipline, not actual relationship depth.
The highest-value use of CRM in a pursuit context is upstream of the RFP: informing the go/no-go decision by surfacing how many documented touchpoints exist with the client, whether a preferred teaming partner is already committed to a competitor, and how the firm has performed on prior shortlists with this agency. During active pursuit, BD teams should use CRM to identify which principal carries the strongest documented relationship with the key evaluators, not just the closest geography. After award or debrief, loss reasons and evaluator feedback belong in CRM immediately, before the pursuit team moves to the next deadline and that institutional knowledge disappears. Firms that treat CRM updates as post-pursuit housekeeping rather than pre-pursuit intelligence generation are effectively paying for a contact database.
Design-bid-build is a project delivery method in which an owner engages a designer under one contract, waits for construction documents to reach a defined completion threshold, and then solicits competitive bids from contractors under a separate contract, with selection driven primarily by price.
Because the design is largely fixed before contractors compete, the owner's risk calculus during the design phase is almost entirely about qualifications, not price. This is where QBS applies most cleanly: the Brooks Act (1972) mandates qualifications-based selection for federally funded A/E services, and many state equivalents mirror that structure for design-bid-build public work. What experienced BD teams sometimes miss is that the contractor bid phase creates a second window of owner anxiety: if bids come in over budget, the owner often returns to the designer for scope reductions, and that relationship history matters the next time the owner is selecting a designer. A firm that has helped clients navigate post-bid value engineering quietly accumulates credibility that never appears in a project data sheet.
On the design side, SF-330 Section F (example projects) needs to reflect completed, bid, and built work rather than projects that were designed but handed off to a design-build entity, because owners evaluating design-bid-build pursuits are implicitly asking whether your documents can survive a hard-money competitive bid environment. A project that was designed under one delivery method and then repriced under another is not the same reference. Shortlist pools for public design-bid-build work typically run three to five firms, and the evaluation criteria in the RFQ or RFP will often include questions about your firm's cost estimating integration during design development, because document quality directly determines bid spread. Wide bid spreads and rejected low bids are a known liability for design teams, and sophisticated owners track that history even when they don't ask about it explicitly.
Design-bid-build pursuits accumulate a type of data that most firms store poorly: the gap between the engineer's estimate at construction document completion and the actual low bid. That number, tracked across a project portfolio, is one of the clearest signals of document quality and estimating discipline, and it's exactly the kind of proof point a client services director wants to cite in a cover letter or project approach section. Most firms can't retrieve it because it lives in a project manager's memory or an archived email thread rather than in any system the marketing team can query. Kantiv captures that post-bid outcome data alongside the original project record so pursuit teams can surface it when an owner's evaluation criteria reward demonstrated cost reliability, without reconstructing it from scratch two days before submission.
Related terms
Design-build is a project delivery method in which a single entity holds contracts for both design and construction, making that entity solely responsible to the owner for schedule, cost, and quality.
Unlike design-bid-build, where an AEC firm competes on design merit alone, design-build pursuits require a teaming agreement before the proposal is written. The contractor-designer relationship must be locked in early, which means BD teams are negotiating team roles, fee splits, and liability exposure simultaneously with developing win themes. Owners evaluating design-build submissions score technical approach, past performance, and price together, so a proposal that separates those elements reads as organizationally unprepared. The pursuit clock also starts earlier: firms that wait for an RFP to identify a construction partner routinely lose to teams that have been cultivating that relationship for months.
Most design-build RFQs require demonstrated experience as the design-build entity, not as a subconsultant or prime on a traditional delivery project. A firm with 40 years of design experience may be disqualified if it cannot show projects where it held the design-build contract directly. Past performance narratives must reflect integrated delivery outcomes: schedule compression, single-point accountability, and owner cost certainty. BD teams should audit their project database specifically for delivery method before shortlisting relevant experience, because misfiled projects waste proposal hours and weaken technical sections.
Design-build market share has grown consistently across federal, transportation, and municipal sectors, which means BD directors who built their pipelines around traditional delivery are now competing in a different qualification environment. Teaming strategy becomes a standing BD activity rather than a pursuit-by-pursuit reaction: maintaining pre-qualified contractor relationships, understanding each partner's bonding capacity, and knowing which owners prefer contractor-led versus designer-led structures all affect go/no-go decisions before a project is ever advertised. Kantiv surfaces design-build opportunities by delivery method, letting pursuit teams identify relevant project types early enough to build the right team before an RFQ drops. Firms that track design-build pipeline separately from traditional delivery can allocate teaming resources more precisely and avoid the scramble that produces weak partner agreements.
Related terms
A digital asset is any file that a marketing or BD team owns, stores, and reuses across pursuits: project photographs, renderings, resume templates, past proposal sections, SF-330 exhibits, award submissions, and boilerplate narratives.
The term sounds broader than it behaves in practice. For AEC marketing teams, the assets that matter are the ones that get pulled into proposals under deadline: a high-resolution site photo from a completed transit project, a fee matrix from a similar scope, a tailored project description written for a previous QBS submission. The distinction between a digital asset and a random file on the server is intentional organization; an asset has metadata, an owner, and a known location. Most firms have thousands of files that could be assets but function as clutter because no one tagged them, dated them, or connected them to the projects they document.
A two-week RFP response window does not leave room for archaeology. When a proposal coordinator cannot find the current rendering of a water treatment facility or cannot confirm which version of a project description cleared the client for public use, the team either defaults to older material or rebuilds from scratch. Both options cost hours that should go toward win strategy and differentiators. The deeper problem is that asset failure is often invisible at go/no-go: teams approve pursuits assuming the supporting material exists in usable form, and discover otherwise during production. Firms that track asset completeness by project type catch this gap before it lands in the schedule.
A shared drive stores files. A content library with consistent tagging by project type, client, geography, delivery method, and size makes files retrievable under deadline. Many firms conflate these two things, investing in storage capacity while underinvesting in the taxonomy that makes retrieval possible. The common misconception is that a digital asset management system solves this by itself; a DAM without a governance model for who tags, who updates, and who retires outdated files eventually becomes a more expensive version of the problem it replaced. Kantiv connects digital assets to the pursuit records and project data that give them context, so a team searching for a relevant project photograph or past technical approach section gets results tied to verified project history rather than filename guesses.
Related terms
A digital asset management system (DAM) is a centralized platform for storing, organizing, versioning, and retrieving the files an AEC marketing team uses across pursuits: photography, renderings, project sheets, templates, brand assets, and approved boilerplate text.
Most AEC DAMs hold production-ready files: finished project photography, rendered images at multiple resolutions, InDesign templates, logos in every required format, and PDFs of past submittals. What they rarely hold is the institutional knowledge behind those files: which project photo was approved for a specific client sector, why a particular rendering was pulled from circulation, or which boilerplate narratives are current versus flagged for revision. A file with no context attached is just a file. That gap matters most when a coordinator is pulling assets for an SF-330 Section F under a two-week deadline and has no way to verify whether the project shown in that photograph is actually comparable to what the RFQ requires.
A DAM supports the production layer of a pursuit, not the intelligence layer. It answers "where is the file?" but not "which file belongs in this pursuit and why?" During go/no-go, teams need project data tied to win criteria; during shortlist prep, they need accurate personnel information and relevant project narratives. A DAM surfaces assets but cannot resolve whether a project qualifies under FAR Part 36 thresholds, whether it reflects the right delivery method for a design-build pursuit, or whether the principal shown in a photo is still at the firm. That verification still lives in email threads, someone's memory, or a spreadsheet that may or may not be current.
DAM vendors and pursuit intelligence platforms solve different problems, and conflating them creates gaps that show up at the worst time. A DAM is a retrieval system for finished files; a pursuit intelligence platform captures the verified context that tells a team which of those files to use, for which client, in which competitive situation. Firms sometimes try to force a DAM into an intelligence role by adding metadata fields, but metadata without a governance process decays quickly: tags go unupdated, project records reflect old scopes, and staff credentials are never refreshed after a licensure change. Kantiv surfaces verified pursuit context directly from a firm's existing project data, proposal history, and personnel records, so the intelligence travels with the asset rather than sitting in a separate system no one updates.
Related terms
A Due Diligence Questionnaire (DDQ) is a structured pre-contract document issued by a client, JV partner, or acquiring entity requesting verified data on an AEC firm's financial health, bonding capacity, insurance limits, safety record, litigation history, and operational controls before work is awarded or a transaction closes.
Most proposal teams first encounter DDQs on large construction manager at-risk or design-build pursuits, where owners need financial assurance before a GMP negotiation begins. But DDQs also surface in merger and acquisition due diligence, JV formation, prequalification for federal IDIQ vehicles, and surety-driven bonding reviews. The scope is narrower than an RFQ package and more legally specific: clients are asking for audited financials, Experience Modification Rates (EMRs), OSHA 300 logs, and certificates of insurance, not project narratives or team resumes. A DDQ submitted with an inflated EMR or outdated bonding letter is a disqualifying event, not a minor compliance miss.
Marketing and BD rarely owns the DDQ outright; the information lives across finance, legal, HR, and risk management. What the proposal team typically owns is coordination: collecting verified data from four or five internal stakeholders under a tight deadline that often runs parallel to the technical proposal itself. That simultaneous pressure is where errors compound. Bonding capacity figures get pulled from last year's prequalification package without checking whether the surety updated the limit after a large project closed out. Insurance certificates get attached without confirming the named insured matches the contracting entity. The proposal coordinator's job is not to generate the answers but to confirm that every answer is current, consistent, and traceable to a primary source.
The most common mistake is treating a DDQ response as a static document that can be copied from the last submission with minor edits. EMRs update annually in the first quarter; audited financials roll over on the fiscal year; bonding limits change when the backlog shifts. A response assembled from last cycle's files will often contain figures that contradict the current prequalification on file with the same client. Firms that maintain a structured record of when each DDQ data point was last verified, and by whom, catch these mismatches before submission rather than during a post-shortlist compliance review. Kantiv's pursuit intelligence structure ties DDQ data points to their source and last-confirmed date, so the proposal coordinator can see immediately which figures are stale before assembling the package.
Related terms
An embedding is a numerical representation of text, images, or other data as a vector of floating-point numbers, allowing a machine learning model to measure semantic similarity between pieces of content.
In AEC pursuit work, embeddings are the mechanism behind "find content like this" searches across past proposals, project descriptions, and resumes. Rather than matching keywords, an embedding model encodes meaning: a search for "adaptive reuse of historic structures" can surface a project narrative that never uses those exact words but describes the same scope. This is why modern proposal libraries built on embedding search outperform legacy keyword systems on long-tail pursuit queries. The vector distance between two embeddings is the mathematical answer to the question "how relevant is this past project to this RFP?"
Embedding-based retrieval becomes most valuable at the shortlisting stage, when a pursuit team is pulling relevant project experience and staff qualifications under deadline pressure. A proposal manager can paste an RFP scope paragraph and retrieve the ten most semantically similar project write-ups from a corpus of hundreds, without manually tagging or categorizing anything in advance. The quality of results depends heavily on what was embedded: clean, consistently structured content yields better vector representations than raw, inconsistently formatted source documents. Garbage-in still applies, even when the retrieval mechanism is sophisticated.
Most BD teams treat embedding search as a feature they turn on; the more consequential decision is which embedding model generated the vectors stored in the database. Switching models later requires re-embedding every document in the library, because vectors from different models occupy incompatible mathematical spaces and cannot be compared across models. Firms that embed their pursuit archive using a general-purpose model may later find that a domain-specific model trained on construction or government procurement language produces materially better retrieval results for AEC content. Kantiv uses embeddings as the retrieval layer connecting RFP requirements to your firm's historical pursuit data, so that relevant experience surfaces by meaning rather than by metadata tag.
Related terms
An enterprise resource planning (ERP) system is a firm-wide software platform that consolidates finance, HR, project accounting, and resource scheduling into a single database, giving AEC firms a unified record of where money comes from, where it goes, and who is doing the work.
The dominant ERP platforms in AEC are purpose-built for the industry: Deltek Vantagepoint (formerly Vision), Unanet, BST Global, and to a lesser extent Oracle and SAP at larger firms. These systems track labor multipliers, overhead rates, utilization, contract ceilings, and project-to-date financials, all of which feed into indirect cost rate calculations that govern how a firm prices work on federal contracts under FAR Part 31. The project records inside an ERP include phase codes, client names, contract values, and team assignments, but those records are structured for accounting purposes, not for qualifications. A project might be coded correctly for billing and still have a description that reads "Phase 2 Civil" with no narrative, no scope context, and no detail useful to a proposal writer pulling together an SF-330 Section F.
Proposal teams sit at a frustrating distance from ERP. The data is accurate and current, but access is often restricted to finance and project managers, and the format is built for reports, not for go/no-go analysis or hit-rate tracking. When a BD director needs to know whether a pursuit aligns with the firm's profitable project types, that answer lives in ERP fee versus actual data, but pulling it requires a custom report or a call to accounting. Resource availability is another gap: ERP tracks utilization, but proposal coordinators building a people-project matrix for a shortlist presentation rarely have live visibility into whether the technical lead they're featuring is actually available during the project timeline. That mismatch between what ERP knows and what the pursuit team can see is where proposals get built on assumptions instead of verified data.
The common misconception is that ERP integration solves the proposal data problem. It doesn't, because ERP captures operational and financial truth, not the qualifications narrative around that truth. A completed project appears in ERP as a line item with a dollar value and a closeout date; what made that project worth citing in a proposal, which challenges the team navigated, what the client said at the debrief, none of that is in the ERP record. Connecting ERP project data to a content library requires a translation layer that enriches financial records with pursuit-relevant context. Kantiv pulls verified project data from sources including ERP and CRM systems, then surfaces it with the qualifications context a proposal team actually needs during an active pursuit, so the team isn't reconciling accounting exports against a shared drive of old proposals to confirm a fee range or a delivery method.
Related terms
Explainability is the degree to which an AI or scoring system can show its reasoning in terms a human decision-maker can verify, challenge, or act on.
AEC pursuits involve judgment calls that carry legal, financial, and reputational weight: which opportunities to chase, which partners to team with, which differentiators to lead with. When a platform scores a pursuit as high-priority or flags a client as winnable, the BD director needs to know whether that conclusion rests on win-rate history, budget signals, relationship depth, or something else entirely. A black-box score that simply outputs "87% fit" gives a proposal manager nothing to defend in a go/no-go meeting. Explainability converts a system's output into a reasoning trail that experienced professionals can interrogate.
In practice, explainability surfaces at three points in the pursuit cycle. At opportunity identification, it tells the team which signals drove a recommendation so they can confirm those signals against their own market knowledge. At go/no-go, it lets a BD director override or validate a system score with documented rationale rather than gut instinct alone. At debrief and pipeline review, an explainable system produces records that show why certain pursuits were prioritized, which supports process improvement over time rather than anecdote-driven correction. Firms that skip explainability at these stages often find that staff distrust the tooling and revert to spreadsheets.
A non-obvious risk: explainability failures compound over time. If a pursuit intelligence system recommends opportunities based on factors the team cannot inspect, the firm cannot tell whether its win-rate improvement came from the system's actual insight or from a favorable market cycle. That ambiguity makes it impossible to calibrate the system, retrain staff, or make the case to leadership that the investment is working. Explainability is also a procurement concern; some public-sector clients now ask primes to disclose AI use in proposal development, and a tool whose logic cannot be described creates compliance exposure. Kantiv is built so that every opportunity score surfaces the specific data points behind it, giving BD teams a defensible record rather than a confidence interval they cannot explain.
Related terms
A fee proposal (or fee letter) is a formal document submitted to a client that states a firm's proposed cost for delivering a defined scope of work, broken down by phase, discipline, or task, and structured to align with contract requirements or procurement rules.
Under the Brooks Act (1972), public sector QBS procurement prohibits discussing price until a firm is selected on qualifications alone. That means fee proposals for federal and most state work arrive late in the pursuit, after shortlisting, often in a separate envelope or submission sequence entirely. On design-build or CMAR pursuits, the structure changes again: cost may be part of a best-value evaluation from the start, requiring the fee document to be price-competitive rather than simply defensible. FAR Part 36 governs federal construction fee negotiations and sets specific expectations around cost breakdowns, overhead rates, and profit justification. Knowing which procurement path you are on determines when the fee document enters the process and how much detail the client actually wants to see.
A well-structured fee letter typically covers: labor by phase and discipline, direct expenses, subconsultant costs, exclusions, and any assumptions that cap the firm's exposure if scope changes. The exclusions and assumptions section is where most disputes originate; clients read past it during submission review, then cite it during construction when additional services come up. On public procurements, fee proposals are often subject to audit, which means your overhead multipliers and profit rates need to match what your accounting system can actually support. Submitting a fee structure that contradicts your firm's audited indirect cost rate, even unintentionally, can trigger a negotiation reset or disqualification.
Fee proposals are among the least-shared documents inside AEC firms. They live in project managers' folders, get attached to contracts, and rarely make it back to the marketing or BD team in any structured way. That creates a genuine problem: when a pursuit team is scoping a similar project type for a new client, they are often building fee structures from scratch instead of calibrating against what the firm has actually negotiated and delivered. The non-obvious risk is not just efficiency; it is accuracy. A fee estimate built without reference to comparable past projects tends to underprice complex phases and overprice straightforward ones. Kantiv captures fee-related context from past pursuits and project records and surfaces it during active pursuit scoping, so the team is working from verified history rather than instinct.
Related terms
A few-shot prompt includes two or more worked input-output examples inside the prompt itself, giving the model a concrete behavioral template to follow rather than relying solely on verbal instructions.
Language models are trained to predict patterns, not to follow rules. Telling a model to "write a project approach in an active voice, 150 words, focused on the client's drainage problem" produces inconsistent output because those instructions are interpreted differently across runs. Showing the model two or three prior project approaches that match those parameters narrows the output distribution toward what you actually want. The non-obvious implication: a few-shot prompt built from your firm's real SF-330 Section F narratives or shortlist-winning project descriptions does more formatting work than any style guide you can write out in plain language. Your existing proposal archive is, in effect, a prompt engineering asset most teams don't treat that way.
The highest-value moments for few-shot prompts are the ones where format and tone matter as much as content: win themes, project approach paragraphs, cover letter openings, and personnel qualification summaries. A typical two-week RFP response cycle doesn't leave room for repeated iteration on a blank-page output; a few-shot prompt front-loads that calibration before the first draft appears. The practical constraint is construction: you need to locate two or three genuinely relevant examples, confirm they're accurate, and structure them so the model reads them as templates rather than source material to paraphrase. That retrieval step is where most teams lose the time the technique would otherwise save on review cycles.
A few-shot prompt is only as good as the examples inside it. Using placeholder narratives, competitor boilerplate pulled from public submittals, or outdated project descriptions creates a precise-looking output that carries the wrong substance, which is a version of hallucination that's harder to catch because the format looks correct. In pursuit contexts, a wrong project scope or a misattributed client name in a Section E narrative can survive internal review and reach the owner. Kantiv surfaces verified project data, past proposal content, and personnel history so that the examples you use in a few-shot prompt are drawn from your firm's actual institutional record, not from whatever a writer remembered or a search returned. The difference between a few-shot prompt built on verified context and one built on approximation is the difference between a first draft that tightens on redlines and one that gets rebuilt from scratch.
Related terms
A foundational model is a large-scale AI system trained on broad datasets before any task-specific configuration, forming the base layer that purpose-built applications adapt, constrain, or extend for particular workflows.
GPT-4, Claude, Gemini, and Llama are foundational models. None of them were trained on SF-330s, FAR Part 36 procurement language, or the distinction between a CMAR and a design-bid-build delivery structure. They learned statistical patterns across the internet and large text corpora, which makes them capable of fluent prose and basic reasoning but unreliable on AEC-specific accuracy without additional configuration. The practical implication: a foundational model asked cold to describe your firm's approach to stormwater management on a federal campus project will produce something that reads professional and is probably wrong in the details that matter. What sits on top of the foundational model, the retrieval layer, the system instructions, the contextual grounding, determines whether output is usable or just plausible.
Most AEC marketing teams do not choose a foundational model directly; they choose a tool, and the model is embedded inside it. That abstraction has real consequences. Different foundational models have different context windows, meaning the maximum amount of text they can process at once. A model with a short context window may truncate a 40-page RFP before reaching the evaluation criteria section, producing a response that ignores the factors an agency will actually score. Foundational models also differ in how they handle ambiguity: some default to confident-sounding fabrication when source material is thin, a behavior called hallucination that is particularly dangerous when a pursuit tool is surfacing past project data or client history that needs to be accurate for compliance and credibility.
Firms evaluating AI tools for pursuit work often focus on the foundational model as the key differentiator, when the more consequential question is how that model has been configured: what retrieval mechanisms feed it verified context, what system instructions constrain its behavior, and whether a human-in-the-loop step exists before output enters a proposal. A capable foundational model with no grounding produces polished hallucinations; a moderate model with well-structured retrieval and firm-specific institutional knowledge produces answers a proposal manager can actually check and use. Kantiv is built on foundational model infrastructure but applies retrieval-augmented generation against verified pursuit data so that outputs surface from your actual project history, personnel records, and past proposals rather than from statistical inference alone.
Related terms
Generative Engine Optimization (GEO) is the practice of structuring content so that AI-powered answer engines, including ChatGPT, Perplexity, and Google's AI Overviews, cite or surface that content when generating responses to user queries.
Public-sector clients increasingly use AI search tools to research firms before issuing RFQs or initiating sole-source conversations. If your firm's project experience, key personnel, and market sector expertise aren't structured in ways these systems can parse and attribute, you won't appear in the answer, even if your website ranks well in traditional search. GEO prioritizes direct answerability: clear claims, named projects, verifiable outcomes, and authoritative sourcing. A case study that says "significant cost savings" loses to one that says "$4.2M under budget on a CMAR delivery for a K-12 district in Travis County."
Traditional SEO targets click-through; GEO targets inclusion in synthesized answers where no click occurs. For AEC firms, this distinction matters most in the awareness phase of a pursuit, when a program manager at a transit authority is asking an AI tool which firms have relevant light-rail station experience before that agency even drafts an RFQ. Content that answers specific, domain-level questions, staffing models for CM-at-Risk, typical fee structures under QBS, lessons learned on phased occupancy, tends to get pulled into generative responses. Static capability statements written for SEO do not.
The practical work involves converting institutional knowledge into attributable, answer-shaped content: project narratives with named clients and measurable outcomes, personnel bios organized around demonstrated expertise rather than credential lists, and sector-specific thought leadership that names the problems your clients actually face. Schema markup, structured data, and clear entity relationships (firm, project, client, location, delivery method) help generative systems understand what your content is about and who produced it. Kantiv surfaces this kind of verified project and personnel data during active pursuits, which makes it available not only for proposal writing but for the structured content publishing that GEO requires. Firms that treat pursuit data as a publishing asset will be better positioned in generative search than firms that treat it as an internal archive.
Related terms
The go/no-go process is the deliberate decision an AEC firm makes before committing pursuit resources to an opportunity — evaluating experience fit, probability of winning, strategic alignment, and team availability before the proposal team starts work.
A competitive proposal can consume 100 to 300 hours across a marketing coordinator, proposal manager, technical leads, and principals. The go/no-go evaluation determines whether those hours are worth spending. The typical criteria: client relationship (do we have one, and how strong?), competitive landscape (who else is likely bidding, and at what strength?), scope fit (does our documented experience match what the selection committee will score?), team availability (do we have the right people free to perform if we win?), and strategic value (does this pursuit advance the firm's market position or revenue targets?). Firms with a rigorous process capture more of those hours for high-probability pursuits and fewer for work they were unlikely to win.
In practice, go/no-go meetings often happen without the information they require. The BD director wants to pursue; the principal has a relationship; the proposal manager flags a deadline conflict. What's missing is the data layer: how many comparable projects does the firm actually have in this sector? Who has worked with this client before? What did the debrief reveal after the last similar pursuit? Without that institutional record, go/no-go becomes instinct-driven rather than evidence-based, and firms chase opportunities they're poorly positioned to win. Relationships and optimism are not win strategies.
The go/no-go process is one of the clearest levers a BD leader has for improving hit rate — not by pursuing more, but by pursuing better. Firms that track their go/no-go outcomes over time build a calibration model that sharpens every decision that follows: which client types the firm shortlists with, which project scales match the firm's experience depth, which competitors consistently win in specific geographies. Kantiv supports this by surfacing the institutional record behind any pursuit — past work with the client, relevant project experience, team availability signals — so the go/no-go meeting starts from verified data instead of recalled impressions.
Related terms
A go/no-go scorecard is a weighted decision matrix that AEC marketing and BD teams use to evaluate a specific opportunity against predetermined criteria before committing pursuit resources.
Most firms converge on similar evaluation categories: client relationship strength, project type fit, geographic reach, team availability, fee potential, and competitive exposure. The differentiator is how those categories are weighted relative to each other. A firm that weights "incumbent relationship" at 30% of the total score is making an explicit strategic claim that relationship proximity outranks technical fit, which is a defensible position in QBS-driven public sector work governed by the Brooks Act but may be the wrong call in design-build procurements where team composition drives shortlist decisions. Firms that use equal weighting across all criteria are not being objective; they are hiding a strategic choice behind an arithmetic one. The non-obvious trap is that a scorecard with too many criteria (anything above twelve) tends to compress all scores toward the middle, which defeats the purpose entirely.
The scorecard should trigger at first notice of an opportunity, before any RFQ or RFP has been issued, because the decisions that happen in that window, including whether to start relationship-building, whether to position a specific project manager, whether to begin a teaming conversation, are exactly what a go/no-go is designed to inform. Running a scorecard after an RFP drops is not go/no-go decision-making; it is rationalization. In practice, the score itself is rarely the final word: a BD director who has cultivated a client contact for three years will override a marginal score, and that is appropriate. What the scorecard does is force that override to be explicit rather than silent, which creates a record for debrief analysis and hit rate tracking later.
Scorecards decay. A firm builds one during a strategic planning retreat, uses it consistently for six months, then watches it drift into a formality that the team fills out after the decision is already made. This happens because the criteria are not connected to the firm's actual win data: if your three-year debrief record shows that opportunities scored below 65% have a win rate under 8%, that threshold becomes defensible and hard to dismiss. Without that feedback loop, the scorecard is an opinion poll formatted as math. Kantiv closes this loop by connecting pursuit intake data to historical project and client records, so the context that informs a score, prior work with that client, team availability, recent competitive losses to the same shortlist pool, is drawn from verified institutional knowledge rather than whoever is in the room that day.
Related terms
In AEC marketing, a graphic designer or desktop publisher is the team member responsible for translating proposal content into compliant, on-brand layouts that hold up under evaluator scrutiny, a role that sits at the intersection of production deadline pressure and visual communication strategy.
The graphic designer is not just formatting text. On a typical two-week RFP response, they are building section templates, placing project photos, sizing org charts for SF-330 Section H, and enforcing page limits that often demand cutting a third of the content the technical team submitted. They manage the master InDesign file, which means every last-minute scope change from a seller-doer lands on their desk as a reflow problem. At firms where the marketing team is under ten people, the same person doing layout is often also producing qualifications packages, maintaining the image library, and setting the style guide. The gap between what evaluators see and what the pursuit team intended almost always lives in that file.
The most common breakdown is not a design problem; it is a content handoff problem. A subject matter expert sends narrative in a Word document with inconsistent formatting, embedded tables that break on import, and project descriptions that run 40 words over the allotted space. The designer then becomes a copyeditor, a role they are not positioned to fill and for which there is no time in the schedule. Internal review cycles compound this: redlines come back on a PDF, the designer interprets changes, and a second round of review catches interpretation errors. On pursuits with a shortlist interview following the written submission, this cycle repeats under a shorter timeline with higher stakes.
Firms that treat the designer as a production resource at the end of the process consistently produce weaker submissions than firms that involve them at go/no-go, when page and format constraints can actually shape how the win strategy is structured. A designer who understands the evaluation criteria before building the template makes layout decisions that guide an evaluator's eye toward differentiators rather than burying them in dense text. The persistent misconception is that design quality is a finishing touch; in a shortlist pool of three to five firms where qualifications are roughly equivalent, visual clarity is a scoring factor, not cosmetic. Kantiv addresses the handoff problem directly by keeping proposal content in structured, editable form so designers receive clean inputs rather than reformatting everything from scratch before a page has been laid out.
Related terms
In AI, hallucination is when a language model produces output that is syntactically fluent and contextually plausible but factually wrong, fabricated, or ungrounded in any source the model was actually given.
Large language models do not retrieve facts the way a database does. They predict the next most probable token based on learned statistical patterns, which means the model can generate a confident-sounding project name, a contract value, an award year, or a client agency name that simply does not exist. This is not a flaw that will be fully patched out; it is a property of how transformer-based generative models work at inference time. The risk compounds when a model is asked to write about your specific firm, because public training data about mid-market AEC firms is sparse, so the model fills gaps with plausible-sounding fabrications. A hallucinated LEED certification level or a wrong construction cost on an SF-330 Section F project narrative is not a minor editing issue; it is a credibility failure that a technically sophisticated evaluator will catch.
The highest-risk moments are project descriptions, staff credentials in Section E, and any passage where a writer asks an AI tool to "fill in" details about a past project without feeding it verified source material first. Hallucinations also appear in boilerplate narratives that get re-used without review: a model that generated a plausible-sounding safety record or minority business enterprise status in one draft can propagate that error across subsequent pursuit documents. On a two-week proposal timeline, the pressure to accept AI-generated text without cross-checking against the CRM or project database is exactly the condition that lets fabricated details survive into a submitted package. Owners using Best Value or QBS selection criteria under the Brooks Act have evaluators who know these projects; a fabricated reference will not survive a phone call.
Telling the model to "be accurate" or "only use facts you know" does not meaningfully reduce hallucination rate; the model has no reliable self-knowledge of what it does or does not know. The structural fix is retrieval-augmented generation: the model drafts only from verified content that has been explicitly passed into the context window, so invented details have nowhere to enter. Human-in-the-loop review at the section level, not just a final proofread, remains mandatory regardless of retrieval architecture. Kantiv grounds every AI-assisted output in the firm's own verified pursuit data, project records, and personnel profiles, so the generation process starts from confirmed institutional content rather than statistical inference about what your firm probably did.
Related terms
Hit rate (also called win rate) is the percentage of pursued opportunities a firm wins, expressed either as a count of proposals won divided by proposals submitted, or as fee value won divided by total fee value pursued; these two calculations draw from the same data but routinely produce different numbers, and firms that conflate them are measuring different things without knowing it.
A firm that wins three of ten proposals has a 30% count-based hit rate. If those three wins were all small projects and the seven losses were large ones, the fee-weighted hit rate might be 12%. Both numbers are accurate; neither is the hit rate without a qualifier. Fee-weighted hit rate correlates more directly to revenue performance, which is why finance and executive leadership tend to prefer it, while BD teams often default to count-based because it's easier to track in a spreadsheet. The more consequential distinction is whether the denominator includes no-go decisions: firms that exclude abandoned pursuits from the calculation inflate their apparent win rate by hiding the misses that never made it to submission.
Go/no-go analysis is the most direct application: a firm with a 20% count-based hit rate submitting 40 proposals per year is absorbing 32 losses annually, and the question is whether the four to eight wins justify that burn rate on staff time and proposal budget. Some firms set floor thresholds by market sector, requiring a projected win probability above 35% before committing pursuit resources. Hit rate by client type, project delivery method (design-build versus design-bid-build), or geographic market often reveals where a firm is actually competitive versus where it is filling a competitive field as a courtesy submitter. Debrief data is the only reliable way to close the loop between projected win probability at go/no-go and the actual result.
Hit rate is only as accurate as the pursuit tracking behind it. Firms that log RFP responses but not RFQ submissions, or that close out won projects in the CRM while letting losses go unrecorded, end up with a numerator and denominator that don't reflect the same universe of opportunities. Shortlist conversion rate (proposals that reached interview divided by proposals submitted) is a separate and often more useful diagnostic metric because it isolates where in the funnel the firm is losing: before the shortlist, or on the shortlist. Kantiv surfaces historical pursuit outcomes alongside project and client data during active pursuits, so teams can assess win patterns against a specific client or procurement type before committing to a submission.
Related terms
Human-in-the-loop (HITL) is a system design principle where human judgment is required at defined checkpoints before an automated process can proceed, ensuring outputs meet standards that machines cannot verify on their own.
Proposals carry legal, financial, and reputational consequences that generic AI tools are not equipped to weigh. A system that auto-populates a project description from the wrong predecessor contract, or assigns a PM whose license lapsed, creates liability before the RFP response even leaves the building. HITL checkpoints exist precisely to catch those failures before they compound. In AEC pursuits, the human in the loop is usually a proposal manager, a project executive, or a discipline lead reviewing AI-surfaced content against lived knowledge of the client, the project, and the team.
A typical two-week proposal timeline leaves almost no room for error correction late in the process, which is why HITL checkpoints need to be front-loaded rather than treated as a final review. Common insertion points include: verification of relevant project experience before SF-330 Section F is drafted, confirmation of key personnel availability and current credentials before Section E is assembled, and a pursuit strategist reviewing AI-generated win themes before they get baked into the executive summary. Each checkpoint is a deliberate pause, not an interruption. The goal is catching mismatches between automated retrieval and ground truth while there is still time to fix them.
Some teams treat human review as a sign that an AI tool is immature; the inverse is closer to true. A system with well-defined HITL checkpoints is one that has been designed with an accurate model of where machines fail and where human judgment is irreplaceable. Shortlist pools typically run three to five firms, and the margin between winning and honorable mention often comes down to specificity: the right past project cited, the right subconsultant named, the right client sensitivity acknowledged. Those judgments require someone who knows the pursuit. Kantiv is built around HITL by design, surfacing verified context from institutional knowledge so the human reviewer is confirming accuracy rather than reconstructing it from scratch.
Related terms
An image library is an organized collection of photographs, renderings, drone footage, and other visual assets that an AEC marketing team maintains for use across proposals, presentations, award submissions, and marketing materials.
The volume problem is rarely the obstacle. The accuracy problem is. A project photograph taken during construction may show incomplete work, missing site context, or branding from a subconsultant that is now a competitor. Renderings become liabilities the moment a built project diverges from the design shown. Drone footage captured before a landscaping package was installed misrepresents the finished product to an owner who will recognize the difference immediately. Most libraries have no mechanism for flagging assets when a project closes out, which means stale imagery circulates for years before anyone catches it in a submission.
When a proposal coordinator is building a relevant project section under a two-week RFP timeline, image quality is not the first constraint she hits. Finding the right image fast enough is. A library organized by file date or photographer name forces her to search by memory or ask the project manager, who may not respond before the submission window closes. SF-330 Section F and equivalent private-sector project cut sheets both depend on visuals that match the stated project scope; a mismatch between the image and the described project type reads as inattention during evaluation. Firms that shortlist consistently tend to treat image collection as a project closeout deliverable, not a post-occupancy afterthought.
An image without structured metadata is almost unretrievable at scale. File names like "IMG_4892_final_v2.jpg" are common even in otherwise well-organized libraries, and they make keyword search useless and tagging retroactively expensive. The non-obvious fix is not a new platform; it is a submission protocol that requires photographers, project managers, and marketing coordinators to attach a minimum metadata record at the point of ingestion: project name, client, building type, phase at time of capture, and photographer credit. Kantiv connects image assets to the broader pursuit record, project data, and personnel context that makes a visual actually retrievable when a team is mid-pursuit and searching by project type or client sector rather than file name.
Related terms
Inference is the computational step where a trained AI model receives an input, processes it against fixed model weights, and produces an output; no further learning occurs during this step, and the model's knowledge is static from the moment training ended.
During inference, the model is not searching a database or retrieving documents in the way a search engine does. It is applying learned statistical patterns across billions of parameters to predict the most probable next token, then the next, until the output is complete. Those weights were frozen at training cutoff, which for most foundation models means months or years before you are running a pursuit. Any project completed after that cutoff, any client relationship that evolved, any new subconsultant added to your roster: none of it exists inside the model unless you supply it at runtime through context. This is why prompt construction and retrieval-augmented generation matter so much in a proposal environment; the model's internal knowledge is not a current record of your firm.
The gap between training cutoff and inference time is where hallucination enters the picture. A model asked to summarize your firm's work on a transit project it was never trained on will not say "I don't know." It will infer a plausible-sounding answer from adjacent patterns, often mixing in real project names, real client names, and fabricated details. In a proposal context, that means a scope summary or an SF-330 Section F narrative that reads fluently but contains information that never happened. Compliance failures on a federal submittal can be traced back to unchecked inference outputs; a reviewer who trusts generated text without verifying it against source documents is the single largest risk factor. The inference step itself has no mechanism for flagging uncertainty unless the system is explicitly designed to surface it.
The practical implication is that every inference call in a pursuit workflow is only as accurate as the context you feed it. Supplying verified project data, actual résumé content, and confirmed client history at runtime is not a workaround; it is the correct architecture. Teams that treat inference as a black box and accept outputs without structured review are introducing a quality control gap that no amount of good prompting fully eliminates. Kantiv is built around this reality: it surfaces verified pursuit context from your firm's own records before the inference step runs, so the model is working from your actual project history rather than interpolating from general training data.
Related terms
Institutional knowledge is the accumulated, firm-specific information that exists across people, past projects, and client relationships: who did what, what worked, what was said in a debrief, and why a team made a particular design or fee decision.
AEC firms lose institutional knowledge at an unusually high rate because the work is project-based and the workforce is mobile. A principal who leaves takes client context, pursuit history, and subcontractor relationships that were never written down anywhere retrievable. Proposal files sit in network folders organized by project number, not by client or market sector, so the pattern of what a repeat client actually values stays buried in old PDFs. The average tenure gap between a senior BD director and a mid-level coordinator means that two people working the same account may have almost no shared context about that client's past objections or award criteria.
In practice, institutional knowledge surfaces in three places during a live pursuit: the kickoff conversation, the résumé and project sheet pull, and the debrief review if anyone saved it. The kickoff conversation is the most fragile, because it exists only in real-time recall and meeting notes that may never be filed. Teams chasing a two-week RFP window rarely have time to excavate a past SF-330 submission, compare it to the scoring feedback, and apply those findings before the deadline. That gap is where boilerplate replaces verified context.
Firms that treat institutional knowledge as a byproduct of project delivery rather than a managed asset repeat the same positioning mistakes across pursuit cycles. A BD director who has watched a firm lose the same agency client three times to the same competitor should be able to pull a documented read on why, not reconstruct it from memory in a kickoff meeting. Capture planning, debrief notes, and project close-out interviews are the standard mechanisms for preserving this context, but they only work if the outputs are findable at pursuit time. Kantiv is built specifically to surface that captured context during active pursuits, so the team starts from what the firm already knows rather than from a blank scope document.
Related terms
Integrated Project Delivery (IPD) is a project delivery method that unites the owner, designer, and constructor under a single multi-party contract, with shared financial risk and reward tied to project outcomes rather than individual scope performance.
The defining legal structure of IPD is the multi-party agreement: a single contract signed by all three core parties, typically on an AIA C191 or owner-drafted equivalent, replacing the bilateral contracts that govern design-build or CMAR. Profit and contingency sit in a shared risk pool; if the project beats target cost, all parties share the upside, and if it misses, all parties absorb losses up to their at-risk amount. This financial interdependence is what actually changes behavior at the table, not just the org chart. True IPD also requires co-location or intensive integrated work sessions during preconstruction, so the GC's estimating and the architect's design evolve simultaneously rather than sequentially. Some owners use "IPD-lite" arrangements that adopt the collaborative language without the shared risk pool; those are closer to CMAR with a BIM mandate than genuine IPD.
Owners who pursue IPD almost always issue an RFQ before any RFP, screening for demonstrated collaboration experience and prior multi-party contract history before they discuss scope or fee. Your SF-330 equivalent still needs project-specific relevance, but the selection criteria weight cultural fit and preconstruction integration track record more heavily than on a hard-bid or even design-build pursuit. Shortlists for IPD projects tend to be smaller, often two to three teams, and interviews are frequently structured as working sessions rather than presentations, so the pursuit team needs to brief technical leads on facilitation, not just talking points. Fee proposal mechanics also shift: rather than submitting a lump-sum or hourly-rate schedule, the design firm is typically negotiating a target cost and profit percentage alongside the GC under owner supervision, which means BD staff must coordinate with finance earlier in the process than on any other delivery type.
Most firms have fewer than five genuine IPD projects in their history, which makes those pursuits disproportionately dependent on the specific people who worked them, and that knowledge rarely survives in a retrievable form after project close-out. When an IPD opportunity surfaces, proposal teams frequently rediscover relevant experience weeks into the pursuit because it was filed under the project name rather than tagged to the delivery method, the contract structure, or the shared-risk outcome. The misconception is that IPD pursuits require less proposal infrastructure because the team is assembled early and selection is relationship-driven; in practice, they require more precise institutional recall because the differentiating evidence is narrower and harder to find. Kantiv surfaces that evidence by connecting delivery method, contract type, and personnel history across a firm's project data, so the pursuit team starts with what actually exists rather than what people remember.
Related terms
Internal review is the structured process by which an AEC firm evaluates a pursuit deliverable before it leaves the building, covering everything from technical accuracy and scope responsiveness to compliance with solicitation requirements and brand standards.
Most internal review failures are scheduling failures, not judgment failures. A two-week proposal timeline compresses fast: if the draft lands with reviewers on day eleven, you get reactions instead of analysis. The more common problem is reviewer misalignment; a principal reviewing for win strategy will mark up different things than a project manager reviewing for technical accuracy, and without a defined scope for each reviewer's pass, you get conflicting redlines and a second draft that satisfies no one. Firms that treat internal review as a single event rather than a sequenced set of passes consistently produce weaker final submittals.
Effective internal review separates the compliance check, the technical pass, and the strategic pass into distinct steps with distinct owners. Compliance first: before anyone evaluates quality, confirm that every required SF-330 section is addressed, every page limit respected, every attachment labeled per the solicitation. The technical pass belongs to the PM or lead engineer, focused on whether the approach actually matches the project scope. The strategic pass belongs to a BD lead or principal who has not been heads-down in the draft, asking whether the narrative makes a clear case for why this firm wins over the three to five others on a typical shortlist.
Internal review surfaces a recurring gap: reviewers flag missing content that no one can locate quickly. A reviewer asks for a comparable transit project from the last five years; the coordinator searches shared drives, calls two PMs, and burns an afternoon. This is not a people problem, it is a retrieval problem. The strategic value of a well-run internal review depends entirely on the team's ability to respond to reviewer comments with verified, current information rather than approximate recollections. Kantiv addresses this directly by surfacing project history, personnel expertise, and past proposal content during the review cycle, so reviewer comments become action items instead of research assignments. Firms that run tight internal reviews with fast retrieval submit stronger work and protect the time of their most expensive reviewers.
Related terms
A knowledge graph is a structured data model that stores entities and their relationships as connected nodes, so that querying one entity (a client, a project, a person) automatically surfaces the web of related entities without requiring separate lookups or manual cross-referencing.
Most AEC firms store data in silos: a CRM holds client contacts, an ERP holds project financials, a shared drive holds proposal PDFs, and nobody's résumé system talks to any of them. A relational database can link two tables, but it doesn't natively represent the kind of multi-hop relationships that matter in a pursuit: the fact that a senior PM worked on a water treatment plant in 2019, that the project was delivered under CMAR, that the client was a municipal utility, and that the project won an ENR award. A knowledge graph holds all of that as a network of typed relationships, so a query about "CMAR experience with municipal utilities" traverses the graph and returns the right people, projects, and outcomes together. That traversal is what makes a knowledge graph qualitatively different from a filtered spreadsheet or a keyword search across a file server.
When a go/no-go decision hinges on whether the firm can demonstrate three comparable projects with relevant subconsultants already in place, someone has to find that evidence fast, usually inside a two-week RFP window. A knowledge graph makes that query answerable in seconds instead of hours because the relationships between project type, delivery method, client sector, geography, and staff are already encoded. The same structure supports Section H of an SF-330, where relevant project experience must map to specific personnel who actually worked on those projects: a graph with verified person-to-project relationships prevents the common mistake of listing a résumé holder who was nominally on a project but contributed nothing billable. At debrief, when a client scores the firm low on "demonstrated experience," the knowledge graph is also the right place to look for what was missing from the submission or incorrectly characterized.
A content library stores documents and assets; a knowledge graph stores facts and their connections. Many firms conflate the two, which is why their "knowledge base" is actually a well-organized folder structure that still requires a human to read every file and synthesize the answer. The practical consequence is that a content library can surface a project write-up, but it can't tell you which of your civil engineers has worked on that project type in a coastal flood zone under a design-build delivery method with a budget over $50M. That kind of multi-attribute query requires graph structure. Kantiv builds this connected layer across a firm's proposal history, project data, and personnel records so that pursuit teams query relationships directly instead of reconstructing them from documents at the start of every pursuit.
Related terms
A knowledge manager in an AEC firm owns the institutional memory that proposals are built from: the accuracy of project descriptions, the currency of resumes, the organization of past performance data, and the retrieval systems that make any of it usable under deadline.
Most AEC marketing teams conflate knowledge management with proposal coordination, and the work suffers for it. A proposal coordinator is working against an RFP deadline; a knowledge manager is working against entropy. Project data goes stale the moment substantial completion is reached, resumes drift from reality as staff take on new project types, and boilerplate narratives accumulate version conflicts across shared drives until no one is sure which paragraph reflects current firm capabilities. The knowledge manager's job is to prevent that drift before a pursuit kicks off, not to catch it during a two-week proposal sprint. Firms that lack a dedicated person in this role typically discover the gap when a shortlist interview falls apart because a highlighted project description contains a scope, dollar value, or client name that no longer matches the record.
During go/no-go, the knowledge manager is the person who can answer whether the firm actually has three comparable projects to cite, not just three that sound similar. When an RFP drops, they supply the proposal coordinator with verified project data, current resumes, and any applicable past performance records rather than letting writers pull from whatever they can find in a shared folder. On SF-330 submittals, Section F (example projects) and Section G (key personnel participation) depend entirely on data that was captured and maintained well before the solicitation arrived. In debrief, the knowledge manager is positioned to update records based on client feedback so the next pursuit starts from a better baseline.
Knowledge management in AEC is active, not archival. It requires negotiating with project managers and principals who do not prioritize data entry, setting standards for what counts as a "complete" project record, and maintaining enough technical fluency to recognize when a description has been genericized into uselessness. Firms running over 50 active project descriptions in a content library without a dedicated owner tend to find that retrieval fails not because content is missing but because tagging is inconsistent and no one has adjudicated duplicates. Kantiv surfaces verified project data, resumes, and client history during active pursuits by connecting to the maintained records a knowledge manager keeps current, which means the quality of what the platform surfaces is a direct function of how well that role is executed.
Related terms
A large language model (LLM) is a neural network trained on massive text datasets to predict statistically probable word sequences, producing fluent output that can appear authoritative whether the underlying information is accurate or not.
The scale of these models is not an abstract technical detail. GPT-4 was trained on roughly one trillion tokens; that scale is what allows the model to handle SF-330 Section F narrative structure, mirror client language from an RFP, and shift register between a technical approach and an executive summary without being retrained for each task. But that same training corpus ends at a fixed cutoff date, contains no knowledge of your firm's actual project history, and was never exposed to your client relationships or your past debrief feedback. The model is fluent about AEC in general and ignorant about your firm specifically. That distinction matters more in a two-week proposal sprint than in almost any other professional context.
The core failure mode is confident fabrication: an LLM asked to describe your firm's healthcare portfolio will produce something plausible, grammatically clean, and potentially false. Project names, square footages, client names, and completion years are exactly the kinds of specifics a model will hallucinate when they are not present in its context window. In a compliance-sensitive submission where a single incorrect project reference can disqualify a response or trigger a post-award audit, that risk is not theoretical. LLMs also have no awareness of pursuit-specific constraints: they do not know the page limits from Section L, the evaluation criteria weighted in Section M, or the incumbent relationships that should shape your win strategy.
The model itself is not the product; the architecture around it determines whether output is trustworthy. Retrieval-augmented generation feeds verified firm content into the context window before generation begins, so the model is drafting against your actual project data instead of its own statistical priors. That architectural choice is what separates a tool that accelerates proposal writing from one that creates liability. Prompt engineering, system instructions, and human-in-the-loop review gates all affect how much a given LLM output can be trusted before it goes into a document that carries your firm's signature. Kantiv routes LLM generation through verified pursuit context: past proposals, project records, and personnel data, so the model is constrained to what your firm can actually substantiate.
Related terms
A letter proposal is a condensed scope, fee, and qualifications document, typically one to five pages, submitted when a client relationship, project scale, or procurement method makes a full proposal package unnecessary.
Letter proposals are most common in three situations: repeat-client task orders under an existing master services or on-call agreement, small-scale projects where a formal RFP would cost more to respond to than the work is worth, and negotiated procurements where the client already knows who they want and needs documentation rather than competition. Federal task orders under IDIQ contracts frequently require a short technical and price response that functions exactly like a letter proposal, even when the agency doesn't use that name. In the private sector, a long-standing client relationship often means the letter proposal is less a persuasion document and more a scope-confirmation instrument, which changes what it needs to contain and how much time you should spend on it.
The constraint is not length; it's that every element of a full proposal still needs to exist somewhere in the document. Scope of work, deliverables, schedule, fee, exclusions, and a basis-of-fee explanation all have to fit without the structure that section headers and tabs provide in a formal submission. The most common failure mode is treating a letter proposal like a cover letter with a number at the bottom: the client receives a relationship narrative but no clear project understanding, which creates scope disputes after award. Firms that win consistently on letter proposals front-load the scope definition and put the relationship context second, because the client already knows the relationship; what they need to sign off on is the work.
Letter proposals feel low-stakes because they're short and often go to existing clients, but they carry a specific institutional risk: the context that makes them possible lives in people's heads, not in systems. When the seller-doer who manages the client relationship is unavailable, or when a new proposal coordinator inherits the account, the team often can't reconstruct what was promised on prior task orders, what fee basis was used, or which exclusions were negotiated. That gap produces fee compression and scope creep on the next letter proposal in the same relationship. Kantiv surfaces prior task order language, fee structures, and scope exclusions from past submissions so a team can draft a consistent, defensible letter proposal against an institutional record rather than a single person's memory.
Related terms
Machine learning is a category of artificial intelligence in which a system identifies statistical patterns in training data and applies those patterns to new inputs, producing predictions or classifications without a human encoding explicit rules for every case.
A machine learning model is only as reliable as the data it trained on. General-purpose models trained on broad web text have absorbed patterns from millions of documents, but almost none of those documents are SF-330 submissions, QBS evaluation narratives, or federal source-selection debriefs. That mismatch is not theoretical; it shows up when a model confidently generates project descriptions that sound plausible but contradict what your firm actually built, who led it, or what the contract value was. The patterns the model learned are real, but they were learned from someone else's domain. For AEC marketing teams, this is the core reason why output always requires verification against internal project records before it goes anywhere near a submission.
Most of the AI tools AEC marketing teams encounter today sit on top of machine learning infrastructure in some form: the similarity search that surfaces related past projects, the classifier that tags a new RFP by delivery method or sector, the ranking model that scores pursuit fit during a go/no-go review. These are not the same capability. Similarity search relies on embeddings and vector math; classification relies on a model trained to recognize category boundaries; ranking relies on a scoring function shaped by labeled examples. Knowing which type of ML is doing the work tells you where the failure mode lives. A classification model that was never trained on construction manager-at-risk scopes will misfile CMAR pursuits. A ranking model trained on win/loss data from one market segment may not generalize when your firm enters a new geography.
Machine learning models do not understand content; they exploit regularities in how content is structured. A model that has seen thousands of project approach sections learns that certain phrases cluster together, not that the underlying technical methodology is sound. This distinction matters when a team uses ML-assisted tools to surface boilerplate from a content library: the model may return the most statistically similar narrative, not the most accurate or most differentiating one. Firms that treat ML output as a first draft requiring human review perform better than firms that treat it as a finished answer. Kantiv applies this principle by grounding ML-assisted retrieval in structured firm data, so the patterns the system exploits are drawn from verified project records and client history rather than generic text.
Related terms
A marketing coordinator in an AEC firm is the execution engine of the pursuit team: the person who holds deadline accountability, assembles compliance packages, tracks which resume is current, and keeps proposal production from stalling when a project manager goes dark 48 hours before submittal.
The coordinator rarely writes the win strategy, but they are the first to notice when the win strategy has no supporting project data to back it up. On a typical two-week SF-330 pursuit, a coordinator might manage 6 to 12 SME contributors, reconcile four versions of a project description for the same job, chase down a key personnel signature, and verify that Section H is within the page limit before anyone on the technical team has looked at the document as a whole. The compliance burden alone, confirming that every RFP-mandated exhibit is present and formatted correctly, can consume four to six hours on a complex federal package. What makes this hard is not the individual task; it is the simultaneous management of tasks across concurrent active pursuits.
Much of what a coordinator knows is not written down anywhere: which principal refuses to send a current bio until the third request, what the client agency actually meant by a vague RFP exhibit requirement, which boilerplate narrative for a particular project type was approved last cycle and which version had the error. This knowledge lives in email threads, in the coordinator's own files, and in memory accumulated over years of pursuing the same client types. When a coordinator leaves a firm, that operational knowledge disappears with them, and the next person rebuilds it the slow way, by making mistakes on live pursuits.
Firms that treat the coordinator as a production resource consistently underestimate how much intelligence passes through that position. A coordinator who has managed 50 federal pursuits knows things about FAR Part 36 compliance patterns, agency formatting preferences, and go/no-go timing that a BD director who focuses on client relationships may not. The common misconception is that coordinator work is templatable; the reality is that template management is the least of it, because templates only help when the underlying content is accurate and current. Kantiv surfaces verified project data, current resumes, and prior proposal content directly into the coordinator's workflow, replacing the time spent hunting down source material with time spent on the decisions that require judgment.
Related terms
In AEC, a marketing manager sits at the intersection of pursuit execution and business development strategy, owning the systems, staff, and content that keep a firm competitive across active opportunities.
Most AEC marketing managers operate under a director of BD or a principal-in-charge, managing a team of one to four coordinators while personally handling the most complex or high-value pursuits. The title varies: some firms use "proposal manager" interchangeably, others reserve "marketing manager" for the person who also owns brand, PR, and conference presence. In firms under 300 people, the marketing manager often writes, designs, and submits proposals directly. At larger firms, the role shifts toward quality control, workflow coordination, and institutional knowledge management across a pursuit pipeline that can include 20 or more active opportunities at once.
A marketing manager in AEC needs fluency with SF-330 structure, FAR Part 36 procurement rules, and the QBS process codified in the Brooks Act (1972). They coordinate Section E project narratives and Section H additional information across rotating casts of PMs and principals who rarely prioritize proposal input. The two-week federal proposal turnaround is common enough to be the default assumption; state and municipal deadlines are often tighter. Beyond writing, the role demands a working knowledge of what the firm has actually done: which projects are relevant to which NAICS codes, which PMs have clearances or certifications, which past clients are referenceable and which are not.
Every experienced marketing manager carries an outsized share of institutional knowledge: who worked on what, which project narratives tested well in past shortlists, which client contacts prefer certain communication styles. When that person leaves or takes on a new role, the firm often discovers it has no reliable record of any of it. Shortlists in federal and public-sector pursuits typically narrow to three to five firms, and the margin between winning and losing frequently comes down to how precisely a team can match past performance to current evaluation criteria. Kantiv captures that institutional knowledge continuously, so it's accessible to the whole team rather than held by one person. The marketing manager who builds that habit early stops being the single point of failure for pursuit intelligence.
Related terms
In AEC, a merger and acquisition (M&A) is a transaction in which two firms combine their ownership structures through either a merger of equals or an outright purchase, instantly creating a new institutional reality: shared project history, overlapping credentials, combined client rosters, and staff from two distinct cultures who now appear on the same SF-330.
The closing date on an acquisition does not synchronize with your next RFP deadline. A firm that closes on a purchase in Q1 may be submitting joint qualifications by Q2, long before any integrated project database exists. The acquired firm's project history lives in a different CRM, a different file server, or someone's personal hard drive, and the acquiring firm's BD team has to assemble a coherent narrative from two disconnected data sets under a two-week proposal clock. The issue compounds in SF-330 Section F, where the project history record requires consistent data points (construction cost, completion date, scope description) that almost never exist in the same format across two firms. ACEC research has tracked an acceleration in AEC consolidation since 2018; the firms absorbing multiple smaller studios in short succession are now managing three or four distinct institutional data histories simultaneously.
A go/no-go scorecard built before an acquisition closes may score a pursuit as a long shot due to thin federal healthcare experience, then become fully competitive the day the acquired firm's project credentials are absorbed. That recalibration rarely happens fast enough to catch pursuits already declined. Personnel changes matter just as much: seller-doer relationships from the acquired firm carry existing client trust, and losing track of who owns which client relationship during integration is one of the most common ways newly merged firms drop hit rate in the first year post-close. Shortlist interviews are particularly exposed because the combined entity may present a project team that has never actually worked together, which experienced public owners will notice immediately.
Most AEC M&A integration checklists cover legal, financial, and HR workstreams in detail. The proposal knowledge workstream rarely gets the same rigor. Project data, staff credentials, and client history from the acquired firm need to be validated, normalized, and made retrievable before they appear in a live pursuit, not after a reviewer flags an inconsistency in Section E. Kantiv addresses this directly by capturing and structuring institutional knowledge from both entities so that post-acquisition teams draw from a single verified record rather than reconciling two competing data sets during a pursuit.
Related terms
Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that defines how AI models exchange context with external data sources and tools through a structured client-server interface.
Most AI integrations in AEC software are point-to-point: one tool talks to one model through a custom connector that breaks whenever either side updates. MCP replaces that with a universal handshake, so a model can query your CRM, your project database, and your document library through a single protocol rather than three separate brittle integrations. For BD teams, the practical implication is that context stops being trapped inside whichever platform it was created in. A project description written in Deltek, a past performance record filed in SharePoint, and a résumé sitting in an HRIS can all become addressable by the same model, in the same session, without manual copy-paste.
A typical federal proposal operates on a two-week window between RFP drop and submission; on design-build procurements the technical volume alone can run forty to sixty pages. The bottleneck is rarely writing: it is retrieval. Someone has to find the right project narrative, confirm the square footages, pull the right résumé version, and verify the subconsultant scope before a single sentence gets drafted. MCP-compatible systems let a model query those sources directly during a session, returning verified data rather than a model's approximation of it. The difference between a hallucinated project number and a confirmed one on an SF-330 Section F is the difference between a compliant submittal and a disqualified one.
The strategic value of MCP is not speed; it is fidelity. When a model has structured, protocol-level access to your firm's actual records, the output it produces reflects institutional knowledge rather than pattern-matched generalities. This is why MCP is foundational to pursuit intelligence rather than just proposal automation: intelligence requires verified context, and verified context requires a reliable mechanism for reaching the systems that hold it. Kantiv uses MCP to connect pursuit workflows directly to a firm's project data, personnel expertise, and client history, so the information surfaced during a pursuit is traceable to a source rather than generated from inference. For QBS environments governed by the Brooks Act, where the evaluator is assessing demonstrated qualifications rather than price, the accuracy of that sourced content is what separates a competitive shortlist position from a polite rejection letter.
Related terms
Model fine-tuning is the process of continuing the training of a pre-built large language model on a curated, domain-specific dataset so the model's weights are permanently adjusted to favor the vocabulary, structure, and conventions of that domain over generic outputs.
Fine-tuning does not add a knowledge layer on top of a model; it shifts the probability distributions the model uses to predict the next token. That distinction matters because a fine-tuned model cannot be easily updated when your data changes. If your firm rebrands, pivots to a new delivery method, or adds fifty new project examples, the model's weights do not update automatically; you retrain. Fine-tuning also does not fix hallucination, which is one of the most common misconceptions in AEC tech procurement conversations. A model fine-tuned on SF-330 submissions will produce outputs that look like SF-330 submissions, but it can still fabricate project square footages, construction costs, or client names with complete syntactic confidence.
Most AEC marketing teams encounter fine-tuning as a vendor claim, not an internal engineering task. A software provider may say their tool is "fine-tuned on AEC proposal data," which is worth interrogating: whose data, how recent, how large the dataset, and does it reflect public-sector procurement conventions like QBS under the Brooks Act or FAR Part 36 compliance requirements? For a team running a federal SF-330 pursuit, a model fine-tuned on commercial real estate RFPs is not neutral; it actively works against the tone, structure, and legal compliance expectations of the submission. The more operationally relevant question is not whether a model is fine-tuned but whether the system can access your firm's actual verified project data at inference time.
Retrieval-augmented generation is almost always more appropriate than fine-tuning for AEC marketing use cases because your most important content changes constantly: new projects complete, staff turn over, clients shift priorities, and past proposals get superseded. Fine-tuning bakes a snapshot of knowledge into weights that are expensive and slow to update; retrieval pulls live, verified content from a structured source at the moment of generation. The practical risk of over-relying on a fine-tuned model in a pursuit context is that it generates confident, well-formatted content that is factually stale or simply wrong, and a coordinator under a two-week proposal deadline may not catch it before submission. Kantiv addresses this by pairing language generation with retrieval from verified institutional content, so outputs are grounded in what your firm has actually built, staffed, and delivered rather than in statistical patterns from prior text.
Related terms
Multi-modal AI is an artificial intelligence system that processes more than one data type within a single inference pass, reading text, images, diagrams, and structured data together rather than separately.
Most AI tools used in AEC marketing today are text-only. They can summarize a project narrative or draft a Section H management approach, but they cannot read the floor plan sitting next to that narrative, interpret a bar chart in a past performance package, or extract data from a scanned SF-330 that was never OCR'd cleanly. Proposal content is rarely pure text: renderings, site maps, org charts, fee schedules, and photo captions all carry meaning that text-only models simply skip. A multi-modal model can process a project image alongside its description and recognize when the two conflict, which matters when a photo labeled "Seattle transit hub" is actually from a Portland job. That kind of cross-referencing is not available in a single-modal pipeline.
During a shortlist presentation, teams frequently pull graphics from a content library and pair them with written talking points; a multi-modal model can verify that a selected image actually depicts the project type described, rather than just matching a keyword tag someone applied three years ago. In RFQ and RFP compliance reviews, scanned attachments often arrive as image files rather than selectable text, and a multi-modal system can read those pages without requiring a separate OCR preprocessing step. For due diligence questionnaires that ask firms to document project scale with both photographs and data tables, multi-modal inference treats the table and the photo as a single evidence set. The practical limit is accuracy: multi-modal models can misread low-resolution images or misinterpret an unlabeled diagram, so human-in-the-loop review remains necessary before any output goes into a deliverable.
Multi-modal AI is frequently confused with image generation tools, but in a proposal context the value is almost entirely on the input side, not the output side. The question is not whether an AI can produce a rendering; it is whether the system can read your existing project photography, extract meaningful context from it, and connect that context to the right pursuit at the right time. Firms with large, inconsistently tagged image libraries often have more to gain from multi-modal reading than from any text-based capability. Kantiv uses multi-modal processing to surface verified project content, including images and associated data, against active pursuit requirements, so teams are not manually cross-referencing a photo archive while a submission deadline closes in.
Related terms
Natural language processing is the branch of machine learning that enables software to parse, interpret, and generate human language text, and in AEC pursuit contexts, it is the underlying mechanism that makes proposal content searchable, classifiable, and reusable without manual tagging.
NLP models do not simply keyword-match. They identify semantic relationships, so a query for "transit-oriented mixed-use" surfaces a past project narrative that never uses that exact phrase but describes a light rail adjacency and ground-floor retail program. Entity recognition, a specific NLP capability, pulls structured data from unstructured text: client names, project values, square footages, and delivery methods buried inside old Word documents. For AEC teams, this matters because a decade of proposal files is almost never consistently tagged, and NLP is what makes that archive queryable without a retroactive data-entry effort.
The two points of highest friction in a typical two-week RFP response are project selection and tailoring boilerplate to the specific evaluation criteria. NLP addresses both: it ranks project experience against SF-330 Section F requirements by comparing the language of past project descriptions to the stated scope in the solicitation, and it flags where existing narratives address the client's stated evaluation factors versus where gaps remain. Some systems also apply NLP to the RFP document itself, extracting mandatory requirements, scoring weights, and page limits so coordinators aren't manually reading the document three times before building the compliance matrix.
NLP's real value in AEC pursuits is not writing speed; it is institutional memory retrieval at the moment it is actually needed. A BD director with 30 years at a firm holds a mental index of every relevant project and the nuance behind each one. NLP attempts to encode that index so it survives turnover, works at 2 a.m. before a shortlist interview, and covers project history that predates any current team member. The ceiling on this capability is the quality of the underlying content: NLP cannot surface context that was never written down, which is why capture notes, lessons-learned debriefs, and post-submittal retrospectives are inputs, not afterthoughts. Kantiv applies NLP across proposals, project data, and client history so teams retrieve verified pursuit context rather than reconstructing it from memory or scattered file shares.
Related terms
A one-shot prompt gives a large language model exactly one example of the desired output before presenting the actual task, anchoring the model's response to a concrete pattern rather than letting it infer format, tone, or structure from training data alone.
When a model sees one labeled example, it performs a form of in-context learning: it extracts the implicit rules embedded in that example and applies them to the new input without any weight updates or retraining. The example effectively overrides the model's default priors for that task. This matters more than most proposal teams realize because a model's default prior for, say, a project narrative skews toward marketing generalities, not the tightly scoped, qualification-forward language that resonates with a public agency evaluator. One well-chosen example can shift the entire register of the output toward QBS-aligned language without a single additional instruction.
The most practical application in AEC marketing is format control during compressed timelines. When a coordinator is producing ten project profiles for an SF-330 Section F under a two-week deadline, a one-shot prompt built from a previously approved profile sets length, field order, and sentence construction instantly. The gap between zero-shot and one-shot output is not subtle: zero-shot responses often drift in length and bury the client name and construction value that evaluators scan for first. One-shot prompting is also useful at the win-theme level, where showing the model a single strong differentiator paragraph trains it to weight firm-specific proof points over generic capability claims across subsequent responses.
Teams assume any example works. It does not. The example is training data for that session, so a mediocre boilerplate teaches the model to reproduce mediocrity at scale. The example should be a piece of content that already passed internal review, cleared the client's stated evaluation criteria, and reflects the tone of the specific pursuit type, whether that is a federal RFQ under FAR Part 36 or a design-build RFP from a transit authority. Kantiv surfaces verified prior content, approved project narratives, and past win language by pursuit type, which means the one-shot example a coordinator pulls is drawn from institutional memory rather than whatever file happened to be open last. Picking the wrong example is the failure mode; the prompting technique itself is sound.
Related terms
A partner or principal at an AEC firm holds an ownership stake or senior leadership title that carries direct accountability for both client relationships and revenue generation, making them the most consequential variable in any pursuit.
At a partnership-structured firm, "partner" implies actual equity; at a corporation, "principal" is often a performance title granted to senior technical leaders with no ownership component whatsoever. The distinction matters in pursuits because a principal-in-charge listed on an SF-330 Section E may have no authority to commit firm resources, set fee strategy, or approve teaming agreements, while a named partner at the same firm carries all three. Some firms run both tracks simultaneously, creating internal confusion about who actually controls a pursuit. BD coordinators who treat every "principal" as a decision-maker will misread the internal approval chain and set up go/no-go conversations with the wrong people.
In most firms under 500 people, the partner or principal is simultaneously the client relationship owner, the technical lead, and the signing authority on the fee proposal: three roles that create compressing demands during a two-week RFP window. They are expected to contribute to the win strategy, review the project approach narrative, and make a final call on subconsultant fees, often while billing hours on active projects. The proposal coordinator's job is frequently to extract specific commitments from this person before the pursuit loses momentum. Knowing which pursuits a given principal has historically championed, and which they have abandoned mid-process, is the kind of institutional knowledge that determines whether a go/no-go scorecard reflects reality.
Principals are the canonical example of the seller-doer model: they are expected to win work and then execute it, with no protected time allocated to either activity. This compression produces a predictable failure mode in BD: verbal commitments to pursue an opportunity that quietly die when a project delivery crisis hits, leaving the marketing team holding a half-built proposal with no champion. Firms that track principal pursuit history, client relationship ownership, and past win rates by pursuit lead can identify which principals consistently convert interest into submitted proposals and which create false pipeline. Kantiv surfaces this kind of structured pursuit history so teams can have an honest internal conversation before the go/no-go call, not after a shortlist miss.
Related terms
A people-project matrix is a structured cross-reference of staff and project history that maps who worked on what, in which role, and at what scope, so a proposal team can identify the strongest qualifications match for a specific pursuit from verified data instead of tribal knowledge.
Most firms carry far more relevant experience than any single person on the marketing team can recall on demand. A project manager who led three water treatment expansions in the last four years may not surface until after submittal if nobody maintains a cross-reference that connects her name to that project type, her specific role, and the construction value she managed. The matrix solves the recall problem structurally, not by asking around. What makes a well-built matrix genuinely useful is role specificity: "contributed to" is not the same as "led design," and owners reviewing an SF-330 Section E can tell the difference. Firms that track role, scope, and fee separately from project metadata get far more utility out of the cross-reference than those who simply log participation.
The go/no-go decision often hinges on whether the firm can staff a pursuit with people who have demonstrable, role-specific experience on comparable projects; a matrix answers that question in minutes rather than requiring a firm-wide email chain. During RFP response, it drives Section H key personnel selection on federal submittals and equivalent staffing narratives on municipal and private sector pursuits. When shortlists come down to three to five firms with similar portfolios, the depth and specificity of the personnel qualifications frequently separates the winner, and teams that can pull verified role histories quickly assemble stronger SF-330 Part I resumes. It also supports debrief analysis: if a firm consistently loses on key personnel scoring, the matrix surfaces whether the problem is a depth gap or a presentation gap.
Building the matrix once and not maintaining it is nearly universal. Projects close, staff turn over, and the cross-reference drifts out of sync with reality within a year unless someone owns the update process as a defined responsibility, not a periodic cleanup task. A secondary failure mode is matrix entries that capture project names without the structured attributes that make them searchable: project type, delivery method, client sector, construction value, and the individual's specific scope of work. Kantiv structures this cross-reference as a living layer of pursuit intelligence, connecting personnel records to project data so teams querying for a pursuit-specific staffing match retrieve verified context rather than a stale spreadsheet. The firms that treat the matrix as infrastructure rather than a document get compounding returns: every closed pursuit feeds the next one.
Related terms
A practice area leader is a senior technical professional at an AEC firm who owns the business development pipeline, client relationships, and service delivery quality for a defined discipline or market sector, functioning simultaneously as a seller, doer, and internal advocate for that practice.
Most practice area leaders carry a billable utilization target alongside a revenue growth target, which creates a structural tension that marketing teams feel on every pursuit. When a leader is 80% billable on a major project, BD activity slows, RFP responses get reviewed at midnight, and go/no-go decisions get made reactively. The role is often confused with a technical director, but the distinction matters for proposals: a technical director owns methodology, while a practice area leader owns the client relationship and the win strategy. In QBS-driven public work under the Brooks Act, the practice area leader is typically the face of the firm to the agency, which means their biography, their project history, and their narrative voice need to be represented accurately in every SF-330 submission. Firms that treat the practice area leader as simply an approver on Section E often miss the opportunity to use that person's specific client language in the project approach.
On a two-week RFP response timeline, the practice area leader is usually the person who sets the win theme in the first two days and then disappears until internal review. That gap is where proposals drift: coordinators fill win strategy sections with generic language because they cannot access what the leader knows about the client's actual priorities. The practice area leader often holds the debrief history, the relationships with the selection committee, and the institutional memory of what this client rejected in the last shortlist pool of three to five firms, but that knowledge rarely makes it into the content library in a retrievable form. The result is that a proposal coordinator or proposal writer rebuilds context from scratch on every pursuit, interviewing the leader for thirty minutes to extract what should already be documented. When a practice area leader transitions out of the firm, that client and market knowledge typically leaves with them unless someone has systematically captured it.
The non-obvious risk with practice area leaders is not succession; it is real-time availability. The knowledge gap shows up on active pursuits, not just after departures. Firms that have mapped their people-project matrix against practice areas can at least identify who has relevant project history when the leader is unavailable, but the qualitative context, client preferences, prior feedback, and relationship history, is almost never structured for retrieval. Kantiv captures that institutional knowledge from past proposals and project data and surfaces it during a pursuit so the team starts from verified context rather than a blank interview transcript. The practice area leader still sets the strategy; the platform ensures that strategy is informed by everything the firm already knows.
Related terms
Preconstruction is the pre-award and early post-award phase in which a contractor or construction manager collaborates with an owner and design team to establish budget, schedule, constructability, and procurement strategy before physical work begins, and it is increasingly the competitive differentiator that wins or loses CMAR and design-build pursuits at the proposal stage.
Owners selecting under Construction Manager at Risk or Integrated Project Delivery don't just want a GMP number; they want confidence that the contractor can actively reduce design risk during schematic and design development. A firm's preconstruction team typically includes estimators, schedulers, and trade coordinators who engage before 30% design documents exist, running parallel cost models against evolving drawings. The non-obvious reality: public owners evaluating CMAR under qualifications-based selection criteria often score preconstruction approach as heavily as the proposed project manager, because poor early estimating is the single most common driver of change orders and budget overruns downstream. SF-330 Section H, the additional information section, is where many AEC firms bury their most compelling preconstruction differentiators rather than foregrounding them in Section E project narratives or the project approach write-up.
When an RFQ or RFP requires a preconstruction services plan, proposal coordinators typically need to pull three categories of content: past fee structures for preconstruction phases, documented outcomes (budget accuracy at GMP establishment, design alternatives that produced verified savings), and named personnel with preconstruction credits distinct from their construction-phase credits. These are separate CVs; a project manager listed for both phases needs two distinct narratives or evaluators will assume the team has no dedicated preconstruction capacity. At the go/no-go stage, a firm should be asking whether its preconstruction track record actually matches the project type and delivery method on the table, because a strong CMAR preconstruction history on K-12 work does not self-evidently transfer to a healthcare pursuit with a different commissioning sequence and phased occupancy constraint.
Preconstruction outcomes are quantitative, but the data rarely lives in a form marketing can access quickly: estimating logs, bid package schedules, and VE tracking sheets sit inside project management systems or individual estimators' files, not in a content library. The result is that proposal teams fall back on vague capability language ("collaborative preconstruction process," "early cost certainty") that says nothing to a sophisticated owner's project manager who ran three CMAR procurements last year. The deeper problem is that preconstruction credits are often miscategorized in a firm's project database as general construction phase work, which means the actual preconstruction-specific narrative gets assembled from scratch every pursuit. Kantiv addresses this by capturing preconstruction-specific outcomes, personnel roles, and delivery milestones as structured data tied to each project record, so teams surface verified, project-specific evidence rather than paraphrasing the same generic paragraph.
Related terms
Procurement, in the AEC context, is the formal process a public or private owner uses to select a design or construction firm and establish a contract for services.
Most industries buy on price. AEC public procurement is governed differently: the Brooks Act (1972) mandates qualifications-based selection (QBS) for federal architecture and engineering contracts, prohibiting price as a selection factor until after a firm is chosen. Most states have adopted parallel statutes. This means the competitive variable in a public pursuit is almost never fee; it is demonstrated qualifications, relevant experience, and perceived team capability. Private owners are not bound by QBS, which is why design-build and P3 procurement on the private side can include price proposals in the first round.
A typical public procurement moves through a defined sequence: solicitation (RFQ or RFP published), submittal (SF-330 or proposal delivered), shortlist (usually three to five firms), interview, and selection. Most firms treat the proposal as the primary competitive event, but shortlist rates across the industry suggest the interview stage is where differentiated firms separate from qualified-but-generic competitors. The procurement calendar also matters: a two-week response window is common for task order work under an IDIQ, while a full design services RFP may allow 30 to 45 days. Knowing the difference changes how you staff the pursuit.
Every procurement your firm has touched is a data asset: the client's evaluation criteria, the scoring weights they published (and how those shifted across similar solicitations), the competitors who made the shortlist, and the debrief notes your BD director wrote after a loss. Few firms treat this systematically. The result is that institutional knowledge about how a specific agency evaluates proposals lives in one person's memory or a folder no one can find. Kantiv captures procurement history across pursuits so that when a client reissues a contract, your team starts with verified context about how that owner actually buys, not a best guess reconstructed from a three-year-old InDesign file.
Related terms
A project approach is the proposal section where a firm demonstrates its understanding of a specific scope of work by detailing methodology, phasing, team roles, risk factors, and client coordination in terms that are clearly responsive to this project, not borrowed from a generic template.
On a public sector pursuit evaluated under QBS criteria, technical merit often carries more weight than any other factor. The project approach is where that technical merit lives. Selection panels routinely say in debriefs that they could tell within the first paragraph whether a firm had actually read the RFP or was recycling last quarter's submission. The section is not a methodology overview in the abstract; it is the place where a firm maps its process to this client's constraints, this site's conditions, and this schedule's pressure points. A strong project approach does not just describe phases, it explains decisions: why this sequencing, why this coordination method, what triggers a contingency plan.
The project approach is typically drafted after go/no-go is cleared and win themes are set, because it should be the written expression of the firm's win strategy, not a standalone section assembled in isolation. On a two-week RFP timeline, this section often consumes the most internal review cycles because it requires input from the technical lead, the project manager, and sometimes a subject matter expert who has never written a proposal section before. Coordinating that input without losing consistency across other sections is where most teams lose time. In SF-330-based federal pursuits, the project approach maps roughly to Section H, though it has to do more persuasive work in a qualifications-based environment where fee cannot yet be the differentiator.
The default failure mode is a project approach that reads as a phasing diagram with paragraphs: phase one, phase two, phase three, generic risk language, boilerplate about collaboration. Evaluators on shortlist panels of three to five firms have read enough of these to recognize the pattern immediately, and it signals that the firm is managing proposal volume rather than pursuing this project. The non-obvious move is using prior project data, not just prior project narratives, to make specific claims: actual schedule variances managed, actual coordination mechanisms used on comparable scopes, specific regulatory constraints navigated. Kantiv surfaces that kind of verified project-level detail during active pursuits so the technical lead can write from real context instead of reconstructing it from memory.
Related terms
In AEC pursuits, the project manager named on a proposal is a positioning decision as much as a staffing one: the right PM can win shortlists; the wrong one, regardless of technical qualifications, can sink an otherwise competitive submittal.
Owners have been burned by bait-and-switch staffing more often than they care to count, which is why many federal and municipal RFPs now require a signed commitment letter from the proposed PM before submission. On SF-330 Section E, the PM's project-specific experience carries significant scoring weight because evaluators treat that person as the de facto promise the firm is making. A PM with deep experience in the client's building type but no prior relationship with that agency can still score well; a PM who is currently overcommitted across three active projects is a liability the evaluator may never see but the BD team absolutely should.
Proposal managers frequently pull the PM into scope reviews, fee sanity checks, and interview prep, but the earlier that person engages, the better the submittal reflects how the project will actually be run. PMs who have worked with a client before carry institutional knowledge that rarely makes it into a CRM: preferred communication cadence, past scope disputes, informal priorities the owner never put in writing. That context shapes how a technical approach section gets framed and whether a cover letter lands as generic or genuinely responsive. Two weeks is a short window; a PM who is not engaged until day ten is a missed opportunity.
Firms with deep benches face a different problem than firms with thin ones: not a shortage of qualified PMs, but a shortage of visibility into who is available, who has the right client-sector history, and who has worked with the proposed design principal before. Team chemistry matters on paper the same way it matters in delivery; evaluators reading SF-330 Section C and Section E simultaneously are checking whether the named team has actually worked together. Kantiv surfaces that cross-pursuit history so a proposal manager can confirm that the PM and PM of record share relevant project precedent before the submittal goes out, not during the debrief after a shortlist miss. Committing the wrong PM early, especially on a teaming arrangement where the GC or subconsultant has approval expectations, is a problem that compounds fast.
Related terms
A prompt is the complete input sent to a language model: the instructions, context, constraints, and examples that together determine what the model produces, not just a question typed into a chat interface.
A well-constructed prompt for proposal work contains four distinct layers: the role or persona the model should adopt, the context it needs to produce accurate output (client background, project type, relevant past work), the constraints that govern the response (word count, SF-330 section format, evaluation criteria language pulled directly from the RFP), and examples of the expected output quality. Miss any of those layers and the model works from assumptions. In a proposal context, that means invented project names, wrong teaming partner credits, or methodology descriptions that don't reflect how the firm actually works. The model doesn't know what it doesn't know, and it won't flag the gap.
A federal design-bid-build RFP may specify that responses to SF-330 Section H address no more than five relevant projects and mirror evaluation language from the SOW. A prompt that omits those constraints produces a response that looks complete but fails on review; the compliance check falls back on the proposal coordinator, who then spends time correcting output instead of advancing the pursuit. Providing the RFP text, the evaluation criteria, and verified past project data as part of the prompt changes the output significantly. This is why prompt construction is a strategic skill in the pursuit workflow, not a task that gets delegated to whoever first opens the chat window.
Firms running 40 to 80 pursuits per year should treat their best-performing prompts the way they treat go-by narratives: saved, labeled by pursuit type, and refined after each debrief. A prompt that reliably produces a strong project approach narrative for a public transit client encodes the firm's voice, the client's evaluation priorities, and the structural requirements of that pursuit type; a generic prompt does none of that. The common mistake is building a strong prompt once, getting good output, and losing the prompt when the pursuit closes. Kantiv surfaces the verified project data, personnel records, and client history that make a prompt accurate in the first place, so teams stop reconstructing context from scratch every time they open a blank input field.
Related terms
Prompt chaining is a technique where a complex AI task is broken into a sequence of smaller, dependent prompts, with the output of each step feeding directly into the next, so the model operates on bounded context rather than attempting to resolve an entire problem in a single generation.
A proposal response to a complex RFP is not a single task; it is a series of distinct tasks that require different inputs, different reasoning modes, and different verification steps. Asking a model to produce a complete project approach, pull relevant past project examples, and apply client-specific win themes all at once creates a context window problem: the model has too many competing objectives and too much undifferentiated information to handle any of them well. Hallucination risk increases with context length, and proposal content demands the opposite of probabilistic guessing. Chaining forces discipline by isolating each sub-task, which means errors surface earlier and stay contained within one step rather than compounding across an entire document.
A typical chain might start with a step that extracts the scope requirements from an RFP, then passes those requirements to a second step that retrieves relevant project experience from a content library, then passes the matched projects to a third step that drafts a project approach narrative against a specific evaluation criterion. Each handoff is explicit and auditable. This matters in an SF-330 context especially, because Section F and Section G involve structured data that must match exactly across the form; a chain lets a team verify the project list before it becomes prose, rather than finding a mismatch at the internal review stage when the deadline is two days out.
Teams sometimes assume that a more capable model eliminates the need for chaining, that a better foundational model will just "figure it out" in one prompt. That assumption conflates model intelligence with task architecture: even the strongest models produce more reliable outputs when problems are decomposed rather than dumped in whole. The discipline required to build a chain, scoping each step, naming its inputs and expected outputs, also produces a reusable workflow rather than a one-off prompt that only one person on the team knows how to run. Kantiv structures pursuit tasks as discrete, sequenced steps precisely because a documented chain becomes institutional process, not individual workaround.
Related terms
Prompt engineering is the practice of structuring inputs to a language model to produce outputs that meet a defined standard for accuracy, format, tone, and scope, without retraining the model itself.
A language model has no intent of its own; it completes patterns based on what it has seen during training and what it receives as input at inference time. The prompt is the only lever available to the user at that moment. Framing, sequence, specificity, and constraint all shape whether the model produces something usable or something that sounds correct but isn't. A prompt that asks a model to "summarize our water/wastewater experience" will produce generic output unless it is also told the audience, the length, the relevant project types, and what to exclude. In a proposal context, that ambiguity is not a minor inconvenience; it is the difference between a past performance narrative that fits the RFQ scope and one that gets flagged in compliance review.
Most prompt failures in AEC marketing are not dramatic hallucinations; they are quiet mismatches: the wrong project scale cited, a client name from a lapsed relationship, a fee range pulled from a sector the firm no longer pursues. These errors pass a casual read and die in technical review or, worse, at shortlist scoring. Prompt engineering cannot fix a context problem by itself. If the model has no access to verified project data, past SF-330 submissions, or actual staff expertise, a well-structured prompt will produce fluent fiction. This is why prompt engineering and retrieval-augmented generation (RAG) are often discussed together: the prompt structures the task, but the retrieved context supplies the facts.
Teams that invest in prompt engineering sometimes treat it as a permanent solution rather than a workflow component. A prompt that works well for a municipal water agency RFP will not transfer cleanly to a federal design-build solicitation with FAR Part 36 compliance requirements, a different page limit, and evaluation criteria weighted toward past performance over approach. Prompts need to be specific to pursuit type, client sector, and deliverable format; a library of reusable, tested prompts tied to common pursuit scenarios is more durable than any single clever input. Kantiv surfaces verified project context, staff qualifications, and prior submission content directly into the prompt environment, so the model is completing against real institutional data rather than filling gaps with inference.
Related terms
A proposal is the compiled response document an AEC firm submits in answer to an RFP — combining relevant project experience, team qualifications, project understanding, approach narrative, and required compliance items into a cohesive argument for why the firm should be selected.
AEC proposals vary by client, project type, and procurement format, but most responses contain a common set of components: a cover letter or executive summary, a section demonstrating understanding of the project and the client's goals, relevant past project experience with scope and performance details, resumes for key proposed personnel, and in some cases a preliminary project approach or schedule. Public sector proposals — particularly federal work — often follow prescribed formats like the SF-330. Private sector and design-build pursuits may have more structural flexibility, but the underlying evaluation criteria are similar: experience, team, and fit. The proposal is the primary artifact the selection committee scores.
The difference between a proposal that shortlists and one that doesn't is rarely the writing — it's the specificity of the content underneath. A project narrative that says "our team has extensive experience in water infrastructure" scores below one that names the client, the scope, the delivery method, and the outcome on a genuinely comparable project. That precision requires having accurate, accessible project data. In most firms, assembling that data — pulling the right project profiles, confirming personnel roles and dates, verifying client references — consumes the majority of available pursuit time, leaving the proposal team less bandwidth for the strategic work: tailoring the approach, sharpening win themes, and writing to what the RFP actually evaluates.
Every proposal a firm submits contains verified project narratives, current resumes, client relationships, and approach thinking that will be relevant again on the next pursuit. The problem: most firms treat proposals as output, not input. Once submitted, the content disappears into a shared drive or a past-submissions folder, and the next pursuit team rebuilds from scratch. Kantiv changes this by capturing proposal content — project profiles, personnel data, approach narratives, win themes — and making it searchable and structured for every pursuit that follows. Each proposal becomes a better starting point for the next one, instead of a document that gets archived and forgotten.
Related terms
A proposal coordinator is the production and logistics owner of a pursuit: the person who holds the schedule, manages contributor accountability, and ensures a compliant, complete submittal reaches the client before the deadline.
The title undersells the job. On a federal SF-330 submittal, the coordinator is tracking Section E resumes across multiple subconsultants, reconciling page limits against Section F project narratives, and chasing down wet signatures or SAM.gov registration numbers days before submission. On a design-build pursuit, they may be synchronizing inputs from a GC partner whose internal process runs nothing like the AEC firm's. The coordinator rarely writes the proposal but is responsible for every word that goes out the door.
The two-week proposal timeline common to many public-sector pursuits compresses every dependency into a narrow window where a single late resume or missing project photo can cascade into an overnight production crisis. Coordinators carry that risk silently, because the failures are visible and the near-misses are not. The deeper problem is information latency: a coordinator starting a new pursuit often spends the first two or three days reconstructing context that already exists somewhere in the firm, whether in a past proposal folder, a project manager's inbox, or a BD director's memory. That reconstruction time is the most avoidable cost in the pursuit process.
Experienced coordinators build personal systems to compensate for firms that have not solved knowledge management: a private folder of reliable resumes, a mental map of which PMs respond quickly, a remembered list of relevant past projects for a given client sector. Those systems work until the coordinator leaves, and then the firm discovers how much operational knowledge walked out with them. Turnover in coordinator roles is high relative to BD directors, which makes the institutional cost significant and recurring. A pursuit intelligence platform like Kantiv addresses this directly by making verified project data, personnel records, and prior proposal content available at pursuit start, so coordinators spend day one on strategy and assembly rather than archaeology.
On most AEC marketing teams of under ten people, the coordinator role is either a dedicated position or a function absorbed by a marketing manager running parallel pursuits. Either way, the coordinator is the connective tissue between the capture lead setting pursuit strategy, the technical staff writing content, and the principal signing the cover letter. QBS procurements under the Brooks Act (1972) add a specific compliance layer: qualifications-based evaluation means the coordinator's assembly of Section H narratives and project relevance arguments carries direct scoring weight. Missteps in formatting or missing mandatory elements can disqualify an otherwise strong submittal before reviewers reach the technical content.
Related terms
A Proposal Operations Lead is the person on an AEC marketing team who owns the production infrastructure of a pursuit: the schedules, the compliance matrix, the internal review cycles, and the final assembly and delivery of a submittal package.
In firms under 500 people, this function usually lives inside a single proposal manager who writes, coordinates, and produces simultaneously. At larger firms, the Proposal Operations Lead is a distinct role focused on process and production while pursuit leads or capture managers handle strategy and client relationships. The distinction matters because production failures (missed page limits, non-compliant formats, late FedEx drops) kill pursuits independent of technical quality. On a two-week federal RFP with SF-330 requirements, someone has to own the checklist; assuming it distributes itself is how firms lose on administrative grounds.
Proposal Operations Leads typically own the master pursuit schedule working backward from the submission deadline, the compliance matrix mapped against every RFP section and FAR Part 15 or agency-specific requirement, and the internal Pink Team and Red Team review calendars. They manage version control across contributors, which in practice means knowing which section manager last touched Section E and whether the project descriptions in Section F match the resumes in Section E. They also coordinate with subconsultants to enforce submission deadlines for their portions, a task that consumes more calendar than most job descriptions acknowledge.
Operations Leads accumulate institutional knowledge faster than almost anyone else on a marketing team: they know which project descriptions have been used before, which staff resumes are perpetually out of date, which client names trigger conflict checks, and which internal reviewers return meaningful feedback versus rubber stamps. That knowledge rarely gets captured anywhere useful; it lives in one person's inbox and memory. When that person leaves or moves to a different pursuit, the next team rebuilds from scratch, burning hours that a tight timeline cannot absorb. Kantiv addresses this directly by capturing pursuit artifacts, reviewer feedback, and compliance history in a searchable record that persists across the team, not just the individual. Firms that treat Proposal Operations as a strategic function rather than a production task tend to shorten their setup time on repeat agency pursuits and make fewer compliance errors on the ones that matter most.
Related terms
A proposal writer in an AEC firm is the person who converts technical input from project managers, engineers, and subject matter experts into RFP-compliant narrative that communicates a firm's qualifications, project understanding, and win strategy in the voice of a single, coherent author.
Proposal writers are translators first. A civil engineer will hand over a paragraph about stormwater detention basin sequencing; the proposal writer needs to know enough about FAR Part 36 procurement context, the client's stated evaluation criteria, and the SF-330 Section F narrative conventions to transform that paragraph into a differentiating project example rather than a technical summary. The work also involves holding a document together across five or six subject matter expert contributors who have different levels of writing ability, wildly inconsistent formatting habits, and competing opinions about what belongs in a two-week response window. Compliance is a parallel track: page limits, font size requirements, section ordering, and mandatory certifications all sit in the proposal writer's court even when no one else is watching them.
Most proposal writers enter a pursuit formally at RFP release, but the useful ones are in the room at go/no-go, because the decision to pursue should account for whether the firm has the content to support a credible response. From kickoff through internal review to final production, the proposal writer is the person who owns the master document, reconciles redlines from principals who disagree with each other, and makes judgment calls about what a section says when the technical lead has gone dark three days before deadline. At shortlist, the role often extends into presentation prep: scripting talking points, coaching seller-doers on narrative consistency, and making sure what the team says in the interview matches what the written proposal committed to.
The single largest inefficiency in AEC proposal writing is not slow writers; it is the time spent finding verified content. A proposal writer on a water infrastructure RFP might spend six hours locating the correct square footage, construction cost, and client reference contact for three relevant projects, hunting across SharePoint folders, emailing project managers, and reconciling two versions of the same project sheet with different numbers. That is not a writing problem. Kantiv addresses this directly by surfacing verified project data, personnel qualifications, and prior proposal narratives in context during active pursuits, so the proposal writer starts a section with a confirmed foundation instead of a blank page backed by uncertain institutional memory. The strategic implication is that proposal writers who spend less time on retrieval spend more time on the work that actually differentiates a submission: tailoring language to the client, sharpening the win theme, and closing gaps that a boilerplate-assembled response would leave open.
Related terms
A pursuit is the complete sequence of coordinated activities a firm undertakes to win a specific contract opportunity, beginning when a lead is first qualified and ending at award or formal debrief, encompassing go/no-go evaluation, RFP response, shortlist interview preparation, and close-out.
Most firms date a pursuit from when the RFP drops. That is the wrong starting line, and it quietly distorts hit rate calculations firm-wide. A pursuit begins the moment someone decides the opportunity is worth tracking: a relationship is being cultivated, a project is on a CRM watch list, or a seller-doer is walking the client's facility before any RFP is published. The pre-RFP window is where win probability is actually shaped; by the time the solicitation posts, the shortlist of three to five firms the owner already has in mind is largely set. Firms that track pursuits from RFP receipt systematically undercount the investment required to win and misattribute losses to proposal quality rather than insufficient early positioning.
The pursuit is the container; the proposal is one artifact inside it. A typical pursuit on a public sector project under the Brooks Act (1972) runs through a Statement of Qualifications, a formal go/no-go decision with a scored scorecard, an SF-330 submission, a two-to-three-week RFP response window, shortlist notification, an interview, and a debrief whether the firm wins or loses. Each phase has distinct deliverables, personnel demands, and decision points. A proposal coordinator managing four active pursuits simultaneously is not managing four identical workflows; each sits at a different phase with different deadlines, compliance requirements under FAR Part 36, and internal review cycles running in parallel.
Every pursuit consumes knowledge: past project scopes, relevant personnel qualifications, prior client history, fee structures from analogous work, and win themes that actually held up in debrief. That knowledge is almost never captured in one place, so the next pursuit on a similar project type starts from interviews and folder searches instead of verified context. The most experienced BD directors often carry the critical connective tissue in memory, which means it leaves when they do. Kantiv is built specifically around this gap: it captures pursuit-level intelligence across submissions, project records, and client history, and surfaces it at the moment a new pursuit requires it, so teams start from what the firm already knows rather than reconstructing it under deadline pressure.
Related terms
Pursuit intelligence is the organized body of institutional knowledge a firm draws on during an active pursuit: past project performance, client history, team qualifications, win/loss patterns, and competitive context, all verified and accessible before the proposal clock starts.
Raw project data sitting in Deltek or a shared drive is not intelligence. Intelligence is data that has been interpreted, validated, and connected to a specific pursuit context. A project sheet becomes intelligence when it includes the client contact who can verify past scope, the fee range the firm will defend, and the lessons learned that affected delivery. Most AEC firms have abundant data and scarce intelligence, which is why the same background research gets rebuilt pursuit after pursuit.
The gap shows up earliest at go/no-go, when BD directors are making decisions on incomplete pictures of client relationships and competitive positioning. It compounds at proposal kickoff, when the team spends the first three to five days of a two-week window reconstructing what the firm already knows instead of developing strategy. SF-330 Section F alone can consume two full days of coordination if project data is not pre-validated and mapped to relevant NAICS or agency criteria. Firms that treat intelligence as a pursuit-phase activity are already behind.
The firms that consistently make shortlists of three to five under QBS processes mandated by the Brooks Act treat pursuit intelligence as infrastructure, not preparation. That means capturing debrief outcomes, recording what differentiated the winning approach, and tagging personnel expertise at project close rather than at proposal kickoff. Kantiv is built around this principle: it pulls verified context from past proposals, project records, and client history so teams open a pursuit with a factual baseline instead of a blank document. The strategic advantage is not speed; it is the quality of the narrative that becomes possible when the team is not simultaneously doing research and writing.
Related terms
A pursuit strategist is the BD or marketing professional at an AEC firm who owns the win strategy for a specific pursuit: translating client intelligence into positioning decisions, guiding the narrative arc of the proposal, and ensuring the team is competing on terrain where the firm can actually win.
The title rarely appears on an org chart. In practice, the pursuit strategist role is played by whoever has enough client knowledge and organizational authority to make real positioning calls: sometimes a BD director, sometimes a senior proposal manager, sometimes a practice area leader who knows the client. The distinction that matters is between someone who shapes the strategy and someone who executes against it. Most AEC firms conflate the two, which is why so many proposals read like capability inventories instead of arguments. The strategist's job is to answer the question the client is actually asking, which is almost never "who has done this exact project type most often."
A pursuit strategist enters the work at or before go/no-go, not at kickoff. By the time the RFP drops, the positioning should already be directionally set: which project experiences anchor credibility, which team members signal the right expertise, and what the win themes will be before anyone has written a single word of Section E on an SF-330. During the proposal itself, the strategist is the person who pushes back when a technical lead defaults to firm-centric language or when the project approach section describes process instead of demonstrating understanding. After shortlist, the strategist owns the interview prep, connecting the written narrative to what the selection panel actually needs to hear in 30 minutes.
The most common failure mode is a strong win strategy that never reaches the page because the people writing the proposal didn't have access to the reasoning behind it. A strategist can define a sharp angle on a pursuit and still watch the proposal drift generic because the writer is working from last year's boilerplate with no context about what makes this client different. The second failure mode is a strategist who is spread across too many concurrent pursuits to stay in actual contact with the content being produced. Kantiv addresses this by capturing the strategic rationale alongside the proposal assets, so when a writer pulls a past pursuit for reference, the positioning logic travels with the content rather than disappearing when the pursuit closes.
Related terms
Redlines are the tracked changes, margin comments, and strikethrough edits applied to a proposal draft, typically during internal review, that carry both technical corrections and strategic direction in the same marked-up document.
A redline pass from a principal or pursuit lead often contains the most concentrated strategic thinking on a pursuit: repositioned win themes, excised claims that can't be substantiated, and language swapped to match a client's known vocabulary. The problem is that this thinking disappears when the comment is accepted and the document is finalized. Most firms have no systematic way to capture why a particular phrase was cut or why a specific differentiator was foregrounded, so the same arguments get rebuilt from scratch on the next similar pursuit. Redlines are institutional knowledge in its most perishable form.
On a typical two-week federal proposal cycle, redlines cluster in two places: after the pink team review and again in the 48 hours before submission. The first pass is usually structural, questioning section order, compliance with the RFP's evaluation criteria, and whether the technical approach actually answers the SOW. The second pass is tonal and political, often reflecting last-minute intelligence about the selection panel or a competitor's known positioning. Managing both rounds without version-control discipline means teams frequently incorporate some reviewer comments but lose others, particularly when edits arrive across email threads rather than a single marked document.
Reviewed proposals from similar past pursuits contain a record of what your senior people actually thought was wrong with an approach, which is often more useful than the approved final text. A BD director's redline on a healthcare science proposal from three years ago may note that the client cared more about schedule certainty than unit cost, a fact that won't appear in the submitted document but would change how you structure the next pursuit for that owner type. Recovering that signal requires going back to marked-up drafts that most firms have archived, if they've archived them at all, as PDFs stripped of comments. Kantiv captures reviewer edits and associated commentary as structured institutional knowledge, so the reasoning behind past redlines is searchable the next time a similar project enters the pipeline.
Related terms
A Request for Information (RFI) is a pre-solicitation document issued by a public or private client to survey the market, assess contractor and consultant qualifications, and gather input that may shape a future procurement before a formal RFP or RFQ is released.
RFIs precede both the RFQ and the RFP, and they carry no award obligation. A federal agency might issue one to test whether QBS-eligible firms exist for a specialized project type before committing to a full SF-330 solicitation. State DOTs frequently use them when scoping a new design-build program, pulling in feedback on risk allocation, delivery method preferences, and market capacity before the procurement office drafts the actual RFQ. What surprises some teams: RFI responses are often publicly disclosed, which means your competitors see what you said. Firms that treat an RFI as low-stakes often put forward language they would not include in a formal submission, without recognizing that a program manager is reading across all responses to identify who actually understands the project.
An RFI response is not a proposal, but the decision to respond deserves the same go/no-go discipline. Responding signals market presence to the client and, depending on the project type, may influence whether your firm appears on the shortlist pool when the RFQ drops. More practically, the questions inside an RFI tell you what the client does not know yet: technology gaps, delivery method uncertainty, sustainability requirements still in flux. A BD director who reads those questions carefully gets a two-to-six-month head start on shaping win strategy before the formal pursuit clock starts. Skipping an RFI because it carries no award is how firms end up responding to an RFP shaped entirely by their competitors' input.
Most firms have no consistent place where RFI responses live after submission. They land in someone's sent folder, get saved to a project drive with no tagging, and disappear from institutional memory before the RFP arrives. When the RFQ comes out six months later, the team rebuilding the pursuit often has no visibility into what was already communicated to the client, which creates the risk of contradicting prior language or duplicating effort that was already done. Kantiv captures RFI responses alongside project data and proposal content so that when the formal pursuit opens, the team starts from what was already said rather than reconstructing it from scratch.
Related terms
A Request for Proposals (RFP) is the formal solicitation a client issues to invite AEC firms to compete for a project — specifying scope, evaluation criteria, submission requirements, and the information the selection committee will use to make a decision. In AEC, RFPs appear across virtually every project type and client sector: a county transportation department selecting an engineering firm for bridge rehabilitation, a school district seeking an architect for a new elementary campus, a transit authority issuing a competitive solicitation for a rail extension, a water utility procuring engineering services for a treatment plant upgrade, or a hospital system looking for a construction manager for a new clinical building. The RFP defines the terms of competition — what to submit, how it will be scored, who decides, and by when.
On the surface, an RFP asks for qualifications, project experience, team resumes, a project approach, and sometimes a fee estimate. Underneath that, it is a structured test of three things: does this firm have relevant experience, do they have the right people, and do they understand what we are trying to accomplish? Clients issue RFPs because they need to justify a selection decision — to a board, a funding agency, or a procurement office — so every section carries a scoring weight. The firms that read RFPs as evaluation rubrics, not document checklists, and build their response strategy around what the panel is actually scoring, consistently outperform those that treat every pursuit the same way.
An RFP response requires coordinated input from across the firm — proposal managers, marketing coordinators, project managers, technical leads, and often principals. The proposal manager typically parses the document for compliance requirements, convenes a go/no-go conversation with BD and leadership, and begins assembling the response: identifying analogous projects, pulling relevant resumes, drafting the project approach, and managing reviews against the deadline. In most firms, this process runs on a compressed timeline — often two to four weeks — with the team balancing this pursuit against several others running simultaneously. The quality of the final submission depends as much on how quickly the team can locate and verify the right supporting content as it does on the writing itself.
Most firms lose ground not in the writing phase but in the setup phase — identifying which past projects are genuinely analogous, confirming that resume content is current, and ensuring the project approach is tailored rather than recycled. Proposal teams that spend the first week of a pursuit doing this groundwork have less time for the differentiation that actually moves evaluation scores: sharp win themes, a client-specific approach, and a response that demonstrates the firm has thought about this project, not just this RFP type. Kantiv addresses this by structuring a firm's institutional knowledge — project histories, personnel data, past proposals — so pursuit teams start from verified content on day one rather than rebuilding context under deadline pressure.
Related terms
A Request for Qualifications (RFQ) is a pre-screening solicitation that asks AEC firms to demonstrate their qualifications before being invited to submit a full proposal — evaluating experience, key personnel, and past project relevance without yet requesting a project approach or fee.
An RFQ asks one question: is this firm qualified? Where a Request for Proposals (RFP) requires a project approach, team plan, and often a fee, an RFQ is narrower — typically requesting a firm overview, relevant project experience with scope and delivery details, key personnel qualifications, and evidence of past performance in comparable contexts. In public procurement, RFQs establish a shortlist of pre-qualified firms who then receive the full solicitation. In federal and state DOT markets, the RFQ stage determines which firms even see the RFP. Getting shortlisted through an RFQ is the prerequisite to competing, not just a warm-up round.
Despite the shorter format, RFQs are competitive submissions. Selection committees score the same fundamentals they score in any pursuit: relevant experience, team depth, and confidence that this firm can execute the specific project type. The difference is that firms have less room to tell a story — there's no narrative approach section, no project understanding, no differentiating angle on scope. That compression makes project selection critical. A firm with forty comparable projects that leads with the wrong three will score below a competitor with ten that leads with the right one. Qualification-based selection demands precision, not volume.
Many teams treat RFQs as a lighter lift — fewer pages, faster to assemble, lower stakes. That framing is backward. An RFQ determines whether the firm gets to compete at all; a weak submission ends the pursuit before the proposal stage begins. Teams that build RFQ responses quickly and accurately depend on having current, structured project data: scope, contract value, delivery dates, client contacts, and accurate personnel assignments. Kantiv structures this institutional knowledge — pulling verified project profiles and personnel records — so pursuit teams can build a targeted, competitive SOQ without spending days chasing project managers for numbers that should already be on file.
Related terms
Retrieval-augmented generation (RAG) is an AI architecture that grounds a language model's output in documents retrieved from a specified source at the moment of generation, rather than relying solely on patterns baked into the model during training.
A foundational model trained on public data has no knowledge of your firm's past performance, your project history, or the specific scope language that won you a water treatment plant in 2019. RAG closes that gap by pulling relevant documents from a defined corpus at inference time and feeding them into the prompt as context. The model then generates output grounded in those retrieved documents rather than in generalized internet patterns. For AEC marketing, that corpus is the thing that matters: it needs to contain your actual proposals, project data sheets, SF-330 submissions, and debrief notes, not generic industry content. The quality of RAG output is bounded by the quality, structure, and coverage of whatever sits in the retrieval layer.
RAG retrieves by similarity, not by correctness. If your vector database contains three different versions of the same project description with conflicting square footages or completion dates, the retrieval layer may surface any of them, and the model will write confidently from whichever it pulls. This is the most common source of hallucination in RAG-based proposal tools: not fabrication from thin air, but plausible-sounding output built from stale or inconsistent source documents. In a two-week RFP response cycle, there is rarely time to audit retrieved content sentence by sentence, which means garbage-in-garbage-out applies here with real consequences for compliance and factual accuracy. Retrieval also degrades on short or ambiguous queries; asking a system for "bridge experience" may surface pedestrian bridge narratives when you need major span infrastructure, depending on how the content was tagged and embedded.
RAG is not a plug-and-play feature; it is a dependency on your institutional knowledge infrastructure. A retrieval layer pulling from an unmaintained content library, an unstructured shared drive, or a digital asset management system with inconsistent metadata will produce output that requires more correction than a blank page would. The firms getting accurate, usable RAG output have done the upstream work: structured project data, consistently tagged personnel profiles, version-controlled proposal sections, and a defined process for retiring outdated content. Kantiv is built around this premise, functioning as the retrieval layer that surfaces verified pursuit context from your firm's own history rather than generating from generalized patterns. The human-in-the-loop review step never disappears with RAG; it shifts from writing to verification, which is a different skill but not a smaller one.
Related terms
Role prompting is a prompting technique that assigns a specific persona to an AI model before issuing a task, shaping the register, tone, assumed expertise, and framing of its output based on the attributes of that assigned role.
Assigning a role does not give the model new knowledge; it shifts which parts of its training it draws on most heavily and how it organizes a response. Tell the model it is a federal procurement officer reviewing an SF-330 and it will weight compliance language differently than if you tell it nothing at all. The register changes too: a role framed as a senior civil engineer will produce denser technical language than one framed as a project communicator writing for a lay client. What role prompting does not do is resolve factual gaps. If your context window contains incomplete project history, the persona will still hallucinate to fill it.
The most practical application in AEC marketing is calibrating tone and framing for different sections of the same pursuit package. A role framed as a seasoned BD director reviewing a win-strategy theme will surface different objections than one framed as a technical evaluator scoring a project approach narrative against published evaluation criteria. During internal review cycles, prompting the model to act as a skeptical owner's representative can pressure-test whether your differentiators hold up or dissolve into generic claims. It is not a substitute for a human red team, but it can surface weak spots before the document reaches your principal-in-charge.
Most teams write vague roles: "act as an expert proposal writer." That instruction is nearly useless because it maps to too broad a distribution of the model's training data. Specificity is what creates useful constraint: "act as a QBS-trained procurement officer at a mid-size municipal agency evaluating Section H of an SF-330 against the stated evaluation criteria" produces a materially different output. The other failure mode is treating the role as a fixed header and ignoring how it interacts with system instructions and the rest of the prompt structure; role prompting compounds with contextual prompting and templated guidance, and a role that contradicts your system instructions will produce inconsistent results across a multi-section pursuit. Kantiv applies role and system instructions as part of a structured prompt layer, so the framing governing how institutional content gets surfaced stays consistent across every section of a pursuit rather than varying by whoever typed the prompt last.
Related terms
Sales enablement in AEC is the organized system of content, process, and institutional knowledge that equips BD professionals and seller-doers to pursue work without rebuilding the same materials from scratch on every opportunity.
Most sales enablement frameworks assume a sales team that operates separately from delivery. In AEC, the people closest to the client are usually also running the project: the seller-doer model collapses that boundary. That structural fact changes what "enablement" actually means. A principal pursuing a water treatment expansion needs access to the firm's prior plant experience, the right subconsultant relationships, and a compliant SF-330 Section F before the conversation with the client gets serious, not after. The content has to be accurate, current, and retrievable in under a day, because the RFQ window rarely allows more.
The failure mode is not usually a missing document; it is a document that exists somewhere but cannot be found or trusted. A proposal coordinator on a two-week deadline cannot spend three days locating the correct version of a project narrative or verifying that a resume reflects the engineer's most recent relevant work. Go/no-go decisions made without reliable data on past performance, win rates, or client relationships produce systematic errors that compound over a fiscal year. Shortlist preparation suffers the same way: when a team cannot quickly assemble verified evidence of experience, the interview materials default to generic claims instead of specific proof.
In most AEC firms, the knowledge that makes a pursuit competitive lives in people's heads, in old proposal folders, and in project closeout files that nobody reads. Firms that treat enablement as a content library problem alone miss this: organizing documents does not capture what the project manager learned about a client agency's real priorities during preconstruction, or which pursuit approach failed at shortlist two years ago and why. Effective enablement requires a system that captures context alongside content, not just files. Kantiv functions as that system, pulling verified project data, personnel expertise, and client history into a single place so BD teams start each pursuit from accurate institutional context rather than rebuilding it under deadline pressure.
Related terms
A seller-doer is a technical professional — an engineer, architect, project manager, or principal — who carries both project delivery and business development responsibility, maintaining client relationships and helping win new work while also executing the projects they sell.
Unlike industries with dedicated sales organizations, most AEC firms rely on technical staff to develop business. Clients hire firms partly for the people who will be on the project — and those people are typically the same ones who built the relationship, attended the pre-proposal meeting, and will lead delivery. A senior civil engineer at a 500-person firm might be managing three active projects, mentoring junior staff, attending a municipal transportation committee meeting, and preparing for a pursuit interview in the same week. That dual role is the norm in AEC, not the exception. Technical credibility is the primary currency in client relationships, and sellers without it rarely close work in this market.
The tension in the seller-doer model is time. Delivery demands don't pause for pursuit activity, and proposal timelines don't accommodate full project schedules. When an RFP drops, the seller-doer is often the firm's most critical voice for the pursuit — the person who knows the client, understands the scope, and can frame the technical approach credibly — but they're also the person least available to spend 20 hours on proposal content. Marketing and proposal teams depend on seller-doers for project narratives, resume approvals, technical approach input, and interview preparation. Getting that input quickly, and getting it right, determines whether the proposal reflects the firm's actual capability or a generic version of it.
The more a firm can reduce the administrative burden on seller-doers — the content hunting, the rewriting of project descriptions already written in a previous proposal, the resume updates that happen three hours before the deadline — the more effective the model becomes. Seller-doers produce their best pursuit contribution when they're focused on strategy and client insight, not on reconstructing information that should already be structured and accessible. Kantiv captures the institutional knowledge that seller-doers carry — project experience, client relationship history, past proposal content — so the marketing team arrives at the strategy conversation already grounded in verified data, and the seller-doer's time goes toward differentiation, not documentation.
Related terms
Shared AI memory is a persistent, team-accessible knowledge layer that stores verified pursuit data, project history, and personnel expertise so every member of a BD team draws from the same source when building a response.
A database holds records. Memory holds context. The distinction matters because a proposal team doesn't need raw project data at 9 PM before a submittal; they need the right framing, the proven differentiator, the subcontractor relationship that worked on a comparable job. Shared AI memory surfaces associations between pieces of information rather than requiring a user to know exactly what to search for. Most AEC firms already have the underlying data scattered across SharePoint folders, Deltek project files, and individual inboxes; the memory layer is what makes it retrievable in context rather than retrievable in theory.
On a typical two-week federal proposal timeline, the first three days often disappear into locating usable project narratives, confirming which staff have the right certifications for SF-330 Section E, and tracking down past fee structures. Shared AI memory compresses that reconnaissance phase because the work of prior pursuits is already indexed and associated with the current opportunity's criteria. A pursuit manager can enter the project type, client agency, and delivery method and surface relevant experience without canvassing six project managers over email. The practical effect is that scarce time shifts from assembly toward strategy.
AEC firms lose compounding amounts of pursuit knowledge every time a senior BD director leaves, a principal retires, or a marketing coordinator moves on. What they took wasn't just contacts; it was the interpretive layer: which clients care about schedule over cost, which evaluation committee members weight local presence heavily, which past project narratives performed well in shortlist pools of three to five firms. Shared AI memory makes that interpretive layer a firm asset rather than a personal one. Kantiv builds this layer by capturing signals from proposals, project data, and client history and keeping them accessible to the whole pursuit team during active opportunities, not just archivable after the fact.
Related terms
A shortlist is the group of finalists a client selects after reviewing first-round submissions — the firms invited to interview, present, or submit a best-and-final offer before the selection decision is made. In AEC, shortlisting happens across every project type and procurement format: a county water authority advances three engineering firms to interviews after scoring fifteen SOQs, a transit agency narrows an architecture pool from twelve to four before issuing a best-and-final request, a hospital system selects five construction managers from an initial RFP round to present their team and approach. The shortlist is the dividing line between firms still in the pursuit and firms that are done competing for that contract.
Shortlisting typically follows the initial scored evaluation of submitted proposals or SOQs. The selection committee reviews all responses against a scoring rubric — experience, team, project understanding, approach, sometimes fee — and advances the top three to five firms to the next stage. Making the shortlist means the proposal demonstrated enough relevance, credibility, and client alignment to warrant a deeper look. Missing it ends the pursuit regardless of how strong the interview would have been. That asymmetry makes the proposal the critical gate: firms win or lose the right to compete at this stage, and a shortlist rate below 40% is a signal that something in the firm's submission quality or pursuit selection needs to change.
Shortlisted firms are typically invited to an in-person or virtual presentation — 30 to 60 minutes, often with a panel that includes the client's project manager, procurement officer, and technical evaluators. Some clients provide specific questions in advance; others leave the structure open. In both cases, the shortlist interview is evaluating something the proposal couldn't fully convey: team chemistry, communication style, responsiveness to client concerns, and whether the firm's principals are the people they actually want working alongside them for the next several years. Firms that treat the interview as a second proposal — loading slides with project photos and credentials — consistently underperform teams that focus the presentation on the client's problem.
Win or lose at the shortlist stage, firms that conduct structured debriefs extract the intelligence that sharpens the next submission: what scored well, what the selection committee flagged as a gap, where a competitor's differentiation was stronger. Firms that track shortlist patterns over multiple pursuits — which market sectors they advance in, which client types favor their firm's profile, where experience depth is thin — make better go/no-go decisions and build more targeted proposals over time. The shortlist isn't just a milestone; it's a data point in a longer calibration cycle that separates firms with improving hit rates from those that keep submitting and wondering why the numbers don't move.
Related terms
A Statement of Qualifications (SOQ) is a firm-initiated or client-requested document that presents a company's credentials, relevant project experience, and key personnel to establish eligibility or competitive positioning before a formal proposal is solicited.
Most public agency procurements that follow qualifications-based selection under the Brooks Act (1972) begin with an RFQ that triggers SOQ submissions; the agency shortlists three to five firms before issuing an RFP. On federal projects, the SF-330 effectively functions as a structured SOQ with prescribed sections for project experience (Section F), key personnel (Section E), and organizational chart (Section D). Private clients often request an SOQ informally, outside any published procurement process, which means firms have no standard format to follow and must make deliberate decisions about depth, order, and emphasis. An SOQ submitted too early in a client relationship can look generic; submitted at the right moment, it positions the firm before a project is even publicly announced.
Compliance in an SOQ context means meeting page limits, including required sections, and matching the scope language in the RFQ. Competitive positioning means something different: selecting the four or five projects that most precisely mirror the client's project type, delivery method, regulatory environment, and risk profile, not the firm's largest or most award-winning work. Personnel bios need to show relevant role continuity, not just credential lists; a client evaluating a CMAR pursuit wants to see the same project manager and superintendent pairing across comparable jobs, not a roster of fifteen names. Shortlisting decisions often turn on how legible that match is to a reviewer spending eight minutes per submission.
Firms that chase volume across multiple market sectors struggle with SOQ consistency because the people who know which projects are actually comparable to a given pursuit are rarely the people assembling the document on a two-week clock. Project data lives in ERP systems in formats that do not translate directly into narrative; personnel expertise is stored in previous SF-330s and resumes that may be two years out of date; client relationships and past feedback sit in someone's memory or email inbox. The common workaround is to reuse last quarter's SOQ and edit for fit, which is how firms end up submitting work that references the wrong project type or omits a directly relevant credential. Kantiv addresses this by connecting current project data, verified personnel histories, and pursuit records so the team building the SOQ starts from a complete, accurate picture of what the firm has actually done and who did it.
Related terms
A Strategic Growth Executive is a senior BD leader in an AEC firm whose primary accountability is market positioning and pipeline development, not individual pursuit execution.
Most firms at the 200-person threshold start separating pure business development from proposal management, and the Strategic Growth Executive occupies the senior end of that split. This person owns relationships with key clients and teaming partners, tracks competitor positioning across target sectors, and sets the pursuit filter criteria that determine which RFPs the firm actually chases. They rarely write sections or manage SF-330 assembly; that belongs to the proposal manager. What they carry is the institutional knowledge of why certain clients buy, who the real decision-makers are behind a selection panel, and what positioning has historically won or lost in a given agency relationship.
During an active pursuit, the Strategic Growth Executive functions as the strategic briefer: they set the win theme, define the competitive context, and identify the project experience and personnel that should lead the narrative. On a two-week federal proposal timeline, that briefing needs to happen in the first 48 hours or the proposal team is writing without direction. The gap that kills teams is when this person's knowledge exists only in their head and cannot be accessed quickly enough to shape the first draft. A BD director with 20 years of DOT relationships knows things about an agency's evaluation culture that no RFP will ever state explicitly, and that knowledge has to transfer into the proposal before the kickoff meeting ends.
Strategic Growth Executives are the highest-density carriers of pursuit intelligence in any AEC firm, and also the most mobile. When one leaves, the firm loses the accumulated read on client relationships, competitor behavior, and positioning history that took years to build. Firms that rely on this person's memory alone are one retirement or resignation away from starting those relationships from scratch. Kantiv captures the outputs of that institutional knowledge, which includes past win/loss context, client history, and teaming patterns, so the next pursuit team starts from verified context rather than interviewing colleagues to reconstruct what was already known. The Strategic Growth Executive becomes more effective when that context is already surfaced, not when they spend kickoff meetings answering basic background questions.
Related terms
Structured data is information stored in a predefined schema with typed fields, relational keys, and consistent formatting so that software can query, filter, sort, and compute against it without ambiguity about what any value means.
Project records in a CRM with a construction cost field typed as currency, a delivery method field constrained to a controlled vocabulary, and a contract date stored as ISO 8601: that is structured data. A spreadsheet where one cell reads "$4.2M," the next reads "4,200,000," and a third reads "approx. four million" is not, regardless of its grid format. The defining characteristic is schema enforcement, not visual organization. Most AEC firms have structured data in pockets: Deltek Vision or Vantagepoint project records, Salesforce opportunity stages, BST Global personnel certifications. The problem is that these systems rarely share a common schema, so a "project type" field in your ERP may not map cleanly to the same concept in your CRM, and reconciling them requires either a data governance decision or a manual translation layer.
Go/no-go scorecards pull structured data when they query how many projects of a given type, above a given fee threshold, were completed in a given geography within the last five years. SF-330 Section F requires exactly that kind of answer, and the firms that answer it fastest and most accurately are the ones whose project records were entered consistently at closeout, not assembled under a two-week deadline. Shortlist pools of three to five firms tend to separate on relevance and specificity; a firm that can filter to "water treatment plants, design-build, over $20M construction cost, awarded 2019 or later" in thirty seconds has a material advantage over one reconstructing that list from email threads. Fee proposal calculations also depend on structured cost and labor data; if those fields were entered inconsistently, the numbers your estimator pulls may not mean what they appear to mean.
Most marketing teams assume their data is more structured than it actually is. A field exists in the system; therefore the data is structured. But a text field that someone uses to type "CMAR" in one record and "Construction Manager at Risk" in another is functionally unstructured: software cannot reliably group those two records without normalization. The real discipline is upstream, at project setup and closeout, enforcing controlled vocabularies and required fields before a pursuit creates urgency. Kantiv addresses this by treating project records, personnel data, and past proposal content as a unified knowledge layer with consistent structure, so that when a pursuit opens, the query against relevant experience returns verified results rather than a best-guess assembly of whatever was entered last.
Related terms
Structured retrieval is a method of querying information from explicitly organized, schema-defined sources, returning results based on exact field matches, tags, or metadata rather than semantic similarity or probabilistic inference.
Most AEC content libraries are built on unstructured data: PDFs, Word documents, InDesign files, email threads. Semantic search can approximate meaning across these, but it guesses. Structured retrieval does not guess; it returns exactly what the field contains. If a project record has a tagged field for contract value, construction type, delivery method, and primary client, a structured query returns every design-build project over $50M for a municipal water authority. That is a fundamentally different operation than asking a language model to find "similar projects," which is subject to embedding distance, tokenization artifacts, and whatever proximity threshold the system was tuned to. The non-obvious implication is that structured retrieval is only as good as the tagging discipline behind it: a firm that has been inconsistently classifying projects for ten years will get inconsistently precise results, regardless of how sophisticated the query layer is.
During an RFP response, the fastest wins come from pulling verified, already-approved content: past project descriptions, SF-330 Section F narratives, resume fragments, past performance citations. Structured retrieval handles those pulls precisely, because the content has known attributes. A proposal coordinator building a shortlist-stage submittal can query by NAICS code, client agency, project phase, or relevant personnel without reading through every possible candidate record. Where structured retrieval breaks down is in synthesis: it will return the right records, but it cannot draft the win theme connecting them. That is where retrieval-augmented generation enters, using structured results as grounded inputs to a language model rather than letting the model search unguided. Understanding which task belongs to which method is what separates a functional AI-assisted workflow from one that produces plausible but unverifiable output.
Teams often treat structured retrieval and semantic search as competing alternatives and pick one. They are not alternatives; they are complements covering different failure modes. Semantic search handles fuzzy, exploratory queries where the user does not know exactly what exists. Structured retrieval handles compliance pulls, people-project matrices, and content audits where accuracy is not negotiable. Mixing them without understanding which mode is active is where hallucination risk enters a proposal workflow, because a model filling gaps from unstructured inference will generate content that sounds correct but is not sourced. Kantiv applies structured retrieval against verified pursuit data, project records, and personnel expertise so that what surfaces in a proposal context is a confirmed fact, not a probabilistic approximation.
Related terms
A style guide is a firm-level document that governs the visual and editorial standards applied to all proposal and marketing content: typefaces, color values, logo usage rules, header hierarchies, boilerplate voice, and punctuation conventions.
Most AEC style guides were written during a rebrand and haven't been updated since. By the time a proposal manager inherits one, it may conflict with the current logo suite, reference a deprecated InDesign template, or omit entire content categories like project case study formatting or resumes. The gap between the written guide and actual practice tends to widen with every new hire who never read it. Firms with multiple offices compound the problem: regional teams develop local conventions that quietly diverge from the master document over years.
A functional proposal style guide goes well beyond hex codes and margin widths. It should specify how project descriptions are structured (scope sentence, client name, delivery method, relevant metric), how staff bios differ between SF-330 Section E and a shortlist presentation, and what the firm's editorial voice sounds like at the sentence level. It should also document exceptions: federal pursuits under FAR Part 36 often require plain-language descriptions that conflict with a firm's marketing voice, and the guide should acknowledge that tension explicitly. Without that level of specificity, the guide becomes a brand reference sheet rather than a production tool.
On a two-week proposal timeline, no one has time to audit whether a subconsultant's submitted resume matches the firm's format. A style guide that is actively embedded in templates, content libraries, and reviewer checklists prevents that audit from being necessary. The real value isn't aesthetic consistency; it's decision speed. When a coordinator knows the answer to "how do we handle this?" before the question comes up, that's time recovered across every pursuit. Kantiv surfaces approved content alongside the style conventions that govern it, so teams applying boilerplate or pulling project narratives aren't working from institutional memory alone. Firms that treat the style guide as living infrastructure rather than a static PDF see fewer last-minute formatting corrections and fewer rounds of principal review tied to presentation rather than substance.
Related terms
System instructions are persistent directives embedded at the start of an AI session that shape model behavior before any user input arrives: the role the model plays, the constraints it follows, the format it produces, and the tone it holds across the entire interaction.
Unlike a prompt you type into a chat interface, system instructions operate at the session layer. They define the frame before any content enters. In a proposal context, that means you can set the model to behave as a compliance checker rather than a writer, or instruct it to flag missing SF-330 Section H content instead of silently skipping it. You can also lock output format, so responses come back as structured JSON, a bulleted gap list, or a draft paragraph ready for red-line review. Without explicit system instructions, the same underlying model that helps you draft a project approach will also confidently fill in missing project data from its training set rather than telling you something is absent.
System instructions become operationally significant at three points: go/no-go analysis, compliance review, and shortlist prep. During go/no-go, you can instruct the model to evaluate a new RFQ only against criteria your firm has already defined as disqualifying: geography, project type, bonding capacity, current backlog. During compliance review, you can tell the model exactly what sections an RFP requires and ask it to return only a checklist of what is missing from the draft. Before a shortlist interview, a system instruction can constrain the model to draw exclusively from verified past project records rather than generating plausible-sounding but unverified experience claims. Each of these uses depends on a well-formed instruction set written before the session starts.
Most AEC marketing teams who start using AI tools write a system instruction once, save it somewhere, and forget to revisit it as firm capabilities, project portfolio, or pursuit strategy evolves. A system instruction referencing project types you no longer pursue, or personnel who have left the firm, will still sound authoritative. The instruction constrains behavior, but it cannot correct for stale content it was given to work with. Kantiv connects system instructions to live institutional data, so the constraints the model operates under reflect current project history, current staff expertise, and current client relationships rather than whatever was true when someone last edited a text file. Pairing strong instructions with current, verified context is what separates useful AI output from confident, well-formatted fabrication.
Related terms
System prompting is the practice of supplying a large language model with role definitions, behavioral rules, output format requirements, and hard constraints before any user query runs, shaping every response the model generates within that session.
Most AI interfaces expose a user turn and an assistant turn. The system prompt sits above both, and the model weights it more heavily than subsequent instructions in the conversation. It sets the persona the model adopts, the topics it will refuse, the tone and structure it applies to every output, and the facts it treats as fixed context. A well-constructed system prompt can also define what the model should do when it lacks sufficient information: return a flag, ask a clarifying question, or cite a source rather than fill the gap with inference. That last behavior matters enormously in proposal work, where a model that silently generates plausible-sounding project history instead of surfacing a gap will cost you credibility at shortlist review, not at the point of writing.
In an RFP response context, system prompting is the layer that keeps a general-purpose model from behaving like a general-purpose tool. Without it, the same model that summarizes legal briefs or writes marketing copy applies the same defaults to your Section H narrative or your SF-330 Part I project descriptions. A system prompt can enforce specific output conventions: word count limits tied to a page count, first-person plural voice consistent with your firm's style guide, or a rule that all project references must include an owner name and construction value before the model considers the output complete. For teams running multiple simultaneous pursuits on different delivery methods, including CMAR, design-build, and traditional design-bid-build, distinct system prompts per pursuit type prevent the model from blending procurement logic across delivery contexts.
System prompting is infrastructure, not a one-time configuration. A prompt written for a municipal water agency pursuit carries assumptions about QBS evaluation criteria, Brooks Act compliance framing, and technical narrative depth that will actively mislead the model if applied unchanged to a private-sector mixed-use developer RFP. Firms that treat system prompts as static templates replicate the same problem they have with boilerplate proposals: the frame is familiar but the fit is wrong. The more consequential misconception is that a strong system prompt substitutes for accurate source data; it does not. The prompt controls behavior, but the model's outputs are only as reliable as the context fed into it. Kantiv addresses this by pairing system prompting with verified pursuit context drawn from the firm's own project records, personnel history, and past proposals, so the behavioral rules operate on confirmed institutional knowledge rather than the model's training data.
Related terms
Tagging is the practice of attaching structured metadata labels to content assets so that retrieval systems, whether human-operated or AI-assisted, can surface content based on defined attributes rather than filename, folder path, or the memory of whoever created the file.
A single project narrative might be legitimately tagged as healthcare, renovation, occupied facility, OSHPD, design-build, and federal, and every one of those tags could be the primary search term depending on who is looking. The problem is not labeling the asset; it is anticipating the retrieval context before you know who will be searching. Firms that build tag taxonomies around their own org chart end up with structures that collapse the moment they cross market sectors or delivery methods. The most durable taxonomies are built around how proposals are actually structured: client type, project phase, delivery method, size range, and the SF-330 section the content supports.
The cost of a broken tagging system does not show up during content ingestion. It shows up at 9 PM the Wednesday before a fee proposal is due, when a coordinator cannot find the right project profile for a transit authority client because it was filed under "transportation" by one person and "infrastructure" by another. Inconsistent tagging is also the primary reason content library investments underperform: the assets exist, but retrieval depends on knowing how a specific colleague tagged something three years ago. For AI-assisted retrieval, the problem compounds. A vector database can surface semantically similar content even without exact tags, but it cannot distinguish between a project profile that was used successfully on a shortlisted pursuit and one that was pulled together in 45 minutes and never reviewed.
The firms that treat tagging as a one-time setup task end up re-tagging every two years when the taxonomy drifts from actual pursuit patterns. Effective tagging requires governance: a defined owner, a controlled vocabulary that is enforced at ingestion rather than corrected after the fact, and periodic audits tied to close-out workflows so new project data enters the system already labeled. A tag on a project profile should carry enough context to tell a proposal coordinator not just what the project is, but whether the content is compliant-ready, which SME owns updates, and when it was last verified. Kantiv enforces tag structure at the point of capture, so content enters with consistent attributes from the start rather than accumulating in folders waiting for a tagging sprint that never happens.
Related terms
A technical lead or director is the licensed professional or discipline expert who owns the technical approach on a pursuit, validates scope assumptions, and is typically named as a key person in the proposal submission itself, making them simultaneously a pursuit contributor and a deliverable.
When a technical lead appears in Section E of an SF-330 or as a named key person in a design-build RFP, the firm has made a staffing commitment that clients take seriously and that some contracts enforce through substitution clauses. Public owners in particular, especially at the federal level under FAR Part 36, may require written approval before a named key person can be replaced after award. This means the go/no-go conversation should include a direct confirmation that the named individual is available for the projected duration, not just the proposal sprint. A technical lead who is 90 percent allocated to an active project when their name goes into an SF-330 is a risk the proposal team is signing, not just a resume to fill a slot.
In practice, technical leads are responsible for the project approach narrative, scope clarifications, and any fee assumptions that flow into the fee proposal or GMP structure. They are the person who should be reading the RFP technical sections, not the proposal coordinator. On competitive shortlists of three to five firms, the interview panel almost always includes the technical lead, and evaluators frequently compare named staff across competing submissions before scoring. What the marketing team often does not see is that the technical lead's internal review comments on redlines reflect real scope judgments, not just editorial preference; when those comments disappear between draft rounds without resolution, the technical risk stays in the document.
Technical leads accumulate the project history, client relationship context, and scope lesson-learned knowledge that proposal teams need most at pursuit time, but that knowledge lives in their heads rather than in any system. When a technical lead has worked with a client on three previous projects, the proposal coordinator drafting the relevant experience section often has no direct access to what went well, what the client complained about, or what fee structure actually held. Seller-doers in this role are especially prone to this gap because they move between active projects and active pursuits without a clean handoff mechanism. Kantiv surfaces verified project history, prior proposal language tied to that client, and personnel context so the technical lead can confirm or correct at review rather than reconstruct from memory during a two-week proposal window.
Related terms
Tech stack consolidation is the process of reducing the number of software tools a marketing or BD team uses to manage pursuits, replacing overlapping or redundant applications with fewer, more integrated systems.
A typical mid-size firm's BD operation runs on an accidental architecture: a CRM that nobody fully adopted, a SharePoint folder structure that made sense in 2017, a proposal-specific InDesign workflow, and three different places where project experience might live. Each tool was added to solve a specific pain point, rarely with any view toward how it would interact with what came before. The result is that a proposal manager chasing a federal A-E contract has to pull SF-330 Section F project data from one system, resume content from another, and past fee history from a principal's inbox. Consolidation addresses this by mapping actual workflow against actual tooling and eliminating redundancy at the source.
Consolidation is not the same as replacement. A firm might keep its CRM for pipeline tracking while retiring a separate pursuit-tracking spreadsheet, or keep InDesign for final production while replacing a shared drive with a system that maintains version control on narrative content. The decision point is usually where institutional knowledge leaks: the gap between where information is created and where it needs to appear during a two-week proposal sprint. Firms that have gone through a serious consolidation effort typically reduce the number of tools a proposal manager touches during active pursuit from seven or eight down to three or four, which has a measurable effect on how much time goes to content assembly versus content quality.
The real cost of a fragmented stack is not the subscription fees; it is the knowledge that disappears between systems. When a BD director who managed a key client relationship leaves, the institutional memory of that relationship is usually scattered across a CRM, email threads, and a pursuit debrief that was never formally captured anywhere. Consolidation forces an organization to decide where the authoritative record lives, which is a precondition for actually using that record during future pursuits. Kantiv addresses this directly by functioning as the connective layer where project data, personnel expertise, and client history are captured once and surfaced in context during active pursuits, rather than requiring teams to reassemble that picture from scratch for every shortlist. The firms that treat consolidation as a strategic initiative rather than an IT project tend to see faster go/no-go decisions and stronger pursuit narratives because the team spends less time finding information and more time applying it.
Related terms
Templated guidance is pre-structured content embedded in a proposal framework that tells writers what to address, how much space to use, and what evidence to include, before a single word of new prose is drafted.
Most AEC marketing teams have templates: a branded SF-330 shell, a technical approach outline, a cover letter format. What they rarely have is the layer beneath those shells that tells a senior engineer what "describe your project approach" actually means for this client, this project type, and this procurement. Without that instruction layer, templates produce inconsistency at scale. A PM filling in Section E on Monday writes something structurally different from what a different PM writes on Friday, even starting from the same document. The guidance layer is what converts a blank form into a repeatable process.
Good templated guidance goes beyond word counts and section headers. It specifies which project types to pull from, which differentiators to lead with based on client priorities, which past performance narratives have scored well with similar owners, and what risks or sensitivities to address proactively. For a federal pursuit under FAR Part 36, that might mean flagging that the agency weights past performance at 40% and that two specific contract vehicles are relevant. For a shortlist presentation to a municipal client, it means telling the team to address the community impact question that came up in the RFQ. Context-specific instruction is what separates guidance from generic prompting.
Templated guidance only works as well as the knowledge behind it. If the guidance says "reference a relevant water treatment project in the Mid-Atlantic region" but no one has systematically captured which projects qualify, what outcomes they produced, or which PMs can speak to them, the instruction creates work instead of saving it. This is the gap most teams hit: the template exists, the guidance exists on paper, but the underlying institutional knowledge is scattered across old proposals, SharePoint folders, and the memory of whoever has been at the firm longest. Kantiv addresses this directly by connecting templated guidance to verified project data, personnel expertise, and prior proposal content, so the instruction and the evidence arrive together. Teams that close this loop stop re-researching their own firms on every pursuit and start building from a verified foundation instead.
Related terms
A tender is a formal submission by a contractor, consultant, or design firm in response to a public or private solicitation, used primarily in Commonwealth procurement systems where the term replaces the American "bid" or "proposal" depending on context.
In Australian, UK, and Canadian public procurement, "tender" covers the full spectrum from design-only consultant appointments to full design-build packages, where American usage would split those into an RFQ, RFP, or bid. The procedural requirements differ just as much as the labels: Australian state government tenders frequently require a Probity Auditor on larger contracts, and UK public sector tenders above certain thresholds trigger the Procurement Act 2023 (which replaced the EU-era Public Contracts Regulations 2015 after Brexit). Firms expanding internationally without understanding these distinctions often treat a tender response like a domestic RFP and miss mandatory pricing schedules, tender security bonds, or mandatory insurance certificates that must be submitted with the response, not after award. A non-compliant tender envelope is typically rejected without evaluation, regardless of the firm's qualifications.
Most international tender processes begin with an Expression of Interest (EOI) or Prequalification stage, which functions similarly to an RFQ under the Brooks Act model but carries different legal weight: shortlisted firms in a UK or Australian tender are often bound by confidentiality obligations from the moment they receive tender documents. The tender response itself typically includes a fee or price component even for professional services, which separates it structurally from Qualifications-Based Selection as mandated under the Brooks Act for US federal work. Teams juggling domestic pursuits alongside international tenders need to track submission requirements separately; a go/no-go scorecard built around FAR Part 36 assumptions won't account for tender bonds, parent company guarantees, or the specific formatting rules in a OJEU-style notice.
When a firm wins its first Australian infrastructure tender and then pursues a second three years later, the people who navigated the first submission rarely documented what made it compliant: which appendices were mandatory, how the fee schedule was structured, which subcontractor declarations were required. That institutional knowledge stays with whoever assembled the first response. Kantiv surfaces verified submission data from prior tenders so teams starting a new international pursuit can see exactly what a past compliant response included, instead of reconstructing it from memory or a folder of PDFs. The non-obvious risk in tender work isn't the unfamiliar terminology; it's treating each cross-border pursuit as if it were the first one, when the firm has already solved those problems before.
Related terms
Training data is the labeled or structured corpus of examples a machine learning model learns from during initial development; its composition determines which patterns the model can recognize, which biases it will reproduce, and what it will fabricate when queried about something outside its experience.
Most general-purpose large language models were trained on web-scale text: forums, articles, code repositories, and scraped documents with no particular depth in AEC. That training corpus shapes every output. A model trained without significant exposure to SF-330 structures, QBS evaluation criteria, or FAR Part 36 language will produce plausible-sounding text that is factually wrong about those things, because it is pattern-matching from adjacent domains rather than from actual federal procurement practice. The non-obvious implication: two models with identical architecture can perform radically differently on proposal tasks purely because of what each was trained on. Benchmark scores measured on general corpora tell you almost nothing about how a model will handle a scope narrative or a past performance summary.
The failure mode is rarely obvious. A model with weak AEC training will not blank out; it will confidently populate a project approach section with language that sounds precise but misrepresents delivery methods, misnames standard contract forms, or cites evaluation criteria that do not exist in the actual solicitation. During a two-week RFP window, no one has time to fact-check every sentence the model generates, which is exactly when errors survive into final submittals. Go/no-go decisions that rely on AI-summarized opportunity data carry the same risk: if the model has no grounded training in how owners structure selection criteria for CMAR versus design-bid-build, its summary of a pre-RFP opportunity will reflect a generic construction world that may not match the actual client.
Model fine-tuning can adjust tone and improve task-specific formatting, but it does not rewrite foundational knowledge; a model fine-tuned on your past proposals still carries the gaps from its original training corpus. Retrieval-augmented generation addresses this more directly by grounding outputs in documents you provide at inference time, but it depends entirely on the quality and structure of your content library. The practical floor for any AI tool used in proposals is that someone with domain expertise must review outputs against verified source material before anything goes out the door; human-in-the-loop review is not optional. Kantiv is designed around this constraint: it surfaces verified content from your firm's own pursuit history as the retrieval layer, so the model is working from your actual project data rather than interpolating from a general corpus that has no knowledge of your clients, your wins, or your staff.
Related terms
Unstructured data is information that lacks a predefined schema or fixed format: project narratives, interview transcripts, meeting notes, past proposal PDFs, client feedback emails, and the thousands of other documents that hold most of what an AEC firm actually knows.
A typical mid-size AEC firm generates structured data in its CRM and project accounting system, but those fields capture maybe 15 percent of institutional knowledge. The rest lives in Word documents, marked-up PDFs, Outlook threads, and shared drives with folder structures that made sense in 2011. SF-330 submissions alone contain dense, firm-specific content across Sections E, F, and G that is never extracted or reused systematically. Every pursuit team that rebuilds a project description from scratch is losing time to a retrieval problem, not a writing problem.
The cost shows up at the worst moments: a shortlist interview coming in ten days, a teaming partner asking for relevant project cuts, a client reference who needs context before a call. When past performance data lives in unstructured documents scattered across drives, finding the right project narrative for a specific building type, delivery method, or client agency requires someone who either has institutional memory or has time to dig. Most pursuit teams have neither. The two-week proposal timeline that governs most public procurements does not accommodate manual archaeology.
The practical goal is not to eliminate unstructured data; that is not realistic and not desirable. Detailed narratives, nuanced client feedback, and project lessons learned should stay in prose form because that context does not compress cleanly into a database field. The goal is retrieval: being able to surface the right content at the right stage of a pursuit without knowing in advance exactly where it was stored or who wrote it. Kantiv indexes unstructured content from proposals, project files, and personnel records so that institutional knowledge becomes searchable context during an active pursuit, not a background research task. Firms that treat past proposal content as a structured asset rather than an archive stop rebuilding from zero and start from a verified starting point.
Related terms