How do you read a technical requirement in AGL?
Split each clause into condition, item, strength, value and reference — then check you have read what it says, not what you expect.
Interpreting a technical requirement means reading it in parts: the condition that triggers it, the item it covers, its strength (shall, should or may), the value with its unit and tolerance, and the reference to the document, edition and method. Each part changes what you must do.
Most errors come from skipping the condition, treating a note as a rule, or reading an old edition. When the wording is unclear, ask the specifier and keep the written answer against the requirement.
- Read the whole clause. Include its definitions, notes and any cross-references.
- Split it into parts. Condition, item, strength, value and reference.
- Decide if it applies. Check your case against the condition and exceptions.
- Restate it plainly. Write it in your own words and compare with the source.
- Resolve doubts in writing. Ask, record the answer, and carry it into the matrix.
What the clause actually says, including its conditions, strength words and cross-references.
What we expect it to say from habit or a similar project, which may not match this clause.
Frequently Asked Questions
Q1What is the difference between shall, should and may?
In standards drafting, shall normally marks a requirement, should a recommendation, and may a permission. ICAO uses shall for Standards and should for Recommended Practices. Always check the foreword or definitions of the document you are reading, because wording conventions can vary. Strong wording such as must or shall not also binds, and a should can become binding if the contract or the authority adopts it.
Q2What if a requirement is ambiguous?
Do not guess. Write down the reading you think is correct and the alternatives, then ask the specifier or the document owner for clarification. Record the answer against the requirement so the same question is not argued again later.
Q3Do notes and examples count as requirements?
Often not. Many standards separate the normative text, which is binding, from notes, examples and guidance, which explain it. Read the document's own statement of which parts are normative before relying on a note.
Q4Why do the conditions matter so much?
Many requirements apply only in certain cases, such as a runway type, operation category or night use. Missing the condition can mean applying a rule that does not apply, or overlooking one that does.
Q5What if two documents seem to say different things?
Check that both really apply to your case, then check which document the contract names as governing. If the conflict remains, raise it with the specifier and record the decision. The standard comparison entry shows how the documents differ in purpose.
See It. Understand It. Then Learn How to Engineer It.
Recognising an AGL system visually is the first step. The next step is knowing how to design, install, test, commission and maintain them correctly.
Build Practical AGL Engineering Skills
Go deeper with structured training from Precision AGL Academy, covering:
Learn how each light, sign and circuit works as part of a complete airport lighting system, not just as an isolated diagram.