Looking for some advice. I recently started working on the government side, and am assisting in the preparation of a major RFP. An issue I have spotted, but haven't brought up until I am more sure of the answer, is the proper use of the DAL. My understanding is that when used, it is a CDRL, and it is a list of all technical data and software generated under the contract. It is not the data itself; it is a roadmap to it. The purpose of it is to give the government visibility into all contractor-generated technical data, and enable the government to decide what it wants to order under the deferred ordering clause. After some research I found that it has its own data item description (DID) - DI-MGMT-81453C. The DID pretty much matches my understanding, and adds that the DAL shall also identify the government's rights in the data.

Here's the problem: in the draft RFP, they define the DAL as a repository of everything generated under the contract, and I mean literally everything, not just technical data. In at least 40-50 places in the SOW, where it tells the contractor to do something or generate something, it then says "deliver via the DAL." Reports, presentations, lists, briefings, administrative matters, etc.

I understand wanting everything in a repository so that the government can access anything it wants, but I think they have merged the two concepts - repository and DAL. I think the repository should be a separate SOW requirement - create it, host it, make an index, make it searchable, accessible, etc. Any references would then say "upload to/store in the data repository." The DAL should then be a CDRL and be a list of technical data and software, as described in the DID. Of course, the technical data and software should also go in the repository.

I've already heard that "this is the way they've always done it." Before I challenge it, I'd like to know where I stand. Is my understanding correct? Should the repository and the DAL be two separate things? Should the DAL be limited to technical data and software?

I appreciate any input and advice.

6 hours ago, Fara Fasat said:

I appreciate any input and advice.

Call me foolish by I could imagine that a specific contract could define anything as specific to that contract. With emphasis added what one might think is a Data Accession "List" in one contract might be defined as something else (repository) in another contract. This said has your research lead you to these?

https://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=205931#:~:text=The%20Data%20Accession%20List%20(DAL,tier%20issued%20under%20that%20contract.

AcqNotes

Data Accession List (DAL) - AcqNotes

The purpose of the Data Accession List (DAL) is to provide a medium for identifying contractor internal data that has been generated by the contractor in compliance with the work effort described in t

7 hours ago, Fara Fasat said:

I understand wanting everything in a repository so that the government can access anything it wants, but I think they have merged the two concepts - repository and DAL. I think the repository should be a separate SOW requirement - create it, host it, make an index, make it searchable, accessible, etc. Any references would then say "upload to/store in the data repository." The DAL should then be a CDRL and be a list of technical data and software, as described in the DID. Of course, the technical data and software should also go in the repository.

It is a list of what was produced and is available. It is not a repository, and it is not a CDRL.

See DI-MGMT-81453C:

The Data Accession List (DAL) shall identify all data (technical data, computer software, computer software documentation, contract administration information) the contractor and all its subcontractors generated in the performance of the contract or any subcontract at any tier issued under that contract. The DAL does not list data the contract requires the contractor to deliver in accordance with any other Contract Data Requirements List (CDRL). The DAL is not a requirement to deliver any of the data so listed. The Government can order data listed on the DAL via the Deferred Ordering clause (DFARS 252.227-7027) or as otherwise described in the contract.

a. This data item description (DID) is not a substitute for requiring delivery of data the Government knows it needs prior to award, as the Government shall require delivery of such data via CDRLs other than the DAL.

Carl - yes, I said I had the DID for the DAL, and discussed it in my original post. Since there is a DID for the DAL, I don't think you can choose to define it another way.

Vern -

3 hours ago, Vern Edwards said:

It is not a repository, and it is not a CDRL.

I agree with "not a repository" but not with "not a CDRL." If the government wants a DAL, it is a deliverable and is listed as a CDRL. I've attached a CDRL for a DAL.

From the former Defense Acquisition Guidebook: "To order the deferred delivery, the data must have been actually developed under the existing contract. A common practice in recent contracts has been the requirement for contractors to develop a Data Accession List as a CDRL item." And from MIL-HDBK-502A: "...useful information can often be gained from performing activity data which is not submitted formally, but which can be made available through an accession list. A data item for this list should be included in the Contract Data Requirements List (CDRL)."

If you don't require the contractor to deliver a list of the technical data it generated, how would the government know what technical data it wants to order later? Your quote from DI-MGMT-81453C doesn't say the DAL is not a CDRL; it says that you order the delivery of data that you know prior to award via a CDRL other than the DAL.

DD Form 1423-1, Data Accession List.pdf

