Ironmark provides application features that can support a customer's compliance program: role-based access, selected security and workflow event logging, and an HMAC-chained audit record with on-demand integrity verification. These features are controls within the product, not a compliance determination for the deployed system.
Supported authentication, authorization, administrative, publishing, distribution, and controlled-workflow operations write audit rows with the fields implemented by that event. Rows are chained by HMAC of the prior row's fields, so alteration or deletion within the recorded chain is detectable at the next verification pass. Ironmark does not claim complete event coverage for every mutation.
Nine application roles — admin, author, qa, peer_review, cir_controller, graphics_editor, program_manager, customer, viewer — plus sysadmin as a separate capability for offline-update flows. A user has a primary role plus optional granted roles. Protected operations apply API-layer role checks; document, graphics, and parts routes also enforce the project-access boundary described in the capability matrix.
The three authoring roles — author, peer_review, cir_controller — are the seat-consuming ones (see the pricing section on the homepage). Each edits content:
Everything else — qa, program_manager, admin, graphics_editor, viewer, customer — is unlimited and unlicensed. See FAQ 6.02 for the full role table.
The admin role (Project Admin) manages users, projects, and licensing inside the running instance. The sysadmin capability is separate: it owns software updates and system-wide configuration (offline-update bundle apply, cert rotation, backup coordination). The split is deliberate — a system operator can't grant themselves an author seat, and a user administrator can't push a new binary without a peer holding the sysadmin capability. Programs mapping this to ATO / SoD requirements can assign the two to different individuals and audit each independently.
Granted roles are activated through a time-bounded elevation workflow. The interface displays the active window and its expiry. Audited privileged operations can carry the associated elevation_event_id; this does not imply that unaudited actions become visible merely because elevation was active.
There is no single "DoD mode" that turns a deployment into a compliant system. Ironmark's application controls are configured alongside the customer's identity, network, host, storage, backup, logging, and records-management controls. Programs should evaluate the installed version and settings against their own requirements.
Administrators can export recorded audit rows as NDJSON and verify the chain through the supported audit interface. An auditor may also require identity-provider records, host and network logs, configuration history, role assignments, and evidence from systems outside Ironmark.