One platform for every technical manual — from first draft to customer receipt.

Browser-based, schema-aware editor with context-filtered element completion, real-time validation, and inline error reporting. No desktop installation required.

Fig. 4.1 — Four editor views: structured, visual, preview, and source XML.

• .01Element palette filtered by active standard and cursor position
• .02One-click XSD, DTD, and BREX validation with a linked error list
• .03Structured preview with proper admonition styling
• .04Check out / check in with exclusive locking
• .05Change notice and effectivity tracking on every check-in
• .06CGM, SVG, PNG, and TIFF graphic support with ICN management^*

* On CGM. CGM previews are auto-converted for the browser via the built-in cgm2svg pipeline (covering ATA GREXCHANGE, WebCGM, CALS, and PIP profiles). Support in published output — PDF and IETP — depends on the target renderer's CGM handling. See FAQ § 04 (question 4.04) for the current cgm2svg coverage and known limitations.

Central repository for all technical documents. Browse, search, and filter by type, status, standard, or validation state. Every revision stored with author, timestamp, and change notice reference.

Fig. 5.1 — The library, filtered.

• .01Search and filter by DMC, type, standard, status, or validation
• .02Version history with element-level structural comparison
• .03Named baselines for publication milestones
• .04Side-by-side diff at paragraph, step, table row, and figure level
• .05HMAC-chained audit log exportable for SIEM integration

In-Process Review Form workflow with reviewer routing, inline redline markup, per-comment severity + status pipeline, dispute resolution by QA, and aggregate approve/return/reject. On approval, the S1000D issueInfo auto up-issues (configurable per project); on check-in, inWork increments — matches the convention that authoring bumps inWork and approval cuts the next issue.

Fig. 6.1 — Reviewer routing, aggregate decision, cycle-time analytics.

• .01Peer-review and QA participate during review; assignments carry required/optional status. Aggregate decision doesn't close until every required reviewer responds.
• .02Structured comments with mandatory / recommended / query severity and an open → addressed / deferred / rejected / disputed status pipeline. Authors can resolve to addressed; only QA/admin can defer or reject a mandatory finding, and authors can flag it disputed to hand off for QA resolution.
• .03Aggregate review result — Approved, Accepted with Comments, Rejected — plus force-close override for admin/QA with audit-logged disputed-comment count
• .04Cycle-time analytics report — average review duration, reviewer response time, SLA violations, slowest reviews
• .05S1000D <issueInfo> auto-bump on approval (project setting, default on); inWork increments on every check-in; full review history per document version and cycle

Full manual assembly with cover page, warning summary, LEP, table of contents, all work packages in order, and alphabetical index — in a single PDF. Change bars computed automatically from version history.

Fig. 7.1 — Publications with cycle history.

• .01MIL-STD-40051 compliant PDF stylesheets via XSL-FO
• .02Automatic change bars from baseline comparison
• .03Automatic List of Effective Pages generation
• .04IETP-X interactive output (S1000D)
• .05Multiple output profiles per program
• .06Applicability filtering applied at publish time

Common Source Database with full DMC management, SNS tree visualization, and cross-reference integrity checking. Automatic DMRL generation and SNS gap analysis.

Fig. 8.1 — DMC parser, SNS gap analysis, and xref health.

• .01DMC parsing and validation for S1000D document coding
• .02SNS tree with gap analysis and suggestions
• .03Cross-reference extraction and broken-link detection
• .04Business rule management with BREX integration

An interactive builder for structureObjectRule entries — pick the target element, scope, allowed values, and messaging from the form, or drop into an XPath escape hatch when the form isn't enough. Dry-run against the project to see what would flag before you commit the rule.

Fig. 9.1 — Existing rules on the left, form + XPath preview on the right.

• .01Quick-start templates: "element must have an attribute", "attribute must be one of a list", …
• .02Full XPath escape hatch for rules the form can't express
• .03allowedObjectFlag semantics surfaced directly in the form
• .04Test-against-project button before adding a rule to the live BREX DM
• .05Rules land as regular S1000D BREX data modules — no proprietary rule format

Group projects across different standards into a single acquisition program. Trace GEIA-STD-0007 logistics product data — breakdown elements, maintenance tasks, and provisioning — directly to the S1000D or MIL-STD-40051 data modules that document them.

• .01Program groups associate projects across different SDM families
• .02Auto-discover links by matching part numbers, NSNs, CAGE codes, and EIAC model identifiers
• .03Bidirectional navigation — click from logistics data to the procedure, or back
• .04Traceability matrix report with confidence scoring and coverage statistics
• .05Manual link creation for non-automatable relationships

