Find Incumbent for a Federal Contract Opportunity
# Find Incumbent for a Federal Contract Opportunity
## User Input
- **Target opportunity:** [Solicitation number, GovTribe link, or opportunity title plus agency]
## Goal
Use GovTribe MCP tools to determine the confirmed incumbent for a specific federal contract opportunity when the opportunity thread exposes direct evidence and, if it does not, recover the most defensible current child order or award before resorting to broader predecessor evidence and tightly constrained fallback evidence.
## Required Input
The user must provide a specific target opportunity before analysis begins.
Accept any of the following:
- Solicitation number
- GovTribe link
- Opportunity title plus agency
- Plain-language description only if it is specific enough to resolve a single opportunity
Input rules:
- If the input resolves cleanly to one opportunity, proceed immediately.
- If the input is too vague to resolve a single opportunity, ask for the minimum missing detail needed to proceed.
- If no direct incumbent can be confirmed, continue to current child-order recovery, then broader predecessor recovery, and only then to the likely-incumbent fallback.
- Include vehicle, IDV, or opportunity-thread context only when it materially clarifies the incumbent determination.
- Do not guess the target.
- Do not start substantive analysis until the target is resolved.
## Workflow
### Steps
1. Call `Documentation` once with `article_names=["Search_Query_Guide", "Search_Mode_Guide", "Aggregation_and_Leaderboard_Guide", "Date_Filtering_Guide"]`.
- Use the documentation results to confirm valid tool names, `search_mode`, `query`, `fields_to_return`, relationship fields, `similar_filter` behavior, aggregation options, and sort keys before searching.
2. Resolve the target opportunity exactly with `Search_Federal_Contract_Opportunities`.
- Favor exact lookup first.
- For exact solicitation numbers, quoted titles, or exact GovTribe-derived identifiers, use a double quoted `"query"`.
- If the user provides a GovTribe link, use the record identity embedded in the link when possible; otherwise resolve it through exact quoted lookup.
- If the user provides an opportunity title plus agency, use the strongest exact title phrase plus agency context, then disambiguate with returned fields.
- Use `fields_to_return` explicitly.
- At minimum request:
- `govtribe_id`, `govtribe_url`, `govtribe_type`, `solicitation_number`, `name`, `opportunity_type`, `posted_date`, `due_date`, `set_aside_type`, `descriptions`, `govtribe_ai_summary`, `federal_meta_opportunity_id`, `federal_contract_vehicle`, `federal_agency`, `place_of_performance`, `naics_category`, `psc_category`, `federal_contract_awards`, `federal_contract_idvs`, `points_of_contact`
3. If multiple opportunities match, disambiguate with the minimum additional evidence needed.
- Compare agency, opportunity type, posted date, due date, set-aside, NAICS, PSC, and vehicle context.
- Do not merge multiple possible matches into one narrative.
- If the record still cannot be resolved to a single opportunity, stop and ask for one clarifying detail.
4. Run Tier 1 direct incumbent discovery before any fallback search.
- Use direct dataset linkage first.
- If the resolved opportunity has `federal_meta_opportunity_id`, query `Search_Federal_Contract_Awards` with `federal_meta_opportunity_ids`.
- If the resolved opportunity already exposes direct linked-award relationships, use those linked awards as the primary thread evidence.
- For direct-link searches, request explicit row fields needed to interpret incumbent ownership and thread context:
- `govtribe_id`, `govtribe_url`, `name`, `contract_number`, `award_date`, `completion_date`, `ultimate_completion_date`, `contract_type`, `descriptions`, `govtribe_ai_summary`, `dollars_obligated`, `ceiling_value`, `set_aside_type`, `awardee`, `parent_of_awardee`, `federal_contract_idv`, `federal_contract_vehicle`, `contracting_federal_agency`, `funding_federal_agency`, `naics_category`, `psc_category`, `place_of_performance`, `originating_federal_contract_opportunity`
- Use the label `Confirmed Incumbent` only when the evidence supports current or thread-direct incumbent ownership and the linked award or order is current or recent exact-scope work.
- If direct linked evidence is exact-scope but clearly older historical work rather than the current or most recent order, treat it as supporting predecessor evidence rather than `Confirmed Incumbent`.
- If multiple directly linked award rows are returned and performer concentration matters, add a narrow aggregation-only verification pass:
- Use `Search_Federal_Contract_Awards`
- Use `per_page: 0`
- Reuse the same `federal_meta_opportunity_ids` or other direct-link award filters
- Use `aggregations` such as `dollars_obligated_stats`, `top_awardees_by_dollars_obligated`, and `top_contracting_federal_agencies_by_dollars_obligated`
- Use that aggregation branch only to distinguish a single dominant direct performer from a more distributed direct-history thread.
- If the opportunity clearly references a linked vehicle or IDV and the direct award thread is still ambiguous, run one targeted parent lookup only when it materially clarifies the incumbent thread.
- IDV path with `Search_Federal_Contract_IDVs`:
- Use the linked IDV when available, or an exact quoted contract number if that is all you have.
- Request `govtribe_id`, `govtribe_url`, `name`, `contract_number`, `award_date`, `last_date_to_order`, `contract_type`, `description`, `govtribe_ai_summary`, `ceiling_value`, `set_aside`, `multiple_or_single_award`, `awardee`, `parent_of_awardee`, `federal_contract_vehicle`, `contracting_federal_agency`, `funding_federal_agency`, `naics_category`, `psc_category`, `place_of_performance`, `task_orders`, `blanket_purchase_agreements`, and `originating_federal_contract_opportunity`
- Vehicle path with `Search_Federal_Contract_Vehicles`:
- Use the linked vehicle when available, or an exact quoted vehicle name if needed.
- Request `govtribe_id`, `govtribe_url`, `name`, `award_date`, `last_date_to_order`, `contract_type`, `descriptions`, `govtribe_ai_summary`, `set_aside_type`, `shared_ceiling`, `originating_federal_contract_opportunity`, `federal_agency`, and `federal_contract_awards`
- If a parent lookup exposes candidate `task_orders` or `blanket_purchase_agreements`, treat them as mandatory leads for the next current child-order recovery step rather than as order-level proof by themselves.
- Do not use parent-instrument context alone to overstate incumbency when task-order ownership remains unclear or multiple awardees remain plausible.
5. Run Tier 2 current child-order incumbent recovery immediately after Tier 1 if no direct linked award confirms the incumbent.
- Use `Search_Federal_Contract_Awards` as the primary recovery surface.
- Treat missing `federal_meta_opportunity_id` linkage or other direct-thread linkage as a Tier 1 miss only, not as negative evidence against Tier 2 or Tier 3.
- Derive exact quoted office, program, site, platform, system, acronym, and scope phrases from the resolved opportunity's `descriptions` and `govtribe_ai_summary`.
- Generate normalized quoted variants for office, program, site, and platform names, including acronyms, punctuation variants, apostrophe variants, and shortened office phrasing.
- Prioritize exact quoted platform or system names and office acronyms as the first recovery terms.
- Treat quoted platform or system names and office acronyms as higher-signal than NAICS, PSC, or agency-level filters when distinguishing one office's work from another inside the same contracting agency.
- Run this tier in order:
1. Exact quoted platform or system name, office acronym, and office, program, or site terms without broadening.
2. The same quoted terms with the strongest available same contracting-agency context and, when present, same NAICS, PSC, vehicle, IDV, set-aside, or place filters.
3. One narrow semantic retry using those same office or platform terms only if the keyword sweep remains too broad or too thin.
- Do not move to Tier 3 until this office-first keyword pass and the single narrow semantic retry are exhausted.
- If a same-agency, same-office, same-functional-scope award appears inside the recent performance window, review it even when the branded site or platform name is absent from the initial row text.
- Always request the fields needed to judge current order status and lineage:
- `govtribe_id`, `govtribe_url`, `name`, `contract_number`, `award_date`, `completion_date`, `ultimate_completion_date`, `contract_type`, `descriptions`, `govtribe_ai_summary`, `dollars_obligated`, `ceiling_value`, `set_aside_type`, `awardee`, `parent_of_awardee`, `federal_contract_idv`, `federal_contract_vehicle`, `contracting_federal_agency`, `funding_federal_agency`, `naics_category`, `psc_category`, `place_of_performance`, `originating_federal_contract_opportunity`
- Mine `govtribe_ai_summary` and `descriptions` for exact identifiers such as contract numbers, IDV numbers, task-order numbers, child-award references, and other exact lineage hints.
- If any exact identifier is surfaced, rerun an exact quoted lookup on that identifier immediately and treat the resulting record as stronger evidence than semantic similarity.
- Use `sort` with `awardDate` descending for this sweep, then compare `ultimate_completion_date` across the returned cohort.
- Prefer the most recent exact-scope child order or award whose completion or ultimate completion timeline is nearest to the new opportunity timeline.
- When the evidence suggests the incumbent likely sits under an IDV or parent instrument, bias toward order-like awards using documented award-type filters or ranking rather than hard-coded industry phrase banks.
- If a candidate award references a `federal_contract_idv`, or if the row text, AI summary, or surfaced identifier reveals parent/child contract lineage, lineage expansion is mandatory before exclusion.
- Resolve the referenced IDV, parent instrument, or exact identifier immediately.
- If a candidate award references a `federal_contract_idv`, resolve that IDV and inspect its `task_orders` before finalizing incumbent status.
- If child orders exist, resolve them with `Search_Federal_Contract_Awards`.
- Use the child order or child award as the incumbent record and the IDV only as lineage.
- If the same vendor holds multiple overlapping or sequential exact-scope child orders or awards, treat them as reinforcing evidence of one incumbent chain rather than as competing candidates.
- Use the most current or recent exact-scope child order or award as the incumbent record.
- Treat the related overlapping or sequential order as continuation or bridge evidence that strengthens the same incumbent conclusion.
- Do not weaken same-office, exact-scope, recent or current child-order evidence merely because the new opportunity does not yet name a vehicle.
- Do not weaken same-office, same-scope, current or recent child-order evidence merely because a continuation or bridge order sits on a different vehicle.
- Use the label `Confirmed Incumbent` for a current or recent exact-scope child order or award.
- Use the label `Likely Incumbent` only when the current-period match is strong but not exact.
6. Run Tier 3 predecessor award or order recovery only if Tier 1 and Tier 2 do not confirm an incumbent.
- Extract exact office names, acronyms, branded website names, internal platform names, and 1-3 high-signal scope phrases from `descriptions` and `govtribe_ai_summary`.
- Preserve acronyms and branded names exactly as retrieved, and search multiple quoted variants when the record supplies them, including punctuation variants, apostrophe variants, and shortened office phrasing.
- Run exact quoted keyword searches before any `similar_filter` or semantic fallback.
- If a same-agency, same-office, same-functional-scope award or parent candidate is surfaced inside the recent performance window, review it even when the branded site or platform name is absent from the initial row text.
- Use `Search_Federal_Contract_Awards` as the primary predecessor-recovery surface.
- Use quoted office, site, program, and scope phrases plus the strongest available same-agency, same vehicle or IDV, set-aside, place, and recent-window filters.
- Request the same award fields used in Tier 1 so the recovered rows can be compared directly.
- Mine `govtribe_ai_summary` and `descriptions` for exact identifiers such as contract numbers, IDV numbers, task-order numbers, child-award references, and other exact lineage hints.
- If any exact identifier is surfaced, rerun an exact quoted lookup on that identifier immediately and treat the resulting record as stronger evidence than semantic similarity.
- Use `Search_Federal_Contract_IDVs` when the opportunity language, direct evidence, or recovered awards suggest a parent instrument.
- Use exact quoted office, site, program, and scope phrases or an exact quoted contract number when one is available.
- Request `govtribe_id`, `govtribe_url`, `name`, `contract_number`, `award_date`, `last_date_to_order`, `contract_type`, `description`, `govtribe_ai_summary`, `ceiling_value`, `set_aside`, `multiple_or_single_award`, `awardee`, `parent_of_awardee`, `federal_contract_vehicle`, `contracting_federal_agency`, `funding_federal_agency`, `naics_category`, `psc_category`, `place_of_performance`, `task_orders`, `blanket_purchase_agreements`, and `originating_federal_contract_opportunity`
- Prioritize exact same office, program, or site-name matches over same NAICS, PSC, vehicle, or generic same-agency similarity.
- Treat same sub-agency, same office, and same website matches as a first-class recovery path even when NAICS or PSC differ.
- If a candidate IDV, parent award, or surfaced lineage reference is found, expanding that lineage is mandatory before concluding incumbent status.
- If a candidate IDV is found, inspecting its `task_orders` and `blanket_purchase_agreements` is mandatory before concluding incumbent status.
- If `task_orders` exposes candidate child award IDs or names, resolve them with `Search_Federal_Contract_Awards`.
- Prefer the child order or child award over the parent IDV as the incumbent evidence record.
- Treat older exact-scope predecessor child orders or awards as supporting predecessor evidence unless they remain current or recent enough to satisfy Tier 2.
- Use the label `Likely Incumbent` only for weaker predecessor matches that are strong but not exact.
- Do not label a parent IDV alone as the incumbent contract. When both a child order or award and a parent IDV or vehicle are found, report the child as the evidence record and the parent only as `Supporting Lineage`.
7. Normalize vendor identity only when it materially affects interpretation.
- If incumbent identity, parent-child structure, or legal-entity naming matters, use `Search_Vendors`.
- Prefer `vendor_ids` from relationships when available.
- Otherwise use an exact quoted company name.
- Request:
- `govtribe_id`, `govtribe_url`, `name`, `uei`, `dba`, `parent_or_child`, `parent`, `business_types`, `sba_certifications`, `govtribe_ai_summary`
- Use vendor normalization to clarify entity ownership, not to replace direct-link or predecessor evidence.
8. Run Tier 4 constrained likely-incumbent fallback only if Tier 1, Tier 2, and Tier 3 do not confirm an incumbent.
- Use the resolved opportunity as the seed.
- Use `similar_filter` on the resolved opportunity only when direct linkage, current child-order recovery, and predecessor recovery are exhausted.
- Keep strict structural filters in place when available:
- Same agency
- Same NAICS or PSC
- Same vehicle or IDV when available
- Same set-aside context
- A recent award window, defaulting to the last 5 years when no tighter thread timing is available
- If office, site, or program terms survive into this tier, let exact quoted office, site, or program matches outrank generic same-agency digital-services similarity.
- Use `Search_Federal_Contract_Awards` as the primary fallback surface.
- Use `_score` sorting only for this fallback tier unless a date sort materially sharpens the answer.
- Use `search_mode: "semantic"` only inside this fallback tier when the exact and filter-first fallback pass is still too thin.
- Use the label `Likely Incumbent` only for strong constrained matches.
- Do not widen into open-ended likely-bidders or general prior-performer logic.
9. Exclude weak or misleading evidence explicitly.
- Exclude awards that are only keyword-adjacent.
- Exclude same-agency work with the wrong scope.
- Exclude same sub-agency work that does not reference the same office, site, or program.
- Exclude same-vehicle work with the wrong capability lane.
- Exclude parent-only IDVs when no child order or award tied to the requirement is identified.
- Exclude entity-mismatched vendor results.
- Exclude predecessor or fallback matches that are too thin to support an incumbent claim.
10. Perform a verification pass before final ranking.
- Remove weak fallback matches, weak predecessor matches, weak current child-order matches, or weak direct-link rows that distort the thread.
- Re-check whether the top conclusion still holds.
- Collapse same-vendor overlapping or sequential exact-scope child orders into one incumbent conclusion rather than listing them as separate competing candidates.
- Before returning `No Defensible Incumbent`, perform one mandatory lineage-expansion pass over every plausible Tier 2 or Tier 3 IDV, parent-award, same-office same-functional-scope, or surfaced-identifier candidate.
- Do not return `No Defensible Incumbent` until each plausible Tier 2 or Tier 3 lineage candidate has been either expanded or explicitly rejected with a reason.
- If a direct-link aggregation pass was used, confirm the final evidence label still matches the direct cohort shape after weak rows are removed.
- If the answer depends on Tier 2 current child-order recovery rather than direct thread linkage, say so explicitly and explain why the current or recent child-order evidence supports the label.
- If the answer depends on older predecessor recovery rather than direct thread linkage or Tier 2, say so explicitly and present that evidence as supporting predecessor evidence unless it still qualifies as current or recent.
- If the answer depends only on Tier 4 fallback evidence, lower confidence explicitly.
- If only a parent IDV or vehicle could be tied to the work, say that order-level incumbency remains unconfirmed and present the parent only as `Supporting Lineage`.
- If no defensible direct, predecessor, or fallback incumbent remains, return `No Defensible Incumbent`.
- If the question becomes primarily about the underlying notice or the awarded contract rather than incumbency, recommend `Federal Contract Opportunity Deep Dive` or `Federal Contract Award Deep Dive` instead of overloading this workflow.
## Output Format
Return in this order:
1. **Resolved Target Summary**
- Briefly explain how the opportunity was resolved
2. **Direct Incumbent Evidence**
- Present this section as a compact markdown table first
- Recommended columns: `Performer`, `Evidence Label`, `Direct Record`, `Why`
- Use `Confirmed Incumbent` only when the evidence is direct, thread-grounded, and current or recent exact-scope work
- If no direct thread-grounded incumbent was confirmed, say so briefly
3. **Current Child-Order Recovery**
- Include this section only if Tier 2 was needed
- Present current child-order recovery results as a compact markdown table first
- Recommended columns: `Performer`, `Evidence Label`, `Current Order / Award`, `Supporting Lineage`, `Why`
- Use `Confirmed Incumbent` only for current or recent exact-scope child orders or awards
- Use `Likely Incumbent` only for strong current-period matches that remain slightly indirect
- If the same vendor holds overlapping or sequential exact-scope orders, use the lead current or recent order as the main record and describe the related order or orders in `Why` as reinforcing continuation or bridge evidence
- Use `Why` to state when a surfaced identifier or expanded child-order chain materially drove the conclusion
- If no defensible current child-order evidence remains, say so briefly
4. **Recovered Predecessor Evidence**
- Include this section only if Tier 3 was needed
- Present recovered predecessor results as a compact markdown table first
- Recommended columns: `Performer`, `Evidence Label`, `Recovered Record`, `Supporting Lineage`, `Why`
- Use `Supporting Predecessor Evidence` for older exact-scope same-office, same-program, or same-site work that helps explain lineage but is not current enough to be `Confirmed Incumbent`
- Keep older exact-scope same-vendor orders here unless they are current or recent enough to belong in Tier 2
- Use `Likely Incumbent` only for weaker predecessor matches that remain strong but not exact
- Use `Why` to state when a surfaced identifier or expanded child-order chain materially drove the conclusion
- If no defensible predecessor evidence remains, say so briefly
5. **Supporting Lineage**
- Use this section for parent IDVs, vehicles, and thread lineage that materially support the incumbent determination
- Use the label `Supporting Lineage` for parent IDVs or vehicles
- Never center this section as the incumbent record when a child order or award exists
- Do not place bridge, continuation, or other child-order evidence in this section
- If only parent lineage was confirmed, say that order-level incumbency remains unconfirmed
6. **Likely Incumbent Fallback**
- Include fallback results only if Tier 1, Tier 2, and Tier 3 did not confirm an incumbent
- Present fallback results as a compact markdown table first
- Recommended columns: `Performer`, `Evidence Label`, `Closest Record`, `Why`
- Use `Likely Incumbent` only for strong constrained fallback matches
- If no defensible fallback remains, say `No Defensible Incumbent`
7. **Why Others Were Excluded**
- Briefly note weak, mismatched, or insufficiently supported candidates that were rejected
8. **Risks, Gaps, or Unknowns**
- Briefly note missing linkage, ambiguity, sparse history, or other data limits
9. **Overall Confidence**
- State overall confidence and why
## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to the specific claims they support, not only at the end.
## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the goal cannot be fully completed from the available evidence.
- If a statement is an inference rather than a directly supported fact, label it as an inference.Last updated
Was this helpful?