Home → Capability matrix
Capability matrix
What exists, stated precisely enough to argue with.
The rest of this site explains why these capabilities matter. This page answers the narrower question of what is implemented, and under what constraint. Where a capability is bounded, the bound is in the row rather than in a footnote.
How to read this matrix.
A mark means Ironmark implements the capability described in that row. It does not imply capability beyond the stated scope. Where support is version-specific or constrained, the version or limitation is stated explicitly in the qualification column — that column is the claim, not decoration.
- ✓
- Supported. Implemented and available.
- ◐
- Bounded. Implemented within the stated limit. Read the qualification before assuming the general case.
- —
- Not provided. Intentionally absent, not a roadmap gap.
Standards
Two different relationships. Ironmark authors the narrative technical-manual standards: there is an editing UI, document templates and a publishing path. It exchanges the S-Series analysis and feedback standards: they are ingested, cross-linked and re-emitted as exchange bundles. Each S-Series package does register a single dataset document type you can create and edit, but none of them offers the multi-document authoring model the narrative standards do — the depth is an order of magnitude apart, and that difference is the honest version of the distinction. Both are useful; they are not the same claim.
| Standard | Author | Ingest | Schema validation | Cross-link | Exchange export | Qualification |
|---|
| S1000D 4.2 / 5.0 / 6.0 | ✓ | ✓ | ◐ | ✓ | — | Native authoring, per issue. Ironmark ships a permissive stub schema; upload the official S1000D specification package to enable full schema conformance. BREX validation works either way. |
| MIL-STD-40051E | ✓ | ✓ | ◐ | ◐ | — | Native authoring; 11 work-package and front-matter document types. Structural stub schema — upload the Government DTD for full validation. Cross-links by part number, NSN, CAGE and model-ident code, not by S-Series identifiers. |
| MIL-STD-40051-3C | ✓ | ✓ | ◐ | ◐ | — | As above. Also MIL-STD-40051E w/Change 1 (30 July 2025) as a separate package. |
| MIL-PRF-63029J | ✓ | ✓ | ◐ | ◐ | — | Native authoring. Structural stub schema. Cross-links by part number / NSN / CAGE as above. |
| GEIA-STD-0007C | ✓ | ✓ | ◐ | ✓ | — | Logistics product data, authored and ingested. Stub schema — overlay the official SAE XSD from Appendix C. Contributes EIAC, LCN, part number and NSN identifiers to the graph. |
| S3000L 3.0 | ◐ | ✓ | ◐ | ✓ | ✓ | Intended for exchange. Ships a permissive stub; upload the official S-Series schema package to enable full conformance. One dataset document type is registered with a starter template and element model, so a dataset can be created and edited — but this is not a multi-document authoring environment the way S1000D or MIL-STD-40051 is. Breakdown elements, parts, tasks and components extracted verbatim. |
| S4000P 3.0 | ◐ | ✓ | ◐ | ✓ | ✓ | Intended for exchange. One dataset document type with a starter template, but no element model, so editing assistance is thinner than the other S-Series packages. Preventive-maintenance task and analysis identifiers, matched against S3000L breakdowns and the S1000D data modules implementing each task. |
| S5000F 4.0 | ◐ | ✓ | ◐ | ✓ | ✓ | Intended for exchange. One dataset document type with a starter template and element model. Ingest over authenticated REST or as a file; schema validation occurs during ingest when the required schema is available. BREX remains available through the normal on-demand validation workflow. |
| S6000T 3.0 | ◐ | ✓ | ◐ | ✓ | ✓ | Intended for exchange. One dataset document type with a starter template and element model. Learning objectives and competencies, matched against S1000D content and S3000L competency libraries. |
| SX000i 4.0 | ◐ | ◐ | ◐ | — | — | Ships a permissive stub; upload the official schema package for full conformance. One document type with a starter template and no element model. No identifier extraction and no exchange export — it is not wired into the traceability graph, and is the least developed package in the set. |
On stub schemas. Ironmark does not redistribute any specification schema. S1000D, the S-Series, MIL-STD-40051, MIL-PRF-63029 and GEIA-STD-0007 are all published by their authorities under their own terms, so every package ships a permissive stub that accepts well-formed content in the correct namespace. An administrator downloads the specification from its authority — each package records where — and uploads it to enable full conformance checking, per instance or per project. Everything else works without it: authoring, ingest, BREX validation, publishing, cross-linking and exchange export are all unaffected. One rule, no exceptions, so there is nothing to look up about which standards behave differently.
Validation & QA
| Capability | Support | Qualification |
|---|
| XML Schema (XSD) | ✓ | Validation against the project's XSD, including xs:import / xs:include resolution. |
| DTD | ✓ | For the DTD-based standards, resolved through the package's XML catalog. |
| RelaxNG | ✓ | Supported as a schema language. |
| Schematron | — | Not implemented. Rule-level constraints are expressed through BREX instead. |
| S1000D BREX data module | ✓ | The project's own BREX DM is evaluated: structureObjectRule (objectPath, allowed/prohibited, severity) and contextRule value constraints. A rule whose XPath cannot be compiled is reported as not evaluated rather than skipped. |
| BREX authoring without XPath | ✓ | 55 typed rules with plain-English descriptions, examples and guidance, configured through a builder rather than hand-written XPath. |
| Validation on demand | ✓ | Per document or across a project, whichever editor produced the XML. |
| Validation as a gate | — | Check-in, export and publish do not block on validation failure. Validation is run and reported; enforcement is a program decision, not a tool-imposed one. |
| Style lint with auto-fix | ✓ | Double punctuation, consecutive spaces, stray whitespace, empty emphasis, warning punctuation, repeated words. Each rule pairs a check with a fix. |
| In-process peer review (IPRF) | ✓ | Assign, comment, disposition and close review cycles, with cycle-time reporting. |
Publishing & Delivery
| Capability | Support | Qualification |
|---|
| PDF — WeasyPrint | ✓ | CSS-based engine. In-box. |
| PDF — ironmarkpdf | ✓ | Ironmark's own renderer. In-box, no Java. |
| PDF — XSL-FO (Apache FOP) | ◐ | Optional external publishing engine. Requires Apache FOP (Apache-licensed, free) and a JRE, installed alongside Ironmark — not a paid module and not licensed by us. The two in-box engines need no Java at all. |
| FOSI (MIL-PRF-28001) | ◐ | Publishes directly from a program's existing FOSI, rather than requiring it be rewritten in XSL-FO. The FOSI is rendered by an in-box engine — to XSL-FO, then to PDF — with no Arbortext and no Java. Page geometry and page sets, per-chapter page sequences with restarting folios, change bars and change levels, savetext/usetext, boxing, ruling, leaders and the FOSI's own tab positions are honoured. Limits: where a page set declares more than one page specification the first is used; a table of contents is not produced as a document; some formatting characteristics are unmapped. Output is measured against Arbortext-published PDF, not assumed to match. |
| PDF/A | ◐ | PDF/A-1b is implemented in the renderer and available from the command line. There is no per-publish PDF/A toggle in the web interface or REST API. |
| HTML output | ◐ | Declared for S1000D, MIL-PRF-63029J and GEIA-STD-0007. MIL-STD-40051E currently declares PDF output only. |
| IADS package generation | ✓ | Generate and import IADS packages. |
| Change bars | ✓ | Applied at publish time from revision comparison. |
| Customer delivery portal | ✓ | Deliverable revisions, audited downloads, receipt acknowledgement, subscriptions, customer file inbox, and DA-2028 / redline feedback capture. |
| In-portal PDF annotation | — | Feedback is captured through structured DA-2028 / redline forms with page, paragraph, line, figure and table locators — not by marking up the delivered PDF. |
Migration & legacy ingest
| Capability | Support | Qualification |
|---|
| SGML ingest | ✓ | Source archive in, normalised XML out, against a target SDM you choose. |
| Tag-map transformation | ✓ | Element-name remapping, extensible per project. A name-for-name substitution, not a semantic revision-to-revision migration. |
| Disposition reporting | ✓ | Per-element counts for mapped, recognised-but-unmapped and unknown, plus carried attributes, discarded vendor artifacts and defaulted values. |
| Unmapped-content preservation | ✓ | Unknown elements pass through with their source tag rather than being dropped, so content survives before it validates. |
| Vendor-artifact removal | ✓ | Recognised authoring-tool processing instructions and banner comments are discarded deliberately and counted, rather than carried into normalised XML. |
| Re-ingest against fixed mappings | ✓ | Extend the tag map and re-run against the same source archive; the prior conversion is overwritten idempotently. |
| Provenance baseline | ✓ | Cut a baseline before content editing to preserve what conversion produced from the legacy source. |
Workflow & configuration management
| Capability | Support | Qualification |
|---|
| Role-based access | ✓ | Nine roles, each documented with its purpose and whether it consumes a licensed seat. |
| Separation of duties | ✓ | Structural, not advisory: admin and qa are unlicensed access roles and cannot author. Holding both approval and authoring authority requires two accounts, deliberately. |
| Check-out / check-in | ✓ | Including working-copy flush on save and resumable checkouts through the Desktop Launcher. |
| Baselines | ✓ | Cut, compare against current, and compare two baselines head to head. Comparison is structured data, not a rendered diff PDF. |
| Change requests | ✓ | Internal change-request records with document association and activity history. |
| Cross-domain traceability | ◐ | Identifier extraction and link discovery across projects, with a review gate: proposals stay out of the traceability matrix until confirmed, and rejections are remembered. Available through the REST API; no dedicated user interface yet. |
| Tamper-evident audit log | ✓ | HMAC-SHA256 hash chain over each record with an integrity-verification endpoint. No delete or update route is exposed. |
Integration & API
Ironmark is a web application backed by an API-complete application layer. The web interface is one client of that layer; you can build others or automate against it directly.
| Capability | Support | Qualification |
|---|
| Web authoring interface | ✓ | The standard user interface. Structured and visual editing in the browser. |
| REST API | ✓ | Application capabilities exposed programmatically across 60 endpoint modules. |
| OpenAPI specification | ◐ | Machine-readable definition served from the instance itself. Behind administrator authentication, so the API surface is not public on an Internet-facing deployment. |
| Swagger UI and ReDoc | ◐ | Both served from assets bundled with the install, so they work with no Internet access. Administrator-authenticated, as above. |
| Headless publishing | ✓ | Submit a publication build, poll the job, download the artifact — no browser involved. |
| Machine-to-machine tokens | ✓ | Personal access tokens scoped read-only or full, acting as the owning user. A separate ingest-only scope exists for S5000F feedback. |
| Custom API clients | ✓ | Independent applications can consume the same API the web interface uses. |
| Desktop editor round-trip | ✓ | Optional Windows launcher: check out, open in Oxygen / Arbortext / any editor that accepts a file path, flush each save to the server, check in on close. |
| Desktop client required | No | There is no default desktop client and none is required. The launcher is a bridge to an editor you already own. |
| Outbound webhooks | — | Not provided. Integration is inbound: you call Ironmark. |
Deployment & security
| Capability | Support | Qualification |
|---|
| Air-gapped operation | ✓ | No outbound network connection is made by default. Three are possible and each stays off until you turn it on: your identity provider (only if you configure OIDC), an SMTP relay (only if you configure notifications), and a dependency-CVE check (opt-in). |
| Telemetry | — | None. No analytics, no crash reporting, no usage beacon, no update check. |
| Licence activation call-home | — | None. Licences are verified offline by signature. |
| Outbound email | ◐ | Disabled by default. Sending requires an SMTP host to be configured deliberately. |
| Local accounts | ✓ | Password hashing with history and rotation controls. |
| LDAP / Active Directory | ✓ | Implemented; pending field validation against real customer environments. Simple bind with optional Kerberos. TLS certificates validated by default. |
| OIDC | ✓ | Implemented; pending field validation against real customer environments. Authorisation-code flow with PKCE. The identity token's signature, audience, issuer and expiry are verified against the provider's keys, and the nonce is bound to the login attempt. |
| CAC / PIV | ✓ | Client-certificate authentication terminated at the reverse proxy. |
| WebAuthn / FIDO2 | ✓ | Hardware authenticators as a registered credential type. |
| SAML | — | Not implemented. |
| Signed update bundles | ✓ | Verified by signature before application, strict by default. |
| Signed standard-definition packages | ✓ | Signature verification against a registry of trusted signers you control. Unsigned packages are rejected unless an administrator makes a deliberate exception. |
| XML external-entity hardening | ✓ | Entity resolution, network fetch and DTD loading disabled at every parser construction site, with the process default hardened at start-up. |
| Graphics metadata scrubbing | ◐ | Raster formats only — JPEG, PNG, TIFF, GIF, BMP, WebP. SVG, CGM and PDF are not scrubbed. Off by default; enable globally or per project. Multi-frame images are skipped rather than flattened. |
| Project access isolation | ◐ | Membership-based access enforced on documents, graphics and parts routes; administrators and QA are cross-project by design. Not every endpoint family has been audited to this standard, so the claim is scoped to those three. |
Generative AI
| Capability | Support | Qualification |
|---|
| AI content generation | — | None, by design. There is no model, no embedding store and no external inference call anywhere in the product. Every transformation is deterministic and reproducible, which is what makes conversion and validation results auditable. |
Nothing on this page carries a mark until it can be defended literally. Where a row says ◐, the limitation is the interesting part — it is there because someone asked the question and the honest answer had a boundary in it.
Related