A supplier package can contain usable engineering content while leaving the publication delivery unresolved. The open questions concern which rules control, what needs correction and who accepts the result. We scope that work around a representative package, then use the sample to agree on production and maintenance work. Dakota Systems, Inc. is based in Chicago, Illinois. Dakota Systems
The buyer owns a publication handoff
This work is for publications managers responsible for supplier deliverables and engineering or PLM leads responsible for the source handoff. It also suits an OEM or MRO team assessing a package before taking responsibility for its maintenance.
The delivery job is narrower than replacing an authoring system. We assess the source against the agreed baseline, define conversion or correction work and assemble the evidence for acceptance. Tool selection follows that scope rather than deciding it. An unresolved rule is recorded as a decision for the acceptance owner, not silently turned into a conversion assumption.
The contract baseline comes before conversion
The ASSIST record for MIL-STD-3031 identifies Revision B with Change Notice 1 and business rules using S1000D Issue 4.2. Its scope includes new-acquisition technical publications with page-oriented and interactive electronic technical publication outputs. ASSIST MIL-STD-3031 record
The official text covers Army and Marine Corps publications and excludes training. It also distinguishes content requirements from business rules. That distinction gives the assessment separate questions: whether the technical content is present and whether the package follows the applicable rules. MIL-STD-3031 official text
We do not treat this Army and Marine Corps reference as the baseline for an Air Force or Navy delivery. For each engagement, we record the controlling contract and its tailoring before proposing schemas or checks. A current public standard record is a reference point, not evidence of what a particular contract calls for.
A useful sample includes the acceptance context
A source file alone leaves too many decisions open. For qualification, we ask for the package and the context in which it will be accepted:
- The contractual deliverable and the specified S1000D issue, with applicable service guidance and project business rules.
- Representative source content and its graphics, together with known findings or rejected delivery notes.
- The expected publication output and receiving environment, including relevant configuration cases.
- The acceptance owner and review process, together with the planned delivery milestone.
We propose a sample that exposes a difficult handoff rather than only a clean topic. Useful candidates include content with a changed illustration or a configuration-dependent procedure. The assessment records missing inputs and assumptions so that later source discoveries do not look like unexplained changes in scope.
The sample produces a bounded delivery scope
We organize the proposed deliverables around decisions the buyer can review. Each finding points to the source item, the applicable rule or agreed check and its proposed disposition.
- Requirements-to-check matrix. A record linking the agreed baseline to checks and evidence, with unresolved interpretations visible.
- Representative assessment. Findings that separate source gaps from mapping choices and output defects.
- Conversion or correction package. Agreed changes with a record of what was corrected, deferred or returned for engineering review.
- Publication outputs and acceptance evidence. The scoped delivery package accompanied by check results and review dispositions.
- Production and maintenance scope. Work boundaries based on the sample, including responsibilities for later source changes.
The statement of work names the output formats and exclusions. We keep source repair distinct from publication transformation so that a missing technical instruction is not mistaken for a formatting defect.
A revision tests more than an initial export
We propose demonstrating a revision before agreeing to production scope. An initial package can look acceptable while leaving change handling untested. The sample review therefore follows a selected source change through correction, publication and inspection in the receiving environment.
- Agree on the sample baseline and the evidence the acceptance owner will inspect.
- Produce the scoped output and record findings against that baseline.
- Apply an agreed source change and identify the affected content and graphics.
- Rebuild the package and review the changed result alongside unaffected content.
This is a proposed delivery acceptance test, not a claim that a standard mandates this sequence. Its purpose is to expose repeat-work risks while the scope is still small enough to change.
Qualification ends with a proceed or resolve decision
The sample review establishes what can proceed and what still needs a decision. Rule maturity and source quality shape that decision. Illustration work, output profiles and review responsibilities also belong in the scope rather than in unstated assumptions.
Bring a real source package, the required output and the person who accepts delivery to the scoping workshop.
Sources
- MIL-STD-3031 — Army Business Rules for S1000D — US Defense Logistics Agency / ASSIST, 2025-07-31
- MIL-STD-3031B with Change 1 — US DoD / Army, 2025-07-31
- Dakota Systems — Dakota Systems, Inc., publication date not stated