Home / Aerospace and defense program execution / Aerospace and defense project closeout
The technical data package is the program's permanent record of what was built. It is often the last major deliverable, and it is where every shortcut taken during development comes due. Delivering one that is complete, consistent and correctly marked is one of the clearest signs of a program that finished well.
What goes into a TDP
The exact content is set by the contract, but most defense TDPs draw on the same elements.
| Element | What it contains | What usually goes wrong |
|---|---|---|
| Product definition | Engineering drawings or 3D models with product manufacturing information, and associated lists | Approved changes never incorporated; drawings and models that disagree |
| Specifications | Performance, material and process specifications the product depends on | Referenced revisions superseded or unavailable to the customer |
| Parts and bills of material | The structure of the product down to purchased parts | Structure out of step with the as-built configuration |
| Quality assurance provisions | Inspection and test requirements needed to accept the item | Requirements that live only in internal work instructions |
| Packaging and marking | Preservation, packaging and identification requirements | Left until the end and written in a hurry |
| Data rights markings | Legends on each item stating the government's license rights | Markings inconsistent with the contract or the assertions made |
Why TDPs stall
The design moved and the documents did not. Changes approved late in development, or made on the shop floor to get hardware out the door, are the largest single source of TDP rework. The package has to match the approved product baseline, which is why it depends on configuration management being closed first.
Supplier data is missing. When the contract requires data for supplier designed items, that data has to be obtained, reviewed and delivered too. If the requirement was never flowed down in the purchase orders, closeout is the moment the gap appears.
The format is not what the contract asked for. Native model versus neutral format, drawing standards, file naming, metadata and delivery media all come from the data requirements. A technically complete package in the wrong form still gets rejected.
Markings were an afterthought. Data rights legends need to be applied deliberately, item by item, against the contract and the rights the company asserted. Getting them wrong can give away proprietary rights or invite a challenge, and both are far harder to undo than to prevent.
How to deliver it cleanly
Read the data requirements early. The contract data requirements list and its data item descriptions define the target. Build a checklist from them at the start of closeout, not at submission.
Reconcile against the product baseline. Walk the drawing tree against the approved configuration and the as-built records, and resolve every discrepancy before anything is packaged.
Collect supplier data in parallel. Supplier deliverables usually take the longest. Start them first and track them like any other critical path item.
Review markings with contracts. Have the contracts team and engineering agree the marking for each item before it is applied, with the asserted rights in front of them.
Do a customer style review first. An internal review that checks the package the way the customer will check it catches most rejections while they are still cheap to fix.
Drawings, models and model based definition
More programs now define parts in annotated 3D models rather than 2D drawings, with the dimensions, tolerances and notes carried in the model itself. This is often called model based definition. It can remove a whole class of errors, because there is no longer a drawing that can drift out of step with the model. It also changes what the customer needs to receive: the right native or neutral model formats, the product manufacturing information intact, and viewers or derivatives the customer can actually open. When a contract asks for a model based package, confirm early that every supplier and every downstream user can work with it, because discovering a format gap at delivery can force a late conversion that introduces the very errors the approach was meant to avoid.
What are the main categories of data rights?
| Category | What it generally means for the government | Typical basis |
|---|---|---|
| Unlimited rights | May use and disclose the data for any purpose | Developed exclusively with government funding |
| Government purpose rights | May use within the government and share for government purposes, for a period | Developed with mixed government and private funding |
| Limited rights (technical data) | Use within the government with tight restrictions on disclosure | Developed exclusively at private expense |
| Restricted rights (software) | Use on a limited number of computers with restrictions on copying and disclosure | Software developed exclusively at private expense |
| Specifically negotiated rights | Whatever the parties agree in the contract | Negotiated license |
The governing clauses are in the DFARS, and the details, including assertion requirements and marking formats, matter. This summary is a general orientation; confirm specific rights and markings with the contracts team or counsel, because mistakes are costly in both directions.
How do CDRLs and data item descriptions shape the package?
The contract data requirements list names each data deliverable, its due date, format, distribution and approval process. Each entry points to a data item description that defines the required content. Together they are the specification for the technical data package. Reading them line by line at the start of closeout, and building a checklist from them, is the most effective way to avoid rejection.
What delivery formats are common?
Requirements vary by contract, but packages commonly include drawings as PDF or other viewable formats, native CAD models where the contract requires them, and neutral 3D formats such as STEP so that the customer can open the models without the original CAD system. Parts lists and metadata often travel as structured files. Confirming early which formats the customer can actually use prevents late conversions, which are a common source of errors.
How should a package be checked before submission?
The way the customer will check it. Walk the data requirements line by line and confirm each item is present, in the required format, at the correct revision, with the correct markings. Open every file the way the customer will open it, especially models in neutral formats. Confirm that drawing revisions match the approved product baseline and the as-built records. A short internal review run this way catches most rejection causes while they are still cheap to fix.
Which TDP type does a contract call for?
The one the contract selects, and the choice sets how much detail the package has to carry. MIL-STD-31000 defines several technical data package types, each meant for a different stage of a product's life, and an acquiring activity tailors the package by choosing a type and its elements on the standard's option selection worksheet. Knowing which type was ordered is the first thing to check at closeout, because a package built to the wrong level is rejected however good it is.
| TDP type | What it is for | Level of detail expected |
|---|---|---|
| Conceptual design | Describing a design concept so it can be evaluated | Enough to show the concept and its intended performance |
| Developmental design | Supporting the build and test of prototypes and development units | Enough to make and test development hardware, not yet a production baseline |
| Product design | Allowing a qualified manufacturer to produce the item and the customer to accept it | Complete definition of the production configuration, with the lists, specifications and quality assurance provisions that go with it |
| Commercial | Describing items developed at private expense and sold commercially | Typically less than a product design package, often enough for identification, installation and support |
Most closeout trouble sits with the product design type. It is the package a government buyer may later use to compete or reprocure the item, so it is held to the highest standard, and it is where the gap between the approved design and the hardware actually built gets exposed.
How are distribution statements different from data rights legends?
They answer different questions, and a single drawing often needs both, along with an export control notice. Mixing them up is one of the most common marking errors in a package.
| Marking | The question it answers | Where it comes from |
|---|---|---|
| Data rights legend | What the government is licensed to do with the data | The DFARS rights in data clauses in the contract and the restrictions the contractor asserted |
| Distribution statement | Who the data may be distributed to, from public release through tightly controlled audiences | DoD Instruction 5230.24, applied as directed by the government office that controls the data, using the lettered statements |
| Export control notice | Whether the data is subject to export control laws, such as ITAR or the EAR | The export classification of the technical data, typically confirmed by the company's export compliance function |
A legend that protects the company's rights does not limit distribution, and a distribution statement does not protect a single license right. Decide each marking separately, with the right owner for each: contracts for data rights, the customer's direction for distribution, and export compliance for export notices. Record the decision for each item so the reasoning survives when someone asks about it years later.
What should supplier purchase orders flow down?
Everything the prime will need to deliver about that supplier's item, stated before the order is placed. Supplier data that was never ordered is the hardest gap to close at the end of a program, because the leverage to get it disappeared when the last payment went out. A purchase order for a supplier designed item should normally cover:
- The data items themselves, with content, format, revision level and due dates traced to the prime contract's data requirements.
- The rights in data clauses the prime contract requires to be flowed down, and an obligation to identify and assert any restrictions before delivery rather than at it.
- Change notification, so changes to design, process, material or sub-tier source reach the prime before they reach the hardware.
- Marking instructions for distribution statements and export control notices, so supplier data arrives already marked the way the package needs it.
- Records retention, so data the customer might order later still exists when it is asked for.
When a program inherits orders that missed these, the fix belongs in supplier recovery, long before closeout.
Can the government ask for more data after closeout?
Sometimes, yes. When a contract includes the DFARS deferred ordering clause, the government can order technical data or software that was generated in performing the contract but not originally listed for delivery, for a set period after the delivered items are accepted. The contractor is compensated for converting and delivering the data, but it has to be able to produce it. The government can also challenge a restrictive marking it believes is not justified, for a period after delivery or final payment, and the contractor then has to support the marking with records showing how the item was funded and developed.
The practical lesson is that closeout does not end the data obligation. Archive the as-built configuration, the supplier data and the records behind each data rights assertion in a form someone can find later, ideally alongside the configuration management records, and keep them for as long as the contract and company policy require.
Related guides
- Configuration management through closeout
- First article inspection under AS9102
- Aerospace and defense project closeout
How Set Boundaries helps
During project closeout, Set Boundaries builds the delivery checklist from the contract, reconciles the documents against the approved configuration, chases supplier data, coordinates data rights markings with the contracts team and runs the internal review before submission. The aim is a package accepted on the first submission, so the contract can close. It pairs directly with closing out first article inspection.
If a data package is the last thing standing between a program and closeout, schedule a call.
References
- US Department of Defense, MIL-STD-31000, Technical Data Packages.
- Defense Federal Acquisition Regulation Supplement (DFARS) Part 227, Patents, Data and Copyrights, including 252.227-7013 for noncommercial technical data and 252.227-7014 for noncommercial computer software.
- DFARS 252.227-7017, identification and assertion of use, release or disclosure restrictions.
- DFARS 252.227-7027, deferred ordering of technical data or computer software.
- DFARS 252.227-7037, validation of restrictive markings on technical data.
- US Department of Defense, DoD Instruction 5230.24, Distribution Statements on DoD Technical Information.
- US Department of Defense, DD Form 1423, Contract Data Requirements List.
- US Department of State, International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120 to 130.
Questions
Common questions
What is a technical data package?
A technical data package, or TDP, is the complete set of technical information needed to define, produce, inspect and support an item: drawings and models, specifications, parts lists, quality assurance provisions, and packaging requirements. On defense contracts its content and format are defined in the contract, usually through a contract data requirements list.
Why do TDPs hold up program closeout?
Because the TDP is usually a contract deliverable, and the contract cannot close until it is accepted. Late design changes that never reached the drawings, missing supplier data, and data rights markings that do not match the contract are the most common reasons a TDP is rejected or delayed.
What standard governs a defense TDP?
Department of Defense technical data packages are commonly specified against MIL-STD-31000, which defines technical data package types and elements, including model based definition. The contract data requirements list and its data item descriptions then set the exact content, format and delivery requirements for a given program, so those documents, rather than the standard alone, are the final word on what must be delivered.
What are data rights markings?
Legends on technical data that state the government's license rights, such as unlimited, government purpose or limited rights. They must match what the contract allows and what was asserted during the procurement. Incorrect markings can give away rights the company meant to keep, or trigger a formal challenge from the government.
What are government purpose rights?
Government purpose rights generally let the government use technical data within the government and share it for government purposes, such as competitive procurement, for a set period, after which they typically convert to unlimited rights. They usually apply to data developed with mixed government and private funding. The DFARS clauses in the contract define the exact terms, so confirm them with the contracts team.
What is a CDRL?
A CDRL, or contract data requirements list, is the part of a defense contract that lists each data deliverable with its due date, format, distribution and approval process. Each item references a data item description defining the required content. For a technical data package, the CDRL and its data item descriptions are effectively the specification the delivery is judged against.
What is not included in a technical data package?
A technical data package generally excludes anything not needed to define, produce, inspect and support the item. That usually means financial and cost data, management and progress reports, internal work instructions not called out by the contract, and software source code unless separately ordered. Proprietary data may also be withheld or delivered with restrictive markings, depending on the contract's data rights. The contract's data requirements, usually a CDRL and data item description tied to MIL-STD-31000, set the actual boundary. Set Boundaries confirms that boundary early so nothing is over or under delivered at closeout.
What does TDP stand for in engineering, manufacturing and government contracting?
TDP stands for technical data package. In engineering and manufacturing, it is the technical description of an item adequate to support acquisition, production, engineering and logistics support, including drawings or 3D models, specifications, parts lists, quality assurance provisions and packaging requirements. In government contracting, the TDP is usually a contract deliverable ordered through a CDRL and prepared to MIL-STD-31000, and the government uses it to reprocure, sustain or modify the item. Set Boundaries helps contractors deliver TDPs that are complete, consistent with the as-built configuration and correctly marked.
Have a question that is not here? Ask Holly on a short call