S1000D-native applicability with a coverage bar, orphan-ref check against the project ACT, and preview-for-asset that renders the DM filtered for a specific configuration. Documents list filters by asset so authors and reviewers see only what applies.

Fig. 11.1 — Asset Registry with sync-from-XML + per-asset preview filtering.

• .01Per-DM coverage — % of elements carrying applicRefId, unused-id hint, orphaned-ref check against the ACT
• .02Preview-for-asset — filter the DM through the applicability evaluator for any registered asset; rendered WYSIWYG, not raw XML
• .03Asset Registry — sync-from-XML scans project ACT/PCT DMs and upserts asset records with a dry-run diff
• .04Documents-page asset filter — pick a tail number, list narrows to DMs that apply
• .05MIL-STD-40051 UOC support alongside S1000D applicRefId — element-based condition sources declared per SDM

Cross-DM parts search, browse tree (DM → figure → callouts), and a detail drawer that shows every figure appearance with open-in-editor, part-swap chain, and the project's asset roster. Description drift surfaces where one PN carries N spellings across the TM so QA can canonicalize in one step.

Fig. 12.1 — Two views: cross-DM search and the DM → figure → callouts browse tree.

• .01Search by PN, NSN, CAGE, or description across every IPD in the project
• .02Three-level lazy tree (DM → figure → entries), then a collapsible NHA (next-higher-assembly) hierarchy inside each figure — handles large parts catalogs (100k+ entries) without freezing the browser
• .03Canonical Parts (CIR-analog) — one row per (project, PN, CAGE) with consumable flag; promote from conflicts, link matching entries in one action
• .04Scan TM — walks project doc XML for partRef / partNumber mentions not yet in the catalog, bulk-import to a chosen DM
• .05IPD/RPSTL BOM export — CSV and Excel at file and project level; MIL-STD-40051 RPSTL work packages covered via SDM-declared parts_element

Ten built-in rules catch the everyday quality drift schemas can't — orphan step references, empty admonitions, non-standard signal words, missing part descriptions, over-long procedural steps. Half the rules auto-fix; the other half report with a link back to the offending element.

Fig. 13.1 — Per-doc modal and per-project Content Quality rollup.

• .0111 built-in rules — 5 auto-fix, 6 report-only (including stub / empty-document detection) — extensible per SDM via rule registry
• .02Per-doc modal from the editor with severity tagging and inline element navigation
• .03Per-project bulk summary — Content Quality report tab shows worst-offender docs and the top rules firing
• .04Project-wide “Lint Project” report opens from the Documents page — per-doc counts plus the top rules firing across the whole project
• .05Stub & empty-document detection — bodies under a threshold flagged (import leftovers)

Twelve-week check-in velocity, aging review-queue buckets, publish-failure streak detection, and a Legacy Conversion burn-down (for programs running a migration in parallel). Deliberately shipped without a composite productivity score — read the signals together, don't rank the authors.

Fig. 14.1 — Velocity, aging, publish-failure streaks.

• .01Check-in velocity — project-level series by week (checkins + chars added), median WP-size band for calibration
• .02Per-author drill-down — three signals side-by-side (no leaderboard); WP-type mix so a single long troubleshooting WP isn't compared to twenty generals
• .03Aging redlines — 0–7 / 8–30 / 31+ day buckets on the open review queue
• .04Publish-failure streaks — docs whose last N publish attempts all failed, grouped by error class
• .05Cross-tab Reports — Parts hygiene (missing NSN, description drift, consumable candidates), Applicability coverage, broken-link ownership rollups, stub-doc detection

Three distribution tiers (unclassified ZIP, CUI AES-256-GCM, ITAR/EAR with 16-char passphrase and SHA-256 integrity). Full-nuke sanitize option scrubs every attribute value and text node except the structural allowlist — cross-doc links, part where-used, applicability, and validation behavior all preserved so the recipient can reproduce a defect without seeing proprietary content.

Fig. 15.1 — Tier picker with compliance banner + sanitize + PDF cover report.

• .01Three tiers — plaintext ZIP, AES-256-GCM encrypted, ITAR-controlled with mandatory passphrase and package SHA-256 recorded
• .02Full-nuke sanitize — consistent-fake substitution for PN / CAGE / NSN / serial / tail / modelIdentCode; text bodies replaced with length-preserving lorem-ipsum
• .03Preview-one-file before generating — side-by-side original vs. sanitized with scrub counts (attrs / texts / distinct-id remaps)
• .04S1000D DMC filename rewriter — modelIdentCode segment swapped to match the sanitized XML; JGP-structural components kept
• .05PDF cover report with manifest, included DMs, omitted-per-tier register, and integrity table
• .06Compliance banner — encryption and audit are tools, not authorization; local rules govern

