Production map

A device production is never complete on the first pass, and the gaps are rarely random: the records that are missing are the ones that would answer the question. A legal team cannot see the gaps without knowing which records a manufacturer must keep, and in what form. This skill supplies that knowledge and turns it into one table the team can act on: request by request, what came, what did not, and why it should exist.

The output is read by counsel in a meet-and-confer and, later, by a judge. Every "missing" must therefore be defensible: the record is named in a regulation or a standard the manufacturer certified against, or it is referenced inside a document that was produced. Never list something as missing because it "usually exists".

1. Inputs

• The request: the requests for production (or the subpoena, or the Alpha Devices request schedule from guide 05 when the team has not served one yet). Number each item as the request numbers it.
• The production: the folder, with its index. If the archive from the case-brief skill exists (index.csv, one text file per document with page markers), use it; if not, build it the same way first — one text file per document, a header, an index with a category per document. Do not map from file names; map from contents.
• The device and the matter: model, software version, dates of the event. The map must cover the versions and the period that matter, not the model in general.
• Which side the user is on, because a map for the requesting party lists deficiencies, and a map for the producing party lists exposure. The table is the same; the last section differs.

2. Know what should exist

Before searching, write down for each request item the records that answer it, where they come from, and who requires them. The table below is the starting point; adapt it to the device and the request. Cite the current rule (QMSR, 21 CFR 820, incorporating ISO 13485:2016, in force since February 2, 2026) and the former section for records made before that date, because the production will use both names.

A record that is referenced inside a produced document (a DHF index listing a report; a CAPA citing a test; a release note citing a problem report number) is the strongest evidence that it exists. Collect those references as you read; they go into the map as "referenced in [ID p.N], not produced".

3. Build the map

For each request item, in order:

1. Search the archive for the record types in section 2: by document titles, by form numbers and document IDs, by terms the manufacturer uses (read a few produced documents first to learn their vocabulary; a "DHF" may be called a "design dossier" or a "technical file").
2. Record what was found: the documents (IDs or Bates ranges), their dates and revisions, the versions and lots they cover, and the pages. One row per document or per coherent set.
3. Judge coverage for the item, with a single word and a reason: complete (the record set the rule describes is present for the relevant versions and period), partial (say what part: a revision missing, a period not covered, a report without its protocol, an index without the documents it lists), missing (nothing responsive), not applicable (say why — a Class I exempt device has no premarket submission).
4. State why it should exist for every partial or missing: the rule from section 2, or the produced document that references it. If neither applies, the item is unknown, not missing.
5. Note objections and claims from the responses: privilege, trade secret, "not in possession", "will produce". Record each against the item with its source, so the map shows what was refused as well as what was omitted.

The map is production-map.csv with columns: request no. · item · record type · produced (IDs / Bates) · dates / revisions covered · coverage · basis (rule or reference) · response / objection · note.

4. Verify

• Open each produced document you list and confirm it is what the row says (an index page is not the file; a protocol is not the report; a summary is not the record).
• For every missing row, run one more search with different terms before you keep it. Then record the terms you used in the note, so the other side cannot answer "you did not look".
• Check version coverage against the device: a risk file produced only in its latest revision, when the event happened under an earlier one, is partial, not complete.
• Do not count pages or documents as a measure of completeness. A thousand pages of training slides do not answer a request for the DHF.

5. Write the output

1. The map (production-map.csv), complete, including the complete rows; the team needs to see what is settled as well as what is open.
2. A one-page summary (production-summary.md): a table with one line per request item and its coverage word; then the gaps in order of importance for the question in the matter, each with its basis; then the objections to resolve.
3. Deficiency points (deficiency-points.md), when the user is on the requesting side: for each gap, one numbered paragraph in neutral language, ready for counsel to put into a letter — the request number, what was produced, what is missing, the rule or the produced document that shows the record exists, and the specific thing asked for (by name, version, date range). Counsel writes the letter; the skill supplies the facts. When the user is on the producing side, write exposure-points.md instead: the same gaps as the other side will see them, so they can be cured or explained.

Every line in the summary and the points cites the map row or the document ID. Nothing is stated from general experience of productions.

6. Rules

• Originals untouched; work on the archive copy.
• "Missing" only with a basis. "Unknown" is an honest word.
• Learn the manufacturer's vocabulary from its own documents before judging what is absent.
• Keep the search terms used; they are part of the record of the work.
• No opinions on motive ("they withheld") — the map says what was requested, what came, and what the rules require. Counsel draws the inference.
• When the production arrives in waves, keep one map and add a wave column; the summary's first section becomes "what the latest wave added and what is still open".