Standard Template & Style Guide

Note: This document is a template. It contains structural guidance in [bracketed italics] and [Required]/[Optional] annotations on section headings. Remove these annotations when writing a real standard. Refer to the SANE conventions for shared requirement language and process rules.

---

1. Standard at a Glance [Required]

Use this section as the quick-reference page for the standard. It should help a reader understand the basic idea of the standard without reading the entire document first. Keep it short, practical, and easy to scan. Do not use this section for deep explanation, edge cases, long examples, or background theory — those belong later in the document.

1.1 What This Standard Is About [Required]

Briefly explain what the standard controls. Write in plain language. Good pattern: “This standard defines how [subject] should be [labeled / documented / measured / installed / configured / verified] in professional AV systems.” One short paragraph is usually sufficient.

This standard defines how [subject] should be [action] in professional AV systems.

1.2 Why It Matters [Required]

Briefly explain the practical problem this standard solves. Focus on real AV work: design clarity, installation consistency, commissioning, troubleshooting, service, owner handoff, safety, interoperability, or long-term maintenance. Good pattern: “This standard exists so that [reader or role] can [do useful thing] without [common problem].” One short paragraph is usually sufficient.

This standard exists so that [reader or role] can [do useful thing] without [common problem].

1.3 Core Rules [Required]

List the most important requirements from the body of the standard. This is a summary, not a replacement for the full requirements section. Each item should be short enough to scan quickly. Use MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY only when the same requirement is fully defined later in the document. Recommended length: 3 to 7 items.

• [First core rule]
• [Second core rule]
• [Third core rule]

1.4 Compliance Snapshot [Required]

Summarize how someone can tell whether the standard was followed. This should not introduce new requirements — it should point back to the compliance section later in the document. Address: what must be present, what must match, what must be verified, what must be documented, what would clearly fail.

• What must be present: [brief]
• What must match: [brief]
• What must be verified: [brief]
• What must be documented: [brief]
• What would clearly fail: [brief]

1.5 Where to Go Next [Required]

Guide different readers to the parts of the standard they are most likely to need. Only include roles relevant to the specific standard.

Template note: When writing real standards, prefer descriptive references (e.g., “the Compliance section”) over specific section numbers. Section numbers may shift during revision, and descriptive references are less likely to go stale.

• Designers should review Sections [X] and [Y].
• Installers should review Sections [X] and [Y].
• Programmers should review Sections [X] and [Y].
• Commissioning agents should review Sections [X] and [Y].
• Service technicians should review Sections [X] and [Y].

---

2. Purpose [Required]

Explain why the standard exists. The purpose should describe the problem being solved and the outcome the standard is trying to create. Keep this section focused — do not put detailed requirements here. Good pattern: “This standard defines [subject] for use in professional AV system design, installation, documentation, commissioning, and long-term support. The purpose of this standard is to reduce [ambiguity / inconsistency / rework / service difficulty / safety risk / coordination problems] by establishing [clear requirement or convention].”

This standard defines [subject] for use in professional AV system design, installation, documentation, commissioning, and long-term support.

The purpose of this standard is to reduce [problem] by establishing [solution].

---

3. Scope [Required]

Define the boundaries of the standard. The reader should understand what the standard applies to and what it does not apply to.

3.1 In Scope [Required]

List the systems, documents, equipment types, project phases, workflows, or conditions covered by the standard. May include: covered system types, document types, project phases, physical conditions, signal types, user roles, verification activities.

• [Covered system type]
• [Covered project phase]
• [Covered activity or condition]

3.2 Out of Scope [Required]

List related topics that are not covered by this standard. This is important because many AV topics overlap. May include: topics handled by another SANE standard, topics governed by code/law/authority having jurisdiction, manufacturer-specific procedures, owner-specific requirements, design choices intentionally left flexible. If another standard covers an excluded topic, reference it here.

• [Excluded topic]
• [Excluded topic] — handled by SANE-[XXX] if applicable.

---

4. Audience [Required]

Identify who the standard is written for. A SANE standard should be readable by the people who need to create, review, install, commission, service, or maintain the work. Include only the roles that are relevant to the specific standard.

