At some point, every Part 21J design office concludes that spreadsheets and shared drives are costing more than they save, and someone is asked to "look at tools."
That person quickly discovers the problem is not a shortage of options. It is that every option demos well. Generic document management platforms, engineering PLM suites, quality management systems, and aerospace-specific tools all show polished interfaces, all claim audit trails, and all have a slide about compliance.
The differences that matter only show up later — in the first authority audit, the first major change classification, the first attempt to reconstruct a submitted package. By then the contract is signed and the migration is done.
This guide is the evaluation framework we wish more design offices used: what is genuinely non-negotiable for Part 21J work, which questions separate real capability from demo capability, and where the total cost actually hides.
Start With the Question the Tool Must Answer
Strip away features and every certification tool exists to answer one question quickly and defensibly:
"Show me exactly what was approved, by whom, under what authority, based on what evidence — as it stood at any given moment."
Generic document tools answer parts of this. They version files and log actions. What they lack is the structure underneath: they do not know what a compliance document is, what a requirement link means, what signatory authority is, or why a submitted state must remain reconstructable forever.
That is the real dividing line in this market — not features, but whether the data model matches certification work. Keep it in mind through every demo.
The Non-Negotiables
These five capabilities are the pass/fail tier. A tool missing any of them will reproduce your spreadsheet problems with a nicer interface.
1) Revision Immutability With Enforced Approval States
Approved revisions must be genuinely immutable — not "discouraged from editing," but structurally impossible to alter without a formal new-revision event. Approval must be bound to a specific revision, and any post-approval change must visibly invalidate the approval.
Test: in the demo, approve a document, then try to edit it. If the tool lets you, or quietly creates ambiguity about which version was approved, stop the evaluation.
2) Point-in-Time Reconstruction
You must be able to produce the complete state of a document set as it existed at a past moment — a milestone, a submission, an approval date. Version history on individual files is not this: reconstructing a 200-document package from per-file histories is exactly the manual archaeology you are trying to escape.
Test: "Show me this project's entire document set exactly as it stood on a date six months ago, in one operation."
3) Structured Approval Workflows With Authority Control
The tool must model who can approve what — by document type, risk class, and project — and enforce it, including time-boxed delegations. If approval is just a button any user can press, the tool has an opinion-free audit trail: it records violations beautifully but prevents none.
Test: "Configure it so I cannot approve this document class, then show what happens when I try — and show me how a two-week delegation is granted, recorded, and expired."
4) Traceability as Data, Not Description
Requirement-to-document-to-evidence links must be first-class objects that survive revisions and flag affected items when something changes. A "related documents" free-text field is not traceability.
Test: "Link a requirement to this document, revise the document, and show me what the system tells the compliance owner."
5) Complete, Exportable, Attributable Activity Records
Every state change — who, what, when, under what authority — with export in a format an auditor can consume. Also check the inverse: can the vendor's own staff alter records, and is that logged?
Test: ask for a full audit-trail export of the demo project, and read it. If it is unreadable or incomplete in the demo, it will be worse in year three.
The Differentiators
Beyond the pass/fail tier, these determine how much value the tool delivers per week of use:
- Search that engineers actually use. Full-text, across projects, fast. Every failed search creates a duplicate document; duplicates create the version chaos you are paying to eliminate.
- Comparison between states. Diffing two baselines or two revisions as a routine operation — this is what makes milestone reviews and change impact assessments fast.
- Task and deadline visibility. Approval queues, aging items, and workload per approver, visible to leads without asking anyone.
- Low onboarding burden. If a new engineer needs a training course before contributing, adoption will stall and the shared drive will quietly return.
- API access. Not for day one — for the integration you will inevitably want in year two.
Weight these by your actual pain. An office drowning in audit preparation should weight reconstruction and audit exports; an office losing weeks to approval delays should weight workflow and visibility.
Questions That Expose Weak Products
Six questions whose answers are hard to fake:
- "Walk me through your data model for a compliance document." Vendors with generic file-plus-metadata models will answer with folder structures. That is your answer.
- "A document was approved in error and must be withdrawn. Show me the process and what the record looks like afterwards." Immature tools handle the happy path only.
- "How do we get all of our data out if we leave?" Complete export, in open formats, including audit trails — anything less is a hostage situation on a subscription.
- "What happens to our submitted packages if you go out of business?" Listen for escrow arrangements, self-hosted options, or export guarantees.
- "Show me the audit trail of the demo you just gave me." A surprisingly effective request. The vendor's own actions should be sitting in the log.
- "Which of your customers are Part 21J organisations, and what did their last authority audit say about the tool?" References from adjacent industries (automotive, medical) are informative but not equivalent.
Where the Cost Actually Hides
Licence price is the visible fraction of total cost. The evaluation should price four other things:
| Cost category | What to ask |
|---|---|
| Per-seat scaling | What happens at 2× headcount? Per-seat pricing quietly penalises exactly the growth you want, and pushes offices to share logins — which destroys attributability |
| Feature gating | Are audit trails, API access, or SSO locked behind a higher tier? Compliance-critical features on premium tiers are a red flag |
| Implementation | Vendor services, data migration, configuration — get it quoted, not estimated |
| Internal adoption | Training time, workflow redesign, the months of parallel running with the old system |
A flat-rate tool with a higher sticker price is frequently cheaper by year two than a per-seat tool that gates features — run the arithmetic at your realistic headcount, not the pilot team size.
On migration: distrust both extremes. "We'll import everything automatically" underestimates the data-quality decisions involved; "just start fresh" abandons the history your audits depend on. The credible answer is a scoped migration of active programmes with the archive handled deliberately — a vendor who talks this way has done it before.
A Four-Week Evaluation That Produces a Defensible Decision
- Week 1 — Write the requirement, not the wishlist. Take the non-negotiables above, add your weighted differentiators, and agree the scoring with the head of office before seeing demos. Demos reorder priorities in favour of whoever presents best.
- Week 2 — Scripted demos. Give each vendor the same script built from the tests in this guide. Refuse the standard demo; the standard demo is rehearsed precisely where their product is weakest.
- Week 3 — Pilot with one real project. Not sample data — a live, low-risk project with real documents and real approvers. Sample data hides every data-model weakness.
- Week 4 — Score, reference-check, decide. Speak to at least one Part 21J reference customer, and ask them the audit question. Then score against the week-1 criteria and record the rationale — the decision record itself is the kind of attributable evidence your future audits will appreciate.
Final Takeaway
The document control market is full of tools that manage files and a small number that understand certification. The difference is invisible in a demo and decisive in an audit.
Evaluate against the one question the tool exists to answer — what was approved, by whom, under what authority, based on what evidence, at any point in time — and most of the field eliminates itself in the first hour.
The right tool does not make a design office compliant. It makes the compliance the office already practises provable in minutes instead of weeks — and it stops charging you, in reconstruction time and audit findings, for the structural gaps of tools that were never built for this work.