Before Meridian's crew-scheduling optimization project begins pulling data from HR, payroll, and FAA duty-time systems, the PM wants retention rules, quality standards, and access permissions agreed upon in writing rather than decided informally as issues arise. What should the PM establish?

The formal data management plan is the documented, up-front artifact defining how data will be handled across the initiative — retention periods, quality standards, and access permissions — established before the pipeline is built, not negotiated informally later. This matters acutely at Meridian because crew-scheduling data touches HR, payroll, and regulated FAA duty-time records, each with different sensitivity and compliance implications. The verbal agreement between the data engineer and the PM, revisited only if disputes arise, relies on informal, undocumented agreement, which breaks down exactly when disputes or audits occur — there's nothing written to point to. The no-plan approach, with standards emerging organically once the model is already in production, defers all planning until after production, which is backwards; by then, poor access controls or missing retention rules are already embedded in how the system operates and are costly to retrofit. The plan limited only to the technical database schema, with retention and access left undefined, narrows the plan to schema only, omitting governance elements (retention, access, quality) that are the actual point of data management plans — technical schemas alone say nothing about who can see data or how long it's kept. For the exam: data management plans are governance artifacts, not technical database design documents.