1. Global Industry Services
API Document Format & Style Manual and API Intellectual Property Presentation
Teresa Ambrosius
Danielle Jones
Global Industry Services

2. Forms and Reference Materials for Drafting API Standards
CRE web page – Forms and Reference Documents
Standards Development Tools including:
API Style Manual
API Standards Procedures
Applies to ALL API standards committee documents
Increasingly referenced in API contracts for content specialists/master editors
1220 L Street, NW • Washington, DC •

3. API Document Designation
Specifications - Documents that are written in such as way as to facilitate communications between purchasers, manufacturers, and/or service suppliers
Standards - Documents that combine elements of both specifications and recommended practices
Recommended Practices - Documents that communicate recognized industry practices; RPs may include both mandatory and non-mandatory requirements
Bulletins & Technical Reports - Documents that convey technical information on a specific subject or topic and are generally issued on a one time-basis
1220 L Street, NW • Washington, DC •

4. Why do you need to know about this?
Standards Writer
Facilitates standards development process if documents generally conform when drafting begins
Legal interpretation
Standards User
Regulatory compliance
Ease of use (uniformity of structure, style, terminology within a series of documents)
Legal Interpretation:
Should
Shall
1220 L Street, NW • Washington, DC •

5. Expression of provisions
Shall – provision is mandatory
Should – not mandatory, recommended as good practice
May – provision is optional, permissible, allowed
Can – statements of possibility
1220 L Street, NW • Washington, DC •

6. Expression of requirements
Verbal Form
Equivalent Expressions for Use in Exceptional Casesa
shall
is to
is required to
it is required that
has to
only... is permitted
it is necessary
shall not
is not allowed (permitted) (acceptable) (permissible)
is required to be not
is required that... be not
is not to be
NOTE 1 Do NOT use “may” when “shall” is meant.
NOTE 2 Do NOT use “may not” when “shall not” is meant.
a The equivalent expressions given the second column shall be used only in exceptional cases when the form given in the first column cannot be used for linguistic reasons.
1220 L Street, NW • Washington, DC •

7. Expression of requirements
Do NOT use “must” as an alternative for “shall” (this will avoid any confusion between the requirements of a document and jurisdictional regulatory obligations).
Do NOT use “must” instead of “has to” or “have to” for statements of fact (e.g. the vapor has to be above 300 psi in order for the valve to open).
Avoid using vague expressions that are not truly informative and may cause the reader to make an incorrect judgment call. Words like “very,” “all,” “every,” “never,” “excessive,” “slightly,” “approximately,” “nearly,” or “significant” are NOT useful.  
1220 L Street, NW • Washington, DC •

8. Expression of recommendations
Verbal Form
Equivalent Expressions for Use in Exceptional Casesa
should
it is recommended that
ought to
should not
it is not recommended that
ought not to
a The equivalent expressions given the second column shall be used only in exceptional cases when the form given in the first column cannot be used for linguistic reasons.
The Table summarizes the verbal forms that shall be used to indicate:
that among several possibilities one is recommended as particularly suitable, without mentioning or excluding the others, or
that a certain course of action is preferred but not necessarily required, or
that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.
1220 L Street, NW • Washington, DC •

9. Expression of permission
Verbal Form
Equivalent Expressions for Use in Exceptional Casesa
may
is permitted to
is allowed
is permissible
need not
it is not required that
no…is required
Do NOT use “possible” or “impossible” in this context.
Do NOT use “can” instead of “may” in this context.
NOTE “May” signifies permission expressed by the document, whereas “can” refers to the ability of a user of the document or to a possibility open to him/her.
a The equivalent expressions given the second column shall be used only in exceptional cases when the form given in the first column cannot be used for linguistic reasons.
1220 L Street, NW • Washington, DC •

