IGCE Builder: Firm-Fixed-Price (FFP)

Overview

This skill produces Independent Government Cost Estimates for FFP contracts using a layered wrap rate buildup model. Instead of the single burden multiplier used in T&M/LH pricing, FFP separates direct labor, fringe benefits, overhead, G&A, and profit into distinct auditable cost pools. The BLS base wage anchors the estimate; each cost pool adds a layer; the result is a fully burdened FFP rate per labor category.

Required MCP servers:

1. bls-oews -- market wage data by occupation and geography. Key tools: get_wage_data, igce_wage_benchmark, list_common_metros, list_common_soc_codes.
2. gsa-calc -- awarded GSA MAS ceiling hourly rates. Key tools: suggest_contains, exact_search, keyword_search, igce_benchmark, price_reasonableness_check.
3. gsa-perdiem -- federal CONUS travel lodging and M&IE. Key tools: lookup_city_perdiem, estimate_travel_cost, get_mie_breakdown.

The MCPs handle API keys, URL construction, series ID assembly, MSA renumbering, JSON path parsing, and the 75% first/last day M&IE rule. Call the tools directly; do not hand-construct API requests.

Regulatory basis: FAR 15.402 (cost/pricing data). FAR 15.404-1(a) (cost analysis). FAR 15.404-1(b) (price analysis). FAR 15.404-4 (profit/fee analysis). FAR 16.202 (FFP contracts).

Operating Principle (ai-boundaries)

This skill assembles data and formats documents from reasoning the contracting officer supplies. It does NOT originate evaluative conclusions. Specifically:

• The skill pulls BLS wages, CALC+ ceiling rates, and Per Diem rates, and formats them into a workbook.
• The skill does NOT determine whether a rate is "fair and reasonable" under FAR 15.404-1. That determination is the CO's.
• The skill does NOT assert premiums (TS/SCI, OCONUS, SCIF, specialty labor) that are outside BLS/CALC+/Per Diem data. If a premium is needed and the data does not support it, the skill names the gap and hands the decision back to the CO.
• The skill does NOT draft a price reasonableness memo, a responsibility determination, or any FAR-citing signature document unless the CO has already supplied the rationale and conclusion, in which case the skill formats the CO's text into the template.
• Narrative prose (chat summaries, Methodology sheet, Rate Validation status) avoids evaluative verbs: "defensible," "reasonable," "acceptable," "competitive," "outlier." Replace with neutral positioning: "at P77 of CALC+ pool (n=X)," "within BLS P90 fully-burdened equivalent," "above P50 by Y%, document stacked factors in Methodology."

Stacked factors refers to the component sources of a rate premium. Typical examples: metro wage differential, seniority tier premium, clearance requirement premium, lab/SCIF overhead, thin CALC+ corpus (directional only), MAS ceiling vs CR cost-plus-fee separation, BLS vintage aging. Name the specific factors that apply, not the word "stacked" alone.

If you find yourself writing a conclusion about whether a number is right or wrong, stop. Present the data and let the CO conclude.

Pre-flight: MCP dependency check

Runs before Workflow Selection. Required on every skill trigger.

This skill needs three MCP servers: bls-oews, gsa-calc, gsa-perdiem. Do not proceed to any workflow until both checks below pass.

Check 1: MCP presence. Verify all three are available in the current session by looking for one known tool from each:

• bls-oews (check for mcp__bls-oews__detect_latest_year)
• gsa-calc (check for mcp__gsa-calc__suggest_contains)
• gsa-perdiem (check for mcp__gsa-perdiem__get_mie_breakdown)

If any are missing, respond with:

This skill requires the bls-oews, gsa-calc, and gsa-perdiem MCP servers. Missing: [list]. Install and configure them in your MCP client before using this skill.

Check 2: API key presence. Two of the three need API keys. Verify by lightweight ping:

• mcp__bls-oews__detect_latest_year (needs a BLS API key)
• mcp__gsa-perdiem__get_mie_breakdown (needs an api.data.gov key)
• gsa-calc needs no key, skip

If either ping returns an auth error or missing-key error, respond with:

[bls-oews | gsa-perdiem] is installed but its API key is not set. This MCP needs a free API key (BLS for bls-oews, api.data.gov for gsa-perdiem). Register the key with the provider and add it to the MCP's configuration, then restart your MCP client.

Only proceed to Workflow Selection after both checks pass. Do not try to work around missing MCPs by calling APIs directly; the skill relies on MCP-guaranteed behaviors (MSA renumbering lookups, JSON path normalization, first/last day M&IE math).

Workflow Selection

Workflow A: Full FFP IGCE Build (Default)

User needs a complete FFP cost estimate. Execute Steps 1 through 9 in order. Triggers: "FFP IGCE," "firm fixed price estimate," "wrap rate buildup," "cost buildup."

Workflow A+: SOW/PWS-Driven FFP Build

User provides a Statement of Work or requirement description instead of pre-structured labor inputs. Execute Step 0 (Requirements Decomposition) first, validate with user, then Steps 1-9. Triggers: "build an FFP IGCE from this SOW," "price this PWS as FFP," or when the user provides a block of requirement text rather than a labor category table.

Skip Step 0 if the user provides explicit staffing (headcount per labor category) even if they reference an underlying PWS or SOW. Go straight to Workflow A.

Workflow B: FFP Rate Positioning (Data Only, No Determination)

User has proposed rates and wants to see where they sit against market data. The skill returns the data and the CO decides reasonableness. The skill does not produce a "fair and reasonable" determination, a signed memo, or advisory text telling the CO how to negotiate.

Triggers: "is this FFP rate reasonable," "validate these wrap rates," "check this FFP proposal," "price reasonableness analysis."

Step 0 / GATE (MANDATORY FIRST — runs before any other Workflow B step).

Workflow B entry = gate fires unconditionally. If the user's prompt matches any Workflow B trigger ("is this FFP rate reasonable," "validate these wrap rates," "check this FFP proposal," "price reasonableness analysis," or any variant), the ENTIRE first response must be the refusal template below, emitted verbatim. No rate analysis. No CALC+ pull. No BLS pull. No "let me start with the analysis" preamble. No offer to continue with the memo if the user provides more info in the same response. Emit the template. Stop. Wait for the user's explicit Option A or Option B choice. This applies whether or not the prompt contains memo-drafting tokens; the gate is not token-gated.

Memo-drafting tokens (emit the template WITH the additional hard prohibition in bold: "I will not draft a determination section absent your verbatim rationale"): "memo", "determination", "fair and reasonable", "reasonable" (standalone), "price reasonableness", "reasonableness memo", "draft the memo", "for the file", "contract file", "document this", "memorandum", "validate," "acceptable," "justify."

Refusal template (emit verbatim):

