Technical work begins with a need, not with a document title. A new standard, framework or guideline is not evidence of progress unless it solves a problem that existing systems and knowledge do not already address.
The document-first problem
New institutions often feel pressure to demonstrate activity quickly. Publishing a named standard or certification scheme can appear more substantial than asking a careful question. Yet document-first programmes risk duplicating established work, overlooking legal requirements, creating incompatible terminology or offering a solution before the problem is understood.
In aerospace, these risks are serious because many subjects already sit inside mature regulatory, standards, research and industry systems. A new document can increase uncertainty if users cannot see how it relates to existing authority and practice.
Technical work begins with a need, not with a document title.
A responsible starting sequence
- Identify the operational, technical or evidence problem in clear language.
- Review the authorities, standards, research and practices already relevant to it.
- Examine available evidence and the limits of that evidence.
- Confirm whether a meaningful gap exists.
- Define a bounded scope and the users affected by the question.
- Assemble expertise appropriate to that scope.
- Select the smallest useful output—or conclude that no new output is required.
This sequence does not make technical work slow. It reduces effort spent solving the wrong problem. It also gives future reviewers a traceable explanation of why the work exists.
What a landscape review does
A technical landscape review maps the environment around a question before a new response is designed. It considers applicable regulation, existing standards, published research, industry specifications, known guidance and current professional practice. It should also show where evidence is strong, where implementation differs and where a genuine coordination problem remains.
Suppose several organizations report difficulty exchanging lifecycle data between design, manufacturing and maintenance systems. The first question is not what an AF digital-thread standard should contain. The first questions are which data standards already exist, which interfaces fail in practice, whether the problem is technical or contractual, and whether different aerospace sectors use the same terms in the same way.
The review may find that an existing standard is adequate but poorly understood. In that case, an explanatory brief or professional workshop may be more useful than a new specification. It may find that evidence is incomplete, making research the appropriate next step. It may also reveal a narrow gap that justifies a framework or guidance document.
The AI assurance example
Artificial intelligence illustrates why scope must come before output. The phrase AI in aerospace can refer to design optimization, predictive maintenance, image analysis, decision support or functions with direct operational consequences. These applications do not share one risk profile.
An organization should not begin by announcing an “AF Artificial Intelligence Standard.” It should first examine existing aviation requirements, software and system assurance principles, current AI research, regulatory initiatives, cybersecurity concerns, data governance, human oversight and the operational context in which a model would be used.
Verification asks whether a system was built according to its specified requirements. Validation asks whether the resulting system is suitable for its intended use. For an AI-enabled function, both questions may require more than measuring model accuracy. They can include data representativeness, behaviour outside expected conditions, explainability appropriate to the user, change control and the ability of a human operator to recognize uncertainty.
After that work, the useful AF contribution might be a landscape review comparing assurance questions across sectors. It might be guidance on describing operational context. It might be a research collaboration. It may be no new document at all.
Matching the output to the need
| Identified need | Proportionate response |
|---|---|
| Participants use inconsistent concepts | A terminology note or framework |
| Existing requirements are frequently misunderstood | Guidance or a professional briefing |
| Evidence is insufficient | A research question or study |
| A proposed approach needs wider testing | Structured consultation |
| A voluntary practice is supported by evidence | Recommended Practice with a clear scope |
| Existing work already addresses the issue | No new technical document required |
“No new technical document required” can be a technically responsible conclusion. It avoids institutional duplication and directs participants toward the work that already has standing.
Expertise with governance
Future AF Technical Committees and Expert Working Groups should be established only where a defined need and sufficient competence justify them. A committee provides continuity and oversight within a mandate. A working group can bring focused expertise to a bounded task. Neither should exist merely to fill an organizational chart.
Useful work will require engineers, researchers, operators, manufacturers, testing professionals, universities, software specialists and others depending on the question. Membership can create a formal route through which relevant people and institutions indicate their expertise and participate where scope, available places and conflict-of-interest safeguards permit.
The quality of a technical programme is ultimately visible in its restraint: the questions it defines, the evidence it respects, the boundaries it records and the work it decides not to create.
Writing a question that can be worked
A useful topic proposal describes an observed problem, the users affected and the consequence of leaving it unresolved. It separates evidence from assumption and avoids prescribing the answer. “Organizations use inconsistent lifecycle-data definitions across supplier boundaries” is workable; “AF should create a universal digital-thread standard” has already selected an output before the need is tested.
The proposal should also indicate context. Is the issue found in design, production, operation or maintenance? Does it concern aircraft, spacecraft, infrastructure or several sectors? Are users facing a safety, interoperability, cost, knowledge or coordination problem? A bounded question helps AF identify existing work and the competence required for review.
Evidence does not all carry the same weight
Operational reports, controlled tests, peer-reviewed research, expert judgement and stakeholder experience can all contribute, but they answer different questions. A recurring observation can reveal a problem without explaining its cause. A laboratory test can isolate a mechanism without representing full operating conditions. Expert judgement can interpret incomplete evidence but should record the basis and uncertainty of that judgement.
Technical work should not exclude practical experience merely because it is difficult to quantify. It should distinguish the form of evidence, seek corroboration where possible and avoid presenting a limited observation as a universal conclusion.
Choosing participants for the question
Representation is not achieved by inviting one person from every broad sector. The necessary perspectives follow from the system and interfaces under review. An AI maintenance question may require data specialists, maintainers, system designers, safety engineers, operators and researchers. A spaceport question may require infrastructure, launch operations, emergency planning, airspace and local public-authority experience.
Competence should be relevant to the actual task. Conflicts should be disclosed and managed rather than assumed away. The group should be large enough to challenge blind spots but small enough to work. External consultation can broaden review after a coherent draft exists.
Draft, review and consultation
A draft makes reasoning inspectable. It should identify sources, define terms, explain choices and state limitations. Technical review then tests whether conclusions follow from the evidence. Editorial review tests whether users can understand the document without changing its technical meaning.
Consultation is not a vote on technical truth. It can reveal missing evidence, implementation constraints, unintended ambiguity and contexts the drafting group did not see. Comments should be recorded and resolved through a transparent method. Substantive changes may require further technical review.
Maintaining—or closing—the work
Publication is not the end of responsibility. A technical resource needs an owner, review date and route for reporting new evidence. Some documents should be revised; others should be withdrawn when authority, technology or practice changes. A document that cannot be maintained should not be given an indefinite appearance of currency.
Working groups should also close when their mandate is complete. Continuity belongs where the subject requires ongoing oversight, not where participants simply wish to preserve a title. This keeps the institutional structure proportionate to the work.
The standard is not the measure of success
AF can demonstrate technical seriousness through a well-evidenced landscape review, a research question directed to suitable partners or a clear explanation that an existing resource already meets the need. These outcomes may be less visible than launching a new standard, but they are more useful to the aerospace community.
Members will matter because they bring real problems and contexts into this process. The Federation’s responsibility is to resist turning every concern into a programme and to select work that its governance, evidence and available expertise can genuinely support.
