stage 4 thematic synthesis

---
layout: raw-data.njk
title: "stage 4 thematic synthesis"
---

# Stage 4: Thematic Synthesis

## Date and Agent
- Date: 2025-11-19
- Agent: Claude (general-purpose agent)

## Objective

Synthesize all findings from Stages 1-3 to identify major themes, contradictions, and improvement opportunities. Transform detailed analysis into strategic insights that will inform Phase 2 structure proposal and content creation. Bridge the gap between analysis (Stages 1-3) and recommendations (Stages 6-7).

## Methodology

### Synthesis Approach

1. **Comprehensive Review**:
   - Read all three previous findings documents (Stages 1-3)
   - Re-read TomNotesManualReview.md with deeper contextual understanding
   - Synthesized across 9,374 nodes, 30 documents, 23 annotation sets, 40+ Tom observations

2. **Pattern Integration**:
   - Connected Stage 1 findings (document taxonomy, MCP capabilities) with Stage 2 patterns (7 major themes) and Stage 3 evaluations (4 material sets)
   - Identified recurring themes across multiple data sources
   - Distinguished root causes from symptoms

3. **Root Cause Analysis**:
   - Investigated why issues exist, not just what they are
   - Examined historical, structural, and cultural factors
   - Considered constraints and trade-offs

4. **Strategic Framing**:
   - Organized findings by user impact and feasibility
   - Prioritized issues by severity, scope, and implementation complexity
   - Developed actionable pathways for Phase 2

## Executive Summary

### The Core Problem

The identification standards suffer from a fundamental misalignment between their **primary purpose** (enabling conformance assessment) and their **actual presentation** (conceptual explanation of identification management). This manifests in three critical ways:

1. **Conformance is invisible despite being "the whole point"**: The conformance process, which Tom correctly identifies as the primary reason users engage with standards, is semantically isolated (0 semantic neighbors), "tucked away" in a separate document, and treated as peripheral when it should be central.

2. **Guidance is more accessible than standards but treated as secondary**: Implementation guides score higher in semantic searches than the standards they explain (0.911 vs 0.871), contain more examples and practical content, yet are separated into parallel documents that force users to navigate between requirements and implementation.

3. **Presentation obscures rather than reveals**: Passive voice pervades guidance (15+ annotations), detail expanders hide essential information, threshold considerations appear late in documents, and the structure assumes reading for comprehension rather than working toward conformance.

### The Opportunity

Phase 2 restructuring can transform these materials from **reference documentation** into **implementation assets** by:

1. **Making conformance the organizing principle**: Structure the entire resource around the conformance workflow - what users must do, how to do it, how to document it, and how to get assessed.

2. **Integrating standards and guidance**: Eliminate artificial separation between requirements and implementation, presenting both together with clear visual distinction (following digital.govt.nz content design methodology).

3. **Shifting from passive description to active direction**: Rewrite guidance materials using active voice and direct address ("you must...", "perform these steps..."), following Plain Language Act 2022 requirements and digital.govt.nz standards.

4. **Addressing critical gaps**: Augment with biometric privacy requirements (Privacy Code 2025) and specific cybersecurity cross-references (NCSC standards), filling gaps that Tom identified.

### Priority Actions for Phase 2

**MUST DO** (Critical for usability and compliance):
1. Make conformance central organizing framework
2. Systematic active voice conversion in guidance
3. Eliminate all detail expanders
4. Integrate standards and guidance
5. Add biometric privacy requirements (mandatory law)

**SHOULD DO** (Significant improvements):
6. Surface threshold information early
7. Clarify DISTF-Standards relationship
8. Add specific NCSC cross-references
9. Integrate "About Identification Management" concepts
10. Create user journey pathways

**COULD DO** (Enhancement opportunities):
11. Flatten excessive hierarchy (>5 levels)
12. Convert checklists to integrated markdown
13. Clarify terminology authority approach
14. Resolve Privacy Act relationship tension

## Recurring Themes Across All Findings

### Theme 1: Conformance Should Be Central, Not Peripheral

**The Defining Issue**: Tom's observation is definitive: "It feels like the process of conforming with the standards is the whole point of even reading the standards in the first place. People are coming to the standards to try and conform with them, or to understand others' conformance with them. It's not clear why this is tucked away." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 1**:
- Semantic search for "conformance processes" returned lower scores (0.85-0.88 range) compared to other topics (0.89-0.93)
- Conforming with Standards document has 205 nodes but only 1,690 semantic connections (8.2 per node)
- Compare to Federation Standard: 3,160 connections for 431 nodes (7.3 per node) - similar density but lower absolute connectivity