10. Expression of possibility and capability
Verbal Form
Equivalent Expressions for Use in Exceptional Casesa
can
be able to
there is a possibility of
It is possible to
cannot
be unable to
there is not possibility of
it is not possible to
a The equivalent expressions given the second column shall be used only in exceptional cases when the form given in the first column cannot be used for linguistic reasons.
1220 L Street, NW • Washington, DC •

11. Preliminary matter When drafting standards
API Special Notes and Forward text is approved by API Office of General Council and cannot be revised by the committee.
Include “Draft” watermark and legal language in headers on all pages.
Committee can add to the Foreword, including:
other (complete) documents superseded;
list of specific sections of other documents superseded;
statement of significant technical changes from previous edition (optional).
1220 L Street, NW • Washington, DC •

12. Preliminary matter When drafting standards – Introduction
If including an Introduction:
NOT a numbered section;
appears on separate page prior to scope;
shall NOT contain requirements, recommendations, figures or tables;
background information/general description of document content/specific information or commentary about technical content/reasons prompting its preparation.
1220 L Street, NW • Washington, DC •

13. Document Scope Try to make it a single paragraph.
Define without ambiguity the subject of the document:
aspects covered;
limits of applicability (e.g. what it does not cover).
Shall NOT contain requirements or recommendations.
Always numbered as Section 1.
If it is an API Monogram document, reference to Annex A – API Monogram Annex – shall be included in the Scope:
“If product is supplied bearing the API Monogram and manufactured at a facility licensed by API, the requirements of Annex A shall apply.”
1220 L Street, NW • Washington, DC •

14. References to other documents Normative vs. Informative
Normative – those elements of a standard with which compliance is mandatory in order to claim conformity with the standard
Informative – those elements of a standard that provide additional information intended to assist in the understanding or use of the document
1220 L Street, NW • Washington, DC •

15. References to other documents
Normative – cited in such a way as to make them indispensable for the application of the document, for example:
Obtain a sample in accordance with API Standard 650.
Tanks shall be calibrated using the procedures given in API MPMS Chapter 2.2A or Chapter 2.2B.
Normative – can reference any document that is publicly available.
Normative – always numbered as Section 2 (if any normative references included).
1220 L Street, NW • Washington, DC •

16. References to other documents
Informative – bibliography, e.g.:
For more information, see API Publication 2566.
Guidance on this subject is given in ASME MFC-6M.
Informative – bibliography
References do not have to be cited in the document.
Informative – bibliography, always appears at the end of the document.
1220 L Street, NW • Washington, DC •

17. References to other documents
May be undated or dated
Undated references:
references to complete documents only;
if it is accepted that it will be possible to use all future changes of the referenced document;
understood to include all amendments and revisions of the referenced document.
Dated references:
references to specific sections, tables and figures of another document shall always be dated.
1220 L Street, NW • Washington, DC •

18. Definitions Definitions can not contain requirements
Should be a brief, self-contained description of the term in question (one sentence)
Additional information can be provided as notes
1220 L Street, NW • Washington, DC •

