A supplier package is approaching delivery, but the review team cannot explain which findings block submission and which need a program decision. We turn the controlling publication requirements into checks, assess a representative package and correct the agreed defects. Dakota supplies the checked package and evidence; the receiving organization makes the acceptance decision.
The work serves both delivery owners and reviewers
Prime-contractor publication leads need a repeatable basis for reviewing supplier submissions. Supplier quality managers need findings that can be assigned and closed. Equipment suppliers need a correction scope that separates content defects from unresolved customer decisions.
Engineering and PLM leads join when a finding depends on source configuration or engineering change. The review then has a named route for technical questions instead of leaving publication authors to infer the answer. We agree those responsibilities before correction begins.
The contract defines the acceptance baseline
We begin by identifying the contracted S1000D issue and the applicable national or program rules. For example, MIL-STD-3031 Revision B Change Notice 1 applies Army business rules for S1000D Issue 4.2 to new acquisition technical publications, including page-oriented and IETP outputs. That is a specific baseline, not a reason to select a newer issue by default. DLA MIL-STD-3031 record
Australian Defence guidance also addresses more than file validity: DEF(AUST)IPS-5630 Edition 2 covers quality assurance, verification, validation and acceptance in chapters 13–17. We use the applicable contract and guidance to distinguish these review activities rather than treating a validation report as the whole acceptance record. Australian Defence publication guidance
The proposed acceptance matrix links each controlling requirement to a check and its evidence. It distinguishes automated checks from human review. Where the requirement is unclear, we record the question and decision owner rather than inventing a supplier rule.
A representative package exposes the correction scope
We scope the assessment around a representative delivery package and an agreed acceptance profile. The sample should reflect the module types and delivery risks under review, not just the cleanest available content. We ask for:
- The contractual deliverables and required S1000D issue, with applicable business rules and national guidance.
- The XML modules and graphics, together with the delivery manifest.
- The BREX files and allowed values, with the applicability model.
- The required viewer or publishing profile and the available validation configuration.
- Recent rejection reports and severity definitions, with review responsibilities.
- The delivery milestone and the person authorized to accept the publication.
Direct CSDB access is not the only working arrangement. We can scope assessment around exchanged packages, provided the agreed exchange includes the dependencies and configuration needed to reproduce the checks. We record missing inputs as limits on the assessment.
The evidence pack connects findings to disposition
We separate assessment from correction so the findings establish the work to be done. The agreed delivery contains:
- A requirement-to-check matrix showing the planned evidence and review owner.
- A findings register with reproducible evidence and severity, plus ownership and disposition.
- A corrected representative package with a record of the changes.
- Rerun validation results tied to the corrected package.
- A delivery manifest and acceptance evidence pack for the receiving authority.
A disposition is not always an edit. It may be a correction, an authorized exception or a request for a technical decision. We keep those outcomes distinct so an unresolved question does not appear as a closed defect. Recurring batch assessment and author coaching can be scoped after the sample establishes the correction pattern.
A demonstrated revision makes the checks useful
We demonstrate the review cycle against the agreed sample before extending it to production. The demonstration follows a finding from its original evidence through correction and rerun. It also shows whether the change affects linked content or delivery packaging.
We propose these acceptance tests for Dakota's work:
- The reviewer can reproduce the checks using the recorded issue and rule configuration.
- Blocking findings have either a demonstrated correction or an explicit disposition from the designated authority.
- References and illustrations resolve within the agreed scope, with applicability and packaging reviewed.
- The receiving organization can trace the submitted evidence to each agreed requirement.
Keep an unresolved business rule as a decision item rather than changing it to clear validation. Otherwise, the corrected package and its evidence rest on an unauthorized baseline. We record approved rule changes separately from content corrections so reviewers can see what changed and why.
Qualification starts with the acceptance authority
Before scoping delivery, we establish who owns technical decisions and who can accept the publication. We also identify access restrictions and open rule questions. Correction planning follows the findings and the availability of those decisions, rather than an assumed volume of edits.
Dakota is listed among Oxygen XML consulting partners under training and consulting. That listing supports our stated consulting role; it does not confer authority to accept a customer's publication. Oxygen XML partners
Bring a real delivery package or rejection report to the scoping workshop, together with the controlling requirement and the person who accepts delivery.
Sources
- MIL-STD-3031 — Army Business Rules for S1000D — US Defense Logistics Agency / ASSIST, 2025-07-31
- DEF(AUST)IPS-5630 Edition 2 — Australian Department of Defence, 2026-03-13
- Oxygen XML partners — Oxygen XML, undated