A paralegal opens a claim file for a civil engineer who spent eighteen months at a bare-base airfield in Southwest Asia. The contract paperwork says "Air Force Contract Augmentation Program." She types the prime contractor's name into a carrier lookup and gets a hit. Then she checks the dates and realizes the injury happened under a task order awarded years after the coverage she just found. The carrier on file is wrong for that period, and the claim deadline is two weeks out.
This is the trap that AFCAP sets. The AFCAP Air Force contract augmentation program DBA insurance carrier question almost never has a single, stable answer. AFCAP is a task-order vehicle, and the Defense Base Act carrier rides on the individual task order, not the umbrella contract everyone names in conversation. Miss that distinction and you chase the wrong insurer.
AFCAP is the Air Force's logistics and base-operations answer to the Army's LOGCAP. The two programs look similar from the outside. Both surge civilian contractors into austere overseas locations. Both run on indefinite-delivery structures. But their carrier trails diverge in ways that matter when you are trying to name the right respondent on a DBA claim. The contracting agency is different, the contractor roster is different, and the way coverage attaches to each task order follows its own logic.
This article explains what AFCAP is, how it differs from LOGCAP, and why its task-order structure controls carrier identification. The AFCAP Air Force contract augmentation program DBA insurance carrier question is really a series of dated, task-order questions stacked on top of each other. We will not hand you a lookup table matching a specific AFCAP task order to a specific insurer. That work requires cross-referencing federal award records against coverage filings, and it changes by award. What we will do is show you why the answer is harder than it looks, and where the real evidence lives.
What is AFCAP and how does it differ from LOGCAP?
AFCAP stands for Air Force Contract Augmentation Program. It is the Air Force's vehicle for surging contracted support into contingency locations: base operations, civil engineering, force-beddown, airfield services, and logistics at expeditionary sites. When the Air Force needs a bare patch of desert turned into a working airbase, AFCAP is how the contractor labor gets there.
LOGCAP, the Logistics Civil Augmentation Program, does the parallel job for the Army. The headline difference is the contracting agency. AFCAP is run through Air Force contracting channels; LOGCAP is run through the Army. That single fact reshapes the whole investigation, because the agency that awards a contract drives where the records sit and which mandatory insurance rules, if any, apply.
The structural similarity is real. Both programs use indefinite-delivery, indefinite-quantity (IDIQ) frameworks. Under an IDIQ, a small number of prime contractors hold the master contract, and actual work flows through discrete task orders issued as needs arise. We have written about why the IDIQ structure complicates DBA work in our breakdown of which task order controls the carrier on an IDIQ vehicle. AFCAP and LOGCAP share that DNA, so they share the same core problem: the master contract name tells you almost nothing about coverage.
Here is where they part ways for a carrier investigator:
- Contractor roster. AFCAP and LOGCAP have drawn from different pools of prime contractors over their histories. A name that anchors one program may never appear in the other.
- Record trail. Air Force awards and Army awards surface under different funding agencies in federal spending data, which changes how you filter.
- Mission profile. AFCAP leans heavily on airfield and civil-engineering work. LOGCAP leans toward broad base life-support and logistics. Different work means different subcontractor layers, and subcontractors carry their own coverage.
If you have already mapped a contractor through LOGCAP, do not assume the same carrier carries over to AFCAP work. The carrier coverage gaps we documented in our analysis of LOGCAP contract transitions are program-specific. AFCAP has its own gaps, on its own timeline.
Why does the AFCAP task order control DBA carrier identification?
The instinct on any contingency claim is to name the prime contractor, look up the prime's DBA carrier, and move on. On a task-order vehicle like AFCAP, that instinct produces wrong answers more often than right ones.
The master AFCAP contract is an umbrella. It authorizes work but does not, by itself, fix a single insurer for the life of the program. Each task order is a separate award with its own period of performance, its own funding, and frequently its own insurance arrangement. A prime can hold DBA coverage through one carrier for early task orders and a different carrier for later ones. The coverage attaches at the task-order layer.
That means the controlling variables for an AFCAP claim are the specific task order number and the date of injury. Get those two facts pinned, and the carrier question becomes answerable. Skip them, and you are guessing. The Department of Defense's sheer volume of overseas awards is part of why this is so hard. A single program can generate hundreds of task orders across a decade, each with its own coverage history.
Three things make AFCAP task-order tracing especially unforgiving:
- Temporal shifts. DBA carriers do not stay fixed. ClaimTrove's source records indicate coverage for most contingency contractors moves every three to five years. An AFCAP task order from one period and an AFCAP task order from another can sit under entirely different insurers.
- Subcontractor depth. AFCAP airfield and engineering work fans out to subcontractors who hold their own DBA policies. The injured worker may have been employed by a sub two layers below the named prime.
- Third-party administrator confusion. The entity sending letters and handling the file is often a TPA, not the actual carrier. On AFCAP files, this mix-up is common because large logistics programs lean on TPAs to manage claim volume. The name on the correspondence rarely settles who actually wrote the policy.
Where does the AFCAP carrier evidence actually live?
There is no single registry that maps an AFCAP task order to its DBA carrier. The answer has to be assembled from separate federal record systems that were never designed to talk to each other. Knowing which source answers which question is half the battle.
Federal spending data is the starting point. It tells you who held the prime award, under which task order, during which period of performance, and which Air Force office funded it. ClaimTrove holds 43,298 prime contract awards and 4,315 subcontract awards drawn from this source. Learning to read these records is a core skill. Our walkthrough on reading USAspending data for DBA investigations shows how to isolate the task order that matters. The goal is to stop at the right task order, not the umbrella contract.
Spending data names the contractor and the task order, but it does not name the insurer. For that, you need coverage filings. Insurance evidence comes from FOIA-obtained DOL records that record which carrier held DBA coverage for a given employer during a given window. ClaimTrove holds 154,886 such coverage filings. These are the documents that tie a contractor to an actual policy, and they are dated, which is what lets you match coverage to the AFCAP task order period.
Decisions from the Office of Administrative Law Judges add a third layer. ClaimTrove indexes 5,022 OALJ decisions. When a carrier dispute reaches litigation, the decision often names the carrier, the employer, and the contract context on the record. For contingency programs like AFCAP, these decisions are a useful cross-check against the coverage filings.
The practical workflow looks like this:
- Confirm the prime and the exact task order in federal award data.
- Fix the period of performance and the injury date.
- Resolve the employer's true legal name, accounting for aliases and subsidiaries.
- Match that employer and date window against dated coverage filings.
- Cross-check the carrier name against any relevant OALJ decision.
Each step has its own failure mode. The alias problem alone derails plenty of investigations, because a contractor may appear under several legal names across its AFCAP history. Resolving the AFCAP Air Force contract augmentation program DBA insurance carrier therefore starts with getting the employer's true legal identity right.
What makes AFCAP carrier identification harder than a standard DBA claim?
A standard DBA claim under a single fixed-price contract is comparatively clean. One employer, one contract, one period, usually one carrier. AFCAP breaks almost every one of those assumptions.
First, the program spans many years and many task orders. Coverage that was accurate for an early beddown task order tells you nothing about a later sustainment task order. The temporal pattern is not noise; it is the rule. We documented the mechanics of insurer turnover in our analysis of why DBA carriers change over time, and AFCAP is a textbook case.
Second, the work is layered. Airfield construction, civil engineering, and base operations pull in tiers of subcontractors. The named prime on the award may not be the injured worker's employer. Tracing through those tiers, and finding the sub's own carrier, is its own investigation.
Third, the Air Force funding channel means AFCAP awards do not always sit where investigators expect them in spending data. If you filter for the wrong funding agency, the task order you need never surfaces, and you conclude the record does not exist when it does.
Fourth, mandatory-insurance assumptions do not transfer. Some agencies require contractors to buy DBA coverage through a single designated carrier; others leave it to the open market. You cannot assume AFCAP behaves like a State Department or USAID program, where the government may designate a single carrier. AFCAP coverage is not a free pass to that shortcut. You still have to prove which insurer actually held the task order.
Put together, these factors mean an AFCAP carrier answer is a constructed result, not a lookup. You are reconciling award data, coverage filings, alias resolution, and sometimes litigation records into a single dated conclusion. Do any one of those steps loosely and the answer collapses.
This is precisely the kind of multi-source reconciliation ClaimTrove was built to run. Instead of toggling between federal spending portals, FOIA document sets, and decision databases by hand, you enter the contractor and the period. The investigation engine then traces the AFCAP task-order coverage across all of those records at once. Run your AFCAP task-order coverage trace in ClaimTrove and get a dated, source-backed carrier answer instead of an umbrella-contract guess.
How should a DBA investigator approach an AFCAP claim step by step?
Treat AFCAP like the task-order vehicle it is, not like a single contract. The sequence below keeps you from naming the wrong carrier.
Start with the injury date. Everything keys off it. A carrier that is correct for the program in general can be wrong for the date in front of you. Write the date down and keep it visible through every later step.
Next, identify the actual employer, not just the program name. The worker may have been employed by a subcontractor several layers below the headline prime. Resolve that employer's legal name and any aliases before you touch coverage records. Getting the entity right is non-negotiable, and it is why employer verification through federal entity records matters; the same alias discipline applies across all task-order programs.
Then pin the task order. Use federal award data to find which AFCAP task order covered the period of performance that includes your injury date. The task order, the prime, the period, and the funding office should all line up before you go looking for an insurer.
Only now do you go to coverage records. Match the resolved employer against dated coverage filings for the window that contains your injury date. If the dates do not overlap cleanly, you have the wrong filing, not the right carrier. The same rebid dynamics that shift coverage on other vehicles apply here. Our note on what happens to DBA coverage when contracts get rebid explains why a recompete can reset the carrier mid-program.
Finally, cross-check. If a carrier name shows up in your coverage filing, confirm it against any OALJ decision touching that employer and period. Confirm that the entity contacting your client is the carrier and not a TPA. Two independent sources agreeing on the same insurer for the same date window is the standard you want before you name a respondent.
Done by hand, this is hours of cross-referencing per claim, and every gap is a chance to name the wrong insurer and blow a deadline. Done in ClaimTrove, it is a single query against the same underlying records, returned with the source documents attached so you can verify before you file.