Build ONE S1000D data module (descript / proced / process / fault) or publication module (pm) from a structured draft and number it from the allocation rules. You give titles, paragraphs, steps, tables, figures and references as a tree; the server writes the XML (you never write XML, DMCs, ICNs or the BREX reference). The XML is verified (XSD, BREX along the brexDmRef chain, references; applicability too when a product is given); fixes the server is certain about (confidence "exact") are applied automatically and verified again, up to maxFixRounds times. Returns xml, fileName, dmCode (pmCode for a pm), verification, appliedFixes[] (what was changed automatically), fixes[] (what remains: candidates to choose from), the updated ledger and the next ICN number. Writes into the CSDB only when write is true. A malformed draft comes back as error.code "input-error" with the path of the problem.

Convert an experiential operation manual (@shuji-bonji/experiential-manual-model JSON) into S1000D: one publication module, one data module per topic (description → descript, procedure → proced, troubleshooting → fault, screenFlow → process plus one proced per screen), a glossary data module, applicability from the scopes, and ICNs for the assets. Every data module goes through the same flow as build_data_module (build, verify, automatic exact fixes, verify again); references between the data modules are resolved against the CSDB plus the data modules built in this call. Returns dataModules[], publicationModule, assets[] (assetId → ICN and the original file; with write: true the originals are copied under the ICN file name), the ledger, a summary of verification states and notRepresented (what the draft format cannot express). Nothing is written unless write is true.

Apply fixes to an existing data module. Each selection copies the location and ONE candidate of a fix that s1000d-verify-mcp suggest_fixes (or this server) returned: { location, action, target?, value? }. The server computes the fix candidates again and applies a selection only if it matches one of them; a value outside the candidates (or outside a range / pattern candidate) is not applied and comes back in rejected[] with the reason. "provide" candidates change the product, not the document: pass them as "product". The result is verified again. Returns xml, applied[], rejected[], verification, the fixes that remain. Writes only when write is true (a path is overwritten in place; xml is written under its own file name in the first CSDB folder).

Build a comment data module (comment.xsd): a remark about data modules, publication modules, DMLs or DDNs, with the type (q / i / r), the priority code (cp01–cp99), paragraphs, the originator and the sender. The enumerations are written as given and not interpreted. The sequence number defaults to the next free one in the CSDB. The XML is verified (comment.xsd, BREX). Returns xml, fileName, commentCode, verification, fixes[]. Writes only when write is true.

Take the sentences that a person reads out of a data module so they can be translated: titles, paragraphs, step texts, warnings / cautions / notes, table cells and figure captions. Each segment has a stable id, its XPath, a context hint and the text, with inline elements (emphasis, references …) replaced by {1}, {2} placeholders that must stay in the translation. Attribute values, DMCs, ICNs, applicability expressions and ids are never offered. Also returns the skeletonHash to pass to apply_segments. The server does not translate and does not score translations.

Put translated sentences back into the data module they were taken from. The output has the same DMC with only the language changed (issueInfo too if given). It stops with error.code "skeleton-mismatch" when the data module changed since extract_segments (skeletonHash). A segment whose id is unknown, duplicated, or whose {n} placeholders do not match is not applied and is listed in unapplied[] (the original sentence stays). The result is verified. Writes only when write is true.