32 minutes ago, Fara Fasat said:

I agree with "not a repository" but not with "not a CDRL."

You're wrong if you think a CDRL and a DAL are the same thing.

Read the DID for DALs!

A DAL is a list of what was developed by the contractor and subcontractors during performance and that is available to order after contract performance. A CDRL is a contract exhibit, a list of data to be prepared and delivered as part of performance. It's used instead of having separate CLINs or SUBCLINs for each data item.

A DAL is a contract deliverable. It is a data item on a CDRL.

They have different names because they are different things!!!!!!

But you go right ahead and think what you like.

2 hours ago, Vern Edwards said:

A DAL is a list of what was developed by the contractor and subcontractors during performance and that is available to order after contract performance. A CDRL is a contract exhibit, a list of data to be prepared and delivered as part of performance. It's used instead of having separate CLINs or SUBCLINs for each data item.

A DAL is a contract deliverable. It is a data item on a CDRL.

They have different names because they are different things!!!!!!

Exactly. I taught classes on this subject. Painfully boring especially on repeat instances. I cringed every time I saw the course on the schedule.

2 hours ago, Vern Edwards said:

You're wrong if you think a CDRL and a DAL are the same thing.

I don't.

2 hours ago, Vern Edwards said:

A DAL is a contract deliverable. It is a data item on a CDRL.

Of course. I should have said it's on the CDRL rather than being a CDRL, but I've never seen anyone get hung up over saying 'a CDRL' vs. 'on a CDRL'. It's common -- "report xyz is a CDRL"; "drawing abc is a CDRL"; "such and such is a CDRL"; and so on. Maybe it's not technically correct, but it's just a loose way of saying 'on the CDRL'. I'm not going to correct an engineer every time he says that something is a CDRL instead of on the CDRL. Even the DID you quoted ("via CDRLs other than the DAL") skips the 'on' distinction, and literally calls a DAL a CDRL. How else could there be "CDRLs other than the DAL"? To meet your standard, it should have said "the Government shall require delivery of such data via data items on the CDRL other than the DAL." But they didn't, it's in the DID, and you quoted it.

I've been corrected, so may we move on? The questions I asked were:

1. Should there be separate requirements in the RFP -- one (probably in the SOW) to create and populate the repository and a second (on the CDRL) to create a DAL, rather than calling the DAL the repository? My answer - yes. They are distinct requirements with different purposes.

2. Can or should there be more than just technical data and software on the DAL? My answer - no. The purpose of the DAL is to assist the government in ordering technical data and software generated under the contract.

@Fara Fasat

I agree with your yes and no. You may want to refer to MIL-HDBK-245, which says not to describe data requirements in the SOW. I know it's only guidance, but at least it's something official to counter the "we've always done it this way" folks.

The SOW must describe the work to be done. See Military Handbook 245. Attached.

DODhandbook For Prep of SOW.pdf

When the performance of work produces data about products, services, and work processes, and when the government wants the contractor to deliver those data, it must specify their format, content, and delivery in data item descriptions (DID), either standard or unique. The SOW should not specify data.

From the DOD handbook:

The tendency of SOW writers is to include requirements which belong in other parts of a government contract. Contract requirements should be specified in Sections A - M and should not be restated in other parts of the contract. Quantitative technical requirements should be specified in the specification and not be restated in other parts of the contract.Work requirements should be specified in the SOW, and all data requirements for delivery, format, and content should be in the Contract Data Requirements List (CDRL) in conjunction with the appropriate Data Item Description (DID) respectively, with none of the requirements restated in other parts of the contract. Redundancy invites conflict.

Data format and content should be specified in accordance with MIL-STD-963C, Data Item Description. Attached.

MIL-STD-963 DIDs.pdf

As deliverables, each data items should be identified in a contract line item or in separately deliverable subline items. . But if there are numerous DIDs, they should, for convenience, be listed in a Contract Data Requirements List, DD Form 1423. The CDRL then is referenced in a single contract line item as an exhibit.

This rational system is based on long experience and describes sound contract design practice. It has been in place since before I entered the contracting career field in 1974. I was rigorously trained in its operation. Yes, it is formal, and yes, it requires study, but it prevents contractual chaos. Unfortunately, too few 1102s have been educated and trained in the proper operation of that system. It is wrongly considered a "technical" concern. It is not. It concerns how contracts are written, which is a contracting officer concern.

This system specifies sound contract design practice. It renders contracts clearer and more understandable. It minimizes disputes.