Possible audiences include: AV designers, AV engineers, installers, rack fabricators, DSP programmers, control system programmers, commissioning agents, service technicians, project managers, owners and operators, IT/network teams, architects and electrical engineers, and reviewers responsible for project acceptance.

---

5. Definitions [Required]

Define terms that are necessary to understand the standard. Only define terms that are used in a specific way in this document. Do not define common AV terms unless the definition matters to the standard. Format: Term Name — Definition of the term as it is used in this standard. If a term is defined by an external standard, cite that source in the references section.

Term Name — Definition of the term as it is used in this standard.

Another Term — Another definition. As defined in [external standard].

---

6. Requirement Language [Required]

This standard uses the key words defined in the SANE conventions document for expressing requirement levels. A summary is provided below; the canonical definitions are maintained in the SANE conventions.

MUST — The requirement is mandatory for compliance.

MUST NOT — The item is prohibited.

SHOULD — The item is strongly recommended, but exceptions may exist with documented justification.

SHOULD NOT — The item is discouraged, but exceptions may exist with documented justification.

MAY — The item is optional.

Only use MUST for requirements that can be verified by review, inspection, measurement, testing, or documentation.

---

7. Requirements [Required]

This is the main body of the standard. Each requirement should be: clear, numbered, testable, specific enough to implement, and written so a third party can verify it. Avoid vague requirements like “use best practices” or “ensure good performance” — instead, define what “clear,” “good,” or “complete” means.

7.1 General Requirements [Required]

Requirements that apply broadly across the standard.

1. [First general requirement.]
2. [Second general requirement.]

7.2 Format Requirements [Optional]

Use this section when the standard defines a required structure, naming convention, drawing convention, table format, label format, file format, signal format, or other repeatable pattern. Tables are often useful here.

Element	Format	Example
[Element name]	[Format specification]	[Example value]

7.3 Documentation Requirements [Optional]

Information that must appear in drawings, schedules, configuration files, reports, labels, handoff documents, or other project records. Remove this section if the standard does not impose documentation requirements.

1. [First documentation requirement.]
2. [Second documentation requirement.]

7.4 Installation or Implementation Requirements [Optional]

Requirements that affect physical installation, configuration, programming, commissioning, or deployment. Remove this section if the standard does not cover installation or implementation.

1. [First installation requirement.]
2. [Second installation requirement.]

7.5 Prohibited Practices [Optional]

Things that are not allowed because they create ambiguity, inconsistency, unsafe conditions, service difficulty, or project risk. A prohibited practice should use MUST NOT. Remove this section if no practices are prohibited.

1. [First prohibition — use MUST NOT.]
2. [Second prohibition — use MUST NOT.]

7.6 Recommended Practices [Optional]

Practices that are strongly recommended but not mandatory. Use SHOULD. Do not put optional advice here if it has no real effect on the success of the work. Remove this section if no practices are recommended beyond the requirements above.

1. [First recommendation — use SHOULD.]
2. [Second recommendation — use SHOULD.]

---

8. Compliance [Required]

Define what it means to claim compliance with the standard. Compliance should be objective. A reviewer should be able to determine whether the standard was followed without guessing the author’s intent.

8.1 Compliance Requirements [Required]

List the conditions that must be satisfied for compliance. These should reference requirements from Section 7 rather than introduce new rules.

An installation, document, or deliverable claiming compliance with this standard shall:

1. [Compliance condition referencing a requirement from Section 7.]
2. [Compliance condition referencing a requirement from Section 7.]

8.2 Compliance Evidence [Optional]

List the types of evidence that can be used to verify compliance. Possible evidence may include: drawings, equipment schedules, cable schedules, rack elevations, photographs, configuration files, DSP files, control system files, network configuration records, test results, commissioning reports, handoff documentation. Include only evidence types relevant to the specific standard. Remove this section if evidence requirements are covered by the compliance requirements above.

• [Evidence type 1]
• [Evidence type 2]

8.3 Non-Compliance [Optional]

Describe the kinds of failures that would make an implementation non-compliant. This section should help reviewers, installers, and project teams recognize common failure modes. Remove this section if non-compliance is self-evident from the requirements.