Customers file DA Form 2028 / civilian redlines from their portal with page / paragraph / line / figure / table locators. Staff triage via a pipeline (submitted → triaged → accepted / rejected / duplicate / closed), attach the 2028 to one or more DMs, and the Documents view surfaces an open-feedback count with a filter — the ask lands on the author's list, not in a mailbox.

Fig. 16.1 — Portal intake, staff triage, DM association.

• .01DA-2028 form on the customer portal with structured locators + free-text recommendation and reason
• .02Staff triage modal — status pipeline, internal notes, customer-visible resolution
• .03DM association — link one 2028 to N DMs from a scoped picker (program's projects only)
• .04Documents view — per-DM count badge + "has open 2028s" filter, scoped to the current cycle
• .05Email notifier — admins (or a per-instance override address) notified on new submissions

Ironmark exports packages compatible with existing IADS-based delivery workflows, so a program can adopt a different authoring and repository platform without requiring immediate changes to downstream consumers. A visual builder scopes the content, orders the TOC, and produces the standard dataset.xml — plus a nested toc.xml for non-S1000D projects — that IADS packaging documentation describes.

Fig. 17.1 — Custom TOC editor with depth controls.

• .01Dataset metadata form — weapon system, revision, publish date, service branch, security marking
• .02All-content or pick-individually document selection
• .03Nested TOC editor with depth controls — chapters, sections, entries
• .04Or upload your own toc.xml built externally
• .05Automatic exclusion of non-content types (DDN, BREX, catalog) from the visual builder
• .06S1000D projects use the Publication Module for navigation; a separate TOC file isn't required

Maintain a register of every controlled copy issued. Track receipt confirmation, manage supersession and recall, and monitor expiry dates with automatic notifications.

Fig. 18.1 — Numbered copies with receipts and transmission references.

• .01Numbered controlled copies with classification markings
• .02Receipt confirmation and transmission reference tracking
• .03Supersession with automatic replacement issuance
• .04Expiry notifications with configurable lead time
• .05Full chain-of-custody audit trail per copy

A baseline freezes every document's version at a point in time and carries a contract reference. Re-publish from a baseline for a re-issue, diff two baselines to see what changed between deliveries, or bundle multiple baselines into a single export archive with per-baseline subdirectories.

Fig. 19.1 — Named baselines with contract references.

• .01Named, locked snapshots with contract references (CDRL number, delivery ID)
• .02Re-publish or re-export from any baseline without disturbing head
• .03Compare a baseline against the current head, or two baselines head-to-head — per-document version diff plus added / removed / changed documents between the two points in time
• .04Multi-baseline export archive: each baseline in its own subdirectory, graphics shared at the root
• .05Change-bar rendering can reference any baseline as the diff origin

Real-time dashboard for program managers showing document status, review pipeline, team activity, and automated alerts for overdue reviews and expiring copies.

Fig. 20.1 — Counts, pipeline, workload, and alerts.

Every program ships with a branded, customer-facing portal. Assigned customers see the current revision set, acknowledge receipt against a specific revision, and download the package from a URL you own — not a vendor's.

Fig. 21.1 — Subscribed program showing an outstanding acknowledgment.

• .01Per-program access grants — individual users or named recipient lists
• .02Release-note visibility and full prior-revision history on every deliverable
• .03Receipt confirmation gated by an ack-before-download setting when contractually required
• .04Email release notifications when a new revision is promoted
• .05CFI/GFI back-flow — customers upload furnished info against the program record
• .06Expiring, use-capped share links for contacts without portal accounts
• .07Every download logged with user, IP, and timestamp for audit
• .08Custom wordmark, logo, accent color, and CSS per install — airgap-safe, no CDN dependencies

Deliverables table with release notes on every revision, full history, downloads gated to acknowledgment when required, and a customer-side upload panel for CFI/GFI — visible to the contractor team from the same program record.

Fig. 21.2 — Expanded deliverable with release notes and prior revisions.

The internal Deliverables page groups every program's release history in one view. Compare revisions, promote or supersede, mint expiring share links, or review the CFI/GFI a customer has pushed back — without leaving the platform.

Fig. 21.3 — Contractor page with incoming CFI/GFI panel.