# Why AI Programs Reach the T&M Ceiling > Source: https://ibl.ai/resources/guides/t-and-m-ceiling-price-ai-program-overruns > Last updated: 2026-08-19 *A ceiling caps exposure without creating an incentive to stay under it — and only one of the three reasons programs breach it is fixed by raising the number* Reading time: 11 min read | Difficulty: advanced **On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.** ## How do you why AI Programs Reach the T&M Ceiling? Every time-and-materials contract carries a ceiling price. It is the government's protection against the structural weakness FAR names explicitly: a T&M contract provides no positive profit incentive to the contractor for cost control or labor efficiency. The ceiling caps how much can be spent. It does nothing about the reason spending grows, which is why programs reach it and then negotiate an increase rather than finishing under it. The useful analysis is not whether a ceiling was set correctly. It is which of three distinct failures put the program against it, because they demand different responses and only one is solved by a larger number. In our reading of how AI programs actually breach: the estimate was built on a scope that did not yet exist; the undifferentiated platform work consumed the budget before differentiated work started; or the definition of done was never testable, so nothing could be accepted and closed. Raising the ceiling addresses the first. It makes the second and third worse. ## Prerequisites - **Cumulative invoiced value against ceiling, by month:** Burn rate matters more than absolute spend. A program at 60% of ceiling with 30% of scope delivered is already in trouble. - **Technical progress measured independently of hours:** If the only progress signal is hours burned, you cannot distinguish work from motion. - **The original independent government estimate:** If the ceiling was set to available budget rather than to an estimate of the work, the breach was scheduled at award. - **A testable definition of done:** For AI, an evaluation set with a passing threshold drawn from your own data. Without one, acceptance is a negotiation. ## Step 1: Diagnose which of the three failures you have These look identical on a burn chart and require completely different responses. Diagnosing correctly is the only step that matters, because the wrong remedy accelerates the problem. - [ ] Scope that did not exist at estimate time — The requirement changed or was discovered. A ceiling increase is the legitimate remedy here. - [ ] Undifferentiated platform work consuming the budget — Retrieval, evaluation, guardrails, access control, audit — built from scratch on your funding. More ceiling buys more of the same. - [ ] No testable definition of done — Nothing can be accepted, so nothing closes. More ceiling extends an engagement that cannot end. ## Step 2: Measure how much spend went to undifferentiated work Categorise delivered effort into platform infrastructure versus work specific to your organization. This single ratio explains most AI ceiling breaches and is almost never computed. - [ ] Effort spent on retrieval, evaluation, guardrails, RBAC, audit and model routing - [ ] Effort spent on your data model, workflows and integrations - [ ] Compute the ratio and compare it to what the contract implied you were buying **Tips:** - Any capability a competitor in your sector would need identically is undifferentiated. That test is quick and rarely disputed. ## Step 3: Decide between re-baselining and changing the starting point A ceiling increase re-runs the same structure with a larger number. That is correct only where the scope genuinely changed. Where the platform is being constructed, the alternative is to stop constructing it. - [ ] If scope changed: re-baseline with a revised estimate and a defensible D&F - [ ] If platform construction is consuming the budget: license a platform that exists and re-scope to integration - [ ] If done was never testable: define the evaluation set before any additional funds are obligated ## Step 4: Install the controls the next phase needs Whatever the remedy, the conditions that produced the breach persist unless they are changed deliberately. - [ ] Report technical progress against the evaluation set, not hours - [ ] Gate each phase on acceptance rather than on elapsed time - [ ] Set the trigger point for ceiling conversations well before the ceiling - [ ] Make knowledge transfer a deliverable with its own acceptance test ## Common Mistakes ### Treating every breach as a scope change **Consequence:** A larger ceiling funds more of whatever caused the breach, most often platform construction. **Prevention:** Compute the undifferentiated effort ratio before accepting a scope-change diagnosis. ### Setting the ceiling to available budget **Consequence:** The ceiling stops being an estimate and becomes a spending target that will be reached. **Prevention:** Derive the ceiling from an independent estimate of the effort required. ### Measuring progress in hours **Consequence:** Motion is indistinguishable from progress until the ceiling arrives. **Prevention:** Report against a held-out evaluation set with a passing threshold. ### Raising the ceiling without changing acceptance criteria **Consequence:** An engagement that could not close before still cannot close, at a higher number. **Prevention:** Make a testable definition of done a condition of any additional obligation. ## FAQ **Q: What is a ceiling price in a time-and-materials contract?** A maximum value the contractor may invoice, required by FAR for T&M and labor-hour contracts. It caps government exposure but creates no incentive for efficiency, which is why the regulation also requires surveillance. **Q: Why do AI programs reach the ceiling so often?** Usually because the estimate covered a platform that did not exist yet. Retrieval, evaluation, guardrails, access control and audit logging are substantial engineering, identical across organizations, and easy to under-scope when nobody has built them before. **Q: Should we raise the ceiling or restructure?** Raise it if the scope genuinely changed. If undifferentiated platform work is consuming the budget, a larger ceiling buys more of the same construction — licensing a platform that already exists and re-scoping to integration addresses the cause. **Q: Can a program change direction mid-contract?** Usually yes. Work already delivered that is specific to your organization tends to survive as an extension on a licensed platform; the undifferentiated portion simply stops being rebuilt. Settle rights to existing work before transitioning. **Q: How should progress be measured on an AI contract?** Against a held-out evaluation set drawn from your own data, with an agreed passing threshold, reported monthly. Hours burned measure activity; evaluation pass rate measures whether the system works. **Q: How does ibl.ai fit in?** ibl.ai removes the largest cause of ceiling breaches by removing the construction phase. The platform is already in production and ships with the full source code, so the engagement scopes integration rather than building a base. You own all the code and the data, run it model-agnostic across any LLM, with no per-seat pricing, and can deploy anywhere including fully air-gapped. ## Can you do this on infrastructure you own? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.