Nasa De Acquisition

NASA Digital Engineering Acquisition Framework Handbook (NASA-HDBK-1004)

Source: NASA, Office of the NASA Chief Engineer (US Government work, public domain) | Chapters: 8

When to use

Use this skill to specify, contract for, and control the digital data and models a program buys across the life cycle (Pre-Phase A through Phase F): writing DRDs and SOW/RFP language that force interoperable, machine-readable, neutral-format delivery; setting the right Government control level and data rights; standardizing requirement exchange and the as-delivered build record; governing model-based data definition and release; choosing interoperability standards; and developing the program's MBE Plan. This is the acquisition-and-contracting companion to the broader systems-engineering and MBSE landscape (dau-se-guidebook, nasa-npr-7123, sebok, se-standards-signpost).

Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.

How to Use This Skill

• Without arguments — load the core frameworks below: the acquisition framework and DEE, the DRD instrument and Data Type scale, the contract-language placement model, REF/MRI, model-based data definition, the four architectures, the use-case ladder, and the MBE Plan.
• With a topic — ask about a specific DRD (e.g. "TDP", "MRI", "REF"), a Data Type, data rights / Table 3 license categories, release-state mapping, an interoperability standard (STEP/MIL-STD-31000/ASME Y14), or an MBE use case.
• With a chapter — ch02 (the DRD suite + CDM), ch03 (requirements exchange + contract language), ch04 (data-acquisition contract language + rights), ch05 (model-based data definition), ch06 (collaboration/architecture/interoperability), ch08 (MBE Plan).

Supporting files: glossary.md, patterns.md, cheatsheet.md.

One handbook, two halves. The Handbook's acquisition half is the DRDs plus SOW/RFP contract language (chapters 1-4); its model-based engineering half is the data-definition, collaboration, architecture, interoperability, use-case, and planning appendices (chapters 5-8). The unifying move throughout: replace document-centric, "contractor format acceptable" delivery with model-based, neutral-format, contractually enforced data.

Core Frameworks & Mental Models

The digital engineering acquisition framework — what it is

NASA-HDBK-1004 is a guidance handbook (not a binding requirement) for buying and controlling digital data and models. It has two visible instruments — Data Requirements Descriptions (DRDs) and contract language for the Statement of Work / RFP — and one purpose: to stand up and feed a Digital Engineering Environment (DEE), the connected fabric of data, people, processes, and technology that stores, accesses, analyzes, and visualizes a system's evolving data and models. It supersedes NASA-HDBK-0008 (PDLM) and broadens coverage to all program/project data, not just technical data. The framing is mission assurance: getting the right data to the right people at the right time enables the right decision, lowers risk, and raises the probability of mission success. Five key areas execute it — model-based data definition, digital data collaboration, architecture, interoperability standards, and contractual data acquisition via DRDs.

The DRD — the contractual lever

A DRD is the atomic instrument that fully specifies one deliverable data item: its purpose, content, format, compliance standards, maintenance, and submittal terms. DRDs are assembled into a Data Procurement Document (DPD) that rides alongside the SOW/PWS and is invoked by SOW/PWS language. Treat each DRD as a data contract with an interface spec attached — it pins down the schema (Contents), the encoding (Format + named neutral standards), the SLA (submission timing as milestones, never calendar dates), and the access policy (Data Type). The acceptance criterion is integration without rework. Appendix A is an example library — select, tailor, and add DRDs per program. The baseline suite: STD-TDP, STD-MBx, STD-CDMP, STD-CDMPA, STD-CSA, STD-SDT, STD-EMDAL, STD-CR, STD-AD, STD-REF, STD-MRI. They cite each other deliberately — specify them as a connected set.

The Data Type scale (1-5) — a control-and-trust dial

How much Government oversight a deliverable needs: Type 1 (written approval before any use; the choice when data enters the Center baseline under CDM control), Type 2 (time-limited disapproval window, default 45 days, tailorable), Type 3 (deliver on time, no approval), Type 4 (contractor-retained, delivered on written request — needs FAR 48 CFR §52.227-16 to compel), Type 5 (incidental, inspectable). Pick the lowest level that still protects the baseline.

Configuration & Data Management (CDM) — a closed loop

