Unit Type Codes and Force Packages
A unit type code is how the Air Force turns "we need contracting support at this location" into a specific set of people with specific skills. Understanding what sits inside one explains most of why readiness reporting works the way it does, and why a name in a slot carries more weight than it looks like it does.
01What a unit type code is
A unit type code (UTC) is a capability, packaged so that a planner somewhere can request it without knowing anything about the squadron that will fill it. Each one carries a unique five character alphanumeric identifier, and the guidance describes them as rightsized, modular, and scalable, deliberately not tied to a specific theater or a specific unit.
That last part is the useful bit. A planner building a requirement for an operation does not ask for people from a named squadron. They ask for a capability by its code, and the sourcing process works out which unit provides it. A UDM sits on the receiving end of that process.
A unit type code describes what a capability can do, not who is currently filling it. The squadron supplies the names. The code makes a promise about what those names can accomplish, which is where a UDM's readiness tracking starts to matter.
02The three parts
Every unit type code is built from three elements. A UDM works directly with one of them, indirectly with the second, and rarely with the third.
Plain language description of what the capability does, its basic mission, where it typically operates, and which other unit type codes travel with it. This is the promise being made to the commander who requested the capability. It is also the one element that can carry a classification, up to and including SECRET, which is a good indicator of how seriously the content is treated.
The people. Lists the minimum personnel needed to deliver the capability, broken out by Air Force specialty code, grade, and quantity. Planning assumes a bare base operation lasting about thirty days. When a squadron fills a tasking, this is the list the names have to satisfy, and a slot calling for a particular skill level means a person who can perform at that level.
The equipment that travels with the capability, sized to sustain operations for roughly thirty days without resupply. Contracting deploys people rather than equipment packages, so this element is mostly somebody else's work. Knowing it exists is enough for most contracting squadron UDMs.
The manpower element is where a UDM spends real time. A tasking that calls for a five level is asking for someone who performs five level work, and the squadron's answer to that is a name. Module 03 picks up what that name is actually promising.
03Standard, non-standard, and who owns the code
Standard and non-standard
Standard unit type codes define full mission capabilities and are the ones that actually move forces. Non-standard codes exist for a different reason: they let readiness reporting systems categorize units by type without implying any transportation requirement. A non-standard code is an administrative label rather than a deployable package, which is worth knowing before assuming every code on a roster represents something that deploys.
Pilot units and everyone else
Each unit type code has a pilot unit, appointed to develop and maintain it. The pilot unit writes the capability statement, builds the manpower and logistics detail, and reviews the whole thing at least every two years. Most squadrons are not pilot units for the codes they fill.
A non-pilot unit still has a voice. When the pilot unit proposes a change, other units are given the chance to comment, with a response window measured in weeks. That is the moment when a squadron can say that a code no longer reflects what the capability actually needs, and it passes quietly if nobody is paying attention.
| Role | Responsibility |
|---|---|
| Pilot unit | Develops and maintains the code. Writes the capability statement, builds the manpower and equipment detail, reviews everything at least biennially. |
| Non-pilot unit | Fills the capability when tasked. Provides input on proposed changes within the response window, and maintains any equipment the logistics detail calls for. |
| Functional Area Manager | Appoints the pilot unit and coordinates code actions across the career field. Holds the contracting codes, and is a direct contact for a contracting squadron UDM. |
| Major command | Acts as the single point of contact for code actions within the command and coordinates with other commands. |
| Air Force level | Approves codes and publishes them, after which they become available for planners to task against. |
Once approved and published, a code becomes available in the systems planners build requirements from, and units get assigned to provide and maintain that capability. A squadron finding itself tasked against a code it does not recognize is a reasonable thing to raise with the readiness cell and the Functional Area Manager.
04Where contracting fits
Contracting is a small career field that supports operations run by much larger ones. That shapes how contracting forces move in ways worth understanding early.
Small packages and individuals
Where a larger career field may deploy a formed team that trains together, contracting frequently sources individuals and small teams against requirements at scattered locations. The practical effect on a UDM is that taskings tend to arrive naming small numbers of specific skill levels rather than whole capability packages, and the sourcing conversation with the Functional Area Manager gets specific about people faster.
Ways contracting support gets employed
- Demand force teams. Capability sourced against emerging demand rather than a standing rotation. Contracting shows up in this category more than most career fields, because contracting support is often needed early and in small amounts.
- Employed in place. Capability delivered without the member physically deploying. Contracting can support a forward operation from a home station, which means readiness obligations exist even where a member never leaves.
- Reserve component. Guard and Reserve contracting units fill taskings alongside active duty. A UDM at a unit that works with reserve component members has an extra set of readiness rules to coordinate through the readiness cell.
- Civilian deployments and extended taskings. Contracting deploys civilians and takes long duration individual taskings more often than many career fields. Module 04 covers how those arrive.
The contracting family of codes
Contingency contracting capability is packaged under a family of unit type codes that share a common prefix. These show up on tasking lines and on the list of codes a squadron is postured against, and members are usually aligned to one when they arrive at a duty station.
Highlighted codes are the ones contracting squadrons are asked for most often.
Recognizing them by sight is the point of listing them. A tasking line reading XFFK7 should register as a contracting requirement rather than an unfamiliar string, and knowing which code a member is aligned to makes the rest of the readiness conversation concrete. Codes get added, revised, and retired over time, so treat this as orientation and confirm the current set against the squadron's own record.
What a code calls for, and where that lives
Each code carries its own requirements for skill level, grade, and certification. Those are worth reading from the current record rather than carrying in your head, because they change and because the consequences of guessing land on a member at the worst possible moment. Three places hold different pieces of the answer.
- The mission capability statement describes what the capability does and where it operates. This is the narrative, not the roster.
- The manpower force element is the authoritative list of positions: Air Force specialty code, grade, and quantity. This is the part that answers whether a slot calls for a five level or a seven level.
- Line remarks on the tasking itself carry requirements attached to a specific tasking rather than to the code in general, which is where added training, certification, or equipment requirements usually appear. Module 04 covers reading those.
The capability statement and manpower element are both published as part of the force packaging record for the code, and the planning and execution system the Air Force uses for deliberate and crisis action planning is where that packaging data and the readiness reporting against it live. The Installation Deployment Readiness Cell (IDRC) gets a UDM access to that system and to the local process around it.
For the codes themselves, the contracting Functional Area Manager is the better call. That office belongs to the career field, holds contracting's unit type codes, and knows why a code says what it says. A UDM does not need the readiness cell to make that introduction, and building the relationship before a tasking arrives is worth more than building it during one.
Compositions and current posturing guidance for contracting capability are not published openly, and a capability statement can carry a classification. Listing what each code requires here would put a number in front of a reader that may already be wrong, in a place where nobody would think to check it. The codes are stable enough to learn. What sits behind them belongs to the record.
05Force packages
Capabilities do not deploy alone. They get assembled into larger packages, and contracting support usually plugs into one rather than standing up on its own. These are the constructs worth recognizing by name.
A grouping built to present a package of capability to a commander as a coherent whole rather than as separate pieces arriving from separate places. Contracting support attaches to the package rather than forming one.
A squadron sized element built around operating an airbase. Support functions, contracting among them, sit inside this kind of element rather than alongside it.
A wing sized package that deploys as a unit with its command structure intact, rather than being assembled from individuals sourced across the Air Force.
The organizational construct for a base established in an operational location. Where contracting support most visibly earns its keep, since a base being stood up needs things bought locally almost immediately.
Force elements
Underneath the packages sits a set of functional groupings describing what a force is doing at a given stage of an operation. These come up in briefings and planning documents, and name recognition is enough for a contracting squadron UDM.
Contracting support tends to show up early, because opening and establishing a location involves buying things before the supply chain has caught up.
06AFFORGEN in one page
Air Force Force Generation is the model that decides when a unit is preparing, when it is available to be tasked, and when it is resetting. Units cycle through phases, and where a squadron sits in that cycle drives what a UDM is focused on at any given moment: rebuilding readiness during a preparation phase, watching the tasking flow during an available phase, and closing out records and recovering people during reset.
Phase names, durations, and the mechanics underneath them have changed more than once and will change again. Anything written here about the specifics would be stale before it was useful, so this page stops at the shape of the idea. For where the squadron currently sits in the cycle and what that means for the next few months, the Installation Deployment Readiness Cell has the current answer.
The part that stays true regardless of what the phases are called: readiness is built during the quiet part of the cycle, and a squadron that treats the preparation phase as downtime discovers the gap during the part where there is no time left to fix it.
07Working with the IDRC
Unit type codes are one of the areas where a UDM genuinely cannot self serve. The current codes, the current posturing guidance, and the current phase of the cycle all live with people whose job is to know them. Two of those people sit in different places, and a UDM works with both.
- An honest read on whether the squadron can actually fill the positions its codes call for, by skill level rather than by headcount.
- Notice when the manpower reality drifts from what a code assumes, well before a tasking arrives against it.
- Squadron input when a pilot unit proposes a change to a code the squadron fills, inside the response window rather than after it closes.
- Questions about codes the squadron does not recognize, raised early rather than absorbed quietly.
- What the squadron is currently postured against at this installation, and how that shows up in local reporting.
- Where the installation and the squadron sit in the force generation cycle right now.
- Interpretation when published guidance and local practice appear to disagree.
- Access to the planning systems and the local process wrapped around them.
- Contracting's unit type codes, including why a code is written the way it is.
- Sourcing decisions that match contracting requirements to contracting people across the enterprise.
- Career field specific answers the installation cannot give, since the readiness cell supports every squadron on base rather than this one.
- Visibility on what is coming for contracting specifically, which is often earlier than what reaches a squadron through the installation.