**Evidence from Stage 2**:
- Semantic neighbor query for conformance section (#part3-subpart1-section1) returned **0 results above 0.75 threshold**
- Conformance content is semantically isolated from standards content
- Tom's annotation: "This should be the way in to understanding the standards and the guidance" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart1-section1))
- Tom's annotation: "If the main purpose of the identification standards is to demonstrate conformance, and the main way of demonstrating conformance is to generate evidence and perform assessments, then these checklists should be the most important and predominant way into all of this material, and the material should be directed toward explaining these assets." ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5))

**Evidence from Stage 3**:
- Digital.govt.nz content design principle: organize by user goals and needs
- User-centered design: put most important information first
- Plain Language Act: content should be "appropriate to the audience" and "well organised"

**Root Cause**:
The standards were structured for **conceptual explanation** (understanding identification management as a discipline) rather than **operational implementation** (achieving conformance). This reflects a traditional "standards document" model where conformance is an afterthought to specification.

**Strategic Implication**:
Conformance should be the **primary organizing framework** for Phase 2 restructured materials. This means:
- Starting with "Why conform?" and "Is conformance relevant to you?"
- Organizing content around conformance workflow: Assess → Implement → Document → Get Assessed → Maintain
- Making checklists central navigation and organizational tools
- Integrating standards, guidance, and assessment materials into cohesive conformance pathway

**Severity**: CRITICAL - Misalignment between user goals and content organization
**Scope**: System-wide - Affects entire information architecture
**Feasibility**: MODERATE - Requires significant restructuring but doesn't conflict with core standards constraint

### Theme 2: Passive Voice Obscures Agency and Responsibility

**The Pervasive Problem**: Tom identified passive voice in 15+ annotations across multiple documents, consistently noting it makes content "confusing," "very vague," and harder to understand than active voice alternatives.

**Evidence from Stage 2**:
- "Passive voice is confusing" (Assessing Risk, part1-para2)
- "Why so passive? 'Issuance' - by who?" (Conforming, part3-subpart3-title)
- "Very vague. Very passive" (Conforming, part3-subpart2-section4-para2)
- "Would be much clearer in active voice" (Assessing Risk, part4-det7)
- Contrast: "Active voice - much clearer" appears in multiple annotations where Tom praises clear sections

**Examples of Passive Constructions**:
- "This standard applies to..." vs "You must apply this standard when..."
- "Application of the controls will contribute..." vs "Apply these controls to..."
- "The scope of requirements is related to..." vs "These requirements cover..."
- "Credential enrolment" vs "X enrols the credential"

**Evidence from Stage 3**:
- Digital.govt.nz Tone and Voice guidance: **"Use the active voice, where possible"**
- Digital.govt.nz: **"Use 'you' and 'your' when talking to the reader"**
- Example provided: "Take a copy of your [document]" not "provide supporting documents"
- Plain Language Act 2022: Content must be "clear" and "appropriate to the audience"
- Technical practitioners need clarity on who does what, when

**Constraint Consideration**:
- **Core standards text cannot be changed**: Authentication Assurance Standard, Binding Assurance Standard, Information Assurance Standard, Federation Assurance Standard retain passive voice in normative requirements
- **Guidance materials CAN be rewritten**: Implementation guides, process guidance (Conforming, Assessing Risk, Counter Fraud, Authenticator Types, etc.) can be systematically converted to active voice

**Root Cause**:
Passive voice reflects traditional regulatory/standards writing conventions that emphasize requirements as abstract, objective facts rather than instructions to specific actors. This conflicts with modern content design principles that emphasize clarity, directness, and user-centered language.

**Strategic Implication**:
Phase 2 must systematically convert all guidance materials (not core standards) to active voice:
- Identify the actor: "You perform...", "The credential provider must...", "DIA validates..."
- Use imperative constructions: "Apply these controls...", "Document your evidence..."
- Address the reader directly: "When you assess risk...", "Your conformance assessment..."

**Severity**: HIGH - Significantly impacts comprehension and usability
**Scope**: System-wide - Affects all guidance materials (12+ documents)
**Feasibility**: HIGH - Straightforward rewriting task using digital.govt.nz methodology

### Theme 3: Content Fragmentation and "Tucking Away" Critical Information

**The Structural Problem**: Tom identified 12+ instances where essential information is hidden in detail expanders, buried in separate documents, or placed late rather than prominently featured.

**Evidence from Stage 2 - Detail Expanders**:
- "The detail expanders here don't help because they're the main point of the content" (Conforming, part1-title)
- "There is no point to burying these in detail expands" (Conforming, part3-subpart3-section7)
- "So much essential information in here all buried away" (Assessing Risk, part3-det4)
- "So much information tucked away" (Assessing Risk, part3-det5, part3-det7)
- "Rehashes information... Much clearer, but buried away in a detail expander" (Assessing Risk, part3-det3)
- Tom's explicit directive: **"Get rid of all detail expanders"**

**Evidence from Stage 2 - Threshold Information Buried**:
- "This is again a really important entry threshold consideration for anyone who is considering whether they want to even bother reading the standards" (Conforming, part3-subpart3-section6-para1)
- "Again, re-conformance and point in time assessment is an important threshold consideration for any entity that might be considering the conformance process" (Conforming, part4)
- "This is a really important point to establish much earlier because they seem exclusive" (Conforming, part3-subpart1-section1-para5)
- "This again seems like a precondition for performing this whole exercise and it should be brought up much earlier" (Assessing Risk, part4-det9)

**Evidence from Stage 2 - Important Guidance Placed Late**:
- "Much clearer and better. Should come up much earlier" (Assessing Risk, part3-para3)
- "Really useful information. Good guidance. Tucked away and could be brought up much more prominently" (Assessing Risk, part3-section3-para1)
- "This would be much better said up front" (Assessing Risk, part4-det8)

**Evidence from Stage 3**:
- Digital.govt.nz content design: Page structure - put important information first
- Findable content guidance: Don't hide critical information
- Plain Language Act: Content must be "well organised"

**Root Cause**:
This pattern reflects two problematic assumptions:
1. **Progressive disclosure principle misapplied**: Detail expanders work for optional/supplementary information, not for core content users need to understand requirements
2. **Linear reading assumption**: Content structured for reading beginning-to-end, not for users who need to make threshold decisions before investing time

**Strategic Implication**:
Phase 2 must:
1. **Eliminate all detail expander syntax** (`+++` ... `+++`)
2. **Create "Before You Start" sections**: Surface threshold considerations upfront
   - Is conformance relevant to you?
   - Which assessment type do you need?
   - Do you need risk assessment?
   - What's the relationship to DISTF/EIVA?
3. **Use clear heading hierarchy** instead of hidden content: All information scannable

**Severity**: HIGH - Users may miss critical information or make wrong decisions
**Scope**: Document-specific - Primarily Conforming and Assessing Risk guidance
**Feasibility**: HIGH - Straightforward restructuring task

### Theme 4: Standards-Guidance Separation Creates Unnecessary Navigation Burden

**The Fundamental Question**: Tom asks directly: "Standards are standards. Guidance is guidance. Does having separate pages really help? It's not for reading, it's for working through." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 1**:
- Each core standard has paired implementation guide of similar size:
  - Authentication Assurance Standard (328 nodes) + Implementing guide (280 nodes) = 608 nodes
  - Federation Assurance Standard (431 nodes) + Implementing guide (438 nodes) = 869 nodes
  - Information Assurance Standard (169 nodes) + Implementing guide (214 nodes) = 383 nodes
  - Binding Assurance Standard (161 nodes) + Implementing guide (158 nodes) = 319 nodes
- **Total: 2,179 nodes across 8 documents for 4 topics**
- Semantic searches show implementation guides often score **higher** than standards (0.911 vs 0.871 for information assurance)

**Evidence from Stage 2**:
- Tom's observation: "The guidance is really useful for understanding the standards, but is stored separately on another page. There is probably a simple way to indicate when something is guidance and when it's a standard so that they can be included in the same document."
- Tom's observation: "Given the guidance is authoritative (ie, referred to by the standards maker, and also linked to in the standards themselves, there is not really any reason why they can't be stored together.)"
- Implementation guides are MORE semantically connected than standards (avg 2,568 connections vs 2,073)
- Implementation guides have MORE hierarchical complexity (depth 6 vs depth 4-5 for standards)

**Evidence from Stage 3**:
- Digital.govt.nz content design: Organize complex information for user workflows
- Plain Language Act: Content must be "well organised"
- Users working toward conformance need both requirements AND implementation guidance together

**Root Cause**:
This separation reflects traditional regulatory model where:
- **Standards = normative requirements** (authoritative, must not be changed frequently)
- **Guidance = non-normative explanations** (helpful but secondary, can be updated)

However, this distinction is problematic here because:
- Guidance is created by standards maker (DIA) - equally authoritative
- Guidance is linked from standards - officially recognized
- Users need both simultaneously - separation creates friction
- Implementation guides are MORE accessible than standards to users

**Constraint Consideration**:
- **Core standards text cannot be changed**: Requirements, controls, in-text reference numbers must remain unchanged
- **Structure and presentation CAN change**: Standards and guidance can be in same document with clear visual distinction
- **Guidance can be fully rewritten**: Active voice, plain language, restructured

**Strategic Implication**:
Phase 2 should **integrate standards and guidance** while maintaining clear distinction:

**Possible Approaches**:
1. **Interleaved model**: Standard requirement followed immediately by implementation guidance
   - Pro: Requirements and guidance adjacent
   - Con: May interrupt flow of standard requirements

2. **Parallel structure**: Standard requirements in one section, guidance in paired section
   - Pro: Can read standard alone or with guidance
   - Con: Still requires navigation between sections

3. **Embedded guidance boxes**: Standard text with guidance in clearly marked boxes/callouts
   - Pro: Visual clarity about what's standard vs guidance
   - Con: May be harder to extract standard alone

4. **Single cohesive document with visual styling**: Standards in one formatting style, guidance in another
   - Pro: Everything together, clear distinction through formatting
   - Con: Requires careful markdown styling conventions

**Recommended**: Single cohesive document with clear visual styling (headings, formatting) to distinguish normative requirements from explanatory guidance. This follows Tom's observation that "no reason they can't be stored together" and digital.govt.nz content design principles.

**Severity**: HIGH - Creates significant navigation burden and cognitive load
**Scope**: System-wide - Affects all four core standards and implementation guides
**Feasibility**: MODERATE - Requires careful restructuring and markdown styling but technically feasible

### Theme 5: DISTF Relationship Self-Defeating Despite Being "Only Mandatory Use"

**The Paradox**: Tom observes: "The standards are at pains to distinguish themselves from the DISTF framework, but when it comes down to it, the only mandatory use of the standards is the DISTF. That seems self-defeating." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 1**:
- Federation Standard has highest semantic similarity with DISTF legal documents (7,960 DISTF Act connections, 2,970 DISTF Rules connections)
- Federation documents (standard + guide) are most connected identification management materials (4th and 5th in connectivity ranking)
- Tom's observation: Federation is "easiest way in to understanding identification as a whole, because most people think of a driver's licence when they think of 'ID'"

**Evidence from Stage 2**:
- Tom's annotation: "What is the point of laying it out like this when there is only one mandated conformance framework" (Conforming, part2-para1)
- Tom's annotation: "The federation standard guidance references digital credentials quite frequently. It's worth using this as a way in to exploring the overlap or not between these standards and the DISTF digital identity framework." (Implementing Federation, h1)
- Tom's annotation: "Facilitation mechanisms are exclusively digital, meaning there is a strong overlap with DISTF/digital identity as a concept" (Implementing Federation, part3-para4-ex1)
- Federation as primary linkage point to legal framework