Plan (CDMP) → Identify (CIs, baselines) → Control (CRs, CCBs) → Account (CSA) → Verify (CDMPA for process, FCA/PCA for product). The CDMP is the backbone (SAE GEIA-859 / EIA-649 / EIA-649-2). Three baselines — functional, allocated, product. FCA asks "does it perform to the approved documentation?"; PCA asks "is it built as designed?" — both establish the Product Baseline. The TDP matures with the life cycle (Conceptual ≈ SRR/SDR, Developmental before PDR, Product before CDR, Commercial for off-the-shelf), grounded in MIL-STD-31000, and seeds the as-sustained Product Baseline once ingested.

Requirements exchange and the build record

REF (STD-REF) standardizes a minimum requirement-object attribute set — every object owns a UUID (ISO/IEC 11578) plus shall-text, a lifecycle state (In-Work → Completed → Accepted → Obsolete), version/source identity, and optional multi-cardinality Upstream/Downstream UUID traceability — carried as RIF/ReqIF-compatible XML so requirements stay integrable across vendor tools. Agree the schema, not the tool. The MRI (STD-MRI) is the indexed as-delivered build standard (CIs, components to piece-part, drawings, configuration documentation, ECPs, RFVs, ancillary equipment); if you cannot reconstruct the build standard from the MRI, the configuration record has failed.

Contract language and data rights

Buy the data while bidders still compete: put the same data approach in three places — the SOW (functional/technical requirements), the DRD (the details, submitted with the proposal), and the Cost Volume (data as a separate priced line item). Use Table 3 to match each technical-data (TD) or computer-software (CS) deliverable to a license category (Unlimited, Government Purpose, Limited, Restricted, Specifically Negotiated, SBIR, Commercial) by funding source and commerciality; mark less-than-unlimited data with the FAR 52.227-14 Alt II/III legend; defer with priced options and DFARS 252.227-7026/-7027 plus a Data Accession List. Acquire the minimum essential data with sufficient rights for the full life cycle, including downstream re-bid.

Model-based data definition

A subset and critical element of MBE, required by NPR 7123.1. The DRD is the contract for meaning: fix the meaning, scope, and handling of every MBx category there. A deliverable's truth is {object + metadata + state + effectivity + authorized usage} — object type alone never determines usage. Models are authoritative; documents are generated views. Map supplier release states to program-defined destination states (Notional State Compatibility Map). M&S credibility is owned by the PM and Technical Authority (NASA-STD-7009 / NASA-HDBK-7009). Manage multiple BOM views (EBOM/MBOM/as-manifested/as-flown/as-disposed) with effectivity.

Collaboration, architecture, and interoperability

