Explainer

What Is a Technical Data Package?

A technical data package (TDP) is the authoritative technical definition of an item: everything needed to build it, inspect it, and support it, delivered as data. Here is what goes in one, how its levels and types work, and where technical manuals fit.

The Definition

The Item, Defined Completely

A technical data package is the authoritative technical definition of an item, supporting its acquisition, production, inspection, engineering, and logistics support. In U.S. defense contracting, how a TDP is structured and delivered is set by MIL-STD-31000, currently at Revision C (3 February 2025).

The point of the package is independence from whoever designed the item. A complete one lets a program compete production, qualify a second source, or support the item for decades after the original engineering team has moved on. An incomplete one is found out at exactly those moments, which is why the level and contents a contract orders matter far more than they look on the paperwork.

Contents

What Goes in a TDP

MIL-STD-31000 calls the contents elements. A contract picks the ones it needs from this list:

Engineering design data: The drawings or models that define the item, with their associated lists: the core of every package.
Specifications: Performance, material, and process specifications the design depends on.
Software documentation: For items whose function depends on software or firmware.
Special packaging instructions: How the item must be preserved, packed, and marked.
Quality assurance provisions: The inspections and tests that prove a built item matches its definition.
Additive manufacturing data and manufacturing process descriptions: Added in Revision C (2025): the data file for additively manufactured parts, and required manufacturing process descriptions.

Like any defense technical document, the drawings and models in a package carry distribution statements that decide who may receive them.

Levels

Conceptual, Developmental, Product

Levels describe how mature the design definition is. MIL-STD-31000 has three: conceptual, developmental, and product, the full definition an item is produced and supported against. Revision B (2018) renamed the last level from production to product, so older contracts still say production level. Commercial engineering design data is a separate option, not a fourth level.

You will also meet Level 1, Level 2, and Level 3, especially on older drawings and in supplier conversations. Those are the drawing levels of DOD-D-1000B, “Drawings, Engineering and Associated Lists”: Level 1 for conceptual and developmental design, Level 2 for production prototypes and limited production, and Level 3 for production. DOD-D-1000B was closed to new programs after 1 July 1990 and superseded by MIL-DTL-31000, the predecessor of today's standard. The idea survives, a progression from concept to a package a competent manufacturer can build from, but the names do not map one to one. When a contract or a drawing note says Level 2 or Level 3, read it against the document it actually cites.

Types

Drawings or Models

Types describe form. A Type 2D package is built on drawings, following the ASME Y14.100 series. A Type 3D package is built on native 3D models, with derived 2D drawings, 3D viewables, or neutral files as the contract requires. Derived data must never conflict with the master model, and at the product level the models must be complete, fully annotated design disclosure models.

Type 3D is where the Department's digital engineering push meets the package, and where the model becomes the source of truth for everything downstream of it, manuals included. Our piece on model-based technical data follows that thread.

The Contract

Same Standard, Different Packages

MIL-STD-31000 is a standard practice: it defines how a package is structured and delivered, while the contract decides what is in it. The tool for that is the TDP Option Selection Worksheet, which sets the level, the type and formats, the elements, associated lists, data management products, and metadata. When the worksheet forms part of a contract, the standard makes it mandatory.

The consequence is that two programs citing the same revision can owe very different packages. A worksheet settled late, after the work is priced, tends to become a dispute over what was owed. Who gets to use the data afterward is a separate question, settled by technical data rights, and a live one: see our briefing on right to repair and technical data.

Technical Manuals

Upstream of Every Manual

Technical manuals are not part of a TDP. Revision C states that technical, procedural, and maintenance manuals shall not be referenced in a TDP element, and that anything essential in them must be carried in the package itself. Manuals are separate deliverables, written from the package's engineering data against their own standards, such as MIL-STD-40051 for the Army.

That makes TDP completeness a publications problem too. When the package is missing a view, a part number, or a current revision, the gap surfaces in the manual: a procedure nobody can illustrate, a part nobody can identify. If your program needs to know what it holds and what it was owed, our technical data audit checklist is the place to start, and the MIL-STD-31000 reference page covers the standard's revisions, designations, and where to get it.