stage 8 markdown style guide
Raw Data
This file contains raw search retrieval results or agent logs. The content below shows the original markdown source.
---
layout: raw-data.njk
title: "stage 8 markdown style guide"
---
# Stage 8: Markdown Style Guide
## Date and Agent
- Date: 2025-11-20
- Agent: Stage 8 - Markdown Style Familiarization
## Objective
Create comprehensive style guide for custom markdown used in Identification Standards to ensure consistency across all Phase 2 writing agents.
## Methodology
Examined 8 representative markdown files from MarkdownVersionsOfDocRefDocuments/ directory:
**Core Standards (4 files)**:
1. Federation Assurance Standard (federation-assurance-standard/2025--2025-01-10--en.md)
2. Information Assurance Standard (information-assurance-standard/2024--2024-09-27--en.md)
3. Authentication Assurance Standard (authentication-assurance-standard/2024--2024-09-27--en.md)
4. Binding Assurance Standard (binding-assurance-standard/2024--2024-09-26--en.md)
**Implementation Guidance (2 files)**:
5. Implementing the Federation Assurance Standard (implementing-the-federation-assurance-standard/2025--2025-01-10--en.md)
6. Implementing the Binding Assurance Standard (implementing-the-binding-assurance-standard/2024--2024-09-26--en.md)
**Supporting Materials (2 files)**:
7. Identification Terminology (identification-terminology/2025--2025-05-22--en.md)
8. Overview of the Identification Standards (overview-of-the-identification-standards/2024--2024-09-27--en.md)
Analysis focused on identifying patterns, visual distinction techniques, TOC auto-generation behavior, and deviations from standard markdown.
---
## Custom Markdown Style Reference
### 1. Headings
**Pattern**: No explicit markdown numbering. Use descriptive headings with clear hierarchy.
**Hierarchy Structure**:
```markdown
# Document Title (H1 - once per document)
### Subtitle/tagline (H3 - document description)
## Major Section (H2 - main sections)
### Subsection (H3 - objectives, topics)
#### Sub-subsection (H4 - controls, guidance items)
```
**Key Observations**:
- H1 used only once for document title
- H3 (not H2) used for subtitle/tagline immediately after H1
- NO H5 or H6 headings observed in any document
- Maximum depth: 4 levels (H1, H2, H3, H4)
- Headings use sentence case, not title case
- No trailing punctuation on headings
**Control/Objective Numbering**:
- Control IDs embedded in heading text: `#### FA1.01 Control`
- Guidance IDs embedded in heading text: `#### FA1.01 Guidance — risk assessment`
- Table titles embedded in text: `**Table 1:** Assurance components`
**Examples from Source**:
```markdown
# Federation Assurance Standard
### This standard provides additional controls for parties that provide credentials...
## Application of this standard
### Version and effective date
#### FA1.01 Control
```
**TOC Auto-Generation Implications** (per Tom's guidance):
- DocRef system auto-generates TOC from headings
- Only ONE table of contents possible
- Structure headings to create optimal auto-generated navigation
- Keep heading text concise and descriptive
- Ensure heading hierarchy is logical for TOC presentation
---
### 2. Lists
**Unordered Lists**:
```markdown
* First item
* Second item
* Nested item (4 spaces indent)
* Another nested item
* Third item
```
**Ordered Lists**:
```markdown
1. First item
2. Second item
3. Third item
```
**Key Patterns**:
- Use asterisk `*` for unordered lists (not dash `-` or plus `+`)
- Use `1.` `2.` `3.` for ordered lists (actual numbers, not all `1.`)
- Nested lists indent with 4 spaces
- Blank line before and after lists
- No blank lines between list items unless separating major groups
**Complex List Example** (from Federation Assurance Standard):
```markdown
The following assumptions have been made:
* Presentation of a Credential does not necessarily require the involvement (facilitation) of the Credential Provider.
* There are many ways in which a Credential can be presented, including physically or digitally and whether all or only part of the Credential subject information is made available.
```
---
### 3. Tables
**Standard Table Format**:
```markdown
| Column Header 1 | Column Header 2 |
|---|---|
| Row 1 Cell 1 | Row 1 Cell 2 |
| Row 2 Cell 1 | Row 2 Cell 2 |
```
**Alternative Alignment** (for longer content):
```markdown
| Column Header 1 | Column Header 2 |
| -- | -- |
| Content | Content |
```
**Table Title Pattern**:
```markdown
**Table 1:** Assurance components
| Assurance component | Description |
|---|---|
| **IA**: Information Assurance | Robustness of the process... |
```
**Key Patterns**:
- Table title BEFORE table using `**Table N:** Title` format
- Bold first column for emphasis where appropriate
- Use `|---|---|` or `| -- | -- |` for alignment row
- No trailing spaces in cells
- Multi-line content in cells uses `<br><br>` for paragraph breaks
- Keep cell content readable (avoid very long cells)
**Complex Table Example** (from Federation Assurance Standard):
```markdown
**Table 1:** Assurance components
| Assurance component | Description |
|---|---|
| **IA**<br><br>Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information. |
| **BA**<br><br>Binding Assurance | Robustness of the process to bind the Entity to Entity Information. |
```
---
### 4. Links and Cross-References
**External Links**:
```markdown
[Link Text](https://full-url.com)
Example:
[Collins Dictionary](https://www.collinsdictionary.com/)
```
**Internal Cross-References** (to other identification documents):
```markdown
[Link Text](/nz/identification-management/document-path/)
Examples:
[Information Assurance Standard](/nz/identification-management/information-assurance-standard/)
[Assessing identification risk](/nz/identification-management/guidance/assessing-identification-risk/)
```
**Email Links**:
```markdown
[identity@dia.govt.nz](mailto:identity@dia.govt.nz/)
```
**Image Links**:
```markdown
```
**Key Patterns**:
- Use descriptive link text (not "click here")
- Internal links use absolute paths starting with `/nz/identification-management/`
- No file extensions in internal document links
- Email links use `mailto:` protocol
- Alt text required for images
---
### 5. DocRef Citations
**CRITICAL PATTERN**: DocRef citations MUST follow this exact format:
```markdown
Content text ([DocRef](https://docref.digital.govt.nz/nz/path/to/document/#anchor))
```
**Integration Requirements**:
- Citations integrated naturally within text (not standalone)
- Citation appears at END of sentence or paragraph it references
- Format: `([DocRef](URL/))`
- NO text between parentheses except "DocRef" and URL
**Example from Implementation Guide**:
```markdown
During the Credential establishment process the Credential Provider is in the role of Relying Party and will need to apply the controls contained within the following Identification Standards ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard)).
```
**Phase 2 Requirement**:
- EVERY piece of content derived from source documents MUST include DocRef citation
- Maintain full traceability to source material
- Citations will come from MCP server query results
---
### 6. Visual Distinction: Standards vs. Guidance
**CRITICAL FOR PHASE 2**: Must distinguish normative standards text from implementation guidance.
**Current Pattern Analysis**:
Standards documents and implementation guides are SEPARATE files currently. We need to integrate them in Phase 2 with visual distinction.
**Pattern Observed in Standards Documents**:
- Standards use **objective-based structure**: "Objective N — Title"
- Controls within objectives: "#### XY#.## Control"
- Controls contain normative "MUST/SHOULD/MAY" language
- Additional information provided after controls in plain text
**Pattern Observed in Implementation Guides**:
- Guides use **same objective structure** but add "Guidance" suffix
- Guidance items: "#### XY#.## Guidance — descriptive name"
- Guidance uses explanatory, instructional tone
- Examples provided in blockquotes
**Proposed Visual Distinction Pattern for Integrated Documents**:
```markdown
### Objective 1 — Objective title
#### Rationale
[Explanatory text about why this objective matters - GUIDANCE]
#### FA1.01 Control
[Normative control text with MUST/SHOULD/MAY - STANDARD]
Additional information — [Explanatory details - GUIDANCE]
#### FA1.01 Guidance — implementation approach
[Implementation guidance, examples, practical advice - GUIDANCE]
> **Examples of implementation**
>
> * Example 1
> * Example 2
```
**Key Distinction Markers**:
1. **Control sections** = Normative standards text (cannot be modified in core standards)
2. **Rationale sections** = Context/explanation (guidance)
3. **Additional information** paragraphs = Explanatory notes (guidance)
4. **Guidance sections** = Implementation advice (guidance)
5. **Examples in blockquotes** = Practical illustrations (guidance)
**Visual Hierarchy**:
- Standards text (controls): Direct, prescriptive, uses MUST/SHOULD/MAY
- Guidance text: Explanatory, instructional, uses active voice (Phase 2 rewrite)
- Examples: Set off in blockquotes for clear distinction
---
### 7. Special Elements
#### 7.1 Blockquotes
**Standard Blockquote**:
```markdown
> Quote text here.
```
**Note Blockquote** (special callout):
```markdown
> **Note:** Important callout text here.
```
**Examples Blockquote** (common pattern):
```markdown
> **Examples of credential recognition mechanisms**
>
> For physical Credentials: Features that require proprietary knowledge...
>
> For digital Credentials: Digital certificates, cryptography...
```
**Key Patterns**:
- Blockquotes used for notes, warnings, examples
- Bold headers within blockquotes: `**Note:**`, `**Examples of...**`
- Blank line after bold header before content
- Multiple paragraphs separated by `> ` followed by blank line
#### 7.2 Diagrams and Figures
**Pattern**:
```markdown
::: fig
**Diagram 1:** Relationship between elements
:::
+++ Detailed description of diagram
This diagram shows...
* Element 1
* Element 2
+++
[View larger image (PNG 77KB)](../../files/image-file.png/)
```
**Key Components**:
- Wrapped in `::: fig` / `:::` markers
- Title as bold text before image
- Image with alt text
- Expandable description in `+++ ... +++` markers
- Optional link to larger version
#### 7.3 Detail Expanders (TO BE ELIMINATED IN PHASE 2)
**Current Pattern** (found in some documents):
```markdown
+++ Read the detailed description of diagram
Content that is hidden by default...
+++
```
**CRITICAL**: Per Tom's guidance and Phase 1 recommendations:
- **DO NOT use detail expanders in Phase 2 output**
- All content must be visible and accessible
- Use clear heading hierarchy instead
- This is an accessibility requirement
#### 7.4 Additional Information Paragraphs
**Pattern**:
```markdown
#### XY#.## Control
The RP MUST [normative requirement].
Additional information — [Explanatory text providing context or examples].
```
**Key Pattern**:
- Follows control statement
- Starts with "Additional information —" (em dash, not hyphen)
- Plain text (not blockquote)
- Provides clarification or examples
#### 7.5 Contact Information
**Standard Footer Pattern**:
```markdown
## Contact
Te Tari Taiwhenua Department of Internal Affairs
Email: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)
Last updated [DD Month YYYY]
```
**Key Patterns**:
- H2 heading "Contact"
- Agency name with two trailing spaces for line break
- Email on next line
- Blank line before last updated
- Date format: "10 January 2025" (not "2025-01-10")
---
### 8. Metadata and Frontmatter
**Observation**: NO YAML frontmatter observed in any document.
**Pattern**: Metadata provided within document body:
- Document title as H1
- Subtitle/description as H3
- Version history in "Version and effective date" section
- Last updated date at document end
**No Jekyll/Hugo-style frontmatter**:
```
# NO YAML LIKE THIS:
---
title: Document Title
date: 2025-01-10
---
```
---
### 9. Typography and Formatting
#### Emphasis
```markdown
*italic* or _italic_ (rare - almost never used)
**bold** (common - for emphasis)
```
#### Abbreviations/Acronyms
```markdown
Relying Party (RP)
Credential Provider (CP)
Level of Authentication Assurance (LoAA)
```
**Pattern**: Full term followed by abbreviation in parentheses on first use
#### Em Dash Usage
```markdown
Additional information — explanatory text
Objective 1 — descriptive title
```
**Pattern**: Em dash (—) not hyphen (-) for separation
#### Line Breaks
```markdown
Two trailing spaces for hard line break
Next line continues
Blank line for paragraph break
New paragraph
```
---
### 10. Deviations from Standard Markdown
#### 10.1 Figure Containers
```markdown
::: fig
Content
:::
```
**Non-standard**: Custom container syntax (not standard GFM)
#### 10.2 Detail Expanders
```markdown
+++ Expandable heading
Content
+++
```
**Non-standard**: Custom collapsible content syntax
**Phase 2 Action**: DO NOT USE (eliminate all hidden content)
#### 10.3 Table Alignment
Both `|---|---|` and `| -- | -- |` accepted (standard allows variation)
#### 10.4 Line Break Handling
Uses HTML `<br><br>` within table cells for multi-paragraph content
---
## Style Guide Summary for Writing Agents
### Quick Reference Card
**Headings**:
- H1: Document title (once)
- H3: Subtitle after H1
- H2: Major sections
- H3: Subsections/objectives
- H4: Controls/guidance items
- Max depth: 4 levels
**Lists**:
- Unordered: Use `*` (4 spaces for nesting)
- Ordered: Use actual numbers `1.` `2.` `3.`
**Tables**:
- Title: `**Table N:** Description`
- Format: `| Header | Header |` with `|---|---|`
- Bold emphasis: `**Text**` in cells
**Links**:
- External: `[Text](https://url)`
- Internal: `[Text](/nz/identification-management/path/)`
- DocRef: `([DocRef](https://docref.digital.govt.nz/...))`
**Visual Distinction**:
- Controls = Normative (MUST/SHOULD/MAY)
- Guidance = Explanatory (active voice)
- Examples = Blockquotes (`> **Examples...**`)
**Special Elements**:
- Blockquotes: `>` for notes/examples
- Figures: `::: fig` wrapper
- NO detail expanders (`+++`)
- Additional info: After controls
**Formatting**:
- Bold: `**text**`
- Em dash: `—` (not `-`)
- Line breaks: Two spaces or blank line
- No YAML frontmatter
---
## Examples from Source Documents
### Example 1: Standards Document Structure
**From Federation Assurance Standard**:
```markdown
# Federation Assurance Standard
### This standard provides additional controls for parties that provide credentials and/or presentation facilitation mechanisms on which others rely.
## Application of this standard
This standard applies to any Credential Provider (CP) and any Facilitation Provider (FP) that facilitates the presentation of 1 or more Credentials.
### Version and effective date
This standard is effective from 1 October 2024 and replaces all earlier versions.
## Part 1 — Requirements for Credential Providers establishing Credentials
### Objective 1 — Credential risk is understood
#### Rationale
For holders to trust their Credential is being adequately protected from unauthorised access and use, the risk the Credential poses when used in multiple contexts needs to be understood by the Credential Provider and mitigated.
#### FA1.01 Control
The CP MUST carry out an assessment of the risk posed by the existence of the Credential before offering it.
Additional information – While any risk assessment process can be used, specific guidance is available on [assessing identification risk](https://www.digital.govt.nz/standards-and-guidance/identification-management/guidance/assessing-identification-risk/).
```
### Example 2: Implementation Guidance Structure
**From Implementing the Federation Assurance Standard**:
```markdown
# Implementing the Federation Assurance Standard
### Guidance on the Federation Assurance Standard and how to comply with the controls.
> **Help us create the best guidance possible**
> If you would like anything added to or clarified in this guidance, email the Identification Management team at [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).
## Introduction
Federation Assurance deals with all the aspects of creating, managing and presenting Credentials and Authenticators that can be used in multiple contexts.
## Part 1 — Guidance for Credential Providers establishing Credentials
### Objective 1: Credential risk is understood
#### FA1.01 Guidance — risk assessment
Any robust risk assessment process may be used to identify the risk of the Credential. The context for the Credential is the purpose it is to serve and the environment in which it will exist, including whether it's a physical or digital Credential.
> **Example of general levels of binding**
> * Level 1 — Binding is very light, possibly aligned to self-asserted information.
> * Level 2 — A distinct link is needed between the Entity and their information.
```
### Example 3: Table Formatting
**From Overview Document**:
```markdown
**Table 1:** Assurance standards for Relying Parties
| Assurance standard | Description |
| -- | -- |
| **IA**: Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information |
| **BA**: Binding Assurance | Robustness of the process to bind the Entity to Entity Information |
| **AA**: Authentication Assurance | Robustness of the process to ensure an Authenticator remains solely in control of its holder |
```
### Example 4: Terminology Table
**From Identification Terminology**:
```markdown
**Table 1:** Agreed terms
| **Term** | **Definition** |
|----------|----------------|
| account | an instance of entity information in a context<br><br>\[Source: New definition\]<br><br>Additional note:<br><br>Note 1: A common term for the set of entity information relating to 1 entity to which an authenticator can be registered and from which credential subject information can be taken to establish a Credential. |
| accountable | responsible for some action; answerable<br><br>\[Source: expanded Dictionary meaning of accountable\] |
```
### Example 5: Diagram with Description
**From Authentication Assurance Standard**:
```markdown
::: fig
**Diagram 1:** Relationship between elements
:::
+++ Detailed description of diagram
This diagram shows a triangle representing the connection between Entity (in this example, represented by a person) at the top of the triangle, Authenticator (represented by a key) at the bottom left, and Entity Information (represented by files of information) at the bottom right.
The connection between Entity and Entity Information is labelled Entity Binding. The connection between Entity Information and Authenticator is labelled Authenticator Registration. The connection between Authenticator and Entity is Authenticator Control.
+++
[View larger image (PNG 75KB)](../../files/identification-management-element-diagrams.png/)
```
---
## Special Considerations for Phase 2
### 1. TOC Auto-Generation (Critical)
**Tom's Guidance**: "DocRef system will automatically generate a table of contents for headings, and only one table of contents is possible."
**Implications**:
- Structure heading hierarchy carefully for optimal TOC
- Use consistent heading levels throughout
- Keep heading text concise but descriptive
- No need to manually create TOC
- Avoid overly deep nesting (max 4 levels recommended)
### 2. Visual Distinction Pattern (Critical)
**Challenge**: Integrate standards and guidance while maintaining clear distinction between normative and explanatory content.
**Proposed Solution**:
- Use structural cues: "Control" vs "Guidance" in headings
- Maintain normative language (MUST/SHOULD) in standards
- Use active voice explanatory language in guidance
- Set examples in blockquotes
- Use "Additional information" paragraphs for clarification
**Verification Requirement**:
- Core standards text must remain unchanged
- Only structure and presentation improvements allowed
- Visual distinction must be clear without modifying normative text
### 3. Detail Expanders - ELIMINATE (Critical)
**Tom's Directive**: Eliminate all detail expanders and hidden content patterns.
**Action Required**:
- DO NOT use `+++ ... +++` syntax for expandable content
- Surface ALL content through clear heading hierarchy
- Use proper H2/H3/H4 structure instead of hiding content
- Exception: Diagram descriptions can remain expandable (accessibility feature)
### 4. DocRef Citation Integration (Critical)
**Requirements**:
- Every piece of content from source documents needs DocRef citation
- Format: `([DocRef](URL/))`
- Integrate naturally at end of sentence/paragraph
- Never standalone citation paragraphs
- Citations will come from MCP server query results
**Example of Good Integration**:
```markdown
During the Credential establishment process, the Credential Provider applies the Information Assurance, Binding Assurance, and Authentication Assurance Standards ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/#fa2-01)).
```
### 5. Intra-Document Linking Strategy
**Tom's Guidance**: "When it comes to cross-linking, these will need to be achieved through DocRef links back to the document, where the block IDs docrefIDs have not yet been assigned, so we need a simple method of being confident about which links go where."
**Challenge**: Creating cross-references within the new consolidated document.
**Proposed Solution**:
- Use heading-based anchor pattern: `#heading-text-lowercase-hyphenated`
- Document cross-reference map in Stage 9 (content retrieval planning)
- Maintain list of all heading anchors for reference
- For links to existing standards: Use full DocRef URLs
- For links within new document: Use relative anchor links
**Example**:
```markdown
See [Objective 1](#objective-1-credential-risk-is-understood) for risk assessment requirements.
For existing standards reference:
See [Information Assurance Standard](/nz/identification-management/information-assurance-standard/) for information quality controls.
```
### 6. Active Voice Conversion (Critical for Guidance)
**Phase 1 Finding**: Systematic active voice conversion required in guidance materials.
**Current Pattern** (passive - found in many guides):
- "Risk assessment should be undertaken..."
- "Consideration needs to be made..."
- "The process will be assessed..."
**Required Pattern** (active - for Phase 2):
- "Undertake a risk assessment..."
- "Consider the following factors..."
- "Assess the process against..."
**IMPORTANT**: Active voice applies to GUIDANCE only, not core standards controls (which cannot be modified).
### 7. Custom Markdown Flavour Summary
**This is a variant of GitHub Flavored Markdown (GFM) with custom extensions**:
**Standard GFM Elements Used**:
- Headings, lists, tables, links, images
- Bold, italic (rarely)
- Blockquotes
- Email links
**Custom Extensions**:
- Figure containers: `::: fig ... :::`
- Detail expanders: `+++ ... +++` (TO BE ELIMINATED)
- Em dash for section titles and additional info
**Not Used**:
- Code blocks (no technical code examples)
- Horizontal rules (use headings for section breaks)
- HTML (except `<br>` in tables)
- YAML frontmatter
---
## Questions and Uncertainties
### 1. Anchor Link Format
**Question**: What exact format should be used for intra-document anchor links in the consolidated document?
**Context**: Tom noted that "block IDs docrefIDs have not yet been assigned" for the new consolidated content.
**Proposed Solution**: Use heading-based anchors (standard markdown convention):
- `#heading-text-lowercase-hyphenated`
- Document all anchor targets in retrieval planning stage
- Create anchor reference list for consistency
**Resolution Needed**: Confirm this approach with Tom or test anchor format early.
### 2. Visual Distinction Verification
**Question**: Is the proposed visual distinction pattern sufficient to clearly separate normative standards from guidance?
**Context**: Phase 2 requires integrating standards and guidance while maintaining clear distinction.
**Proposed Pattern**:
- Structural cues (Control vs Guidance headings)
- Language cues (normative MUST/SHOULD vs explanatory active voice)
- Format cues (examples in blockquotes)
**Resolution Needed**: Validate pattern early in Stage 11 (content writing) with stakeholder review.
### 3. Diagram Handling
**Question**: Should diagram descriptions remain as expandable content (+++), or should they be fully visible?
**Context**: Detail expanders to be eliminated, but diagram descriptions may be accessibility feature.
**Observation**: Current pattern uses `+++ Detailed description of diagram ... +++`
**Proposed Solution**: Keep diagram descriptions expandable as this serves accessibility (screen reader users can access expanded description). This is different from "tucking away" content - it's providing alternative format.
**Resolution Needed**: Confirm with Tom that diagram descriptions are exception to "no hidden content" rule.
### 4. Table Complexity Management
**Question**: How to handle very complex tables (like those in terminology document) in consolidated format?
**Context**: Some tables have very long cell content with multiple paragraphs and source citations.
**Current Pattern**: Uses `<br><br>` for paragraph breaks within cells
**Proposed Solution**: Keep current pattern but ensure tables remain readable. For extremely complex tables, consider restructuring as definition lists or nested sections.
**Resolution Needed**: Test table rendering early in Stage 11.
---
## Next Steps for Stage 9 (Content Retrieval Planning)
Based on this style analysis, Stage 9 should:
1. **Create heading structure template** for consolidated document following observed patterns
2. **Map visual distinction strategy** for each section (which parts are standards, which are guidance)
3. **Plan anchor link strategy** for intra-document cross-references
4. **Identify content that needs active voice conversion** (all guidance materials)
5. **Document citation integration plan** (how to preserve DocRef citations from MCP queries)
6. **Test markdown rendering** early with sample sections to validate style compliance
---
## Conclusion
This style guide documents the custom markdown flavour used in the Identification Standards documents. The style is a variant of GitHub Flavored Markdown with specific conventions for:
- **Heading hierarchy**: Max 4 levels, no numbering, descriptive titles
- **Visual distinction**: Structural and language cues to separate standards from guidance
- **Tables**: Titled, formatted with emphasis in first column where appropriate
- **Links**: Internal absolute paths, external full URLs, DocRef citation pattern
- **Special elements**: Figure containers, blockquotes for examples/notes, NO detail expanders
- **Typography**: Em dashes, bold emphasis, minimal italics
**Critical Success Factors for Phase 2**:
1. **Maintain this exact style** throughout all writing
2. **Eliminate detail expanders** - surface all content
3. **Integrate DocRef citations** naturally in all content
4. **Distinguish standards from guidance** clearly
5. **Structure for TOC auto-generation** (only one TOC possible)
6. **Convert guidance to active voice** (not standards controls)
This guide provides the foundation for consistent, high-quality Phase 2 content creation across all writing agents.
---
**Stage 8 Complete: Ready to proceed to Stage 9 (Content Retrieval Planning)**