Directives are our primary tool for conveying requirements. If you need to require something of industry that is not already required by legislation, a directive is the first thing you should think of.
It’s important that our directives be as consistent as possible. Always download and use the latest template, available on Spark > Brand and Templates > Our Templates. It provides the standard directive “skeleton.”
Every directive should have a clear purpose statement that will allow any reader to ascertain what the document is about and how it applies to them.
The “AER Requirements” section is boilerplate that should not be altered without reason and without confirming with Law and the editors.
If a directive is being updated, it should have a “What’s New in This Directive” section that summarizes any changes in this edition. Long detailed change logs are inappropriate.
Think carefully about how to structure the main content of the directive. A clear, logical structure goes a long way to making a document easy to read and reference. Here are some things to consider:
Most of the time, only part of the directive will be relevant to a particular duty holder at a particular time in the life cycle. While they may read through the entire thing when it is first released, structure the document so they can quickly find the specific section they need in any given context. Your table of contents should tell a clear story.
Consider any feedback you’ve received from industry (and seek it out if you haven’t asked). Remember that these documents are not for us; they’re for them.
Don’t repeat yourself. If there is material that applies to multiple section, pull it out into its own section and reference it where appropriate. That way if language needs to change, it only needs to change in one place.
Appendices in directives (other than the glossary) should be rare. Appendices should be supplementary and not required reading. Therefore, there should not be any requirements in appendices.
Every requirement that is unique to the directive should be numbered.
Do not number requirements that simply restate or point to requirements in other documents.
Requirements are numbered continuously. In a handful of cases (particularly long and complex directives), requirement numbering may be restarted in each top-level section. This means that adding or removing requirements will result in renumbering of requirements (i.e., requirement numbers are not static).
Do consider knock-on effects as part of the project plan. Ensure you know what other instruments, forms, and web copy may need to change as a result of your work. This is especially true if the name of the directive is changing.
Don’t restate a requirement found in another instrument without providing a citation.