--- title: "Supplier Design Data in Part 21J: Closing the Compliance Gap Between Your DOA and External Partners" description: "External partners deliver drawings and analyses your DOA must own for certification. This guide explains why email handoffs create unowned revisions and unprovable approvals — and how to run an intake model that survives authority sampling." canonical_url: "https://www.tungsten.aero/blog/supplier-design-data-compliance-part-21j" --- > Index of every page on this site: [llms.txt](https://www.tungsten.aero/llms.txt) Ask a Part 21J design office for the supplier's latest drawing and someone will usually produce a PDF. Ask them to show what was *accepted into the certification package*, by whom, under what authority, at which revision, and linked to which requirements — and the trail often ends in an email folder, a shared drive named after a person, or a "we always use the latest from them" assumption. That gap is not a supplier problem. It is a DOA problem. Your design organisation approval makes you accountable for the design data you rely on — including data that originated outside your walls. This article explains why partner handoffs become compliance debt, what it costs under sampling, and how to run an intake and ownership model that stays reconstructable when the authority asks. --- ## Why Partner Data Is Your Problem External design partners — suppliers, subcontractors, specialist analysis houses, sister sites — produce artefacts that enter your compliance story. The drawings, stress notes, interface definitions, and test evidence they send become part of *your* demonstration that the design is controlled. The privilege boundary does not move with the email. If your office incorporates partner content into an approved design context, you must be able to show: 1. What exactly was received and accepted 2. Who accepted it into your controlled environment 3. Which revision is the one the package depends on 4. Who held authority to approve its use on this project 5. What happens when the partner issues a newer revision Offices that treat partner data as "incoming mail" rather than "controlled design input" discover these questions during audits — when reconstruction is slowest and trust is thinnest. --- ## How the Interface Goes Informal Nobody designs an uncontrolled partner interface. It grows from convenience. Typical patterns: - **Email is the system of record.** Attachments land in inboxes; the "latest" version is whoever forwarded most recently. - **Shared folders without intake.** Partners drop files into a collaborative space; nobody records acceptance, only presence. - **Unsigned incorporation.** Content appears in the package because an engineer needed it, not because an authorised role accepted it against defined criteria. - **Revision ownership stays with the partner.** Your office references "supplier Rev C" while continuing to revise locally without a clear rule for who owns the next change. - **Authority matrix blind spots.** The [authority matrix](https://www.tungsten.aero/blog/authority-matrix-access-control-part-21j) covers internal roles; partner-originated content is approved by whoever feels responsible. - **Change ownership is ambiguous.** When the partner updates a drawing after your change was classified, nobody reopens classification or impact — the silent scope growth described in [change classification](https://www.tungsten.aero/blog/change-classification-major-minor-part-21j). Each pattern is individually reasonable on a busy programme. Together they produce two sources of truth: the partner's working set, and the package your office thinks it submitted. --- ## What It Costs Under Sampling When an auditor samples a document that originated with a partner, the questions are the same as for any controlled artefact — plus one more: *show me the boundary.*
Failure mode What it looks like Why it hurts
Unowned revision Package cites a partner file that no longer matches the partner's archive You cannot prove which revision was accepted
No acceptance record File exists in the folder; nobody recorded intake Incorporation looks accidental, not controlled
Email approvals on partner PDFs Sign-off in a thread, not on the controlled record Same reconstructability failure as email approvals
Traceability rot Requirement links point at a partner doc that later moved The compliance matrix decays — see requirement-to-evidence traceability
Wrong authority path Internal junior engineer "accepted" high-risk partner analysis Authority findings against the organisation, not the supplier
Silent partner updates New revision arrives mid-programme; package not rebaselined Milestone baselines describe a state that never existed as a decision
The damaging implication is organisational: if the office cannot demonstrate control over partner inputs, every package that depends on those inputs becomes questionable. That is how a convenient email habit turns into a systemic finding about design data control. --- ## An Operating Model That Holds Durable offices treat partner design data like any other controlled input: intake, acceptance, ownership, approval, and change — not "files we received." ### Intake Gate Nothing enters the certification working set until it passes an intake step: identified partner, artefact type, revision identifier, received date, and intended use (reference only vs incorporate into approved design context). Intake is not engineering approval. It is the moment the office admits the artefact into its controlled world so later questions have a starting point. ### Acceptance Record Someone with defined authority accepts the artefact for a specific purpose on a specific project. The record shows who, when, against which criteria (completeness, applicability, revision identity), and what remains open. "We have the PDF" is not acceptance. Acceptance is a decision. ### Revision Ownership After acceptance, the office must be explicit: does this revision remain partner-owned (you consume updates only through new intake), or does it become office-owned (further changes follow your change control)? Ambiguity here is how dual truth starts. ### Approval Path for Incorporated Data If the artefact will be used as compliance evidence or as part of an approved design definition, it follows the same structured approval gates as internal documents — with roles from the authority matrix, not from whoever is free. Partner origin does not weaken the gate; it often strengthens the need for it. ### Linked Requirements and Evidence Partner artefacts that support compliance must appear in the living traceability model, not only in a folder. When the partner revises, links must be revisited — the same anti-rot discipline as for internal evidence. ### Change and Re-baseline Triggers A new partner revision that touches an accepted artefact is a change event: impact preview, possible reclassification, new acceptance, and — at declared milestones — a [baseline](https://www.tungsten.aero/blog/certification-milestone-baselines-part-21j) that freezes what the package actually depended on. --- ## A Migration Path for Offices Still Living in Email Do not try to onboard every partner into a perfect model in week one. Sequence so the highest-risk interfaces become visible first. 1. **Inventory active partner inputs.** List which programmes depend on external design data today, where those files live, and who "owns" the relationship informally. 2. **Pick the top risk interfaces.** Structures, systems safety, certification-basis touchpoints, and anything already in authority sampling get intake first. 3. **Introduce intake + acceptance in warning mode.** Allow work to continue, but flag incorporated partner files with no acceptance record. 4. **Bind acceptance to named roles** from the authority matrix for those high-risk types. 5. **Enforce revision identity and re-intake** when partners send updates — no silent overwrite of accepted revisions. 6. **Connect accepted artefacts to traceability and approval gates** last, once the office trusts that intake data is real. Offices that reverse this order — hard blocking on day one with no inventory — generate parallel email paths. Parallel paths become the new informal interface. --- ## Signals the Partner Interface Is Still Informal - Engineers say "I'll get the latest from the supplier" and that is the version control process - Acceptance of partner data cannot be shown without interviewing the programme lead - Partner revisions overwrite previous files without a new intake record - Approvals for partner-originated content happen in email threads - The authority matrix has no roles for accepting or approving partner inputs - Compliance matrix rows cite partner documents that nobody can open at the cited revision - Change classification is never reopened when partner scope grows If two or more of these are true, the office is carrying partner-data risk on every package that depends on external design — and the risk peaks exactly when a programme is busiest. --- ## Final Takeaway Supplier and partner design data does not sit outside Part 21J control. Once you rely on it for certification, it is your design data — with the same obligations for identity, authority, approval, and reconstructability. When handoffs live in email and shared folders, the office can produce a PDF but not a decision record. When intake, acceptance, ownership, approval, and re-baseline triggers are explicit, partner content becomes part of a controlled system instead of a convenient attachment. The practical test is simple: for any partner artefact in an active package, can you show — without archaeology — which revision was accepted, by whom, for what purpose, under what authority, linked to which requirements, and what would force a new intake when the partner updates? If yes, the DOA owns the interface. If not, the next sampling question already has your answer: *we are not sure.* ## Sitemap See the full [sitemap](https://www.tungsten.aero/sitemap.md) for all pages.