Taskings, the TPFDD, and Shortfalls
A tasking arrives as a line of structured data that says who is needed, where, and by when. Reading that line correctly is most of the work, and knowing what to do when the squadron cannot fill it is the rest.
01How taskings arrive
Requirements start with a commander who needs a capability, get built into a plan, and eventually reach a squadron as a request for specific people. How much warning comes with that depends on which path the requirement took.
Planned and unplanned
Contingency planning happens in advance. Commands define the situations they consider most likely, identify what forces those situations would need, and build the requirements ahead of time so a response can move quickly. Crisis action planning happens when something actually occurs, and it compresses the same work into far less time.
A UDM feels the difference as lead time. A requirement that came out of deliberate planning may arrive with months of visibility. One that came out of a crisis can arrive with weeks or less, against a squadron whose readiness picture is whatever it happened to be that morning. The tracking work in Module 03 exists mostly to make the second case survivable.
Rotational and everything else
Rotational taskings follow the force generation cycle and are the most predictable thing a squadron sees. They align to the phases, they come with reasonable notice, and they are the taskings a squadron can genuinely plan around.
Outside that, requirements can arrive off cycle. Sourcing an off cycle requirement usually means a waiver of some kind, because it is asking a unit to provide capability during a phase where it was not expected to. Those come with their own approval path, and the Installation Deployment Readiness Cell (IDRC) knows the current one.
Shapes contracting sees more than most
- Individual taskings. Contracting frequently sources one or two people against a requirement rather than a formed team. The sourcing conversation gets specific about names quickly, which is why the Functional Area Manager stays close to it.
- Civilian deployments. Air Force civilians deploy, and contracting uses that more than many career fields. The requirements around a civilian deployment differ from a military one in enough places that it is worth asking the readiness cell early rather than assuming the process matches.
- Extended individual taskings. Year long individual assignments to a deployed location exist and land on contracting periodically. They carry different reporting, different preparation, and a much larger effect on a small squadron than a standard rotation does.
Force sourcing means matching real people to a requirement, and for contracting that runs through the Functional Area Manager. The requirement is visible to force providers well before a name is attached to it. A UDM with a working relationship at that level often hears what is coming before it formally arrives, which is worth more than any amount of preparation after the fact.
02Reading a tasking line
Time phased force and deployment data, universally called the TPFDD, is the structured record of what moves, when, and in what order. A combatant commander builds the movement requirements, and the result is a set of lines that force providers source against.
Contracting squadrons deploy people, so the fields below are the personnel relevant ones. A TPFDD carries a great deal of cargo and equipment detail that belongs to units that move equipment.
| Field | What it means | What you do with it |
|---|---|---|
| Identifying the requirement | ||
| ULNUnit line number | A code identifying a unique increment of a requirement. Once a person is sourced against it, this is the thread tying that person to that tasking. | Use it as the reference in every conversation about the tasking. Ambiguity about which line is being discussed causes real problems. |
| FRNForce requirement number | Identifies the capability requirement and connects it to a mission and a phase of an operation. | Tells you what larger effort the tasking belongs to, which is useful context when explaining it to a member or a commander. |
| UTCUnit type code | The capability being requested. | Tells you which skill levels and grades the line expects. Module 02 covers where to look up what a code calls for. |
| Places | ||
| Origin | Where the movement begins. | Usually home station for a contracting squadron, but confirm rather than assume. |
| POEPort of embarkation | Where the member loads for strategic movement. | Frequently not home station, which means travel before the travel. That leg needs its own arrangements and its own time. |
| PODPort of debarkation | Where the member arrives in theater. | Rarely the final stop. Onward movement is a separate matter with its own timeline. |
| Destination | Where the member is actually going. | Check this against the port of debarkation. The distance between the two surprises people who assumed arrival meant arrival. |
| GEOLOCGeographic location code | Standardized codes identifying locations rather than spelling them out. | Learn to look them up rather than memorize them. Reading a location code wrong sends preparation in the wrong direction. |
| Dates, in the order they happen | ||
| RLDReady to load date | The date the member must be prepared to depart origin. | Treat this as the real deadline and work backwards from it. Every currency, appointment, and document has to be finished before this date, not before the arrival date. |
| ALDAvailable to load date | The date the member must be ready to load at the port of embarkation. | Confirms the travel window between origin and the port. A tight gap here means the earlier leg has no slack. |
| EADEarliest arrival date | The earliest the member can be accepted at the port of debarkation. | Arriving before this is not helpful. It usually means somebody waits somewhere unpleasant. |
| LADLatest arrival date | The latest the member can be accepted and still support the concept of operations. | The date with consequences attached. Missing it means the capability is late to an operation that planned around having it. |
| RDDRequired delivery date | The date the member must arrive and complete off-loading. | Read alongside the latest arrival date. When they differ, understand why before assuming either one is the deadline. |
| How and who | ||
| Mode and source | How the member travels and who provides the transportation. | Drives what travel arrangements are needed and who arranges them. Answers come from the readiness cell rather than from the line itself. |
| Sourcing | Which organization is providing the capability against the requirement. | Confirms whether the line is actually the squadron's to fill before work starts on it. |
| Line remarks | Requirements attached to this specific tasking rather than to the capability in general. | Read these first. Section 04 covers why. |
Actual tasking data commonly sits on the classified network, and the detail attached to a real operation can carry a classification well above anything discussed here. This table explains what the fields mean, not what any particular line says.
There is a personnel search capability on the classified side that is worth knowing about, and the readiness cell can point to what a UDM should have access to and how to get it. Sorting out clearance and classified network access at appointment rather than when a tasking lands is the practical version of this advice.
03Deployment eligibility
A name on the roster and a person who can actually deploy are two different things, and the gap between them is where most tasking work happens.
Module 03 covers deployment availability codes as something a UDM tracks on a rhythm. Against a live tasking they do something more specific: they determine whether a member can be offered at all. A code that is current and correct removes a member from consideration cleanly. A code that is stale creates either a false gap or a false offer, and both cost time at the point where there is least of it.
Waivers
Some conditions that block deployment can be waived, and the authority to grant a waiver sits at different levels depending on what is being waived. Medical waivers, availability waivers, and requirement waivers all follow different paths.
What matters at squadron level is recognizing when a waiver is the right question to ask, and asking it early. A waiver request that starts three weeks before a ready to load date is a different conversation than one that starts the day the tasking arrives.
When a tasking arrives, the useful first pass is not who is available on paper but who is available and would still be available on the ready to load date. Currencies that expire in the window, appointments already scheduled, and members mid permanent change of station all look fine today and do not survive contact with the actual date.
04Line remarks
A unit type code describes a capability in general. A specific tasking often needs something beyond that, and those additions travel with the line rather than with the code. Component requirement codes and line remarks are where they appear.
What shows up there varies: additional training, a specific certification, a clearance level, theater specific requirements, equipment the member has to bring, or a qualification the baseline capability never assumed. A member who is a clean match against the code can still fail against the remarks.
Read the remarks before picking a name
Line remarks drive lead time more than any other part of a tasking. A requirement for training the squadron cannot deliver locally, or a certification with a scheduling queue in front of it, can turn a comfortable timeline into an impossible one.
Finding that on day one leaves room to request a seat, ask for a waiver, or raise a shortfall while all three are still options. Finding it three weeks out usually leaves one option, and it is the least pleasant of them.
Remarks can also be ambiguous, abbreviated, or written for a reader who already knows the context. Asking the readiness cell what a remark means is a normal question rather than a sign of inexperience, and it is considerably better than guessing and preparing the wrong thing.
05When you cannot fill it
Sometimes the squadron cannot fill a tasking. The people who match the requirement are not available, not qualified, not eligible, or not there. This is a normal outcome of a real force management system, and there is a process for it.
Shortfalls and reclamas
A shortfall is a formal statement that a sourced requirement cannot be met. A reclama is a formal challenge to a sourcing decision, used when a unit believes the tasking was misassigned or the unit was inadequately resourced to meet it. Both move through command channels rather than being settled locally, and both are legitimate tools rather than admissions of failure.
Operational impact statements
An unfilled requirement raises an obvious question: what happens to the mission as a result. An operational impact statement answers it. The value of writing one honestly is that it converts a squadron level manning problem into information a planner can act on, whether by sourcing elsewhere, adjusting the timeline, or accepting the risk with open eyes.
Speed matters more than polish
A shortfall raised early gives the sourcing process room to work. Another unit can be found, a date can move, a requirement can be adjusted. A shortfall raised late removes all of those options and leaves the operation absorbing the gap.
The worst version is the shortfall that never gets raised, where a squadron sends somebody who does not meet the requirement and hopes it works out. The gap does not disappear. It relocates to a deployed location where the member carries it alone and nobody expected it.
This is where the honesty argument from Module 03 stops being abstract. A squadron that has been reporting its readiness accurately can raise a shortfall and be believed. A squadron that has been reporting green and suddenly cannot fill a tasking has a harder conversation, because the shortfall contradicts the record.
06Working the problem
Taskings are the area where both external relationships matter at once. The installation runs the process. The career field owns the sourcing. A UDM works both, and neither one covers the other's ground.
- A fast, accurate answer on who can fill a line, checked against the ready to load date rather than against today.
- Line remarks read on day one, with any long lead requirement flagged immediately.
- A shortfall raised as soon as it is real, with an honest account of the operational impact.
- Squadron context nobody else has: who is already committed, who is mid transition, what the squadron is carrying that does not show in a system.
- The tasking flow into the installation and the timeline attached to it.
- Access to tasking data and interpretation of fields and remarks.
- The current shortfall and waiver processes, including which authority approves what.
- Travel, movement, and processing arrangements once a name is committed.
- Sourcing contracting requirements across the enterprise, including whether a line should have come to this squadron.
- Early visibility on what is coming for contracting, often before it reaches an installation.
- Career field judgment on whether a shortfall is a squadron problem or an enterprise one.
- The path for reclamas that turn on career field manning rather than local circumstances.