Structured editor — S1000D data module with schema-aware widgets, validation, and BREX diagnostics.
Ironmark is a self-hosted technical publications platform for MIL-STD-40051, MIL-PRF-63029, and S1000D. Authors can keep Oxygen, Arbortext, or another XML editor through the Desktop Launcher, or use Ironmark's browser editor, while the platform manages document control, review, on-demand validation, publishing, IADS-compatible delivery packages, reporting, APIs, and controlled distribution.
Ironmark isn't a collection of standard-specific products. It's one platform with standards-specific capabilities where they make sense.
Structured editor — S1000D data module with schema-aware widgets, validation, and BREX diagnostics.
…and that's where the box ends. Everything below happens outside the editor.
If your program spends more time on stages 2–9 than on stage 1, you'll outgrow an XML-editor-only tool fast. That's the gap Ironmark was built to close.
Use Oxygen, Arbortext, or Ironmark's browser editor. Every author works in the tool they're most productive in while sharing the same CSDB, workflow, publishing, and delivery platform.
Check-in / check-out happens through the web either way, so review, applicability, parts, publishing, and portal delivery see the same document no matter which editor produced the XML. Ironmark's built-in structured and visual editors are optional — teams already committed to a desktop authoring tool don't need to migrate to adopt the platform.
The Ironmark Desktop Launcher is a small Windows helper that hands off round-trip check-out → external editor → check-in from the browser: one click opens the document in Oxygen, Arbortext, or any XML editor that reads a file path from the command line, and each save flushes back to the server.
Authors keep the editor they know. Programs gain workflow, review, publishing, traceability, and delivery.
Ironmark ships as one platform with per-standard SDM packages. Each landing below covers versions supported, schema/DTD handling, publishing outputs, and what's first-class in the UI versus what round-trips as XML.
Data modules, PM, DDN, BREX, CIR, applicability, IADS import/export.
Work packages, RPSTL, XSL-driven PDF pipeline, PMC assembly.
Commodity-specific technical manuals with the 63029 DOCTYPE chain.
Logistics product data ingested and mapped to source-of-record modules.
The S-Series analysis and feedback standards are consumed as structured datasets rather than manually authored in Ironmark. Ironmark ingests, processes, cross-links and re-emits them as exchange bundles. Each package does register a single dataset document type with a starter template, so one can be created and edited — but none offers the multi-document authoring model the narrative standards have, and that is not what they are here for.
The point is not that Ironmark reads four more XML dialects. It is that these datasets describe different portions of the same support system, and Ironmark treats each dataset as authoritative for the identifiers it owns — so a breakdown element, the preventive-maintenance task analysed against it, and the data module that implements that task all resolve to one another:
S3000L breakdown → S4000P analysis / task → S1000D implementation
S6000T training requirement → competency → supporting S1000D content
Two mechanisms, deliberately separate. Identifiers are extracted deterministically — an identifier in the dataset becomes an identifier in the graph, with no interpretation. Links between projects are then proposed by exact identifier matching, each carrying the identifier that produced it. A proposal is not a relationship: it stays out of the traceability matrix until a reviewer confirms it, and the confirmed link records who accepted it. Rejected proposals are remembered, so re-running discovery cannot quietly reinstate something already ruled out. Ironmark does not infer relationships it cannot point at a matching identifier for.
In-service feedback, ingested over REST or as a file.
Logistic support analysis as a source of identifiers.
Preventive maintenance analysis, linked both ways.
Training needs analysis, tied to the content that teaches it.
Each landing walks the flow, the built-in tools, and what integrates. Start with the ones your program spends the most time on.
In-Process Review Forms, peer review with self-guard, BREX rule validation without XPath authoring from scratch.
Review workflow →Cross-DM parts browser, catalog editor, scan-TM for undiscovered partRefs, NHA tree and part-relationship graph.
Parts workflow →CCT / ACT / PCT wizard, per-asset preview, scan-TM for existing conditions, ingest source-to-master with applicability-tagged rollup.
Applicability workflow →PDF (WeasyPrint or XSL-FO), IETP, IADS. Publications page bundles change cycles and TM Families for paired-manual publish.
Publishing workflow →Branded portal ships with every program. DA-2028 intake, redline feedback, deliverable pickup with acknowledgment, customer file inbox.
Portal & feedback →Role scoping, sudo-style temporal elevation, tamper-evident audit chain, per-project settings for strict SoD.
Compliance workflow →Short guides for the things authors, QA leads, and program managers actually search for. Each answers one question end-to-end, with the exact clicks and settings.
Combined vs ZIP, TM Families for paired manuals, DTD folder, source dataset preservation.
Guide →Rule builder, structural vs non-structural, quick-fix widgets, per-project scoping.
Guide →PM Builder, WeasyPrint vs XSL-FO, change bars, cover page from project metadata.
Guide →DTD folder retention, source TOC + dataset preservation, project-level DTD override.
Guide →Open a review, assign reviewers, close with aggregate result, auto up-issue on approval.
Guide →Ironmark isn't a like-for-like replacement for a desktop XML editor — it adds program-scale workflow around the XML editor your authors already use. These pages walk what stays the same, what changes, and where each tool fits. Consultative, not adversarial.
Already committed to Oxygen or Arbortext? Keep them — the Ironmark Desktop Launcher round-trips a check-out through your desktop editor of choice so your authors don't have to switch tools to adopt the platform.
Structured authoring, S1000D and 40051 support, published 5-, 10-, and 25-seat license bands, browser-based, portal delivery included. Or keep Arbortext and check in through the Desktop Launcher.
Read →Different categories, meant to coexist. Oxygen stays your editor; Ironmark handles the CSDB, review, publishing, IADS delivery, and portal around it. Launcher makes the pairing one-click.
Read →Same-structured content, but the review/publish/deliver flow ships in the same tool — no chain of desktop plugins.
Read →What you keep, what you lose, and what shows up that no desktop tool ships: portal, feedback triage, PM dashboard. Coexist via the Desktop Launcher — one click round-trips a check-out through your editor of choice.
Read →Licenses are sold in 5-, 10-, and 25-seat bands, not as individual seats. The per-seat range below shows the effective annual rate across those bands.
Give us a program contact, a rough seat count, and the standards you use. We will confirm the evaluation scope and provision a time-limited hosted trial instance.