I can pull positioning data that shows where each proposed rate sits against CALC+ ceiling rates and BLS market wages. I cannot draft a price reasonableness memo, write a "fair and reasonable" determination, or recommend negotiation positions. Those are Contracting Officer decisions under FAR 15.404-1, not skill outputs.

>

Tell me which you want:

>

Option A — Positioning data only. I produce a table: per-LCAT proposed rate, CALC+ P25/P50/P75/P90 with sample size, BLS metro burdened equivalent. No verdict. No recommendation. You draw the conclusion.

>

Option B — Memo template fill. You provide your rationale (what supports or doesn't support each rate) and your determination (fair and reasonable / not fair and reasonable / declining to determine). I drop your text verbatim into the memo template, add the benchmark tables underneath, mark it DRAFT. I will not originate determinations, recommend negotiation positions, or add hedging language.

>

Which option?

Proceed to Steps 1-5 only after:

• User explicitly selects Option A, OR
• User provides Option B inputs (rationale text + determination text)

Hard prohibitions at ALL times (Option A or Option B):

• Do NOT write "the rate is fair and reasonable" or "not fair and reasonable" unless quoting the user's Option B text verbatim.
• Do NOT label rates "competitive," "aggressive," "outlier requiring justification," "premium warrants clarification," or any equivalent evaluative phrase. Use positional language only ("at P77," "above P50 by X%," "below P25").
• Do NOT recommend negotiation positions, evaluation notices, or counter-offer dollar figures.
• Do NOT write "Summary of findings" or "Determination" sections that draw conclusions the user has not supplied.

Workflow B steps (run only after Step 0 gate clears):

1. Collect the vendor's proposed labor categories, fully burdened hourly rates, and any scope context (metro, clearance, experience tier).

1. For each LCAT, call mcp__gsa-calc__price_reasonableness_check(labor_category, proposed_rate, experience_min, education_level). The MCP returns count, min/max, median, IQR bounds, z-score, and percentile position. If sample size is below ~25 records, label the pool "directional only, not statistical validation."

1. For senior LCATs, also run the Step 4 dual-pool flow (title-match via suggest_contains + exact_search, plus experience-match via igce_benchmark) and present both medians side-by-side.

1. If metro context matters (DC, SF, NYC, Boston, etc.), pull BLS OEWS for that metro via mcp__bls-oews__get_wage_data and present the P50/P75/P90 fully-burdened equivalent using the vehicle wrap preset. This shows how the rate sits against local market labor independent of the CALC+ nationwide pool.

1. Present a neutral positioning summary. Example format:

Proposed rate: $225/hr fully burdened, Senior Data Scientist, DC metro, Agency BPA cleared.

>

CALC+ benchmark (Senior Data Scientist, 8+ yrs, n=7, thin-corpus directional only): - P25 $170, P50 $190, P75 $218, P90 $236 - Proposed rate at P77, z-score 1.1, within 2σ outlier bounds ($139-$250)

>

BLS OEWS DC metro (15-2051 Data Scientists, 2024 vintage aged to [contract start] at 2.5%): - P50 annual $135,190, P90 annual $208,600 - Applied Agency BPA cleared wrap (3.17x) to P90 hourly: fully-burdened equivalent $234

>

Premium factors this data does NOT capture: TS/SCI clearance premium, any SCIF-specific overhead, specialty cyber/data-science labor market tightness. If the CO intends to attribute part of the premium to clearance, the clearance premium range is the CO's to set based on agency policy or independent market research.

1. Stop. Do not write "the rate is fair and reasonable." Do not recommend negotiation positions. Do not suggest "push back only if..." text.

1. Memo output (Option B path only). If the user selected Option B at the Step 0 gate and supplied rationale + determination text, fill the memo template: benchmark tables from Steps 2-4, the user's rationale text verbatim in the findings section, the user's determination text verbatim in Section 7 (Determination). Do NOT paraphrase, do NOT add hedging, do NOT originate any conclusion text. Mark DRAFT. Use [Contracting Officer Name] and [Agency] placeholders. If Option A was selected, skip this step entirely.

Information to Collect

Batch clarifying questions rather than ask iteratively. If key inputs are missing, ask all in one message before building. Provide defaults where noted. If any Required Input is ambiguous or missing for Workflow A (e.g., labor count without discipline, location without metro, fee type not specified), use AskUserQuestion to collect before pulling data. Do not guess.

Required Inputs

Optional Inputs (Defaults Applied If Not Provided)

Wrap Rate Component Guidance

This table is a sensitivity reference for scenario Low/High bounds, NOT a default pick for MID. MID should come from the Vehicle Preset table below when a vehicle applies. The Low/High columns here are the outer envelope used to stress-test scenarios once MID is set.

The generic Mid (32/80/12/10 → 2.93x) matches the DoD non-cleared vehicle preset. Do not apply it to GSA MAS commercial, Agency BPA, DoE M&O, or OCONUS builds without checking the Vehicle Preset table.

Wrap Rate Presets by Contract Vehicle

CRITICAL: ASK about contract vehicle before applying default wrap rates. Workers have historically defaulted to skill mid (32/80/12/10, implied multiplier 2.93x) regardless of vehicle. That is correct for GSA MAS commercial or agency BPA non-cleared, but materially wrong for DoE M&O, cleared DoD, or OCONUS. Use this table to select MID scenario defaults keyed by the actual vehicle/environment the contract will use:

Notes on vehicle selection: GSA MAS commercial = SIN 520, 541611, ceiling-rate vehicle. Agency BPA/IDIQ cleared = TS/SCI in SCIF. DoE M&O/FFRDC = UT-Battelle, LANS, Sandia (higher fringe, lower profit). R&D/BAA CR carries lower profit; fee is separate on CR contracts.

Math check: Multipliers computed as (1+fringe) × (1+OH) × (1+G&A) × (1+profit). Example GSA MAS commercial: 1.30 × 1.60 × 1.10 × 1.08 = 2.47x. Verify this arithmetic in your workbook; Methodology narrative must match the actual cell values, not a rounded guess.

Sanity band is pinned to each preset row above. Flag for user review only if the MID multiplier falls OUTSIDE the band shown in that row. A 3.17x Agency BPA cleared build lands in its 3.0-3.4x band (normal); a 3.17x GSA MAS commercial build is outside 2.3-2.7x (flag).

Use the MID column as your scenario mid. Generate LOW as mid minus ~20% on each component, HIGH as mid plus ~20%.

If the user doesn't specify a vehicle, ASK before defaulting. If the user provides explicit rates, use those (custom rate workflow below).

Custom rate workflow: When the CO provides explicit wrap rates (e.g., for cleared/SCIF environments), those rates ARE the mid-scenario estimate. Do NOT use skill defaults as mid and the CO's rates as a scenario variant. Instead:

• Use CO-provided rates as MID scenario
• Generate LOW as mid minus offset (e.g., 20% reduction on each component)
• Generate HIGH as mid plus offset (e.g., 20% increase on each component)
• Document the CO-provided rates as the authoritative basis

CO-supplied DCAA-audited rates (override rule, stronger than Custom rate workflow). When the contracting officer supplies DCAA-audited indirect rates from an approved Forward Pricing Rate Agreement (FPRA), a current disclosure statement review, or a bilateral rate agreement, USE THOSE RATES instead of the Vehicle Preset table AND do NOT generate fictional LOW/HIGH bookends around them. Audited rates are a single authoritative value (point estimate), not a midpoint. Apply the FPRA rates in a single column on Sheet 1 and Sheet 2; if a LOW/HIGH band is still required for scenario display, clearly label the band as "sensitivity display only; FPRA is authoritative" in Methodology rather than treating LOW and HIGH as plausible rate outcomes. Document the source: FPRA effective date, approving authority (e.g., DCAA Region), rate composition (fringe / OH / G&A / profit split). Audited rates are a stronger basis than generic vehicle-preset defaults; do not revert to defaults and do not reconcile the CO's number to the closest vehicle row even if it lands outside the table's expected bands. If the CO-supplied rate diverges materially from the vehicle preset for the stated environment, trust the CO-supplied rate and note the divergence in Methodology.

Constants Reference

Orchestration Sequence

Step 0: Requirements Decomposition (Workflow A+ Only)

Converts an unstructured SOW/PWS into the structured inputs needed for pricing.

Process:

1. Sufficiency check. Scan for six priceable elements: labor categories, staffing levels, performance location, period of performance, deliverables, and travel. Flag anything missing. Hard stop if performance location is absent. If 3+ elements are missing and the document is under 500 words, ask the user whether to proceed with flagged assumptions or get clarification first.

1. Task decomposition. Parse into discrete task areas. For each: one-sentence description, primary skill discipline, complexity (routine/moderate/complex), recurring vs. finite.

1. Labor category mapping. Map tasks to SOC codes using the heuristics in Step 1. When a task spans disciplines, map to multiple categories.

1. Staffing estimation. Estimate FTEs per category based on scope indicators (number of systems, shift coverage language, surge/on-call, site count). Present as ranges when scope is ambiguous.

1. Present decomposition table for user validation:

Task Area               | Labor Category      | SOC Code | Est. FTEs | Basis
Application Development | Software Developer  | 15-1252  | 2-3       | 3 apps, agile
Security Operations     | InfoSec Analyst     | 15-1212  | 1-2       | Continuous monitoring
Project Oversight       | Project Manager     | 13-1082  | 1         | Single contract

1. User validation gate (CRITICAL) - two stages, not one. Skip Stage A/B gate when user provides structured inputs: LCATs with discipline, location with metro, FTE counts, and PoP all specified. If any of those four are ambiguous or missing, run the gate. Do not conflate "confirm the decomposition" with "pick build parameters." Run them separately:

Stage A - Decomposition validation. After presenting the decomposition table, ask the user to confirm or amend it. Use AskUserQuestion with options like "Decomposition looks right, proceed" / "Modify LCAT X" / "Add LCAT Y" / "Adjust FTE estimates." Response MUST END after this question. Wait for explicit confirmation before continuing.

Stage B - Build parameters. Only after the decomposition is confirmed, ask the remaining parameter questions (vehicle preset, metro, contract start, NAICS/PSC, hour-allocation method for FFP-by-deliverable, shift coverage density if 24x7). Use a separate AskUserQuestion call. Response MUST END after this question.

DO NOT self-approve either stage. DO NOT skip Stage A to go straight to parameters. Proceeding to Step 1+ before Stage B is also answered is a skill violation. The user must affirmatively validate BOTH the decomposition and the parameters before build work begins.

Step 0.5: Shift Coverage Staffing (if PWS specifies 24x7, continuous, or on-call)

When the requirement specifies continuous coverage, convert to FTE using industry-standard backfill math:

24x7x365 single-seat coverage    = positions_per_shift x 4.2 FTE
24x7x365 double-seat coverage    = positions_per_shift x 8.4 FTE
8x5 single-seat coverage         = positions_per_shift x 1.2 FTE

Derivation: one shift covers 2,080 hrs/yr at ~95% availability. Four shifts cover 8,760 annual hours with 50% blended availability (leave, training, overlap, turnover). Industry convention. The 4.2 factor accounts for ~25% non-productive time: PTO (10%), federal holidays (4%), training (5%), sick leave/turnover buffer (6%). Do NOT staff 4.0 FTE for 24x7 - that undercovers leave. Do NOT staff 1.0 FTE - that only covers one shift.

Document shift-coverage FTE derivation in the Methodology sheet: "24x7x365 SOC coverage at single-seat: 4.2 FTE per covered position per industry standard accounting for leave and training backfill."

Escalation overlay. Add on-call or overtime reserve for surge-driven work beyond base coverage. Typical on-call premium: 10-15% of base labor hours for incident response positions.

Travel for shift-coverage roles. If the requirement includes travel, default to 1 representative per trip (rotating shift lead or designated trip captain), NOT the full 4.2 FTE. Note the convention in Methodology: "Shift coverage uses a single traveler per trip; remaining shift members stay on site to maintain coverage." Ask the user only if they explicitly say "all staff travel" or the PWS requires multiple attendees.

Tier 1 vs Tier 2 distinction. When a PWS says "24x7 Tier 2" or "24x7 Tier 2 incident response" specifically, do NOT blindly apply 4.2 FTE as if it were full 24x7 SOC coverage. Tier 2 is often an on-call overlay on existing Tier 1 monitoring rather than a separate round-the-clock seat. Ask the user to clarify via AskUserQuestion:

• "Tier 2 as a standalone 24x7 coverage layer (4.2 FTE single-seat)"
• "Tier 2 as on-call overlay on existing Tier 1 (typically 2-3 FTE with on-call premium)"
• "Tier 1 + Tier 2 both contractor-provided (4.2 FTE Tier 1 + 2-3 FTE Tier 2)"

Document the choice in Methodology with the FTE derivation.

TS/SCI compliance overhead (optional). On cleared contracts (TS/SCI, SCIF-based, or DoE M&O), NIST SP 800-53 continuous monitoring, STIG remediation, and accreditation maintenance typically consume 5-10% of staff time. This is NOT captured in the BLS wage data. If the requirement references cleared operations, ask the user whether to:

• Absorb compliance overhead into base FTE counts (default, no action needed)
• Add a 5-10% overhead buffer as a separate labor line, with CO confirmation on the percentage

Document the choice. Do not apply the buffer silently.

Step 1: Map Labor Categories to SOC Codes

Map user job titles to Standard Occupational Classification codes.

Domain triage first. Before mapping, confirm: is this an IT/software requirement, a non-IT engineering requirement, a scientific/research requirement, a medical requirement, or a professional services requirement? This single branch prevents the most common mis-mapping (using 15-1211 Computer Systems Analyst for non-IT systems engineers).

IT and software (15-12xx):

Physical and non-IT engineering (17-2xxx): Use these for reactors, aerospace, civil infrastructure, chemical, mechanical, and any "Systems Engineer" that integrates hardware rather than software.

Use 17-2199 when the role doesn't cleanly fit one engineering discipline (RF, antenna, radar, systems integration specialties). Pull alongside a specific engineering SOC for comparison.

Science, research, and medical:

Program / Project Management — context-dependent:

Program Manager SOC depends on the contract type:

• Operations / administrative contracts: 11-1021 (General and Operations Managers) — help desk, logistics, facilities, admin support
• Engineering / technical contracts: 11-9041 (Architectural and Engineering Managers) — reactor design, aerospace, infrastructure, R&D
• IT / software contracts: 11-3021 (Computer and Information Systems Managers) — software development, cybersecurity, enterprise IT

The engineering variant (11-9041) runs 20-40% higher than 11-1021 and is more defensible for technical programs. Document the choice in the Methodology sheet.

Technical writing and support:

When mapping is ambiguous, query multiple SOC codes and present the range.

Step 2: Pull BLS Wage Data

Call mcp__bls-oews__get_wage_data(occ_code, scope, area_code, datatypes) for each labor category. Pass a 6-char SOC, scope metro|state|national, and area_code (5-digit MSA for metro, 2-digit FIPS for state). Request datatypes ["04", "11", "12", "13", "14", "15"] for mean + P10/P25/P50/P75/P90. Valid datatypes accepted by the MCP are 01, 03, 04, 08, 11, 12, 13, 14, 15 only; do NOT pass 02 or 05 (the MCP rejects them).

The MCP builds the 25-char series ID, handles footnote code 5 (cap) vs. code 8 (suppression), and exposes the current MSA list via list_common_metros with OMB Bulletin 23-01 renumbering notes. You do not need to hedge against Cleveland 17410 or Dayton 19430 yourself. If the target metro is not in list_common_metros, resolve the MSA code via https://www.bls.gov/oes/current/msa_def.htm and pass the 7-char code directly to get_wage_data. Do not fall back to state-level wages without first checking the MSA directory.

Geography fallback (caller's job): metro first; if the MCP returns "series does not exist" on every datatype, try state; fall back to national. Recommend the median as the default basis and present the full distribution.

Known-fragile SOCs at metro level. Some specialty SOCs suppress at metro level; fall through to state without treating it as a data quality signal.

Shortcut: for a single-LCAT single-location sanity check, mcp__bls-oews__igce_wage_benchmark(occ_code, scope, area_code, burden_low, burden_high) returns annual and hourly mean/median/P10/P90 with a burdened range in one call. Use for Workflow B rate checks; use get_wage_data when building the full workbook.

Seniority modeling when BLS lacks granularity. BLS does not break out junior / mid / senior variants within a single SOC. When a PWS specifies seniority tiers, use percentile positioning as a documented convention:

• Junior / entry: P25
• Mid / journeyman: P50
• Senior: P50 to P75 depending on scope and distribution shape
• Principal / director / SME: P75 to P90

No tiers specified. When the user gives an N-person team with no seniority breakdown (e.g., "3-person dev team"), default all N members to P50 (mid/journeyman) and note this in Methodology as "no seniority tiers specified, all members priced at mid-level P50 convention." Do NOT invent a 25/50/25 Jr/Mid/Sr split unless the user asks.

Document this in Methodology as a convention, not a BLS standard.

Wage cap ($239,200 annual / $115.00 hourly). When the MCP flags a value as capped, use the cap as a lower bound and flag in the narrative. If the chosen percentile lands within 10% of the cap (≥ $215,280 annual / ≥ $103.50 hourly), note in Methodology that the local market may exceed the stated value and flag for CO review.

BLS flat-tail detection. If P75 equals P90 in the BLS return AND neither hits the $239,200 cap, the local top-tail is sample-constrained (single dominant employer, thin high-end pool). Flag in Methodology: "Local P75/P90 collapsed; top-tail data sparse, local market may run higher than stated."

Cap decision tree when P75 ALSO caps. In single-employer-dominated metros (ORNL/Y-12 Knoxville Nuclear, certain LANL/INL physicists), P90 and sometimes P75 both cap. When P75 is capped:

1. Use BLS Mean (datatype 04) as the senior-tier anchor. Document as "P75 capped, Mean used as uncapped senior anchor."
2. Cross-reference commercial compensation surveys (Radford, Mercer, Payscale) for the specialty market.
3. Apply national P75/median ratio to the local median as a derived P75. Document as derivation, not BLS figure.
4. Never use $239,200 as the point estimate; it is a floor, not the value.

Compressed distributions (P25 equals P10). In the same single-employer metros, the lower half of the distribution can also compress: P25 and P10 return identical values because the dominant employer anchors even the lowest-paid workers at its own scale. When P25 = P10:

• The local P50 itself is likely pulled toward the dominant employer's mid-tier, not a genuine market median.
• Document in Methodology: "distribution compressed (P25=P10=$X); P50 reflects dominant-employer scale, not broader market."
• For Junior-tier pricing, do NOT use P25. Use national P25 × (local P50 / national P50) ratio to reconstruct a defensible junior anchor.

Step 2B: Age BLS Wages to Contract Start Date

BLS OEWS data has a ~2-year lag (May 2024 estimates released April 2025). If the contract Period of Performance starts after the data reference period, the base wages must be aged forward to avoid understating costs.

months_gap = months between BLS data vintage (May 2024) and contract PoP start date
aging_factor = (1 + escalation_rate) ^ (months_gap / 12)
aged_annual_wage = annual_median * aging_factor

Compute months_gap at build time from the contract start date the user provides. Do NOT copy the 29-month example from this skill. Contract start dates vary; aging factors must be current.

Example: if the contract start is 29 months after the BLS data vintage, at 2.5% escalation the aging_factor = 1.025^(29/12) = ~1.061. A $100,000 BLS median becomes $106,100 before wrap rate buildup.

Use the aged wage as the basis for all subsequent calculations. Document the aging adjustment in the Methodology sheet: "BLS OEWS wages (data vintage: May 2024) aged forward [X] months to [contract start] at [escalation rate]%/yr to account for data lag."

Contract start date default. If the user does not specify, default to October 1 of the next federal fiscal year (computed at build time). Surface the assumption in the Summary sheet as a blue-font editable cell. If the user clarifies later, changing the cell recalculates the aging factor and the entire workbook. Do NOT invent a start date silently without noting it in the output.

The aging factor must be a cell-referenced formula in the workbook, not hardcoded. See Step 8 assumption block layout.

The escalation applied in Step 7 across option years starts AFTER this aging adjustment. Step 2B ages the base wage to the contract start; Step 7 escalates from that adjusted base across the period of performance. These are not double-counted.

Step 3: FFP Wrap Rate Buildup

Build the fully burdened rate layer by layer for each labor category:

1. Direct Labor Rate    = aged_annual_wage / 2080
2. Fringe               = Direct Labor * fringe_rate
3. Labor + Fringe       = Direct Labor + Fringe
4. Overhead             = Labor_Fringe * overhead_rate
5. Subtotal             = Labor_Fringe + Overhead
6. G&A                  = Subtotal * ga_rate
7. Total Cost           = Subtotal + G&A
8. Profit               = Total_Cost * profit_rate
9. Fully Burdened Rate  = Total_Cost + Profit

Implied wrap rate: implied_multiplier = fully_burdened_rate / direct_labor_rate. For default rates: 1.0 x 1.32 x 1.80 x 1.12 x 1.10 = ~2.93x. FFP rates are typically higher than T&M because the contractor absorbs cost risk.

Three-scenario approach: Vary each component, not a single multiplier:

Sanity band applies to MID only. The mid-scenario implied multiplier should fall within 2.2x-3.5x for commercial-item CONUS services. The high-scenario multiplier naturally hits 4.18x from arithmetic (1.40 x 2.20 x 1.18 x 1.15) - that's expected, not an outlier, and does not trigger the "SCIF/niche" flag. Flag only the MID multiplier for review against the 2.2x-3.5x band.

For SCIF, cleared, or OCONUS environments, the mid multiplier routinely hits 3.0x-3.8x. That is not an outlier either - it's the actual market. When overhead is user-specified above 85% or the prompt references SCIF/cleared/OCONUS, document the elevated multiplier in methodology regardless of whether it falls inside or outside the nominal band.

Step 4: Cross-Reference Against CALC+

Follow a discovery-first pattern. The MCP returns clean aggregation stats; your job is picking the right tool for the pool you want.

Decision tree:

1. Discover buckets. Call mcp__gsa-calc__suggest_contains(field="labor_category", term=<LCAT term>). Returns up to 100 buckets with doc_count per bucket plus a likely_truncated flag. If truncated, narrow the term.
2. If the top 2-3 buckets have combined records >=50: call mcp__gsa-calc__exact_search(field="labor_category", value=<exact bucket name>) for each, then aggregate. This avoids the wildcard-match contamination that keyword_search produces (it also matches vendor_name and idv_piid).
3. If buckets are fragmented (every bucket under ~30 records, common for niche cleared cyber / specialty engineering): fall back to mcp__gsa-calc__keyword_search(keyword=<term>). Document the contamination caveat in Methodology.
4. Default for Workflow A rate validation: use mcp__gsa-calc__igce_benchmark. Call keyword_search only when you need the example-rate or labor-category buckets. mcp__gsa-calc__igce_benchmark(labor_category=<exact>, experience_min=N, education_level=X) returns count, min/max/mean, std dev, and P10/P25/P50/P75/P90 in one call, without the 50KB+ labor_category/current_price aggregation buckets that blow up response size. page_size=0 is no longer accepted by the MCP. Use page_size=1 minimum when aggregation stats are needed; prefer mcp__gsa-calc__igce_benchmark for stats-only access (no corpus, trimmed return shape).

The MCP returns canonical stats at the top level of the response dict (count, min_rate, max_rate, avg_rate, p25, p50, p75). No JSON-path archaeology required.

Match the vendor's tier in the keyword, not the aggregate title. For 'Mid Software Developer' query Software Developer II not Software Developer — the aggregate pool mixes interns through Senior levels and can falsely flag rates as +70% divergent when the tier-matched pool is +11%.

Rate validation positioning (data only, not a determination). Present the vendor's / IGCE's FBR against CALC+ P25/P50/P75 as a positional statement. Do NOT assert "reasonable," "defensible," "outlier requiring justification," or "within expected band." Those are CO determinations. The skill describes WHERE the rate sits and documents the stacked factors that place it there.

Narrative positioning language (use this, not evaluative verbs):

• "Rate sits at CALC+ P77 (n=7, thin-corpus directional only)."
• "Above P50 by X%; stacked factors: [metro, seniority tier, aging, wrap vs commercial]."
• "Below P25; pool composition or LCAT alignment may warrant CO review."
• "Premium factors not captured by this data: [TS/SCI clearance premium, SCIF overhead, specialty market]. CO sets the relevant premium band if one applies."

Stacked premium: show the math, do not conclude. When divergence above CALC+ P50 looks large (40%+), decompose the divergence into source factors (metro ratio, seniority tier, aging, wrap vs commercial) and present the compounded ratio in Methodology. Do NOT write "this is defensible"; present decomposition and let the CO conclude. If actual FBR is significantly above the stacked-factor expectation, flag which factor is larger than data supports.

Calibration guidelines for Sheet 4 Status column (positioning only, not determinations):

• 0-15% above P50: "Within CALC+ FFP premium range"
• 15-40% above P50: "Above P50 by 15-40%; typical FFP risk premium range"
• 40-70% above P50: "Above P50 by 40-70%; expected in high-cost metros vs nationwide CALC+. See Methodology for factor decomposition."
• >70% above P50: "Position outside ±70% band; document stacked factors in Methodology."
• Below P25: "Below P25; CO review recommended."

The Sheet 4 Status column labels position the rate; it does NOT say "reasonable" or "outlier." If the user asks the skill to assert reasonableness, refer them to the ai-boundaries principle at the top of this skill.

Dual-pool analysis for senior LCATs. For "Senior X" requirements, the MCP does not auto-dual-pool. Query both title-match (suggest_contains then exact_search on "Senior X") and experience-match (igce_benchmark with experience_min=8) and present both medians. They often differ by 10-15%; the CO picks which better matches the vendor's LCAT description.

Known-fragmented LCAT terms. Some common job titles return fragmented CALC+ buckets (no single bucket with enough records for clean stats). Use these canonical queries instead:

• "SOC analyst" / "cyber analyst" → query Information Security Analyst I/II/III (15-1212 pool has tiered buckets)
• "Software engineer" as a generic role → query Software Developer I/II/III tiers
• "Data engineer" → often returns <10 records; fall back to igce_benchmark on Data Scientist with experience filter

Workflow B shortcut: mcp__gsa-calc__price_reasonableness_check(labor_category, proposed_rate, education_level, experience_min) returns z-score and percentile position directly. Use for vendor rate validation without a full workbook.

Step 5: Pull Per Diem Rates (If Travel Required)

Call mcp__gsa-perdiem__estimate_travel_cost(city, state, num_nights, travel_month=None, fiscal_year=None) per destination. The MCP returns nightly_lodging, lodging_total, daily_mie, first_last_day_mie, mie_total, grand_total, and travel_days. First/last day 75% M&IE and the day-trip (0 nights) edge case are handled internally per FTR 301-11.101. If travel_month is omitted, the MCP uses the max monthly lodging rate as a conservative ceiling.

Annual travel math: annual_travel = grand_total * trips_per_year * travelers.

Installation → GSA locality crosswalk. GSA keys per diem by civilian locality, not by military installation or research lab. Looking up "Fort Meade" or "Pentagon" directly returns empty. Translate the installation to its GSA locality BEFORE calling the MCP:

If the installation is not on this list, query mcp__gsa-perdiem__lookup_city_perdiem with the nearest civilian city and cross-check the result's county field.

"Between sites" travel canonical interpretation. When user says "quarterly travel between sites" or "monthly travel between sites" with multiple locations, default to: trips/year TOTAL split evenly across destinations, NOT trips/year each way. Example: "quarterly travel between Fort Meade and Colorado Springs" = 4 trips total (2 MD→CO, 2 CO→MD), not 8. Confirm via AskUserQuestion only if the user says "each way" explicitly, or if the split would exceed reasonable burn rate (more than one trip per month per destination).

Same-metro TDY proximity check. If performance_location MSA equals travel_destination MSA (same metro, <50 mi), overnight lodging per diem may not qualify under FTR 301-7.103. Flag in Methodology: "Same-MSA travel; if this is not overnight TDY, zero the lodging line and use mileage only."

City Pair airfare (optional): When origin and destination are known, look up YCA fares at cpsearch.fas.gsa.gov. Skip if origin is unknown, OCONUS, local travel, or user provides their own airfare.

Fiscal-year fallback. The MCP returns EITHER an empty rates array OR an explicit error string containing "No rates found for FY{year}" when the requested FY is not yet published. Trigger fallback on both cases:

if response == [] or (isinstance(response, dict) and "No rates found for FY" in response.get("error", "")):
    # retry with fiscal_year = requested_year - 1

Note the fallback in Methodology: "FY{requested} per diem not yet published; FY{fallback} rates used as conservative baseline." Default FY policy: use contract-start FY when available; if that FY is not yet published, fall back to current FY.

If the contract PoP start is within 6 months of the next federal fiscal year, query both FYs; if the target FY is not yet published (FY{N+1} publishes mid-August {N}), use current FY as conservative baseline and note in methodology: 'refresh on FY{N+1} publication.'

Absorbed vs discrete low-effort tasks. The skill does not have a hard rule for when to break out quarterly tabletops, annual audits, monthly reports, or similar low-effort recurring tasks as separate labor lines vs absorbing them into base FTE counts. Convention:

• Absorb when the task is <5% of an existing LCAT's time and the LCAT already has the skill set to perform it (e.g., tabletop facilitation absorbed into a Senior IR LCAT's hours).
• Break out as separate line when the task requires a distinct skill set, has its own deliverable cadence the CO will track, or exceeds 5% of any single LCAT's time.

Document the choice in Methodology. If the user asks, offer both options via AskUserQuestion.

When no travel, include the sheet with a single 'Travel Not Applicable' text block. Do not skip the sheet — Sheet 1 Travel row still needs a cell reference target. See Step 8 workbook structure. Also include a Travel row on Sheet 1 Summary with 0 value and "Not Applicable" note (see Step 8 Sheet 1 layout for no-travel handling).

Step 6: Handle Multi-Location Weighting

When the user provides EXPLICIT headcount per location (e.g., "4 FTE Fort Meade, 3 FTE Colorado Springs"): use Option C by default. The user has already answered the weighting question by structuring the input that way. Do NOT prompt for A/B/C; proceed.

When staff allocation across sites is unspecified or ambiguous: ask the user, with defaults:

• Option A (fallback, conservative): Use highest median across locations per category. Preserves information when allocation is truly unknown.
• Option B (weighted): weighted_wage = (wage_A * pct_A) + (wage_B * pct_B) if user provides split.
• Option C (separate lines): Dedicated staff per location get separate rows. Preferred when headcount is explicit.

Option C is the information-preserving choice when data is available. Option A discards real geographic wage differentials and should only be used when allocation is genuinely unknown.

Step 7: Calculate Fixed Prices and Apply Escalation

Two FFP pricing structures (ask user which applies):

Structure A: FFP by Period (default for services)

period_labor = sum(fully_burdened_rate * productive_hours * headcount) per category
period_travel = travel costs from Step 5
period_fixed_price = period_labor + period_travel + ODCs

Structure B: FFP by Deliverable/CLIN

Three legitimate hour allocation approaches. Ask which applies when user provides scope weights:

• Uniform allocation (default): Apply scope percentage uniformly across all labor categories. deliverable_hours = total_hours * scope_weight.
• Per-LCAT matrix: Different allocation per labor category. Technical Writer may concentrate 75% of hours on D4 final report; Nuclear Engineer may spread evenly. User provides an N x M matrix (N labor categories by M deliverables).
• Staffing-profile-driven: Effort ramps (e.g., Technical Writer at 25% effort months 1-12, 75% effort months 13-18). Compute hours per deliverable from the overlap of staffing effort with deliverable date ranges.

Validate scope percentages sum to 100%. If they do not, flag and ask: normalize, reject, or use as-is with documentation. Default to flag-and-ask.

Deliverable-timing escalation (by-deliverable only):

• Single-period PoP (e.g., 18-month feasibility study): age wages once to contract start; hold flat across deliverables. No escalation between CLINs.
• Multi-year milestone structures (e.g., 3-year OT with annual milestones): age wages to contract start, then escalate each deliverable to its midpoint date. Rationale: midpoint tracks burn-weighted cost better than start or completion date.

Partial-year proration:

prorated_hours = productive_hours * (months_in_period / 12)
prorated_travel = annual_travel * (months_in_period / 12)

Escalation across option years (Structure A): year_N_cost = base_year_cost * (1 + escalation_rate) ^ N

Scenario math: Calculate three scenarios using low/mid/high wrap rate components:

low_burdened  = direct_rate * (1+fringe_low) * (1+oh_low) * (1+ga_low) * (1+profit_low)
mid_burdened  = direct_rate * (1+fringe_mid) * (1+oh_mid) * (1+ga_mid) * (1+profit_mid)
high_burdened = direct_rate * (1+fringe_high) * (1+oh_high) * (1+ga_high) * (1+profit_high)

Travel is identical across scenarios (per diem is a published rate, not affected by wrap rates).

Step 8: Produce the FFP IGCE Workbook

Generate a multi-sheet .xlsx workbook using openpyxl. Use Excel formulas for all calculations. Run the recalc script (python /mnt/skills/public/xlsx/scripts/recalc.py <file>) before presenting.

Workbook structure (7 sheets):

Sheet 1: IGCE Summary. Labor categories as rows, periods as columns (Structure A) OR deliverables as columns (Structure B). Rate/Hr shows fully burdened FFP rate. Extra column for implied multiplier. Travel rows below labor. Placeholder rows for Airfare, Ground Transportation, ODCs with 0 value and "TBD" in an adjacent note column - NEVER put "TBD" text in cells that feed into SUM formulas (breaks the grand total with #VALUE!). Grand total with SUM formulas.

When travel is not required: still include a single Travel row on Sheet 1 with value 0 and "Not Applicable" in the adjacent note column (so the grand total formula stays stable and a reviewer sees travel was actively excluded, not forgotten). Sheet 5 gets the full "Travel Not Applicable" block per Step 8 Sheet 5 layout.

Assumption cell layout (Sheet 1, rows 1-11):

A1:  "IGCE Assumptions (FFP)"        (bold, merged A1:B1)
A2:  "Fringe Rate"                   B2: 0.32      (blue font, percentage)
A3:  "Overhead Rate"                 B3: 0.80      (blue font, percentage)
A4:  "G&A Rate"                      B4: 0.12      (blue font, percentage)
A5:  "Profit Rate"                   B5: 0.10      (blue font, percentage)
A6:  "Escalation Rate/Yr"            B6: 0.025     (blue font, percentage)
A7:  "Productive Hours/Year"         B7: 1880      (blue font)
A8:  "Base Year Months (or PoP Months)" B8: 12       (blue font; for single-period PoPs like an 18-month study, relabel "Period Months" and set to total PoP length, e.g. 18)
A9:  "BLS Vintage"                    B9: =DATE(2024,5,1)    (blue font, real date)
A10: "Contract Start"                 B10: =DATE(2026,10,1)   (blue font, real date, user-editable)
A11: "Months Gap"                     B11: =DATEDIF(B9,B10,"m")
A12: "Aging Factor"                   B12: =(1+B6)^(B11/12)   (formula)
A13: (blank row separator)
A14: header row for data table

All labor formulas reference these cells, including the aging factor. If the user changes escalation rate, contract start, or BLS vintage, the entire workbook recalculates correctly.

Sheet 2: Cost Buildup. One block per labor category. Block spacing is 19 rows (18 rows of content + 1 blank separator). First block starts at row 1; block N starts at row 1 + (N-1) * 19. FBR is at row(N) + 17 = 18 + (N-1) * 19. Implied multiplier at row(N) + 18 = 19 + (N-1) * 19.

All `$B$N` references below are literal Excel cell addresses with integer row numbers. Copy them verbatim into workbook formulas. Each row number refers to a specific row in the Sheet 1 assumption block (see Step 8 Assumption cell layout).

*The block-1 formulas shown below are templates for `block N` at `base_row = 1 + (N-1) 19.** For block 2 (starts at row 20), replace B2 with B21, B5 with B24, B12 with B31, etc. Add (N-1) * 19 to every in-block row index. Cross-sheet references to IGCE Summary!$B$N` do NOT get shifted; they always point to the Summary assumption block. Worked example for block 2:

• Row 21: B=[annual median from BLS] (was row 2 for block 1)
• Row 24: B==B23*B22 (was B==B5*B4 - wait that's wrong; re-derive cleanly)

Cleaner: think of it as formula relative to base_row. Block 1 base = 0; block 2 base = 19; block 3 base = 38. Every B{n} in the template becomes B{n + base}. Only in-block references shift; IGCE Summary!$B$N cross-sheet refs stay fixed.

Per-block layout (first block, rows 1-19):

Row 1:  "Cost Buildup: [Labor Category]"                     (bold header)
Row 2:  A="BLS Base Wage (Annual, raw)"  B=[annual median from BLS]
Row 3:  A="Aging Factor"                 B=='IGCE Summary'!$B$12  (formula ref)
Row 4:  A="Aged Annual Wage"             B==B2*B3                  (formula)
Row 5:  A="Direct Labor Rate (Hourly)"   B==B4/2080                (formula)
Row 6:  (blank separator)
Row 7:  A="Fringe Rate"                  B==IGCE Summary'!$B$2     (formula ref, blue font)
Row 8:  A="Fringe Amount"                B==B5*B7                  (formula)
Row 9:  A="Labor + Fringe"               B==B5+B8                  (formula)
Row 10: A="Overhead Rate"                B==IGCE Summary'!$B$3     (formula ref, blue font)
Row 11: A="Overhead Amount"              B==B9*B10                 (formula)
Row 12: A="Subtotal (Labor+Fringe+OH)"   B==B9+B11                 (formula)
Row 13: A="G&A Rate"                     B==IGCE Summary'!$B$4     (formula ref, blue font)
Row 14: A="G&A Amount"                   B==B12*B13                (formula)
Row 15: A="Total Cost"                   B==B12+B14                (formula)
Row 16: A="Profit Rate"                  B==IGCE Summary'!$B$5     (formula ref, blue font)
Row 17: A="Profit Amount"                B==B15*B16                (formula)
Row 18: A="Fully Burdened Rate"          B==B15+B17                (formula, bold)
Row 19: A="Implied Multiplier"           B==B18/B5                 (formula, 0.00"x")

Cross-sheet references from Sheet 1 point to the FBR row: ='Cost Buildup'!$B$X where X = 18 + (labor_category_index - 1) * 19.

The Aged Annual Wage gets its own row so the aging math is visible on the sheet; a reviewer can see BLS Base and Aged side by side. Sheet 2 blocks compute hourly rates. Sheet 1 Summary multiplies by productive hours × FTE × period duration for annual figures. Formula: Sheet 1 annual = 'Cost Buildup'!FBR_cell * $B$7 * FTE * ($B$8/12).

Cell format conventions:

• Blue font (RGB 0,0,255): hardcoded inputs (BLS raw wage in row 2; assumption cells B2:B10 on Sheet 1)
• Black font: all formula cells and formula-referenced cells
• Annotation text: cells containing source notes (e.g., "Source: BLS OEWS May 2024") MUST NOT start with =, +, -, or @. Excel interprets those as formula triggers. Lead with a space or prefix with Source:.

Sheet 3: Scenario Analysis. Three columns (low/mid/high), each using its own fringe/overhead/G&A/profit rates. Display component rates at top of each column. Travel identical across scenarios. Summary row: "Range: $X (low) to $Y (high), Mid estimate: $Z." Note that scenarios do NOT respect Sheet 1's Base Year Months proration (B8) - scenarios always use full-year hours. Document this in Methodology to prevent a reviewer surprise.

Sheet 4: Rate Validation. BLS burdened rate (mid scenario) vs. CALC+ P25/P50/P75, min/max range, divergence percentage (formula), Status column. Use the calibrated flag thresholds from Step 4:

=IF(divergence_pct>0.70,"Position outside +70% band; document in Methodology",
  IF(divergence_pct<-0.25,"Below P25 - review under-pricing",
    IF(divergence_pct>0.40,"Metro geographic premium - document in methodology",
      IF(divergence_pct>0.15,"FFP risk premium - within expected 15-40% band",
        "Competitive"))))

Sheet 5: Travel Detail. Formula-driven per-destination block. For M destinations, block N starts at row 1 + (N-1) * 17 with a 16-row content layout and 1-row separator. In-block row indices shift by (N-1) * 17 the same way Sheet 2 blocks shift by 19. Sheet 1 Summary travel rows sum across all destination blocks:

Annual travel (Sheet 1) = SUM across destinations of (block_N_row_14 * block_N_row_12 * block_N_row_13)
                        = SUM('Travel Detail'!$B$14, 'Travel Detail'!$B$31, 'Travel Detail'!$B$48, ...)

If no travel is required, Sheet 5 contains a single "Travel - Not Applicable" declaration and note:

Row 1: "Travel Detail: Not Applicable"
Row 3: "No travel required per PWS/SOW. Placeholder retained for contract file completeness."
Row 4: "If travel scope is added via modification, populate this sheet with destination, nights,"
Row 5: "trips/year, travelers, and the Summary travel rows will pull through automatically."

When travel IS required, use the full per-destination block:

Row 3:  A="Fiscal Year"           B=<current federal FY>          (blue font)
Row 4:  A="Nightly Lodging Rate"  B=[max monthly]                 (blue font)
Row 5:  A="M&IE Daily Rate"       B=[rate]                        (blue font)
Row 6:  A="First/Last Day M&IE"   B==B5*0.75                      (formula)
Row 7:  A="Nights per Trip"       B=[nights, 0 for day trip]       (blue font)
Row 8:  A="Travel Days"           B==IF(B7=0,1,B7+1)              (formula)
Row 9:  A="Lodging per Trip"      B==B4*B7                        (formula, 0 when nights=0)
Row 10: A="M&IE per Trip"         B==IF(B7=0,B6,B5*MAX(0,B8-2)+B6*2)  (formula)
Row 11: A="Trip Total"            B==B9+B10                       (formula)
Row 12: A="Trips per Year"        B=[trips]                       (blue font)
Row 13: A="Travelers"             B=[count]                       (blue font)
Row 14: A="Annual Travel Cost"    B==B11*B12*B13                  (formula, bold)

Day-trip branch required. Without the IF(B7=0,...) branches on rows 8 and 10, a day trip (Nights=0) produces 150% M&IE instead of the correct 75% single-partial-day per FTR 301-11.101. This is a silent wrong-answer bug at the workbook level; do not skip the IF branches even if all planned trips are overnight.

M&IE double-discount trap. The MCP mcp__gsa-perdiem__get_mie_breakdown returns mie_first_last_day already discounted to 75%. Use that value directly. Do NOT multiply by 0.75 again or you ship 25% low M&IE on day trips. Formula on MCP output: mie_per_trip = mie_first_last_day for 0-night trips.

Sheet 6: Methodology. FFP-specific narrative for the contract file. Target length: 8-12 sections, 2-4 sentences each, readable in 3 minutes. Longer than 14 sections usually means restating data that already lives in Sheet 1-4.

Formula-reference rule (mandatory). Any derived numeric figure in the Methodology prose (implied multiplier, aging factor, months gap, fully burdened rate, total hours) MUST be a cell reference, not a hardcoded string. Use =TEXT(Sheet1!B12,"0.0000") for the aging factor, =TEXT('Cost Buildup'!$B$19,"0.00""x""") for implied multiplier, etc. If you hardcode "1.0615" or "2.47x" as text and the user later changes B6 (escalation) or B10 (contract start) or any wrap rate cell, the Methodology goes silently stale while the workbook numbers update. This is a workbook-consistency trap; no exceptions.

Include:

• Wrap rate buildup with each cost pool explained
• FAR 15.404-1(a), 15.404-4, 16.202 citations
• Implied multiplier basis (note: 2.93x at defaults, within 2.2-3.5x sanity band for commercial-item CONUS)
• Note that FFP rates exceed T&M because contractor absorbs cost risk
• Data sources with dates
• Aging methodology (use =TEXT(Sheet1!B12,"0.0000") formula references so numeric values update when inputs change, not hardcoded strings)
• Escalation basis
• Travel methodology
• Seniority percentile convention (if applied) with disclosure
• SOC mapping decisions (e.g., "Systems Engineer mapped to 17-2199 Engineers All Other vs. 15-1211 because this is reactor engineering, not IT")
• Multi-location weighting choice (A/B/C) with rationale
• Shift-coverage FTE derivation (if 24x7)
• CALC+ query mode used (exact-match vs keyword) with contamination caveat if keyword mode
• Rate validation interpretation (FFP premium expected, not outlier)
• Exclusions (airfare TBD, ODCs TBD, subs not included, OCONUS not covered)
• NAICS/PSC if provided

Sheet 7: Raw Data. All MCP tool call parameters and responses. If the MCP does not surface the full 25-char BLS series ID in its response, record the series-ID equivalent: MSA code + SOC + datatypes queried + year parameter. A reviewer should be able to reproduce the BLS query from what is recorded. Also record: CALC+ keywords and exact-match buckets with record counts, per diem city/state/FY/month parameters, and City Pair fares if retrieved. Record summary tables (count, percentiles, series IDs, query parameters) — NOT raw JSON dumps. A reviewer should reproduce the query from the parameters, not wade through 50KB of aggregation buckets.

Sheet 1 Summary column presentation:

Drop the "Implied Multiplier" column from the Summary if all labor categories use the same wrap rates (all rows will show identical 2.93x, which looks like a copy-paste error to a reviewer). Retain the implied multiplier on Sheet 2 per-block and on Sheet 3 per-scenario. If retained on Summary, add a note: "Identical across rows because wrap rates are uniform; varies by scenario - see Scenario Analysis."

Formatting standards:

• Blue font (RGB 0,0,255) for all user-adjustable inputs and assumptions
• Black font for all formula cells
• Currency: $#,##0 with negatives in parentheses
• Percentage: 0.0%
• Bold headers with light gray fill
• Freeze panes below assumptions block on Sheet 1 (below row 13)
• Auto-size column widths
• Burden/multiplier display format: 0.00"x"

When base year is partial, prorate: `=burdened_rate$B$7(B8/12)*h