Interoperability needs IT standards and contractual enforcement (the DRD clause) — digitization alone fails (NIMA-RPT-004's ~40% manual-discrepancy finding). The Agency-level collaborative environment is four owned architectures — Security and ISSA (Agency CIO), Data (CIO infrastructure, engineering content, PM/TA sign-off), Process (PM/TA defines, CIO/Mission Directorate implements). Neutral 3D formats (STEP/ISO 10303, JT) are the collaboration medium when participants use different CAD systems. Standards are keyed to a maturity model. Run the four interoperability use cases — Viewing → Data Exchange → Data Integrity → Data Interoperability Formats — and let the heaviest you genuinely need set the bar.

The MBE Plan

A living, formally controlled, signed program-wide document (one per single-project/tightly coupled program, per NPR 7120.5) recording how MBE capabilities will be delivered. Table 9 schedules each MBE element through Preliminary → Baseline → Update across phases and KDPs; Table 10 is the required section template (responsible competency + agreement + data). It is a treaty, not a textbook — signatures (PM, Mission Directorate AA, Center Directors, project managers) make it a resource commitment. Refresh at least annually or at a major KDP, through KDP F.

Chapter Index

Topic Index

• Acquisition framework / DEE / Digital Engineering Environment → ch01
• Anti-patterns ("contractor format acceptable", omitted data requirements) → ch04, ch03
• Architecture (Security / ISSA / Data / Process) → ch06
• Authoritative source / manual-copy risk → ch07
• Bill of Material (BOM) / product breakdown structure → ch05
• CDM / Configuration and Data Management (closed loop) → ch02, ch05
• Configuration and Data Management Plan (CDMP) → ch02
• Configuration Status Accounting (CSA) → ch02
• Contract language / SOW / Cost Volume placement → ch04, ch03
• Data Category designations → ch02
• Data interoperability use cases (the four) → ch07
• Data Procurement Document (DPD) → ch02
• Data Requirements Description (DRD) → ch02, ch01
• Data rights / license categories / Table 3 / FAR / DFARS → ch04
• Data Type (1-5) control scale → ch02
• Digital Mock-Up (DMU) → ch05, ch02
• Engineering Models, Drawings & Associated Lists (EMDAL) → ch02
• Engineering release / change management / state mapping → ch05
• FCA / PCA (configuration audits) → ch02
• GSMAF (Goddard Space Mission Architecture Framework) → ch06
• Interoperability standards (STEP / ISO 10303 / MIL-STD-31000) → ch06
• Key Decision Points (KDP) / life-cycle phases → ch08, ch06
• Lead Systems Integrator → ch01
• Master Records Index (MRI) → ch03
• Maturity levels (format, Table 8) → ch07
• MBE Plan development (Table 9 / Table 10) → ch08, ch04
• MBx family (MBSE / MBD / MBE / MBM / MBI) → ch06, ch05
• Metadata vs. PMI → ch07, ch05
• Model-based data definition → ch05
• Model-Based Systems Engineering (MBSE) / system model → ch05
• Models & Simulations (M&S) credibility → ch05
• Neutral formats → ch02, ch06
• OPR / Data Manager split → ch02
• Parts and library management → ch05
• Product Baseline / baselines (functional / allocated / product) → ch02
• Requirements Exchange Format (REF / ReqIF) → ch03
• Standards keyed to maturity model → ch06
• Technical Data Package (TDP) → ch02
• Traceability (paired UUIDs) → ch03
• Transmittal & security baselines (NIST / FIPS) → ch04
• UUID / requirement object schema → ch03

Supporting Files

• glossary.md — key acquisition, DRD, CDM, and model-based terms, alphabetical, with chapter references
• patterns.md — 11 reusable patterns (buying data while bidders compete, the DRD as a data contract, the Data Type dial, maturing the TDP, REF/UUID identity, the MRI build record, neutral formats, data rights, release-state mapping, the four use cases, the MBE Plan as a treaty) with When/How/Trade-offs
• cheatsheet.md — quick decision rules, the framework/DEE map, the DRD suite table, CDM loop, REF schema, model-based data definition, the four architectures, the use-case ladder, key external standards, tells & smells

Scope & Limits

Covers: the acquisition and contracting side of NASA digital engineering per NASA-HDBK-1004 — the DRD instrument and the full Appendix A DRD suite; the Data Type 1-5 control scale and CDM; SOW/RFP/Cost-Volume contract language and data rights (FAR/DFARS, Table 3 license categories, deferral instruments); the Requirements Exchange Format and Master Records Index; model-based data definition (MBSE, CAD/PMI, M&S credibility, BOM, release-state mapping, PLM, parts libraries); digital data collaboration, the four owned architectures (Security/ISSA/Data/Process) and GSMAF; interoperability standards (MIL-STD-31000, STEP/ISO 10303, ASME Y14, the Table 6/7/8 framework); the four MBE interoperability use cases; and MBE Plan development.

Does not cover in depth: the source is an acquisition handbook, so it is thin on practitioner-depth digital-engineering technique — the companion NASA-HDBK-1009A carries that complementary detail (the data-architecture/metadata vocabulary, the NDAF requirement-type framework, and deeper M&S credibility practice are governed alongside it), and this pack repeatedly defers to it. It does not reproduce the text of the third-party standards it cites (ISO 10303/STEP, ASME Y14, MIL-STD-31000, SAE EIA-649/GEIA-859, ISO/IEC/IEEE 42010 — those remain the copyright of their publishers); it names them and describes how the Handbook invokes them. It does not provide the underlying NASA SE process model (see nasa-npr-7123 / dau-se-guidebook), the binding legal text of FAR/DFARS clauses (route through Legal/Procurement), or program-specific tailoring — every example DRD and contract clause must be tailored by the acquiring program/project and reviewed before binding use.

Jurisdiction & version: NASA Technical Handbook NASA-HDBK-1004, Baseline (approved 2020-04-01), superseding NASA-HDBK-0008; a US Government work in the public domain. Guidance is recommended (not mandatory) outside its primary NPR 7120.5 program scope and never overrides existing Agency guidance — conflicts go to the delegated Technical Authority.