Certification conversations are full of people whose job titles explain nothing: the applicant who never wrote a line of the software, the DER who works for a company but speaks for the government, the authority that mostly is not in the room. Getting these roles straight matters practically, because knowing who owns what tells you who to convince, who to inform, and whose signature actually closes an issue.
The map
The applicant: the one name on the approval
The applicant — typically the aircraft, engine or equipment maker seeking the type certificate, supplemental type certificate or equipment authorisation — is the entity the approval is issued to, and therefore the one accountable to the authority for everything underneath it, including the software its suppliers wrote.
The practical consequence runs down the supply chain: a software supplier does not hold an approval and cannot get one on its own. Your DO-178C evidence exists to support someone else's application. That shapes contracts, data rights, and who talks to the authority — usually the applicant, with the supplier one step removed.
The authority: three flags, one shape
| Authority | Jurisdiction | Regulatory frame for design approval |
| TCCA — Transport Canada Civil Aviation | Canada | CAR 521, under the Aeronautics Act |
| FAA — Federal Aviation Administration | United States | 14 CFR Part 21 |
| EASA — European Union Aviation Safety Agency | EU member states | Part 21 |
Authorities certify the product; they do not develop it, and they read only a sample of its evidence. Most of the reading is done by people the authority has formally trusted to act for it — the delegates — which is where the vocabulary gets confusing, because each jurisdiction names them differently.
Delegates: private people, public authority
| Canada (TCCA) | United States (FAA) | Europe (EASA) | |
| Individual delegate | DAR — Design Approval Representative | DER — Designated Engineering Representative | — (privileges sit with organisations) |
| Organisational delegate | DAO — Design Approval Organization | ODA — Organization Designation Authorization | DOA — Design Organisation Approval |
| What they do | Make findings of compliance on the Minister's behalf | Approve data on the Administrator's behalf | Hold privileges to approve within the organisation's approved scope |
The supplier: evidence without approval
The software developer — often you, if you are reading this — owns the plans, the artifacts, and the verification results, and answers for them in SOI reviews. What it does not own is any approval. Between supplier and applicant there is therefore a permanent, structural tension worth naming: the applicant carries the certification risk of the supplier's work, so the applicant will want visibility into evidence the supplier may consider internal. Sorting out data rights, audit access and problem-report flow in the contract is vastly cheaper than sorting it out during SOI #3.
Certification liaison: the job DO-178C actually assigns you
Certification liaison is one of DO-178C's four integral processes — the standard expects someone on the software side to own the relationship: proposing the SOI schedule in the PSAC, keeping the delegate informed between reviews, and making sure issues surface early rather than theatrically. On healthy programmes this is a named person with time allocated. On unhealthy ones it is nobody, until it is suddenly everybody.
Who to call, for what
| Situation | Right first conversation |
| A plan or standard needs to change mid-programme | Your certification liaison → the delegate |
| You think an objective doesn't apply to your case | Delegate, with your rationale written down first |
| A finding seems wrong | The delegate who made it — with evidence, not adjectives |
| The assurance level itself seems wrong | The applicant's systems/safety organisation, not the authority |
| An approval must be recognised abroad | The applicant's certification office; bilateral routes are their domain |
Frequently asked questions
Can a software supplier talk to the authority directly?
The relationship normally runs through the applicant, who holds the application and the accountability. Suppliers participate in reviews of their own evidence, but proposals and formal positions go through the applicant's certification organisation.
Is a DER or DAR the same as a consultant?
No. A consultant advises you and answers to you. A delegate, when acting under delegation, makes findings on behalf of the authority and answers to it — even if they also do consulting work when not wearing that hat. Knowing which hat is on matters.
What is the difference between an ODA and a DER?
A DER is an individual holding delegated authority personally. An ODA is an organisation holding it institutionally, with authorised individuals working inside that approval. Canada's DAR/DAO pair mirrors the same individual/organisation split.
Who is the applicant when we sell an equipment box, not an aircraft?
Equipment can be authorised in its own right — a TSO authorisation in the US, a CAN-TSO in Canada — in which case the equipment maker is the applicant for that authorisation, while installation on an aircraft still belongs to whoever holds the aircraft-level approval.
Do we need our own certification liaison person?
If your software is being certified, someone is doing this job — the only question is whether deliberately or by accident. On small programmes it is a hat someone wears part-time; what matters is that it is named, planned, and not discovered mid-review.
If your programme's role map is fuzzy — or the contract with your applicant left evidence access undefined — that is fixable, and cheaper now than later. Get in touch.
