Dakota Systems · Technical publication delivery

Partners bring a defined publication handoff

This engagement is for publications managers with a delivery obligation and engineering leads responsible for the source system. It also suits partners whose implementation scope ends before publication acceptance. Referral, joint delivery and white-label subcontract arrangements can use the same starting point: a named boundary between the partner’s work and ours.

We separate ownership of source correctness from ownership of conversion and output testing. A mapping decision may belong to publications while a source correction belongs to engineering. Recording those decisions before production makes the review path explicit without treating every rejected page as a formatter defect.

We scope the work around the output

The baseline service scope covers conversion, publishing and continuing publication operations. We select the work from the actual handoff rather than assume that changing an authoring tool resolves the delivery problem.

• Content conversion for RapidAuthor or migration from Arbortext authoring and composition.
• Publication delivery from Teamcenter, with the source-to-output boundary agreed.
• S1000D supplier acceptance support and correction against the supplied project rules.
• Multilingual PDF and interactive electronic technical publication production.
• Authoring, illustration and continuing operations within a defined review process.

Tool capabilities inform that scope. Oxygen’s S1000D Framework lists schema validation and data-module PDF and HTML publishing; its documented coverage is a starting point for checking the proposed authoring environment, not evidence that a whole publication handoff is covered. Oxygen S1000D Framework

For composition, Antenna House documents XML and HTML input with XSL-FO or CSS, including multilingual layout support. We use the proposed languages and output examples to define composition testing rather than infer acceptance from the feature list. Antenna House Formatter

Source samples expose the delivery boundary

For scoping, bring representative source files and the expected output. Include difficult content rather than only clean pages. A sample with applicability changes or illustration references gives the team a better basis for mapping decisions than an isolated text section.

We use the following inputs to draft the statement of work:

• Source content with associated illustrations and available revision history.
• The contracted output definition and supplied business rules, including BREX where applicable.
• The system architecture and permitted access to authoring and publishing environments.
• The delivery milestone and the person authorized to accept the result.
• Review responsibilities and the route for resolving disputed source content.

Customer-hosted and Dakota-hosted AI evaluations remain separate scopes. Their proposed boundaries include permitted data, human review and handling of rejected output. They are not an unstated dependency of the publication delivery plan.

The handover includes decisions and test evidence

We define the deliverable package before production starts. It can include converted content, mapping rules and publishing configuration, with the exact assets tied to the target environment. The scope also names responsibilities and review windows so that handover is more than a folder of output files.

• A mapping record that explains how source structures become target structures.
• Publication assets and rendered outputs for the agreed delivery channel.
• Validation results and an exception record with an owner for each unresolved item.
• Instructions for rerunning the agreed conversion and publishing path.

Where the destination is a DITA-based site, the package can specify validated .ditamap and .dita assets plus publish-ready HTML. That is a separate output agreement, not a substitute for an S1000D delivery package.

A revision is the acceptance demonstration

Our proposed acceptance sequence starts with an agreed sample and its mapping record. After review, the source owner supplies a representative change. We process that revision through the same path and compare the resulting assets and rendered output.

The demonstration checks whether the change reaches the intended content and whether unaffected content stays intact. It also records any manual intervention. Accepting only the first rendered sample can hide repairs that nobody knows how to repeat; demonstrating the revision exposes those repairs before they become routine production work.

The acceptance owner then reviews the evidence against the agreed tests. Open exceptions remain visible rather than disappearing into a general statement that the output passed.

Published evidence sets a bounded starting point

Dakota is listed among Oxygen XML consulting partners under training and consulting. That is evidence of a listed relationship, not proof of acceptance for a particular S1000D program. Oxygen consulting partners

Dakota’s published TAI case describes SGML-to-XML conversion and automated XSL-FO PDF publishing for ATAK helicopter manuals. It provides a concrete delivery reference for conversion and composition, without implying that another program has the same inputs or acceptance rules. Dakota TAI publishing case

Bring a real source sample and its expected output to a delivery-scoping workshop.

Sources

• S1000D Framework add-on — Syncro Soft / Oxygen, date not stated
• Antenna House Formatter V7 — Antenna House, date not stated
• Oxygen XML partners — Syncro Soft / Oxygen, date not stated
• TAI automated technical manual publishing for ATAK helicopter — Dakota Systems, date not stated