19. Definitions What should be defined: What should NOT be defined:
A term that is new or unique to the document being developed (i.e., it is not in the common parlance used by that sector of the industry). Example : High Integrity Pressure Protections System (HIPPS) – the subject of API 17O; Wellhead; Christmas Tree. 
A term that is used by other individuals, industry sectors or documents, but they use it slightly differently.  So the term must be defined for the purposes of use by that document.  Example “Pipeline”…one document may define pipeline to include breakouts and others many exclude breakouts.
What should NOT be defined:
Common words that are used in every day parlance (that do not fall into 1). or 2). above.  Examples, “contract”, “implement”, “records”.
Technical terms that all documents or sector already clearly understand, (example, Benzene, Highly Volatile Liquid, Specified Minimum Yield Strength (SMYS), Nonconformance, Heat Treatment,  Heat Affected Zone (HAZ).
Terms already defined by API elsewhere that apply to the document; example “standard”, “shall”, “should”, “may”, “recommended practice”, etc.
1220 L Street, NW • Washington, DC •

20. Annexes Must be referenced at least once in the text
Must appear in the order in which they are cited in the text
Their presence is optional
Annexes must be identified as “informative” (FYI) or “normative” (required)
An annex’s normative/informative status must be made clear by the way in which it is referred to in the text
1220 L Street, NW • Washington, DC •

21. Annexes
Normative annexes give provisions additional to those in the body of the document (…shall be in accordance with Annex F.)
Informative annexes give additional information intended to assist the understanding or use of the document (…see Annex G.)
Informative annexes may contain optional requirements
If the document is part of the API Monogram Program, the “Use of API Monogram by Licensees” shall be Annex A.
1220 L Street, NW • Washington, DC •

22. Hanging Paragraphs Incorrect Correct
5 Designation The quick brown fox jumps over the lazy dog. 5.1 Xxxxxxxxxxx 5.2 Xxxxxxxxxxx 5.1 General 5.3 Xxxxxxxxxxx
1220 L Street, NW • Washington, DC •

23. Addenda & Errata Errata Addenda
Corrects editorial mistakes or omissions
Cannot contain new material or revisions that changes the intent of the standard
Does not require a ballot
Addenda
Contains changes that either adds new material or changes the intent of the standard
May contain editorial changes as well
Requires a ballot
1220 L Street, NW • Washington, DC •

24. Figures & Tables Must be referenced at least once in the text
Must appear in the order in which they are cited in the text
Tables and Figures may have notes and/or footnotes
Notes in figures, tables, or the text of the document shall not contain requirements
Table footnotes may contain requirements
Contact API Standards staff prior to drafting figures for any questions regarding format, style, or software.
1220 L Street, NW • Washington, DC •

25. Figures
Be VERY cautious of pulling figures and images from 3rd party sources.
API MUST obtain permission from all 3rd party sources, this can be very time consuming.
API has a copyright approval form that can be sent to the 3rd party source for the permission to use the their figures.
API Editorial is happy to work with the API Standards Associate and Committees/Master Editor to draft new figures for documents prior to Ballot.
1220 L Street, NW • Washington, DC •

26. API Copyright Policy
All rights reserved. No part of this work may be reproduced, translated, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from the publisher. Contact the Publisher, API Publishing Services, 1220 L Street, NW, Washington, DC Copyright © 2015 American Petroleum Institute
1220 L Street, NW • Washington, DC •

27. Requesting Permission to Reprint API Copyrighted Material
Permission to Reprint API copyrighted must be submitted to us in writing.
API Request to Reprint API Copyrighted Material Form
1220 L Street, NW • Washington, DC •

28. API Request for Permission Review Process
In addition to the API Request for Permission Form a final draft or demo of the requestor’s publication or system will be required.
Permissions are granted on a case-by-case basis.
Normally, the review process could take up to 30 days.
A permission fee could be required based on the intended use of the API copyrighted material.
1220 L Street, NW • Washington, DC •

29. Reasons API Permissions Will Not Be Granted
Before API standard is published.
For endorsement purposes, implied or otherwise, of products or services, or to use API content as part of an advertisement of advertising supplement.
When using selections of any API document or the full text of any API document on other websites or in print.
1220 L Street, NW • Washington, DC •

30. Intellectual Property FAQ’s
What can I do with my gratis copy?
May I use the API Publication as a basis for my organization’s internal training program?
Can I make a copy of the API publication to share with a colleague?
I found this figure on the internet, can I use it in a new standard that I am developing?
I have a subscription to API standards, can I place documents on my company’s intranet or SharePoint site?
Where can I purchase an authorized copy of an API standard?
1220 L Street, NW • Washington, DC •

31. Questions? Thank you! Teresa Ambrosius ambrosiust@api.org
Danielle Jones E
For all standards writers (we understand):
1220 L Street, NW • Washington, DC •