It is NOT a case of too much bureaucracy.

12 hours ago, Fara Fasat said:

Should there be separate requirements in the RFP -- one (probably in the SOW) to create and populate the repository and a second (on the CDRL) to create a DAL, rather than calling the DAL the repository? My answer - yes. They are distinct requirements with different purposes.

Not unless your team knows what they're doing and knows how to specify their requirement.

For more information about data repositories, see Army Data & Data Rights (D&DR) Guide: A Reference for Planning and Performing Data Acquisition and Data Management Activities Throughout the DoD Life Cycle (2015).

See this, also:

https://apps.dtic.mil/sti/trecms/pdf/AD1165374.pdf

and this:

https://www.nature.com/sdata/policies/repositories

4 hours ago, Vern Edwards said:

This system specifies sound contract design practice. It renders contracts clearer and more understandable. It minimizes disputes.

It is NOT a case of too much bureaucracy.

Yes. It’s to standardize and make data requirements clear and unambiguous. Apparently one reason the system was created decades ago was to eliminate confusion. DoD contractors complained about data requirements hidden inside lengthy SOWs. Then similar data requirements and formats were spelled out differently even within the same office. So a contractor might have to use completely different report formats and reports for the same data requirements within an office. The use of standard DID formats was designed to reduce that mess.

The first mention I have found of the DD Form 1423, Contract Data Requirements List, appeared in the Federal Register of July 11, 1967. The system has been around for a long time, and has continued to be a very useful element of contract design.

A handy reference, the Intellectual Property Guidebook for DoD Acquisition (30 April 2025)

https://www.acq.osd.mil/asda/dpc/api/docs/intellectual%20property%20guidebook%20for%20dod%20acquisition%20signed.pdf

Use of the Contract Data Requirements List (DD Form 1423) is required by DFARS 215.470(b) when data are required to be delivered under a contract.

From "Intellectual Property in Government Contracts" (2020), by Devecchio and Lavallee, in Government Contracts Year in Review Briefs, 2022:

Increasingly, contractors are encountering a requirement to provide a Data Accession List (“DAL”), which often appears as a Data Item Description within a Contract Data Requirements List (“CDRL”). A typical understanding of the DAL (for example by The Defense Acquisition University) is that it specifies particular types of data that must be catalogued and retained by the contractor if they are developed during performance but are not otherwise deliverable to the government. The DAL then becomes a catalogue for ordering under the deferred ordering clause. Yet, equally increasingly, agencies take the position that a DAL itself requires a contractor to deliver the technical data identified on the DAL. This is incorrect.

***

If the government has failed to identify deliverables in the CDRL or elsewhere, the government can later order certain data or software under the DFARS Deferred Ordering or Deferred Delivery clauses or the FAR Additional Data Requirements clause. But unless an agency has crafted a unique DAL clause, a DAL is not itself a delivery requirement. It is simply a list of data the contractor generates during the contract’s performance that allows the government to order what is described on the list if there is a separate delivery mechanism specified in the contract, such as a Deferred Ordering clause.

One final point: Specifying data is not for amateurs.

Thanks everyone, very useful. I think I can convince them that a DAL and a repository are different things. They've defined the DAL as a repository and then use the phrase "shall be delivered via the DAL" throughout the SOW, but it can be fixed. However I've found nothing that suggests they intend to use the deferred ordering process to get the technical data they want. I think they expect to just pull everything from the repository.

A bigger problem is what goes on the DAL (question 2 above). My understanding is that it is for technical data and software that the contractor generates during contract performance, so that the government can determine whether it wants delivery. However, they are using it for literally everything. Here are some examples of what they say should go on the DAL: giver-receiver list of GFP; the security access roster; GIDEP compliance methodologies; supply chain risk information; quality records, processes, and procedures; results of network vulnerability scans.
I have no problem with requiring those things to go in the repository and making it indexed, searchable, accessible, etc so the government can get those things if it wants. But putting them on the DAL would just garbage up the DAL and make it harder for the government to find the technical data it wants.

Am I off-base on this, or is it worth trying to get them to change?

4 minutes ago, Fara Fasat said:

A bigger problem is what goes on the DAL (question 2 above). My understanding is that it is for technical data and software...

Did you read the DAL data item description? I attached it above.

On 11/20/2025 at 5:28 AM, Vern Edwards said:

The Data Accession List (DAL) shall identify all data (technical data, computer software, computer software documentation, contract administration information)...

Really, Fara... Really