Everything a program office typically wants to know before evaluating Ironmark — standards, deployment, compliance, publishing, licensing, and migration. Reach out if we didn't cover yours.
Back to overviewIronmark supports the following standards out of the box:
Ironmark also provides bounded exchange and traceability support for S3000L, S4000P, S5000F, S6000T, and SX000i; see the capability matrix for the limits of each package.
New standards can be added through Ironmark's pluggable SDM (Standard Definition Map) system without modifying the core application. Ironmark does not redistribute specification schemas. Each standard package ships with a permissive stub, and a customer-provided official schema or DTD enables full conformance validation.
Yes. Each project in Ironmark is associated with a specific standard, but a single installation can host projects across all supported standards simultaneously. You can also link projects across standards using the cross-standard traceability feature — for example, tying an S3000L logistics support analysis to the S4000P preventive maintenance program it justifies, to the S1000D procedural data modules that document each task, to the GEIA-STD-0007 provisioning records that source the parts, and to the MIL-STD-40051 technical manual that references the same content.
Cross-standard traceability lets you group projects from different standards into a program group and trace relationships across the full Integrated Logistics Support (ILS) lifecycle. Typical links include:
Ironmark extracts exact identifiers — part numbers, NSNs, CAGE codes, EIAC and DMC codes, LSA candidate IDs, and work-package numbers — and proposes matching relationships for review. A reviewer confirms a proposal before it enters the bidirectional traceability matrix; rejected proposals are remembered. Discovery and review are currently API-driven rather than a dedicated visual traceability workspace.
Yes. Ironmark can author and ingest GEIA-STD-0007C (Logistics Product Data). A starter document model supports creating and editing GEIA datasets, while bulk ingest accepts records from an upstream LSA tool. The package ships with a permissive stub schema; upload the customer-provided official SAE XSD from Appendix C for full conformance validation. See GEIA-STD-0007 on Ironmark for more detail.
GEIA-STD-0007 data cross-links to S1000D and MIL-STD-40051 technical manuals through the traceability system, and ties through the S-Series ILS suite (S3000L LSA / S4000P PMA / S5000F ISF / S6000T training) when those projects are in the same program group.
Yes. The SDM system accepts XSD, DTD, and RelaxNG schemas. You create a package directory with a manifest, schemas, XSLT transforms, and element definitions, then install it through the admin panel or drop it into the packages directory. No code changes are needed. Custom SDM development is also available as a professional service.
Ironmark is a self-hosted web application. It runs on your own infrastructure — a Linux server, VM, or container — and is accessed through a browser. There is no cloud dependency and no data leaves your network.
The stack is Python (FastAPI) + React, with MySQL 8 for production. A single-command setup script handles installation, database migration, and admin account creation.
Note: Ironmark is not SaaS. A hosted evaluation instance may be provisioned solely for a time-limited trial before installation. Production deployments are customer-installed on customer-controlled infrastructure. See 10.02 for the framing.
Yes. Ironmark has no external network dependencies once installed. All processing — XML validation, XSLT transforms, PDF generation — happens locally on the server. There are no telemetry, analytics, or license-check callbacks.
Installation networking. "Zero outbound calls" refers to the running Ironmark application, not necessarily the installation process.
Installation requirements depend on your deployment approach. The standard install.sh workflow retrieves operating system dependencies from your Linux distribution's package repositories and, if you choose to use Let's Encrypt, communicates with the ACME service to obtain a TLS certificate.
Ironmark can also be installed in fully offline environments by staging required operating system packages on an internal repository (or extending the bundled debs/ directory) and supplying your own TLS certificate.
Regardless of the installation method, once Ironmark is installed and running it makes no outbound network calls of its own unless you configure one: OIDC to your identity provider, an SMTP relay for notifications, or the opt-in dependency-CVE check.
Minimum: 2 CPU cores, 4 GB RAM, 40 GB disk, Ubuntu LTS (install-tested; other Linux distributions are viable), MySQL 8+ (the streamlined installer sets up a local MySQL instance for you; existing customer database servers are supported as well). Recommended for programs with 10+ authors: 4-8 cores, 16 GB RAM. The application is lightweight — the primary resource consumers are PDF rendering (XSL-FO) and large XSLT transforms.
Client-side: any modern browser (Chrome, Firefox, Edge, Safari). No plugins or desktop software required.
Ironmark supports local username / password authentication, FIDO2 / WebAuthn security keys (YubiKey, passkeys) for passwordless sign-in, and PKI client-certificate authentication via nginx mTLS. The admin panel controls which methods are available on the login page. Users register their security keys in Preferences → Security Keys; discoverable credentials are used so no email is needed at sign-in — just tap the key.
Additional providers (LDAP / Active Directory, OIDC / Azure AD / Okta) are implemented but pending field validation against real customer environments — contact us if you need one of these for an evaluation and we will work through deployment together.
Not necessarily. Installation requirements depend on how you choose to deploy Ironmark.
The standard install.sh workflow downloads operating system dependencies from your Linux distribution's package repositories. If you choose to use Let's Encrypt for TLS, the installer also contacts the ACME service to obtain a certificate.
For disconnected or controlled environments, Ironmark can be installed entirely offline by staging the required operating system packages on an internal repository (or extending the bundled debs/ directory) and supplying your own TLS certificate.
Regardless of the installation method, once Ironmark is installed and running the application itself makes no outbound network calls unless you configure one: OIDC to your identity provider, an SMTP relay for notifications, or the opt-in dependency-CVE check. There are no telemetry, analytics, license verification, or other application-initiated external connections.
Yes. Every Ironmark purchase includes remote installation assistance. If you encounter issues during installation or configuration, we'll work with you to get the system running successfully.
Ironmark implements controls from NIST SP 800-171 Rev 2 that apply at the application layer, including:
Infrastructure-level controls (encryption at rest, network segmentation, etc.) depend on your hosting environment.
Ironmark is self-hosted software designed for customer-controlled and disconnected environments. Publication content, graphics, and published output remain on your server. The application sends no telemetry and makes no outbound connection by default; optional OIDC, SMTP, and dependency-vulnerability checks contact only the services you configure. Security classification markings are tracked per document and project. Controlled copies support recipient acknowledgment, expiry dates, expired-state reporting, and scheduled notifications; Ironmark does not remotely revoke a downloaded copy.
That said, Ironmark provides the tools; the determination — whether a specific document is CUI, whether a specific recipient is authorized, whether your handling controls satisfy your program's security plan — sits with you, your security officer, and your program. Marking a document, encrypting a copy, or logging a download are controls, not authorizations. Applies to CUI, ITAR / EAR, distribution statements, and any other handling category your program is bound by.
Ironmark ships with a number of features intended to support users with different visual, motor, and cognitive needs:
prefers-reduced-motion preferencenav, main, aside, header, footer) used throughout the React shellWe do not currently claim formal Section 508 or WCAG 2.1 conformance. A full third-party accessibility audit and VPAT have not yet been completed. Dedicated screen-reader tuning, focus-trap infrastructure inside modals, and a bundled dyslexia-friendly font are not shipped today. If your procurement process requires a VPAT, please contact us — we can discuss the current state, known gaps, and timeline. We treat accessibility issues as product defects and prioritize them alongside other software defects.
Ironmark gives you tools, not authorization. Distribution-tier gating on Support Packages, AES-256-GCM encryption for controlled data, mandatory passphrases + SHA-256 integrity for restricted tiers, and a full audit trail on generation and access all help demonstrate handling controls. But the export-control determination itself — whether a specific document can leave your network for a specific recipient — is your responsibility, your security officer's, and your program's. Every Support Package modal carries a compliance reminder to that effect so authors don't confuse tier selection with authorization.
Yes. Your data remains your data. An expired license does not prevent you from exporting your repository or other customer-owned data. A valid license is required to publish new deliverables using Ironmark's publishing features. If a former customer has a legitimate need to perform a final publication, Ironmark may issue a short-term license at its discretion.
Concretely: reads always work, and every project has two built-in exports (IADS-compatible package, plain archive — see 7.02) that keep working regardless of license state. Only new publishing / authoring is gated. Nothing about the software itself changes when a license expires — no components uninstall, no data is deleted; you keep signing in and pulling your content out.
OpenID Connect (OIDC) is supported for enterprise SSO integrations (see 2.04 for the general posture). CAC / PIV smartcard authentication is supported on on-prem and airgap deployments via nginx client-certificate TLS: the reverse-proxy validates the smartcard against the issuer trust chain and maps the certificate subject to a local user record. LDAP / Active Directory is also implemented via python-ldap3. Native SAML 2.0 is not currently shipped — customers whose IdP fronts only SAML typically add an OIDC bridge (Okta, Azure AD B2C, Ping) at their identity layer.
Consistent with 2.04, our OIDC, LDAP, and CAC-via-mTLS paths are implemented against generic providers but individual vendor integrations (Okta, Azure AD, specific DoD CAC issuers) are pending field validation against real customer environments. For controlled deployments, the integration path is discussed on a per-program basis — contact us with your identity-provider details and we'll scope the work.
Ironmark is not FIPS-140 validated. A requirement for validated cryptography must be evaluated against the exact operating system, cryptographic modules, application configuration, and system boundary used by the customer. Ironmark does not claim that every cryptographic operation automatically traverses a validated module.
Because those are two different things.
A license changes what you're entitled to use. An update changes what code runs.
Ironmark separates the two:
The split matters most in controlled and accredited environments, where the person authorized to sign a license order isn't usually the same person authorized to push new code onto a platform inside an accredited boundary. Panel-driven software updates are off by default; the CLI (install.sh --upgrade over SSH) is always available for operators who prefer to keep the update path off the app entirely.
ironmarkpdf renderers, or an optional configured XSL-FO enginedataset.xml plus, for non-S1000D projects, a nested toc.xmlYes. Each SDM package can include custom XSLT transforms and XSL-FO stylesheet options, with multiple output profiles per standard. A FOSI can be used directly: upload a program's existing FOSI and publish from it. The FOSI is rendered by an in-box engine, to XSL-FO and then to PDF, with no Arbortext and no Java. Ironmark reads the FOSI as it is rather than converting it into an XSLT for you to maintain, and some formatting characteristics are unmapped — compare output against your current publisher before adopting it.
Yes, through the in-box ironmarkpdf renderer. Its -pdfa command-line option emits PDF/A-1b with font embedding, an sRGB output intent, XMP metadata, a PDF 1.4 header, and transparency disabled.
PDF/A is not currently exposed as a per-publication option in the web interface or REST API. The standard WeasyPrint output and optional external formatters are not automatically asserted as PDF/A by Ironmark. An external formatter such as Antenna House may provide its own separately licensed PDF/A profile.
Yes. Ironmark includes an integrated CGM-to-SVG converter (also available as the open-source cgm2svg tool) that handles ATA GREXCHANGE, WebCGM, CALS, and PIP profiles. CGM files are automatically converted for browser display and can be included in published PDF and IETP output. Hotspots, colour tables, and dark-background illustrations are supported.
CGM is a complex binary format with many encoder dialects, and the converter does not yet handle every edge case. Known limitations include: embedded raster cell arrays render as placeholder rectangles (no pixel-level decode), CALS V1 Hershey stroke fonts fall back to system fonts, partial elliptical arcs render as full ellipses, and APS hotspot proximity filtering is tuned for Army TM files and may need adjustment for unusual datasets. The full list lives in the cgm2svg README. We treat conversion failures as bug reports and welcome sample files.
Automatically, from a structural diff between the current XML and a chosen baseline snapshot. At publish time, Ironmark loads the baseline (either the most-recent baseline, or an explicit revision you name), fingerprints every element in both trees, and stamps data-change="added|modified|deleted" attributes on elements the current tree adds or edits. Deleted content is marked with a marginal deletion sentinel because the element itself is no longer in the current tree.
The published stylesheets (XSL-FO for PDF, WeasyPrint for HTML) match on those attributes and emit standard fo:change-bar-begin / fo:change-bar-end markers or CSS left-border highlights. Enable per project in Project Settings → Change Bars. No manual markup required — you never touch a <change> element by hand.
Yes, and it's configurable. When an IPRF review closes with the "approved" aggregate, Ironmark bumps <issueInfo issueNumber> and resets inWork to 00 on the reviewed DM. That matches the S1000D convention that approval cuts the next issue. Toggle in Project Settings → Approval Workflow → Auto up-issue on approval — default on. Programs that up-issue manually at delivery time can switch it off; during authoring, inWork still increments on every check-in regardless.
For MIL-STD-40051 and MIL-PRF-63029 full-manual publishing, Ironmark generates a work-package or chapter-level LEP/LOAP from the publication rows as a stage of the publish pipeline. Standalone chapter or section publishes do not receive one automatically. The current generator does not expand document revision history into per-DM issue and date rows.
Documents move through configurable workflow states: Draft → Pending Review → Approved (or Rejected). Checkout / checkin prevents concurrent editing conflicts. Reviewers can add inline redline comments with position tracking. QA and admin users can approve or reject with a single click. All state transitions are logged in the audit trail.
Licensing is seat-based in 5-, 10-, or 25-seat bands. Within those seats, Ironmark does not impose a separate concurrent-session cap. Required capacity depends on document volume, publishing workload, storage, integrations, and usage patterns; sizing should be established for the customer's workload rather than inferred from an unqualified hardware baseline.
Yes — through two different mechanisms depending on what the external person needs to do.
The viewer role is for external reviewers who need to read in-flight documents and submit redline comments without participating in the authoring workflow. Viewer accounts are scoped to specific projects via project membership; submitted redlines flow into the QA queue for the authoring team to triage.
The customer role signs into the branded Deliverables Portal that ships with every program: released-revision downloads with release notes and full revision history, receipt acknowledgment, CFI/GFI back-flow, per-program recipient lists, email notifications on release, expiring share links for contacts without portal accounts, and a complete per-download audit trail.
The Deliverables Portal is optional. It is bundled with every install because it is useful to have on hand, but nothing in Ironmark requires it. Contractors and customers are free to arrange deliveries however they prefer — email the IADS-compatible package, hand off a hard drive, drop the release into an existing SFTP or file share, or use whatever delivery mechanism is already stipulated in the contract. Ironmark produces the deliverable; the transport is your call.
Because Ironmark is self-hosted, how external users reach the system (portal or otherwise) is up to you. Customers typically expose access through their own VPN, reverse proxy, mTLS gateway, bastion host, or other approved network path that fits their existing security policy. Ironmark does not provide or manage the network transport itself.
Two pieces working together. The Asset Registry is your list of concrete tail numbers, hull numbers, or configurations with their applicability attributes. A "sync from XML" pass reads your project ACT / PCT DMs and adds new assets it finds while updating the ones already registered — with a dry-run diff preview so you approve the changes before they land. The Applicability Wizard in the editor sidebar shows per-DM coverage (elements carrying applicRefId, orphaned-ref check against the ACT, unused-id hint) and a preview-for-asset button that filters the DM through the applicability evaluator for a picked asset — rendered WYSIWYG, not raw XML.
On the Documents page there's an asset filter: pick a tail number and the list narrows to DMs that apply. MIL-STD-40051 <uoc> child elements are handled alongside S1000D applicRefId because SDM manifests declare the condition-source shape per spec.
Yes. The Parts Browser indexes every IPD (S1000D) and RPSTL (MIL-STD-40051) in the project so you can search by part number, NSN, CAGE code, or description across the whole TM at once. The detail drawer shows every figure appearance with open-in-editor per row, part-swap history, and the project's asset roster.
Parts can be linked to a project-level Canonical Part (one per project, per PN + CAGE) for canonical reference and conflict reporting. Promotion does not rewrite source descriptions or automatically normalize BOM and publishing output.
Six built-in style rules cover double punctuation, consecutive spaces, stray whitespace, empty emphasis, warning punctuation, and repeated words. Every rule pairs a check with an auto-fix.
Author-side: a per-doc lint modal in the editor toolbar. QA-side: Documents → Lint Project runs the sweep across every DM and produces a summary with per-doc counts and top rules; the Documents-page column shows finding count so reviewers spot problem docs at a glance. Rules are extensible per SDM through the rule registry.
Yes, in CSV and Excel at file and project scope. Individual IPD and RPSTL documents have per-file BOM export. Project-scope export produces one consolidated workbook or CSV with a Source Document column; it does not currently create separate per-document sheets and a summary sheet.
Yes. Customers submit DA Form 2028s (or a lighter civilian redline variant) from the portal with structured locators — page, paragraph, line, figure, table — plus a recommendation and reason. On the Deliverables page, staff triage each submission through a pipeline (submitted → triaged → accepted / rejected / duplicate / closed), leave internal notes, and set a customer-visible resolution.
The triage modal also lets staff attach the 2028 to one or more DMs from a scoped picker (only the program's linked projects, no cross-program mistakes). The Documents page then shows an open-feedback count badge per DM and a "has open 2028s" quick filter — the ask lands on the author's list, not in a mailbox. Submissions email admin users (or a per-instance override address) so nothing goes unnoticed while the portal is quiet.
No — deliberately. Check-in count is a bad signal in isolation because WP size varies wildly by type (one long troubleshooting WP is not equivalent to twenty general WPs). The PM Dashboard shows twelve-week project-level velocity by default: check-ins per week alongside chars added, with a median-WP-size band for calibration. The per-author drill-down is gated to PM / admin and shows three signals side-by-side (check-ins, chars added, average per check-in) — no composite score, no leaderboard.
Also in the tab: aging open-redline buckets (0–7 / 8–30 / 31+ days), publish-failure streaks grouped by error class. It's built to answer "is delivery pacing on track" and "where is the queue getting stuck," not "who is fast."
Ironmark Technical Publications Platform is sold as an annual self-hosted term license in 5-, 10-, and 25-seat bands. Every license includes the full platform — there are no feature tiers or per-document fees. Ironmark's integration points for external XML editors, formatters, identity providers, and the REST API are included; any license required by the third-party product remains the customer's responsibility. Specialty SDM packages beyond the standard set may be quoted separately. Academic and evaluation licenses are also available. See the pricing guide for details. For which roles consume seats and which are unlimited, see 6.02.
Only designated authoring roles consume seats. Roles that read, approve, deliver, or administer the platform are unlicensed and unlimited.
Licensed authoring roles — each active user with one of these consumes one seat:
Unlicensed roles — no seat, no per-user fee, no cap:
Two-account pattern. A person who both authors and, say, does QA gets two accounts — one licensed (author), one unlicensed (qa) — and signs into whichever fits the task. Separate accounts preserve an unambiguous audit trail between content creation and approval. The same pattern applies to admins who also author.
How seats are counted. Ironmark counts assigned licensed-role users, not "logged in recently". Granting the Author role to a 6th person on a 5-seat license triggers the overage immediately — a short grace period lets you either reduce the assignment or extend the license before authoring is disabled. Deactivating a former user (Admin > Users > Edit → uncheck Active) releases the seat without deleting their history. See 3.05 for what stays available when the license lapses entirely.
Yes. cgm2svg is released under the MIT License and may be used in commercial and government projects subject to that license. Other tools will be listed here only when their public repositories and licenses are available.
Your data is yours and it leaves as standard XML for whichever specification your project uses. With the customer-provided official schema or DTD installed, Ironmark reports full conformance validation against that specification; the bundled permissive stub provides structural handling when the official package is not installed. There is no proprietary format, export fee, or required conversion. Two export formats ship on day one: an IADS-compatible package and a plain ZIP / tar.gz archive with per-baseline subdirectories.
We don't lock you in because we don't need to.
Yes. A 30-day full trial is available — not a guided walkthrough, but a real instance where you exercise the workflow on your own documents. Access is provisioned once we confirm the request is legitimate. Contact us at info@ironmark-authoring.com or use the contact form.
Yes. Ironmark supports bulk import of existing XML documents. For S1000D, imports create CSDB entries and extract supported identifiers and relationships; MIL-STD-40051 identifiers are also tracked. General bulk import does not enforce BREX or full structural validation. After import, validation can be run on demand, with full specification-schema results available when the customer-provided official schema or DTD is installed for the project.
Every project has two built-in export options — no premium tier, no paid module. Both ship with every install:
dataset.xml plus, for non-S1000D projects, a nested toc.xml.documents/, graphics/, and a human-readable manifest at the root. When you select more than one revision (e.g. current + one or more baselines), each revision lands in its own subdirectory so a CDRL package can bundle historical + current in a single zip.Exports include the full source XML plus every referenced graphic. With the customer-provided official schema or DTD installed, Ironmark reports full conformance validation against the project's specification; otherwise the bundled permissive stub provides structural handling. There is no proprietary format, export fee, or required conversion. Documents produced by legacy conversion carry any unmapped source attributes under a data-legacy- prefix so nothing is lost silently; they are ordinary XML attributes, itemised in the conversion report, and some strict schemas will flag them until an author resolves them. See the No Lock-In section on the overview for the full framing, or the IADS Builder section for how the package is assembled.
No. Your data is yours. It leaves as standard XML for your project's specification. Full specification-schema conformance is reported when the customer-provided official schema or DTD is installed. There is no proprietary document format, export fee, or required conversion. Your manuals remain your manuals.
Every project ships with two exports on day one:
That content opens immediately in any compliant authoring environment. Use Ironmark's browser editor, Oxygen, Arbortext, or another XML editor. Integrate through our REST API. If you ever decide Ironmark isn't the right fit, your content leaves with you.
We don't lock you in because we don't need to.
Existing S1000D or MIL-STD-40051 XML can be brought in through bulk import and then validated against the project's customer-provided schemas or DTDs. A program's existing FOSI can be published from directly. ACL scripts, editor frameworks, vendor-specific stylesheet extensions, and other environment-specific customization still require a separate migration assessment.
Yes. The Ironmark Desktop Launcher is a small Windows helper that round-trips a document through the author's preferred XML editor. In the Ironmark web editor, an author clicks Open in Desktop Editor; the launcher checks the document out of the CSDB, drops the XML into a temporary file, and opens it in the configured editor (Oxygen, Arbortext, VSCode, or any other editor that reads an XML file path from the command line). Each save flushes to the server as a working-copy update. Closing the editor performs the final check-in and produces a new document version. If the author already has the document checked out from a previous session, a Continue in Desktop button resumes that checkout instead of opening a new one.
Check-in, check-out, review, applicability, parts, publishing, and audit still flow through the Ironmark server, so review queues and publishing pipelines see the same document regardless of which editor produced the XML.
The launcher installs to %LOCALAPPDATA% and requires no admin rights. It stores its configuration under the user's profile only. System administrators can hide the download entirely (setting launcher_download_enabled=false) or force per-user API-token authentication instead of browser-minted session tokens (setting launcher_auth_mode=manual_pat) when program policy requires it. The current release targets Windows only.
Three levels of packaging and audit, matched to how sensitive the content is:
Regardless of tier, a compliance banner on the generate modal reminds the operator that packaging is a control, not an authorization — the export-control determination sits with your security officer and program.
Turned on with a checkbox on the generate modal. The goal is to let a customer share the shape of their repository — the exact conditions that reproduce a defect — without shipping proprietary content.
Preserved:
<uoc>) — id strings themselves are structural, so the graph is intactmodelIdentCode is rewritten, and the output filename is renamed to matchScrubbed: every attribute value not in the structural allowlist (PN, CAGE, NSN, serial, tail number, model ident, personal names…) is replaced with a consistent shape-correct fake. Text bodies in <title>, <para>, <description>, addresses, and similar free-text elements are replaced with length-preserving lorem-ipsum.
The package does not include a mapping file from sanitized values back to originals. Substitutions remain consistent so relationship patterns are usable. The current implementation is deterministic and does not provide a fresh randomized mapping for every package, so separate packages may be correlatable and predictable source values should not be treated as cryptographically unrecoverable.
Sanitization reduces disclosure; it is not a proof of anonymization. Review the preview and scrub report before sharing a package through the program's approved data-handling channel.
Yes. When the sanitize checkbox is on, a Preview button on the generate modal opens a side-by-side view of any one document from the project — original XML on the left, sanitized XML on the right — plus scrub statistics (attributes scrubbed, text nodes replaced, distinct identifiers remapped). You verify the substitutions look right on one document before committing to a whole-package generation.
Yes. Every UI surface is backed by a REST API with an OpenAPI spec (browse at /api/docs; the ReDoc view at /api/redoc is admin-authenticated). Authentication is by Personal Access Token — self-service, per-user, generated from the API Keys page in the sidebar and prefixed iak_. Two scopes are available: api_readonly (GET / HEAD / OPTIONS) and api_full (any method). Admins can disable all user-issued PATs instance-wide with a single toggle, and non-admin PATs are capped to a short expiry.
Legacy machine-to-machine ingest tokens (for example S5000F feedback ingest from a partner system) continue to work with their existing credentials.
Yes. An administrator can generate and download a CycloneDX SBOM covering installed backend Python packages, npm packages present in the installation, runtime and operating-system metadata, and explicitly inventoried Swagger/ReDoc assets. The current generator does not claim comprehensive inventory of every bundled renderer or XSL processor. The SBOM is generated on demand and includes version and generation metadata.
Yes, through bulk XML import — see 7.01 for the mechanics. Ironmark's CSDB is a native re-implementation, not a wrapper around another CSDB product: DMC parsing, cross-reference extraction, SNS gap analysis, and DMRL generation all happen inside Ironmark. What you get from importing an existing CSDB is a fully populated new-project CSDB with your DMs and their metadata; from that point Ironmark manages it.
Export and REST API workflows can support integration with an external CSDB. Ironmark emits S1000D XML, but acceptance depends on the target system's issue, business rules, packaging profile, and import requirements. Compatibility should be validated with the named external CSDB.
No. XML authoring is one application within Ironmark. The XML editor is the primary interface authors interact with, but the repository underneath manages the relationships between documents, parts, assets, publications, workflows, and standards. Features like automatic DMC renames, cross-standard traceability, change bars, applicability, reports, and customer delivery are powered by that repository.
No. Ironmark is self-hosted software, sold as an annual term license in 5-, 10-, and 25-seat bands and installed on your own infrastructure — a Linux server, VM, or container inside your network. There is no multi-tenant cloud, no shared control plane, and no production data leaving your environment. The application, its dependencies, and its documentation ship as a single self-contained installer bundle so it can run in airgapped and controlled environments (see 2.02 for what installation itself requires).
A hosted evaluation instance may be provisioned solely for a time-limited trial before you install Ironmark (see 6.05). Production deployments are customer-installed on customer-controlled infrastructure.
Ironmark provides core CCMS functions including structured authoring, versioning, workflow, repository management, and publishing, together with technical-publication functions such as applicability, parts search, support packages, DA-2028 triage, and program reporting. Specific procurement requirements should be checked against the capability matrix rather than inferred from the CCMS label.
Yes, natively. S1000D DMC parsing, SNS tree with gap analysis, cross-reference extraction and broken-link detection, ICN (graphic) linking, BREX rule management, and DMRL generation are all first-class features of the platform — not a wrapper around another CSDB product. Full specification-schema validation is available when the customer-provided official S1000D schema package is installed. Existing CSDB content imports through bulk XML upload (see 7.01 and 9.03).
No. Ironmark produces packages designed for IADS-compatible delivery workflows; compatibility should be validated against the program's target viewer and profile. The reader-side experience runs in the viewer selected by the program.
Ironmark does have an in-tool preview that authors and QA use during development to inspect published content, but that preview is internal — customers never open it and it isn't part of any deliverable.
No. PLM covers the product lifecycle — engineering change, engineering release, manufacturing, and authoritative product data. Ironmark covers the technical-publication lifecycle. Parts data can be brought into publication content through supported XML and API workflows, but Ironmark does not currently claim a direct PLM connector or replacement for a PLM system.
Partially. The core Ironmark platform is proprietary and sold as an annual self-hosted term license (see §06). Several supporting tools we've built and maintain are open source and free to use standalone:
cgm2svg — CGM-to-SVG converter with ATA / WebCGM / CALS / PIP profile supportcgm2svg is available on GitHub under the MIT License and is also integrated with Ironmark. Additional projects will be listed only when their public repositories and licenses are available. Ironmark sends no telemetry and makes no outbound application connection by default; see 2.02 for the optional configured connections.
No — Ironmark doesn't perform logistics support analysis. It consumes and links to the outputs of an LSA tool. S3000L candidates, S4000P task references, S5000F feedback data, S6000T training analysis, and GEIA-STD-0007 LPD records can round-trip through the platform. Cross-standard discovery uses exact identifiers to propose links from those records to the S1000D or MIL-STD-40051 modules that document them; a reviewer confirms each proposal before it enters the traceability matrix.
No. Ironmark is not FedRAMP authorized. A customer may deploy it within an authorized environment, but inclusion in that system's boundary, control implementation, documentation, assessment, and authorization remains subject to the system owner's FedRAMP process. Deployment inside an authorized environment does not by itself confer authorization on Ironmark.