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:
New standards can be added through Ironmark's pluggable SDM (Standard Definition Map) system without modifying the core application. Each SDM package includes schemas, XSLT transforms, element definitions, templates, and publishing profiles.
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's auto-discovery engine scans for matching identifiers — part numbers, NSNs, CAGE codes, EIAC / DMC codes, S1000D DMCs, LSA candidate IDs, WP numbers — and creates traced links automatically. Links are bidirectional and a traceability-matrix report provides coverage statistics and confidence scoring (HIGH / MEDIUM / LOW) based on exact-match vs. fuzzy-match of identifiers and descriptions.
Yes. Ironmark supports GEIA-STD-0007C (Logistics Product Data), the current standard that replaced MIL-STD-1388-2B (LSAR) and MIL-PRF-49506. The package includes authoring support for all functional areas: product breakdown (EIAC/LCN), maintenance task analysis, provisioning, support equipment, training, manpower, facilities, and transportation data.
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 SQLite for development and MySQL / MariaDB for production. A single-command setup script handles installation, database migration, and admin account creation.
Note: Ironmark is not a SaaS. A hosted evaluation instance at demo.ironmark-authoring.com is a permanent part of the product so prospective customers can try it before installing (see 6.04). Fully-managed production hosting is still available for programs already on that path; the recommended shape for new deployments is customer-installed on customer 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. The application and all its dependencies can be installed from a single offline package.
Minimum: 2 CPU cores, 4 GB RAM, 20 GB disk, Linux (Ubuntu 22.04+ or RHEL 8+). Recommended for teams of 10+: 4 cores, 8 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.
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 designed to process CUI in a self-hosted environment. No data is transmitted to external services. All XML content, graphics, and published output remain on your server. Security classification markings are tracked per document and per project. The controlled copies feature tracks all distributed copies with recipient acknowledgment and automatic expiry.
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 on the accessibility roadmap but 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 raised by users as bugs and address them as we encounter them.
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 three one-click exports (IADS-compatible package, IETP-X, 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 uses standard OpenSSL for TLS and Python's cryptography package for at-rest encryption (AES-256-GCM for Support Packages, bcrypt for passwords, SHA-256 for integrity). Neither Ironmark itself nor those upstream libraries carry a current FIPS-140 module certificate — that certification lives with the underlying crypto module, not the application. For deployments that require validated crypto, we run against a FIPS-mode OpenSSL provider (RHEL / UBI FIPS builds, or the Red Hat FIPS OpenSSL provider) so all crypto operations traverse a validated module. Contact us if you have a specific FIPS-140-2 or FIPS-140-3 module requirement to name in a procurement package.
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.
dataset.xml plus, for non-S1000D projects, a nested toc.xmlYes. Each SDM package can include custom XSLT transforms and XSL-FO stylesheet options. You can add multiple output profiles per standard — for example, a customer-facing style and an internal review style. If you have legacy FOSI stylesheets, our open-source fosi2xslt tool can convert them to XSL-FO for use in Ironmark. The conversion is intended as a strong starting point — the resulting XSL will typically need some tuning to match the original output exactly, but it eliminates the bulk of the manual rewrite work.
Not today. Ironmark's PDF output is produced by WeasyPrint, IronmarkPDF (XSL-FO for 40051), or an admin- or project-defined formatter (Apache FOP, Antenna House Formatter, etc.) — none of which Ironmark gates for PDF/A-1b conformance. No font-embedding check, XMP metadata emission, or sRGB output-intent enforcement is applied by Ironmark on the published PDF. Downstream, published PDFs can be run through a converter (Ghostscript, Adobe Acrobat, or a dedicated PDF/A profiler) and validated with veraPDF before submission.
Note: Antenna House Formatter can be configured with a PDF/A output profile in its own settings — if you register AH as the project formatter, its PDF/A guarantees flow through unchanged.
Native, Ironmark-side PDF/A output on a per-publish opt-in is on the delivery roadmap. For programs that require PDF/A archival deliverables as part of the acceptance package, please raise it during scoping so we can prioritize appropriately.
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.
Every time a full publication assembles. The LEP walks the manifest for the pub, resolves each entry to its approved DM revision, expands change history into per-DM issue/change/date rows, and writes a fresh LEP front-matter section. You don't schedule it and you don't rebuild it separately — it's a stage of the publish pipeline.
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 (5, 10, or 25 seats — see the pricing guide), so the number of named users is governed by the seats on your license. Within those seats, there is no artificial cap on concurrent sessions — capacity is bounded only by the hardware Ironmark is hosted on. The async Python backend handles concurrent connections efficiently and comfortably supports small-to-mid-sized programs on a modest baseline (4 cores / 8 GB RAM); larger deployments scale with additional CPU and memory. We can advise on sizing based on document volume and authoring patterns once we understand the specific workload.
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 most programs find it convenient, but nothing in Ironmark requires it. Contractors and customers are free to arrange deliveries however they prefer — email an IETP-X archive, 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 promoted to a Canonical Part (one per project, per PN + CAGE) — a CIR-analog with description, NSN, consumable flag, and notes. When you promote a PN that has multiple description spellings across the TM, the promotion links every catalog entry to the canonical row so downstream deliverables see a consistent name. The Data Conflicts tab surfaces PNs where description drift hasn't been canonicalized yet.
Ten built-in rules, five of which auto-fix. Rules cover the drift schemas can't catch — orphan step references, empty admonition bodies, non-standard signal words, missing part descriptions, over-long procedural steps, stub or empty documents, and similar. The auto-fix rules apply directly to the XML with a diff preview; the report-only ones link back to the offending element in the editor.
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, both CSV and Excel, at file and project scope. Individual IPD / RPSTL DMs get a per-file BOM Export button in the editor. Project-scope export bundles every IPD + RPSTL DM into one workbook with per-DM sheets and a summary. MIL-STD-40051 RPSTL work packages are covered through an SDM-declared parts_element so both specs use the same export path.
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, and a Legacy Conversion burn-down chart for programs running a migration in parallel. It's built to answer "is delivery pacing on track" and "where is the queue getting stuck," not "who is fast."
Ironmark Authoring Suite is licensed per seat on an annual subscription basis. Every license includes the full platform — there are no feature tiers, no per-document fees, and no add-on charges. Volume pricing starts at 5 seats. Academic and evaluation licenses are also available. See the pricing guide for details. For which roles actually consume seats vs which are unlimited, see 6.02.
Only the roles that author or approve content consume seats. Roles that read, review, 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. Our open-source tools (cgm2svg, fosi2xslt) are released under the MIT License. You can use them freely in commercial and government projects with no licensing fees. Commercial support agreements are available if you need guaranteed response times, custom development, or integration assistance.
Your data is yours and it leaves in the same format it arrived — standard, validated XML conforming to whichever standard your project uses (S1000D, MIL-STD-40051, MIL-PRF-63029J, etc.). There is no proprietary format, no export fee, and no conversion required. Three export formats ship on day one: IETP-X, an IADS-compatible package for existing IADS-based pipelines, and a plain ZIP / tar.gz archive with per-baseline subdirectories. You can open that content in any compliant authoring tool immediately.
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. Quick approval keeps misuse down. Contact us at info@ironmark-authoring.com or use the contact form.
Yes. Ironmark supports bulk import of existing XML documents. For S1000D, CSDB entries are automatically created with full DMC parsing, cross-reference extraction, and ICN (graphic) linking. For MIL-STD-40051, work-package numbers and TM numbers are tracked. Validation is run on import so you immediately see any schema or BREX issues.
Every project has three one-click export options built in — no premium tier, no paid module. All three 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 — validated against the standard the project uses — plus every referenced graphic. There is no proprietary format, no export fee, no conversion required. See the No Lock-In section on the overview for the full framing, or the IADS Builder section for how the package is assembled.
Straightforward for the data — your XML documents are standard S1000D or 40051 XML and import directly. Stylesheets may need conversion: if you have FOSI formatting, fosi2xslt can convert them to XSL-FO as a starting point (some hand-tuning is usually required to match the original output exactly). Custom Arbortext ACL scripts or Oxygen frameworks don't carry over, but Ironmark's SDM system and element palette cover the same use cases differently. We can assist with migration planning.
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.
No — deliberately one-way. The package includes only the sanitized XML plus a summary of what categories were scrubbed. No mapping file ships alongside, so there's no way to recover the originals from the delivered package. If diagnosing a defect turns out to need a specific real value, that has to be shared separately through your normal controlled-data channel — sanitization can't be an accidental leak vector.
Substitutions are deterministic within one package (the same input PN becomes the same fake PN across every doc in the package, so cross-doc links keep resolving), but each new package gets fresh mappings. That's intentional too — two shared packages of the same project can't be correlated to re-derive originals.
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. The Admin panel has an SBOM section that generates a CycloneDX SBOM covering the backend Python packages, frontend npm modules, and bundled binaries (PDF renderers, XSL processors, etc.). Download is admin-only. We regenerate on every release; the file's version and generation timestamp are included so procurement reviewers can compare against the running deployment.
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.
Round-tripping to and from an external CSDB (for programs that need to keep an authoritative repository elsewhere) is scriptable via the REST API — the DM export path emits standard S1000D XML that any conforming CSDB will accept. Contact us if you're looking at a specific integration pattern with a named external CSDB and we'll advise on the shortest path.
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, licensed per seat 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 offline installable package so it works in airgapped and controlled environments (see 2.02).
A hosted evaluation instance at demo.ironmark-authoring.com is a permanent part of the product so prospective customers can try Ironmark before installing it themselves (see 6.04). Fully-managed production hosting is still available today for programs already on that path, but the recommended shape for new deployments is customer-installed on customer infrastructure — production data belongs where the program controls it.
Yes, and more. Every capability a CCMS typically ships — reusable components, versioning, workflow, publishing — is in there. What sits around it is the platform layer: customer portal, applicability wizard, parts browser, support-package generation with sanitize, DA-2028 triage, PM dashboard. If a CCMS is the middle of your delivery pipeline, Ironmark covers the middle and the two ends.
Yes, natively. Full S1000D DMC parsing and validation, 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. Existing CSDB content imports through bulk XML upload (see 7.01 and 9.03).
No — Ironmark produces IETP-X packages that any conforming viewer opens. It also produces packages compatible with existing IADS-based delivery workflows for programs whose downstream uses IADS. The reader-side experience runs in whatever viewer your program has standardized on; Ironmark doesn't replace it.
No. PLM covers the product lifecycle — engineering change, BOM management, engineering release, manufacturing routings. Ironmark covers the TM lifecycle — authoring, review, publishing, delivery, and support of technical publications about that product. The two overlap at the parts list; Ironmark's Parts Browser and IPD/RPSTL BOM export are designed to consume from a PLM's authoritative parts data and produce publication-ready parts content, not to replace the PLM.
Partially. The core Authoring Suite is proprietary, licensed per seat, and self-hosted (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 supportfosi2xslt — FOSI-to-XSL-FO converter for migrating legacy stylesheetsBoth are on GitHub and used inside Ironmark as well as by any team that wants them separately. Airgap-safe: nothing in the Suite phones home, all dependencies are bundled at install time.
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 all round-trip through the platform: import the analysis data as its own project, and cross-standard traceability (§10 on the overview page) auto-links the LSA references to the S1000D or 40051 modules that document them.
No. FedRAMP applies to cloud services, and Ironmark ships as a self-hosted / airgap-capable application. If your program requires FedRAMP, the pattern is to run Ironmark inside a FedRAMP-authorized environment (a customer- or contractor-operated boundary that carries the authorization) — the underlying platform then inherits the environment's controls. Contact us if you need help mapping Ironmark's control set to your FedRAMP System Security Plan.