1. [Common failure mode 1]
2. [Common failure mode 2]

---

9. Examples [Optional]

Show how the standard works in practice. Examples should support the requirements — they should not replace the requirements. Possible example types include: compliant example, non-compliant example, borderline example, drawing example, label example, table example, configuration example, field condition example, exception example. Each example should explain why it passes or fails. If examples would make the standard confusing or artificially specific, keep them minimal and place extended examples in Appendix A. Remove this section if examples are not needed.

Example: [Compliant scenario]

[Description of the scenario and why it passes.]

Example: [Non-compliant scenario]

[Description of the scenario and why it fails.]

---

10. Field Notes [Optional]

Practical guidance that helps people apply the standard in real AV work. This section may include lessons from design, installation, commissioning, service, ownership, or long-term maintenance. Field notes are useful for explaining how the standard is likely to fail in real life. May cover: common mistakes, coordination issues, service implications, handoff issues, retrofit concerns, owner-furnished equipment, legacy systems, multi-phase projects, differences between drawings and field conditions. Field notes are not mandatory unless they use requirement language such as MUST or SHOULD. Remove this section if no field notes are needed.

• [Topic]: [Practical observation or lesson.]
• [Topic]: [Practical observation or lesson.]

---

11. Exceptions [Optional]

Explain how exceptions are handled. Exceptions should be allowed, but they should be documented. A documented exception should include: the requirement being excepted, the reason for the exception, the alternate method used, the person/role/authority approving the exception, the date of approval. Exceptions should not be used to avoid safety, code compliance, testing, documentation, or owner requirements. Remove this section if exceptions are not applicable.

To request an exception from this standard:

1. [Document the requirement being excepted.]
2. [Document the reason for the exception and the alternate method used.]

---

12. Relationship to Other Standards [Required]

Explain how this standard relates to other standards, requirements, or authorities. May include: other SANE standards, public standards, manufacturer documentation, project specifications, codes and regulations, owner standards, contract documents.

• This standard extends / complements / is independent of SANE-[XXX].
• [Relationship to another standard, code, or authority.]

When this standard conflicts with law, code, contract requirements, manufacturer requirements, or an authority having jurisdiction, the higher authority governs.

---

13. References [Required]

List sources used by the standard. Separate references into normative and informative when appropriate.

13.1 Normative References [Optional]

Normative references are required to apply the standard. Use this section for external standards, codes, or documents that the reader must follow in order to comply. Remove this section if there are no normative references.

• [Standard Number]: [Standard Title]
• [Standard Number]: [Standard Title]

13.2 Informative References [Optional]

Informative references provide background, examples, supporting information, or related reading. Use this section for sources that help explain the standard but are not required for compliance. Remove this section if there are no informative references.

• [Source title or description]
• [Source title or description]

---

Appendix A: Extended Guidance [Optional]

Deeper guidance that is useful but not necessary for the quick understanding of the standard. May include: extended explanation, extended examples, edge cases, legacy-system guidance, migration guidance, manufacturer-specific considerations, owner handoff guidance, review procedures. Remove this appendix if not needed.

---

Appendix B: Rationale [Optional]

Explain why the standard was written the way it was. The body of the standard should define what is required; the rationale should explain why those requirements exist. Good content includes: design reasoning, tradeoffs, history, prior art, problems the standard is trying to prevent, why stricter or looser requirements were not chosen. Remove this appendix if not needed.

---

Appendix C: Revision History [Optional]

Track published-version changes here. The canonical revision history is the git log for this repository; this appendix provides a human-readable summary for stable releases only. Remove this appendix for draft standards.

Version	Date	Notes
0.1	YYYY-MM-DD	Initial draft.

SANE. (2026). SANE-000: Standard Template & Style Guide. https://sane-av.github.io/standards/sane-000-example/

@misc{sanesane000,
  title = {SANE-000: Standard Template & Style Guide},
  author = {SANE Community},
  year = {2026},
  url = {https://sane-av.github.io/standards/sane-000-example/},
  note = {Version 0.1}
}