**Evidence from Stage 3**:
- DISTF Act section 16: "Nothing in this Act limits or otherwise affects the Electronic Identity Verification Act 2012" - explicitly separates frameworks ([DocRef](https://docref.digital.govt.nz/nz/distf/14/en/#P2-s16))
- DISTF Rules require compliance with Federation Assurance Standard (score: 0.890) ([DocRef](https://docref.digital.govt.nz/nz/dia-distfr/2/en/#part2-rule9-para4))
- EIVA is separate from identification standards AND from DISTF

**Root Cause**:
Standards were designed as **general-purpose framework** for any identification management scenario (physical credentials, in-person verification, cross-border, private sector). DISTF was created later and mandates standards use for digital identity services specifically.

The "pains to distinguish" approach may reflect:
- **Historical development**: Standards existed before DISTF
- **Scope breadth**: Standards apply beyond DISTF context
- **Authority separation**: DIA standards vs. DISTF legal regime
- **Future flexibility**: Standards could be mandated by other frameworks

However, this creates confusion because:
- Most users likely coming from DISTF context
- DISTF is only cited mandatory use case
- Downplaying DISTF relationship obscures why conformance matters

**Strategic Implication**:
Phase 2 should **embrace and clarify DISTF relationship** rather than downplaying it:

1. **Acknowledge DISTF prominently**: "The primary mandatory use of these standards is compliance with the Digital Identity Services Trust Framework (DISTF). However, the standards apply more broadly to any identification management scenario."

2. **Use Federation Standard as primary entry point**: Tom's observation is correct - federation is most relatable (driver's licence example) and most connected to legal framework

3. **Create DISTF-specific guidance**: Help DISTF users understand which standards apply, what conformance requires, how to demonstrate compliance

4. **Clarify other use cases**: Physical credentials, in-person verification, cross-border scenarios where standards apply without DISTF

5. **Surface relationship early**: Don't bury DISTF context - make it clear upfront whether user is in DISTF context or broader identification management

**Severity**: MEDIUM-HIGH - Creates confusion about relevance and applicability
**Scope**: System-wide - Affects overall positioning and entry points
**Feasibility**: HIGH - Clarifying language and positioning, no technical complexity

### Theme 6: Terminology Authority Unclear, Relies on Dictionary Definitions

**The Authority Problem**: Tom questions: "Not clear why dictionary definitions are useful in such a specialised area. Also, if DIA is the identification authority in some way, then it can fairly be empowered to declare its own definitions as an authority, and all it needs to do is disambiguate terms or enable standardisation with other external standards." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 2**:
- Tom's annotation: "The function of this page needs some thought. If DIA publishes the standards, DIA can declare the meaning of terms. The meanings should be consistent with other relevant standards and instruments, including the law, but relying on a dictionary definition for such a specialised area is not a useful source of authority."
- Tom's annotation: "Also, the identification terminology page should theoretically play a role in helping people understand complex terms used in the wider standards and guidance. Therefore, if the definitions provided are opaque or difficult to understand, or don't include examples, then they don't serve that function."
- Only 9 terms (from ~60 total) actually point to external standards (8 to ISO 31073 risk management, 1 to NIST)
- Terminology page questions: "What's the value of the source if you're expanding it in some way?", "'Undergone a process' by who? On what authority?", "Developed by who?"

**Evidence from Stage 3**:
- Digital.govt.nz content design: Plain language, words to avoid, specialist words guidance
- Writing for specialists: Use specialist terms where necessary but explain them
- Digital.govt.nz: Definitions should aid understanding, not just be formally precise
- DISTF Act defines "identification management" ([DocRef](https://docref.digital.govt.nz/nz/distf/14/en/#P3-s20-p1-a))
- DISTF Rules define "facilitation mechanism" ([DocRef](https://docref.digital.govt.nz/nz/dia-distfr/2/en/#part1-rule4-para18))

**Two Distinct Problems**:

1. **Authority problem**: Who has the right to define specialized identification management terms?
   - Dictionary definitions lack domain authority
   - DIA publishes standards - can assert definitional authority
   - Should align with DISTF legal definitions where applicable
   - Should align with international standards (ISO, NIST) where they exist

2. **Function problem**: What should terminology page do?
   - Current: Formal definitions, often abstract
   - Tom's suggestion: Help users understand complex terms
   - Missing: Examples, plain language explanations, context

**Root Cause**:
Reflects tension between:
- **Technical precision** (dictionary/ISO definitions provide exactness)
- **Domain authority** (DIA as standards maker can define terms)
- **User comprehension** (practitioners need understandable explanations)
- **Legal alignment** (DISTF Act/Rules/Regs define some terms)

**Strategic Implication**:
Phase 2 should adopt **hybrid approach** to terminology:

1. **Assert DIA authority**: "The Department of Internal Affairs, as identification standards authority, defines the following terms for use in identification management practice."

2. **Align with legal definitions**: Where DISTF Act/Rules define terms (identification management, facilitation mechanism), use those definitions

3. **Reference international standards**: Where ISO/NIST definitions exist and are appropriate, cite them as authoritative sources

4. **Add plain language explanations**: For each formal definition, provide:
   - Plain language summary
   - Examples of the term in use
   - How it relates to other terms
   - Why the distinction matters

5. **Distinguish precision from comprehension**: Formal definition provides precision; plain language explanation provides comprehension; examples provide application

**Example structure**:
```markdown
### Facilitation Mechanism

**Definition**: [DISTF Rules definition: facilitation mechanism means...]

**In plain language**: A facilitation mechanism is the method a credential provider uses to present your identity credential to a relying party. Think of it as the "handoff" between the organisation that verified your identity and the organisation that needs to check it.

**Examples**:
- Showing your driver's licence to verify your identity (physical facilitation)
- Using RealMe to log in to a government service (digital facilitation)
- Scanning a QR code on your phone to prove your identity (digital facilitation)

**Why it matters**: The security and reliability of facilitation mechanisms affects the overall assurance level of the identification process.
```

**Severity**: MEDIUM - Affects comprehension but not fundamental functionality
**Scope**: Single document - Primarily Identification Terminology page
**Feasibility**: MODERATE - Requires careful alignment with legal definitions and plain language explanations

### Theme 7: Privacy-Identification Relationship Inconsistent and Confusing

**The Contradiction**: Tom observes: "In the guidance materials on other pages, a lot is made of the fact that identification and privacy overlap but aren't the same, but then a lot of the standards are explicitly stated to be an application of an information privacy principle. That seems inconsistent and makes things harder than they need to be in terms of comprehension and familiarity." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 1**:
- Privacy Act 2020 is largest document in database: 3,611 nodes (38.5% of all nodes)
- Privacy Act has 28,440 semantic connections (2nd highest after "About Identification Management")
- Stage 1 semantic search returned: "Standards work together to prevent identity theft, fraud and loss of privacy" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-standards/2025/en/#h1-subtitle))

**Evidence from Stage 2**:
- Information Assurance implementation guidance states: "This is the application of Information privacy principle 1 of the Privacy Act 2020" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1-section3-para1))
- Pattern repeats: Multiple controls explicitly reference IPP1 and privacy principles
- Yet other materials emphasize identification and privacy are distinct concerns

**Evidence from Stage 3**:
- Privacy Commissioner's Biometric Processing Privacy Code 2025 is **mandatory law** for biometric authentication
- Privacy Code fills critical gap: identification standards address technical controls, Privacy Code addresses legal privacy requirements
- All biometric processing in NZ must comply with both technical assurance AND privacy requirements

**Root Cause**:
This tension reflects genuine complexity:
- **They ARE related**: Information assurance controls implement privacy principles (IPP1: only collect what's needed)
- **They ARE distinct**: Identification = verifying who someone is; Privacy = protecting personal information
- **Overlapping scope**: Identity information IS personal information subject to Privacy Act

The inconsistency arises from:
- **Different document authors/times** emphasizing different aspects
- **Trying to claim distinctness** while actually implementing privacy principles
- **Lack of clear relationship articulation** from the start

**Strategic Implication**:
Phase 2 should **embrace and clarify the relationship** rather than claiming distinctness:

1. **Articulate relationship clearly**: "Identification management involves collecting, using, and storing personal information. Therefore, identification processes must comply with Privacy Act 2020. The information assurance controls in these standards implement privacy principles to protect identity information."

2. **Integrate privacy requirements explicitly**: Especially for biometric authentication (Stage 3 finding - Privacy Code is mandatory)

3. **Don't overstate distinctness**: Identification and privacy are overlapping concerns, not separate domains

4. **Frame standards as privacy-compliant approach**: "These standards provide a privacy-compliant framework for identification management."

5. **Reference Privacy Commissioner resources**: Link to relevant privacy guidance, especially for biometrics

**Severity**: MEDIUM - Creates conceptual confusion but doesn't block implementation
**Scope**: Multi-document - Affects framing across standards and guidance
**Feasibility**: HIGH - Clarifying language in guidance materials

### Theme 8: User Journey and Entry Points Undefined

**The Navigation Problem**: Tom observes: "When all pages are split into so many separated documents, you lose control over how people are approaching the information. It would be better in some ways to have a single document that is well structured, on the assumption that no one is coming here to read these for fun." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Evidence from Stage 1**:
- 30 documents in collection
- Navigation pages exist (Identification Standards, Guidance) but minimal content (26 and 32 nodes)
- No clear "start here" or "choose your path" guidance
- "About Identification Management" (60 nodes) has 74,870 connections - extreme semantic hub
- Suggests users must navigate to separate foundational document for conceptual understanding

**Evidence from Stage 2**:
- No explicit audience segmentation (credential providers, assessors, relying parties, policy makers, implementers)
- Circular references without clear entry: Standards reference guidance, guidance references standards
- Conformance references risk assessment, risk assessment references conformance
- Terminology assumes familiarity with standards, standards use terminology without always defining
- Multiple possible starting points but no guidance on which to choose

**Evidence from Stage 3**:
- Digital.govt.nz content design: User research, user needs methodology
- Content design process: Understand who users are and what they need to accomplish
- Digital.govt.nz: Organize content by user goals, not by internal logic
- Plain Language Act: Content must be "appropriate to the audience"

**Identified User Types** (not explicitly addressed in current materials):
1. **Credential providers seeking conformance**: Need implementation pathway from "we want to conform" to "we achieved conformance"
2. **Assessors performing conformance assessment**: Need assessment methodology, checklists, criteria
3. **Relying parties evaluating credential providers**: Need to understand what conformance means, how to verify it
4. **Policy makers understanding framework**: Need high-level overview, relationship to legal framework
5. **Technical implementers building systems**: Need detailed technical specifications, controls, examples

**Root Cause**:
Materials structured for **reference documentation** model (user arrives with specific question, searches for answer) rather than **guided implementation** model (user arrives with goal, follows pathway to achieve it).

This reflects assumption that users are:
- Already familiar with identification management concepts
- Capable of navigating complex relationships
- Looking up specific requirements, not learning framework

**Strategic Implication**:
Phase 2 should **create explicit user journeys and entry points**:

1. **"Start Here" section**:
   - Who are you? (Credential provider, assessor, relying party, policy maker, implementer)
   - What do you need to accomplish? (Achieve conformance, understand framework, assess provider, implement system)
   - Where should you start based on your role and goal?

2. **Guided pathways**:
   - **Conformance pathway**: Assess → Understand requirements → Implement controls → Document evidence → Get assessed → Maintain
   - **Assessment pathway**: Understand standards → Review assessment types → Use checklists → Evaluate evidence → Issue statement
   - **Understanding pathway**: Foundational concepts → Standards overview → DISTF relationship → Examples

3. **Integrate foundational concepts**: Don't force navigation to "About Identification Management" - weave foundational explanations throughout

4. **Clear prerequisites**: "Before you read this section, you should understand..." with links

5. **Audience-specific content markers**: Visual indicators for "Credential providers: this applies to you"

**Severity**: HIGH - Users may not know where to start or how to proceed
**Scope**: System-wide - Affects overall information architecture
**Feasibility**: MODERATE - Requires restructuring and clear navigation design

## Supporting Evidence

### Evidence of Conformance as Primary User Goal

**Tom's definitive statement**: "It feels like the process of conforming with the standards is the whole point of even reading the standards in the first place." ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Supporting observations**:
- "People are coming to the standards to try and conform with them, or to understand others' conformance with them."
- "If the main purpose of the identification standards is to demonstrate conformance... these checklists should be the most important and predominant way into all of this material"
- "The main purpose of coming to look at any of this is to pursue conformance under the standards - probably for the digital identity services trust framework"

**Data confirmation**:
- Conformance document exists (205 nodes, 24 annotations - most heavily annotated)
- Checklists exist as separate resources (6 Word documents)
- But conformance has 0 semantic neighbors - completely isolated

### Evidence of Active Voice Superiority

**Tom's consistent pattern**:
- Critique: "Passive voice is confusing" (multiple times)
- Critique: "Very vague. Very passive"
- Praise: "Active voice - much clearer" (multiple times)
- Observation: "The whole document is passive but should really be addressed to the person reading it"

**Digital.govt.nz validation**:
- "Use the active voice, where possible"
- "Use 'you' and 'your' when talking to the reader"
- Government standard for all public service content

**Plain Language Act 2022 requirement**:
- Content must be "clear"
- Active voice contributes to clarity

### Evidence of Detail Expanders Hiding Essential Content

**Tom's explicit directive**: "Get rid of all detail expanders" ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Specific problems**:
- "The detail expanders here don't help because they're the main point of the content"
- "There is no point to burying these in detail expands"
- "So much essential information in here all buried away"
- "Much clearer, but buried away in a detail expander"

**Content design contradiction**:
- Digital.govt.nz: Make content findable, scannable
- Detail expanders hide content from scanning
- Should only be used for truly supplementary information

### Evidence of Guidance Accessibility Advantage

**Semantic search scores**:
- Information assurance framework query: Implementing guide 0.911 vs Standard 0.871
- Authentication methods query: Implementing guides score higher than standards
- Pattern: Guidance consistently more aligned with user information needs

**Content characteristics**:
- Guidance has more examples (implementation guides average 5-10 example nodes)
- Guidance has more practical content (workbooks, assessment matrices)
- Guidance sometimes uses active voice (Assessing Risk has mix)

**Tom's observation**:
- Federation implementation guide is "easiest way in to understanding identification"
- Driver's licence example is relatable and effective

**Yet treated as secondary**:
- Separate documents force navigation
- Standards presented first, guidance as "additional reading"
- Contradicts actual user preference/accessibility

### Evidence of Biometrics Privacy Gap

**Stage 2 annotations**:
- "Note importance of biometrics" (twice)
- Tom flagged this as emerging priority

**Current coverage**:
- **Technical controls present**: AA9.04 (spoofing), AA10.01 (false positives), AA10.02 (combining factors)
- **Privacy requirements absent**: Necessity, consent, notice, retention, purpose limitation, disclosure restrictions

**Stage 3 finding**:
- Privacy Commissioner's Biometric Processing Privacy Code 2025 is **mandatory law**
- Effective 3 November 2025 for new systems
- 13 comprehensive rules for biometric processing
- Applies to ALL biometric authentication in NZ

**Gap impact**:
- User implementing biometric authentication per identification standards (AA9, AA10)
- But not complying with Privacy Code
- Still violates law despite following standards

**Critical gap that must be addressed**

### Evidence of NCSC Standards Complementarity

**Tom's concern**: "Linking out to privacy and security standards without specificity is not helpful" ([TomNotesManualReview.md](file:///Users/tombarraclough/projects/official/IdentificationStandards19November2025/ManualReviewIdentificationStandardsAnnotationSets/TomNotesManualReview/))

**Current references**:
- Standards mention multi-factor authentication, security controls
- But link to NCSC standards without explaining relationship

**Stage 3 analysis**:
- **Identification standards** specify WHAT assurance level, WHAT factors, WHAT controls
- **NCSC standards** specify WHICH systems, WHO must use, HOW to implement securely
- **Complementary domains**: Assurance framework + operational security
- **Both required** for compliant implementation in public service

**Solution**: Be specific about which NCSC standards, why relevant, how they relate

## Contradictions Identified

### Contradiction 1: Stated Goal vs. Actual Organization

**Stated goal**: Enable conformance with identification standards

**Actual organization**:
- Conformance "tucked away" in separate document
- Conformance semantically isolated (0 neighbors)
- Conformance has 8.2 connections per node vs 12+ average
- Checklists are separate Word documents
- Standards organized for conceptual explanation, not operational implementation

**Resolution**: Reorganize around conformance as primary framework

### Contradiction 2: Guidance Accessibility vs. Treatment

**Reality**: Guidance is more accessible than standards
- Semantic searches score guidance higher
- Implementation guides have more examples and practical content
- Tom identifies federation guide as "easiest way in"

**Treatment**: Guidance presented as secondary
- Separate documents
- Standards first, guidance "additional"
- Navigation burden to access guidance

**Resolution**: Integrate standards and guidance, make guidance prominence match its value

### Contradiction 3: Privacy Relationship Claims

**Claim 1**: "Identification and privacy overlap but aren't the same"
- Materials emphasize distinctness

**Claim 2**: "This is the application of Information privacy principle 1 of the Privacy Act 2020"
- Standards explicitly implement privacy principles

**Reality**: They are overlapping concerns, not distinct domains
- Identity information IS personal information
- Privacy Act applies to identification processes
- Information assurance controls implement privacy principles

**Resolution**: Embrace relationship rather than claiming distinctness

### Contradiction 4: DISTF Relationship

**Position**: Standards distinguish themselves from DISTF
- "Standards apply more broadly"
- DISTF is one of many possible contexts

**Reality**: DISTF is only cited mandatory use case
- Tom: "the only mandatory use of the standards is the DISTF"
- Most users likely coming from DISTF context

**Resolution**: Embrace DISTF as primary use case while noting broader applicability

### Contradiction 5: Terminology Authority

**Current approach**: Dictionary definitions for specialized area
- Relies on external authority (dictionaries)
- Lacks domain authority

**Alternative authority**: DIA as standards maker
- Can assert definitional authority
- Should align with legal definitions (DISTF) and international standards (ISO, NIST)

**Resolution**: Assert DIA authority while aligning with legal/international sources

### Contradiction 6: Content Design vs. Implementation

**Content design best practices** (digital.govt.nz, Plain Language Act):
- Active voice
- Direct address ("you")
- User-centered organization
- Important information first
- No hidden content

**Current implementation**:
- Passive voice throughout guidance
- Third person ("A Relying Party")
- Conceptual organization
- Threshold information late
- Detail expanders hide essential content

**Resolution**: Apply content design principles systematically in Phase 2

## Root Cause Analysis

### Why Is Conformance "Tucked Away"?

**Hypothesis**: Standards structured for **specification reference** model, not **implementation guidance** model.

**Supporting evidence**:
- Traditional standards documents specify requirements abstractly
- Conformance assessment assumed to be separate organizational activity
- Standards position themselves as technical specifications, not implementation guides

**Why this happened**:
- Standards writing conventions from regulatory/ISO background
- Assumption that practitioners are already familiar with conformance processes
- Separation of concerns: standards specify, assessors assess, implementers implement

**Why it's problematic**:
- Most users are seeking conformance (Tom's observation)
- Standards are implementation guidance, not just specifications
- Separation creates navigation burden and hides user's primary goal

### Why Does Passive Voice Pervade?

**Hypothesis**: Technical writing convention emphasizing **objectivity** over **clarity**.

**Supporting evidence**:
- Passive voice presents requirements as abstract facts: "This standard applies to..."
- Avoids naming actor: "is performed" rather than "you perform"
- Traditional regulatory/standards language patterns

**Why this happened**:
- Standards writing training emphasizes formal, objective tone
- Passive voice seen as more authoritative/official
- Avoids repetition of "you must" throughout document

**Why it's problematic**:
- Tom consistently notes passive voice is "confusing" and "very vague"
- Active voice is "much clearer"
- Digital.govt.nz and Plain Language Act 2022 require active voice
- Users need to know WHO does WHAT

### Why Are Standards and Guidance Separated?

**Hypothesis**: Regulatory model distinguishing **normative** (must not change frequently) from **non-normative** (can be updated).

**Supporting evidence**:
- Standards = requirements, controls (normative)
- Guidance = explanations, examples (non-normative, informative)
- Traditional ISO model separates these

**Why this happened**:
- Standards should be stable (organizations invest in conformance)
- Guidance can evolve with changing practice
- Separation enables independent versioning

**Why it's problematic**:
- Guidance created by standards maker (equally authoritative)
- Guidance linked from standards (officially recognized)
- Users need both simultaneously
- Separation creates navigation burden
- Implementation guides score higher in semantic searches than standards

**Why integration is feasible**:
- Can maintain visual distinction (formatting, headings)
- Core standards text protected by constraint (won't change)
- Guidance can be updated without affecting core requirements

### Why Is DISTF Relationship Downplayed?

**Hypothesis**: Standards designed for **general applicability**, DISTF added later as specific use case.

**Supporting evidence**:
- Standards apply to physical credentials, in-person verification, cross-border, private sector
- DISTF came after standards, mandated their use for digital identity services
- Standards want to avoid being seen as "just for DISTF"

**Why this happened**:
- Standards have broader scope than DISTF
- DIA wants standards to be relevant beyond single legal framework
- Future-proofing: other frameworks might mandate standards

**Why it's problematic**:
- DISTF is only cited mandatory use case
- Most users likely coming from DISTF context
- Downplaying relationship obscures why conformance matters
- Tom observes this is "self-defeating"

### Why Is Terminology Authority Unclear?

**Hypothesis**: Tension between **domain authority** (DIA as standards maker) and **external credibility** (dictionary/ISO definitions).

**Supporting evidence**:
- Dictionary definitions provide objective reference
- ISO definitions provide international credibility
- But relying on external sources suggests DIA lacks authority to define terms

**Why this happened**:
- Concern about overreach: Can DIA declare definitions?
- Want to align with recognized sources (dictionaries, ISO)
- Uncertainty about domain authority

**Why it's problematic**:
- Tom questions: "Not clear why dictionary definitions are useful in such a specialised area"
- Dictionary definitions lack domain specificity
- Terminology should help users understand complex terms, not just formally define them
- DIA publishes standards - can assert definitional authority

### Why Are Detail Expanders Used for Essential Content?

**Hypothesis**: Misapplication of **progressive disclosure** principle.

**Supporting evidence**:
- Progressive disclosure works for optional/supplementary information
- Keeps pages shorter, less overwhelming
- User can choose what to expand

**Why this happened**:
- Web design pattern: collapsible sections reduce page length
- Assumption that users will expand details they need
- Trying to make pages more scannable

**Why it's problematic**:
- Essential information hidden from users
- Tom repeatedly notes "no point to burying these"
- Users may not realize critical information is hidden
- Contradicts content design principle of making important information visible
- Assumes users know what to expand

## Improvement Opportunities Mapped

### By Theme and Priority

#### THEME 1: Conformance-Centered Organization

**MUST DO** (Critical):
1. **Make conformance the primary organizing framework**
   - Structure entire resource around conformance workflow
   - Start with "Why conform?" and "Is this relevant to you?"
   - Organize by conformance stages: Assess → Implement → Document → Get Assessed → Maintain
   - Make checklists central navigation and organizational tools

**Impact**: HIGH - Aligns structure with primary user goal
**Feasibility**: MODERATE - Requires significant restructuring
**Dependencies**: Affects overall information architecture

#### THEME 2: Voice and Tone Transformation

**MUST DO** (Critical):
2. **Systematic active voice conversion in all guidance materials**
   - Identify the actor: "You perform...", "The credential provider must..."
   - Use imperative constructions: "Apply these controls..."
   - Address reader directly: "When you assess risk..."
   - Apply digital.govt.nz Tone and Voice guidance

**Impact**: HIGH - Significantly improves clarity and comprehension
**Feasibility**: HIGH - Straightforward rewriting using established methodology
**Dependencies**: None - can be done during Stage 11 writing

**MUST DO** (Critical):
3. **Use "you" and direct address throughout guidance**
   - "You must perform authentication..." not "Authentication is performed..."
   - "Your conformance assessment..." not "The conformance assessment..."
   - Apply Plain Language Act 2022 requirements

**Impact**: HIGH - Makes content more accessible and clear
**Feasibility**: HIGH - Part of voice conversion process
**Dependencies**: Integrated with item #2

#### THEME 3: Eliminate Content Hiding

**MUST DO** (Critical):
4. **Remove all detail expander syntax**
   - Delete all `+++` ... `+++` markers
   - Surface all content with clear heading hierarchy
   - Never hide essential information

**Impact**: HIGH - Makes critical information visible and scannable
**Feasibility**: HIGH - Straightforward find-and-replace plus restructuring
**Dependencies**: Requires clear heading hierarchy design

**SHOULD DO** (Significant):
5. **Surface threshold information early**
   - Create "Before You Start" sections
   - Place prerequisites and decision points upfront
   - Answer: Is this relevant to you? Which path should you take?

**Impact**: MEDIUM-HIGH - Helps users make informed decisions before investing time
**Feasibility**: HIGH - Restructuring task
**Dependencies**: Requires understanding of user decision points

#### THEME 4: Standards-Guidance Integration

**MUST DO** (Critical):
6. **Integrate standards and guidance into single cohesive documents**
   - Present requirements and implementation guidance together
   - Use clear visual distinction (formatting, headings) between normative and explanatory content
   - Maintain four core standards text unchanged (constraint)

**Impact**: HIGH - Eliminates navigation burden, improves usability
**Feasibility**: MODERATE - Requires careful restructuring and markdown styling
**Dependencies**: Markdown style guide must support visual distinction

#### THEME 5: DISTF Relationship Clarification

**SHOULD DO** (Significant):
7. **Embrace and clarify DISTF relationship**
   - Acknowledge DISTF as primary mandatory use case
   - Explain how standards apply to DISTF digital identity services
   - Note broader applicability to other scenarios
   - Position Federation Standard as primary DISTF linkage point

**Impact**: MEDIUM-HIGH - Clarifies relevance and applicability
**Feasibility**: HIGH - Clarifying language and positioning
**Dependencies**: Understanding of DISTF-standards relationship

#### THEME 6: Biometric Privacy Requirements

**MUST DO** (Critical):
8. **Augment Authentication Assurance guidance with biometric privacy requirements**
   - Add section: "Privacy Requirements for Biometric Authentication"
   - Extract 5 key Privacy Code rules: necessity, consent, security, retention, purpose limitation
   - State clearly: "All biometric processing must comply with Biometric Processing Privacy Code 2025"
   - Link to Privacy Commissioner resources

**Impact**: HIGH - Fills critical gap, ensures legal compliance
**Feasibility**: MODERATE - Requires extracting and summarizing Privacy Code
**Dependencies**: Stage 3 evaluation complete; Privacy Commissioner coordination possible

#### THEME 7: Cybersecurity Cross-References

**SHOULD DO** (Significant):
9. **Add specific NCSC standards cross-references**
   - Create section: "Cybersecurity Requirements for Authentication Systems"
   - Explain relationship: Identification standards (assurance) + NCSC standards (security) = complete implementation
   - Be specific: List which NCSC standards apply and why
   - Address Tom's concern about "linking without specificity"

**Impact**: MEDIUM - Clarifies security requirements for implementers
**Feasibility**: HIGH - Brief section with specific cross-references
**Dependencies**: Understanding of NCSC standards scope

#### THEME 8: User Journey and Entry Points

**SHOULD DO** (Significant):
10. **Create explicit user journeys and entry points**
    - "Start Here" section: Who are you? What do you need?
    - Guided pathways for different user types
    - Integrate foundational concepts throughout
    - Clear prerequisites and sequencing

**Impact**: HIGH - Helps users navigate and understand where to start
**Feasibility**: MODERATE - Requires understanding user types and goals
**Dependencies**: Audience analysis and pathway design

### Quick Wins (High Impact, Low Complexity)

1. **Remove detail expanders** - Find/replace + restructuring
2. **Active voice conversion** - Systematic rewriting with digital.govt.nz guidance
3. **Surface threshold information** - Move content to beginning of documents
4. **Clarify DISTF relationship** - Add clarifying sections
5. **Explicit directive**: Tom's "get rid of all detail expanders" is clear and actionable

### Medium Complexity Improvements

6. **Integrate "About Identification Management"** - Weave foundational concepts into main materials
7. **Add biometric privacy requirements** - Extract and summarize Privacy Code rules
8. **Add NCSC cross-references** - Brief section with specific links
9. **Improve heading hierarchy** - Ensure scanability without excessive depth
10. **Create user entry points** - "Start Here" and pathway guidance

### Complex Restructuring Needs

11. **Integrate standards and guidance** - Requires careful restructuring and markdown styling
12. **Conformance-centered organization** - Requires rethinking entire information architecture
13. **Convert checklists to markdown** - Transform Word documents to integrated assessment tools
14. **Create guided pathways** - Requires audience analysis and UX design
15. **Flatten excessive hierarchy** - Review and simplify depth 6-7 sections

### External Dependencies

**Privacy Commissioner coordination** (for biometric privacy section):
- May want to review biometrics privacy content
- Could provide additional resources
- Validate accuracy of Privacy Code summary

**NCSC coordination** (for cybersecurity cross-references):
- May want to review relationship explanation
- Monitor NCSC standard update frequency

**Stakeholder testing**:
- **Adele (usability)**: Test whether active voice, plain language, and navigation improvements work
- **Joanne (conformance)**: Validate conformance-centered organization and terminology precision

## Prioritization Matrix

### CRITICAL PRIORITIES (Must Do in Phase 2)

**Priority 1: Make Conformance Central**
- **Why critical**: Tom identifies this as "the whole point" - fundamental misalignment
- **User impact**: Users seeking conformance can't find process easily
- **Severity**: Undermines primary user goal
- **Scope**: System-wide information architecture change
- **Feasibility**: Moderate - requires restructuring but no technical barriers
- **Dependencies**: Affects all other improvements

**Priority 2: Systematic Active Voice Conversion**
- **Why critical**: Tom consistently notes passive voice is confusing; digital.govt.nz and Plain Language Act require active voice
- **User impact**: Significantly improves clarity and comprehension
- **Severity**: Affects usability across all guidance documents
- **Scope**: System-wide - all guidance materials
- **Feasibility**: High - established methodology available
- **Dependencies**: None - can be done during writing

**Priority 3: Eliminate Detail Expanders**
- **Why critical**: Tom's explicit directive; hides essential information
- **User impact**: Users miss critical threshold information, make wrong decisions
- **Severity**: High - affects decision-making
- **Scope**: Document-specific - primarily Conforming and Assessing Risk
- **Feasibility**: High - straightforward restructuring
- **Dependencies**: Requires clear heading hierarchy

**Priority 4: Integrate Standards and Guidance**
- **Why critical**: Navigation burden, guidance more accessible but treated as secondary
- **User impact**: Reduces cognitive load, improves workflow
- **Severity**: High - affects all core standards users
- **Scope**: System-wide - 8 documents (4 standards + 4 guides)
- **Feasibility**: Moderate - requires careful restructuring
- **Dependencies**: Markdown style must support visual distinction

**Priority 5: Add Biometric Privacy Requirements**
- **Why critical**: Privacy Code is mandatory law (3 Nov 2025); critical gap in standards
- **User impact**: Ensures legal compliance for biometric authentication
- **Severity**: HIGH - non-compliance with law
- **Scope**: Authentication Assurance guidance only
- **Feasibility**: Moderate - extract and summarize Privacy Code
- **Dependencies**: Stage 3 evaluation complete

### SIGNIFICANT PRIORITIES (Should Do in Phase 2)

**Priority 6: Surface Threshold Information Early**
- **Why significant**: Users need decision points before investing time
- **User impact**: Better informed decisions, reduced wasted effort
- **Severity**: Medium-high - affects user efficiency
- **Scope**: Multiple documents - Conforming, Assessing Risk
- **Feasibility**: High - restructuring task
- **Dependencies**: Understanding user decision points

**Priority 7: Clarify DISTF Relationship**
- **Why significant**: Tom notes this is "self-defeating"; DISTF is only mandatory use
- **User impact**: Clarifies relevance and applicability
- **Severity**: Medium-high - affects understanding of why conformance matters
- **Scope**: System-wide positioning
- **Feasibility**: High - clarifying language
- **Dependencies**: None

**Priority 8: Add NCSC Cross-References**
- **Why significant**: Tom's concern about "linking without specificity"
- **User impact**: Clarifies security requirements for implementers
- **Severity**: Medium - affects completeness for public service agencies
- **Scope**: Authentication Assurance guidance
- **Feasibility**: High - brief section
- **Dependencies**: Understanding NCSC standards

**Priority 9: Create User Entry Points**
- **Why significant**: Users don't know where to start or which path to follow
- **User impact**: Reduces navigation confusion, improves efficiency
- **Severity**: Medium-high - affects initial engagement
- **Scope**: System-wide navigation
- **Feasibility**: Moderate - requires audience analysis
- **Dependencies**: Understanding user types and goals

**Priority 10: Integrate Foundational Concepts**
- **Why significant**: "About Identification Management" is semantic hub but separate document
- **User impact**: Reduces navigation burden for conceptual understanding
- **Severity**: Medium - affects learning curve
- **Scope**: System-wide - weave concepts throughout
- **Feasibility**: Moderate - integration task
- **Dependencies**: Understanding which concepts are foundational

### MODERATE PRIORITIES (Could Do in Phase 2)

**Priority 11: Convert Checklists to Markdown**
- **Why moderate**: Checklists valuable but separate format
- **User impact**: Integrated assessment tools in same document
- **Severity**: Medium - affects conformance workflow
- **Scope**: Conformance guidance
- **Feasibility**: Moderate - conversion task
- **Dependencies**: Markdown table/checklist format

**Priority 12: Clarify Terminology Authority**
- **Why moderate**: Tom questions dictionary definitions, but terminology works adequately
- **User impact**: Improves understanding of complex terms
- **Severity**: Medium - affects precision and comprehension
- **Scope**: Single document - Terminology page
- **Feasibility**: Moderate - requires plain language explanations
- **Dependencies**: Legal definition alignment

**Priority 13: Flatten Excessive Hierarchy**
- **Why moderate**: Some documents reach depth 7 levels
- **User impact**: Improves scanability
- **Severity**: Medium - affects navigation
- **Scope**: Document-specific - Implementation guides
- **Feasibility**: Moderate - review and simplify
- **Dependencies**: Understanding optimal hierarchy depth

**Priority 14: Resolve Privacy Relationship Tension**
- **Why moderate**: Conceptual inconsistency but doesn't block implementation
- **User impact**: Clearer understanding of privacy-identification relationship
- **Severity**: Medium - affects conceptual understanding
- **Scope**: System-wide framing
- **Feasibility**: High - clarifying language
- **Dependencies**: None

**Priority 15: Improve Cross-References**
- **Why moderate**: "This control" ambiguous, but context usually clear
- **User impact**: Clearer references to specific requirements
- **Severity**: Low-medium - affects precision
- **Scope**: Document-specific - Standards
- **Feasibility**: High - use specific identifiers
- **Dependencies**: Consistent identifier system

### Implementation Sequence

**Phase 2 Stage 11 (Content Writing) Sequence**:

1. **First pass - Structure and foundations**:
   - Design conformance-centered structure
   - Create user entry points and pathways
   - Integrate standards and guidance documents
   - Surface threshold information early

2. **Second pass - Content transformation**:
   - Systematic active voice conversion
   - Eliminate detail expanders
   - Integrate foundational concepts throughout
   - Rewrite with direct address ("you")

3. **Third pass - Gap filling and enhancement**:
   - Add biometric privacy requirements
   - Add NCSC cybersecurity cross-references
   - Clarify DISTF relationship
   - Convert checklists to markdown

4. **Fourth pass - Refinement**:
   - Improve heading hierarchy
   - Enhance cross-references
   - Add examples and scenarios
   - Clarify terminology where needed

## Integration of Stage 3 Findings

### Biometric Privacy Gap - ESSENTIAL INTEGRATION

**Stage 2 finding**: Tom flagged biometrics importance (2 annotations)

**Stage 3 finding**: Privacy Commissioner's Biometric Processing Privacy Code 2025 is mandatory law

**Integration**:
- **Current standards**: Technical controls (AA9.04 spoofing, AA10.01 false positives, AA10.02 factor combination)
- **Privacy Code adds**: Legal requirements (necessity, consent, notice, retention, purpose limitation, disclosure)
- **Gap**: Standards address technical effectiveness without legal compliance
- **Solution**: Augment Authentication Assurance guidance with privacy requirements section

**Phase 2 action**: Extract 5 key Privacy Code rules, integrate into AA implementation guidance

### Content Design Methodology - PHASE 2 AUTHORING GUIDE

**Stage 2 findings**: Passive voice, fragmentation, tucked away information, no clear user journey

**Stage 3 finding**: Digital.govt.nz content design guidance provides exact methodology to address these issues

**Integration**:
- **Active voice problem** → Digital.govt.nz Tone and Voice solution
- **Fragmentation problem** → Digital.govt.nz page structure and findable content solution
- **User journey problem** → Digital.govt.nz user-centered design solution
- **Plain Language Act 2022** → Mandatory compliance required

**Phase 2 action**: Use digital.govt.nz as authoring methodology throughout Stages 8, 11, 12

### Cybersecurity Standards - SPECIFIC CROSS-REFERENCE

**Stage 2 finding**: Tom notes "linking out to security standards without specificity is not helpful"

**Stage 3 finding**: NCSC 10 Minimum Cybersecurity Standards complement identification standards

**Integration**:
- **Identification standards**: WHAT assurance level, WHAT factors, WHAT controls (assurance framework)
- **NCSC standards**: WHICH systems, WHO must use, HOW to implement securely (operational security)
- **Relationship**: Complementary domains, both required for complete implementation
- **Current problem**: Standards link to NCSC without explaining relationship

**Phase 2 action**: Add 1-page section explaining NCSC relationship with specific cross-references

### EIVA - MINIMAL RELEVANCE, BRIEF MENTION ONLY

**Stage 2 question**: Tom asks "Should we add EIVA? They don't acknowledge standards at all"

**Stage 3 finding**: EIVA is separate system for specific DIA service, not essential for identification management practice

**Integration**:
- **EIVA scope**: Narrow - specific government service only
- **Standards scope**: Broad - any identification management scenario
- **Relationship**: Parallel systems, no conformance dependency
- **DISTF explicitly separates**: Section 16 states DISTF "does not limit or affect" EIVA

**Phase 2 action**: Brief mention only - "EIVA establishes a specific government service. Standards are technology-neutral and apply regardless of EIVA use."

## Strategic Insights for Phase 2

### Insight 1: Conformance-Centered Organization Is Non-Negotiable

**Why**: Tom's observation that conformance is "the whole point" is definitive. Data confirms: conformance is semantically isolated despite being primary user goal.

**Implication**: Phase 2 structure MUST organize around conformance workflow, not conceptual explanation of identification management.

**Approach**:
- **Primary organization**: Conformance stages (Assess → Implement → Document → Get Assessed → Maintain)
- **Entry point**: "Why conform?" and "Is this relevant to you?"
- **Checklists central**: Make assessment checklists primary navigation tools
- **Standards-guidance integration**: Present requirements and implementation together in conformance context

**Risk if not done**: Perpetuates fundamental misalignment between user goals and content organization

### Insight 2: Voice Transformation Is Feasibility Demonstrator

**Why**: Active voice conversion is high-impact, high-feasibility, and has established methodology (digital.govt.nz).

**Implication**: Successful voice transformation demonstrates project capability and builds momentum.

**Approach**:
- **Apply systematically**: Every guidance document (not core standards)
- **Use digital.govt.nz**: Follow government standard methodology
- **Verify in Stage 12**: Active voice should be 80%+ in guidance materials

**Risk if not done**: Continues to violate Plain Language Act 2022 and creates clarity problems Tom identified

### Insight 3: Standards-Guidance Integration Requires Visual Distinction

**Why**: Integration addresses navigation burden, but users need to distinguish normative from explanatory content.

**Implication**: Markdown style must support clear visual distinction between standards and guidance.

**Approach**:
- **Visual markers**: Formatting, headings, or callout boxes to identify guidance
- **Section structure**: Standards requirements in primary headings, guidance in subsections
- **Consistent convention**: Same visual pattern throughout all integrated documents

**Risk if not done**: Integration without distinction confuses what's normative vs explanatory

### Insight 4: Biometric Privacy Is Mandatory Law - Cannot Be Optional

**Why**: Privacy Code came into force 3 November 2025. Non-compliance is illegal.

**Implication**: This is not "nice to have" enhancement - it's critical gap that must be filled.

**Approach**:
- **Augment AA guidance**: Add privacy requirements section
- **State clearly**: "Mandatory law - must comply"
- **Link to Privacy Commissioner**: Authoritative resources
- **Consider coordination**: Privacy Commissioner may want to review

**Risk if not done**: Users follow identification standards but violate Privacy Code

### Insight 5: Federation Standard Is Natural Entry Point

**Why**: Tom observes federation is "easiest way in" because driver's licence is relatable. Stage 1 shows Federation has highest DISTF connectivity.

**Implication**: Federation Standard should be positioned as primary entry point for DISTF users (majority).

**Approach**:
- **Start with Federation**: For DISTF context users
- **Use driver's licence example**: Relatable credential presentation scenario
- **Explain DISTF relationship**: Make linkage explicit
- **Other entry points**: Authentication, Information Assurance, Binding for non-federation scenarios

**Risk if not done**: Users struggle to find relevant entry point for their context

### Insight 6: Plain Language Act Compliance Is Non-Negotiable

**Why**: Plain Language Act 2022 is mandatory for public service agencies (identification standards are government resource).

**Implication**: Phase 2 content must meet Plain Language Act requirements: "clear, concise and well organised... appropriate to the audience"

**Approach**:
- **Active voice**: Required by Plain Language Act
- **Clear structure**: Well organised with scannable headings
- **Appropriate language**: Technical but explained, with examples
- **Test readability**: Use tools recommended by digital.govt.nz

**Risk if not done**: Non-compliance with mandatory legal requirement

### Insight 7: External Dependencies Must Be Managed

**Why**: Phase 2 integrates references to Privacy Code, NCSC standards, digital.govt.nz guidance - all potentially update.

**Implication**: Need strategy for monitoring and updating external references.

**Approach**:
- **Cross-references, don't reproduce**: Link to authoritative sources
- **Monitor update cycles**: Privacy Code, NCSC standards may change
- **Periodic review**: Schedule for checking external reference validity
- **Stakeholder coordination**: Privacy Commissioner, NCSC may want input

**Risk if not done**: External references become outdated, create compliance issues

### Insight 8: User Testing Will Validate Critical Decisions

**Why**: Some decisions (conformance-centered organization, active voice effectiveness, navigation design) need validation.

**Implication**: Stage 6 recommendations should identify specific testing needs with Adele and Joanne.

**Approach**:
- **Adele (usability testing)**: Test navigation, active voice comprehension, entry points
- **Joanne (conformance validation)**: Test conformance-centered organization, terminology precision
- **Stakeholder review**: Privacy Commissioner (biometrics), NCSC (cybersecurity)

**Risk if not done**: Implementation decisions not validated against actual user needs

## Questions and Uncertainties

### Question 1: Single Document or Multi-Document Structure?

**Context**: Tom observes "lose control over how people are approaching the information" with multiple documents, suggests "single document that is well structured"

**Trade-offs**:
- **Single document**: Better control of user journey, easier consistency, harder navigation, very large file
- **Multi-document**: Modular, easier independent updates, harder coherent journey, navigation burden

**Considerations**:
- Markdown processing capabilities (file size limits?)
- DocRef system requirements (separate documents?)
- User navigation patterns (search vs browse)
- Maintenance and update workflow

**Resolution approach**: Stage 6 structure proposal should evaluate technical constraints and user needs

### Question 2: How Deep Should Conformance-Centered Organization Go?

**Context**: Conformance should be central, but how far?

**Options**:
1. **Conformance as entry point**: Start with conformance process, link to standards details
2. **Conformance as primary organization**: Entire resource structured around conformance workflow
3. **Conformance as one pathway**: Multiple entry points, conformance is one of several paths

**Considerations**:
- Users not seeking conformance (understanding framework, policy makers)
- Balance between operational focus and conceptual explanation
- Risk of overwhelming users with conformance process

**Resolution approach**: Stage 5 (AI Guidance Evaluation) should validate user-centered organization approach; Stage 6 should propose specific structure

### Question 3: Visual Distinction Between Standards and Guidance?

**Context**: Standards and guidance should be integrated, but how to distinguish visually?

**Options**:
1. **Formatting**: Standards in one style (bold, different heading color), guidance in another
2. **Callout boxes**: Guidance in visually distinct boxes/panels
3. **Section structure**: Standards in primary sections, guidance in subsections
4. **Prefix labels**: "[STANDARD]" and "[GUIDANCE]" labels on headings

**Considerations**:
- Markdown capabilities for styling
- Consistency across all documents
- Clarity for users (easily distinguish at glance)
- Aesthetics and readability

**Resolution approach**: Stage 8 (Markdown Style) should examine custom markdown capabilities and propose visual convention

### Question 4: Level of Detail for Biometric Privacy Content?

**Context**: Privacy Code has 13 comprehensive rules - how much to include?

**Options**:
1. **Full integration**: All 13 rules with detailed explanations
2. **Key rules extraction**: 5-6 most relevant rules summarized
3. **High-level summary**: Brief overview with link to full Code
4. **Checklist format**: Rule-by-rule compliance checklist

**Considerations**:
- Risk of too much (overwhelming, duplicating Privacy Commissioner resources)
- Risk of too little (insufficient for users to understand obligations)
- User needs (awareness vs detailed compliance guide)

**Resolution approach**: Stage 6 should propose specific level; Privacy Commissioner coordination could validate

### Question 5: Audience Segmentation - Explicit Pathways or Universal Structure?

**Context**: Multiple user types (credential providers, assessors, relying parties, policy makers, implementers)

**Options**:
1. **Explicit pathways**: "Choose your role" → customized journey
2. **Universal structure**: Single structure that works for all
3. **Hybrid**: Shared foundation + role-specific sections
4. **Markers**: Content labeled for specific roles ("Credential providers: this applies to you")

**Considerations**:
- Maintenance complexity (multiple pathways = more content to maintain)
- User clarity (explicit pathways vs figuring out relevance)
- Overlap (much content relevant to multiple roles)

**Resolution approach**: Stage 4 develops audience analysis; Stage 5 evaluates against AI guidance; Stage 6 proposes specific approach

### Question 6: Terminology Authority - How Far to Assert?

**Context**: Tom suggests DIA can assert definitional authority, but how explicitly?

**Options**:
1. **Strong assertion**: "DIA, as identification standards authority, defines..."
2. **Alignment emphasis**: "DIA definitions align with DISTF Act, ISO standards, NIST guidelines..."
3. **Hybrid**: "DIA asserts these definitions, consistent with legal and international standards..."
4. **Practical focus**: Less about authority, more about plain language explanations and examples

**Considerations**:
- Legal constraints (can DIA assert authority?)
- User needs (authority vs understanding)
- Alignment importance (DISTF Act defines some terms)

**Resolution approach**: Stage 6 recommendations should clarify terminology approach

### Question 7: Stakeholder Coordination Extent?

**Context**: Privacy Commissioner (biometrics), NCSC (cybersecurity) may want input

**Options**:
1. **Formal review**: Request formal review and endorsement
2. **Informal consultation**: Share draft, incorporate feedback
3. **Notification**: Inform of references, no formal review
4. **Independent**: No coordination, just link to their resources

**Considerations**:
- Time and process burden (formal review may delay)
- Value of endorsement (adds credibility)
- Risk of non-coordination (content may be inaccurate)

**Resolution approach**: Stage 13 (Handover) should identify stakeholder coordination recommendations

### Question 8: Historical Material Handling?

**Context**: Two documents contain superseded/historical content (Resource Material Evidence of Identity Standard, Superseded Standards)

**Options**:
1. **Include in restructured resource**: Show evolution
2. **Archive separately**: Remove from main resource
3. **Brief mention**: Note existence, link to archived versions
4. **Omit entirely**: Focus only on current standards

**Considerations**:
- User needs (do organizations reference superseded versions?)
- Historical value (understanding evolution)
- Clutter risk (outdated material confuses)

**Resolution approach**: Stage 6 structure proposal should address

## Next Steps for Stage 5

Based on Stage 4 thematic synthesis, Stage 5 (Evaluation Against Generative AI Guidance) should focus on:

### 1. Switch to AI Guidance MCP Server

Use `generative-ai-guidance-gcdo` MCP server for Stage 5 evaluation.

### 2. Query AI Guidance for Relevant Principles

**Content design and structure**:
- User-centered documentation approaches
- Organizing technical standards for diverse audiences
- Information architecture best practices
- Navigation design for complex content

**Writing and presentation**:
- Plain language for technical content
- Active voice and direct address in standards/guidance
- Voice and tone for government content

**Accessibility and clarity**:
- Making technical information accessible
- Supporting multiple user types
- Progressive disclosure vs comprehensive disclosure

### 3. Validate Stage 4 Strategic Insights Against AI Guidance

**Test these assertions**:
- Conformance-centered organization is appropriate for standards
- Active voice improves clarity in technical content
- Standards-guidance integration reduces cognitive load
- User journey pathways improve navigation
- Plain language principles apply to specialized technical content

### 4. Identify Any Gaps or Contradictions

**Questions for AI guidance**:
- Does AI guidance support conformance as organizing principle?
- Any cautions about active voice in standards context?
- Best practices for integrating normative and explanatory content?
- How to balance technical precision with accessibility?
- Approaches to audience segmentation in technical documentation?

### 5. Refine Recommendations Based on AI Guidance

Incorporate AI guidance insights into:
- Content design framework for Phase 2
- Standards-guidance integration approach
- User journey and navigation strategy
- Terminology and plain language approach
- Structural decisions (single vs multi-document, hierarchy depth, visual distinction)

### 6. Document AI Guidance Alignment and Refinements

Output for Stage 5 should include:
- How Stage 4 recommendations align with AI guidance
- Where AI guidance strengthens or refines recommendations
- Any conflicts or tensions between Stage 4 insights and AI guidance
- Specific AI guidance principles to apply in Phase 2

### 7. Prepare for Stage 6 Structure Proposal

Stage 5 validation will directly inform Stage 6:
- Confirmed recommendations (validated by AI guidance)
- Refined recommendations (adjusted based on AI guidance)
- Content design framework (incorporating AI principles)
- Specific structure proposal ready for evaluation

This ensures Stage 6 recommendations are grounded in:
- Tom's feedback (Stages 2)
- Cross-document patterns (Stage 2)
- External materials evaluation (Stage 3)
- Thematic synthesis (Stage 4)
- AI guidance validation (Stage 5)

Comprehensive foundation for final structure proposal and Phase 2 implementation.