Every Part 21J design office eventually gets asked a version of the same question:
"What did the design data look like at the time this decision was made?"
It comes from EASA during an audit. It comes from an internal investigation after a non-conformity. It comes from a new programme lead trying to understand why a requirement changed between preliminary and detailed design.
Teams with live folders and spreadsheets cannot answer it. They can show what the data looks like now, and they can sometimes reconstruct history from file timestamps and email archives. What they cannot do is produce the exact, complete state of the certification package as it existed at a specific moment.
That capability has a name: a milestone baseline. This article explains what it is, why it matters in Part 21J work specifically, and how to introduce baselining into a design office without freezing productive work.
What a Baseline Actually Is
A baseline is a complete, immutable record of a defined document set at a specific point in time.
Three properties make it a baseline rather than just a backup:
- Completeness. It captures every artefact in scope — documents, revisions, approval states, and the links between them — not just the files someone remembered to copy.
- Immutability. Once taken, it cannot be edited. Later changes happen in the live workspace, never in the baseline.
- Attributability. It records who created it, when, and against which milestone or event.
A folder named CDR_FINAL_2026-03-12 on a shared drive has none of these properties. Anyone can add to it, remove from it, or overwrite its contents, and nothing records whether it was complete when it was created.
Why This Matters More in Part 21J Than Almost Anywhere Else
Certification work is milestone-driven by design. Preliminary design review, critical design review, type board meetings, submission packages, and post-certification changes all reference the state of the design data at a moment, not the current state.
Three recurring situations make the gap visible:
1) The Authority Reviews Against a Submitted State
When you submit a compliance demonstration to EASA, the review happens against what you submitted. If engineering keeps evolving the live documents — which it should — you now have two states: the submitted state and the current state.
Without a baseline, the submitted state exists only as an export on someone's laptop or an attachment in an email thread. Six months later, when the authority raises a finding against "the submitted document," reconstructing exactly what they are looking at becomes archaeology.
2) Change Classification Needs a Reference Point
Deciding whether a change to type design is major or minor requires comparing against an approved configuration. If the approved configuration is not captured anywhere as a fixed state, the classification discussion starts with "well, what did we actually approve?" — a question that should never be open.
3) Audit Findings Are Time-Anchored
Auditors do not ask whether your documentation is good today. They ask whether your decisions were properly supported when you made them. A finding like "the stress justification did not cover this load case at the time of approval" can only be answered with evidence of what the justification contained at that time.
The Reconstruction Tax
Offices without baselining still answer these questions — they just pay for each answer separately.
A typical reconstruction involves pulling file-server versions by timestamp, searching email for approval threads, cross-referencing the document register spreadsheet, and interviewing whoever was on the project at the time. For one document, that is an afternoon. For a milestone package of 200 documents, it is weeks.
The costs cluster in four places:
| Cost | How it shows up |
|---|---|
| Senior engineering time | Reconstruction requires people who understand the project history |
| Audit exposure | Gaps in reconstructed evidence become findings in their own right |
| Delayed change decisions | Major/minor classification stalls while the reference state is debated |
| Repeated rework | The same historical state gets reconstructed multiple times by different people |
The tax is invisible in normal operations because it is paid in irregular, unbudgeted lumps — usually at the worst possible moments, during audits and investigations.
What Good Baselining Looks Like in Practice
The mechanics matter less than the discipline. A working baseline process has four rules.
Rule 1: Baselines Are Taken at Defined Events, Not Ad Hoc
Define the trigger list once and apply it consistently:
- Formal design reviews (PDR, CDR, and equivalents)
- Every submission to the authority
- Approval of a major change
- Project handover or suspension
If baselines are taken "when someone remembers," coverage becomes unpredictable and the record loses its evidential value.
Rule 2: Scope Is Defined Before the Milestone, Not After
The baseline scope — which document classes, which projects, which supporting evidence — should be part of the milestone definition. Deciding scope retroactively invites the exact incompleteness the baseline exists to prevent.
Rule 3: The Baseline Includes Approval State, Not Just Content
A document's text without its approval status is half a record. The baseline must capture, for every artefact: revision identifier, approval state, approver identity, and approval timestamp. "This is what the document said" is far weaker evidence than "this is what the document said, and here is who had approved it and when."
Rule 4: Comparison Between Baselines Is a First-Class Operation
Much of the value of baselining comes from diffing: what changed between concept review and detailed design? Which documents were revised after submission? If comparing two baselines requires manually opening pairs of documents, the comparisons will not happen. The process (or tooling) should make "show me what changed between these two states" a routine query.
Why Spreadsheet-Era Tooling Cannot Do This
It is worth being precise about why the traditional stack fails here, because the failure is structural, not a matter of effort:
- Shared drives have no notion of state. A folder is always live. Copying it creates a second live folder, not an immutable record.
- Spreadsheets track current status, destructively. When the register is updated, the previous status is overwritten. The register's own history is usually the first thing lost.
- Email approvals are not attached to revisions. An approval in an inbox refers to whatever was attached at the time — which may or may not match any version that still exists on the drive.
- Nothing links artefacts together. The relationship between a requirement, its compliance document, and its verification evidence exists only in people's heads and file-naming conventions.
Teams compensate with discipline — read-only folders, strict naming, PDF exports at milestones. These help, but they all depend on every person following the convention every time, and they all fail silently when someone does not.
A structured document control system inverts this: immutability, completeness, and attributability are enforced by the platform, and taking a baseline becomes a single deliberate action rather than a multi-day manual exercise.
Introducing Baselines Without Disrupting Live Work
Baselining fails when it is introduced as a bureaucratic gate that slows engineering down. The rollout below avoids that.
Step 1: Pick One Upcoming Milestone
Do not baseline retroactively and do not start with the whole office. Choose one project with a design review or submission in the next four to eight weeks.
Step 2: Define the Scope With the Project Lead
Agree the document classes and evidence links that belong in the milestone package. Write the scope down as a checklist — this becomes the reusable template for future milestones.
Step 3: Take the Baseline as Part of the Milestone Exit
Make "baseline taken and verified complete" an exit criterion of the review itself, owned by a named person. It should take minutes, not days; if it takes days, that is a signal your document control has deeper gaps worth knowing about.
Step 4: Use It Within 30 Days
A baseline that is never queried convinces nobody. Within a month, run at least one real exercise against it: answer an internal query from the baseline instead of the live workspace, or diff it against the current state to review post-milestone drift.
Once one project has done this twice, the practice spreads on its own merits — usually because the first team stops losing afternoons to reconstruction and everyone else notices.
Signals Your Office Needs This Now
If two or more of these are true, the reconstruction tax is already material:
- An audit or authority query in the past year required reconstructing a historical document state
- A major/minor classification discussion stalled on "what was actually approved?"
- Submitted packages exist only as exports on individual machines or email attachments
- Nobody can say with confidence which revision of a key document a past approval refers to
- Post-submission changes to documents are not systematically distinguishable from the submitted state
Final Takeaway
Part 21J work is judged against moments in time: what was submitted, what was approved, what was known when a decision was made. An office that can only show the current state of its data is structurally unable to answer the questions the regulation will ask of it.
Milestone baselines close that gap. They convert "we think this is what it looked like" into "this is the record, taken at the milestone, complete and unmodified since."
The offices that handle audits calmly are not the ones with the most documentation. They are the ones that can produce any past state of their certification data in minutes — because they captured it deliberately, at the moment it mattered.