Home → Architecture → Baselines
Baselines & reproducible publishing
A published manual should never become impossible to reproduce simply because time has passed.
Baselines are Ironmark's mechanism for that guarantee. A baseline is a named, immutable snapshot of a project at a moment in time — content plus the configuration and packaging that turn content into a published manual. If you can open the baseline, you can rebuild what shipped.
What a baseline is
A baseline is a named point on a project's timeline. It has an author, a timestamp, a reason, and a version identifier. Content is frozen against it — the modules the project held at cut time stay reachable regardless of what happens to the live project afterward. Baselines can be created ad-hoc or via the release cut flow, and every baseline is addressable by name for cloning, comparing, and republishing.
What is captured
Content
- Every DM in the project at its baseline version
- IPD catalog rows (parts data)
- Applicability tables (CCT / ACT / PCT)
- Referenced graphics (ICNs)
- BREX rules
- CIR entries (warnings, cautions, tools, supplies, parts, personnel, prerequisites)
Configuration
- SDM in use at baseline time (schema + descriptors + templates)
- Publish stylesheets (WeasyPrint CSS + XSL-FO) as of baseline
- Per-project overrides (logos, cover pages, section format)
- DTD folder if the project holds a customer-supplied DTD variant
- Applicability vocabulary in force at baseline
- Ingest records from upstream projects (source-of-record provenance)
What is not captured
The line between what's captured and what isn't is where the reproducibility story lives — knowing this up front prevents surprises during a 10-year revisit.
- Third-party publishing backends — if a project publishes via Antenna House or RenderX XEP, the backend is customer-installed and its version is customer-controlled. The baseline records which backend was used, not the backend itself.
- External systems Ironmark integrates with — an upstream LSA system's live state isn't captured. The ingest record captures the source baseline id + name so the upstream anchor is at least identified, but reproducing that upstream side is on the upstream tool.
- Portal user identities and session state — auth surface, not content.
- Runtime instance state — service uptime, transient locks, in-memory caches. Baselines are content + configuration, not runtime.
- Ironmark platform version — recorded on the baseline for provenance, but a future rebuild uses whatever version is running. Bundled backends (WeasyPrint, Apache FOP, ironmarkpdf) come with the platform.
When to create one
- Release cut — every shipped revision of a manual should sit against a baseline. Ironmark can auto-cut on publish for programs that want the invariant enforced.
- Regulatory milestone — customer acceptance, CDRL delivery, audit-of-record date. The baseline is the artifact you point the auditor at.
- Before a large refactor or migration — a rollback anchor if the change goes sideways. Compare-baseline shows the delta once the refactor is in.
- Scheduled heartbeat — long-running programs benefit from a monthly or quarterly baseline even without a release event, so a future revisit has plausible re-entry points.
How baselines support audits
An audit is usually not a question about the current live project — it's a question about state at a past moment. "What did the technical manual say on the date of the incident?" "Which version of the applicability rules applied to serial 402 in Q3 2027?" Baselines answer those directly:
- Open the baseline — read-only view of the project as it stood at cut time.
- Verify the audit chain — the HMAC-chained audit log is anchored against the baseline, so tamper attempts show up.
- Compare two baselines — surface the delta between any two named points, including catalog changes, applicability rule changes, and per-DM diffs.
- Republish — regenerate the exact publish output for the auditor to walk against the delivered manual.
How baselines support long-term sustainment
Defense and aerospace programs measure lifecycle in decades. The people who authored the manual will not be the people who revise it. The tool the manual was authored in will have moved several major versions. The published output will need to be reproducible when a specific part swap needs to be applied against exactly the manual state that shipped in 2029.
Baselines carry the load:
- Clone-from-baseline — spin up a new project from any historical baseline. Useful when a variant program forks off an existing manual's mid-lifecycle state.
- Schema + stylesheet lock — the baseline pins the SDM and stylesheets active at cut time, so an SDM upgrade in the live project doesn't retroactively change what the baseline renders.
- DTD retention — customer-supplied DTDs travel with the baseline. Programs with specialty DTD variants don't lose the variant when the SDM's default schema is upgraded.
- Provenance chain — ingest records tie baselines to their upstream sources, so a sustainment engineer can walk back from a delivered PDF to the LSA baseline that fed it.
Records management is still your responsibility
Ironmark maintains published deliverables as part of the publication history. However, organizations should continue following their established records management and archival policies. We recommend maintaining an independent archive of released deliverables in accordance with your organization's retention requirements.