1. Executive Summary

This plan establishes a distributed role criteria architecture for the Calab.ai Handbook, where evaluation criteria are authored and governed at the Guild level but aggregated into role-specific Evaluation Workbooks at the HR Management practice level.

What it accomplishes:

• Creates a Roles/ directory structure under each Guild for role-level definitions and criteria files
• Distributes the ~175 existing evaluation criteria (currently monolithically embedded in 5 HR workbook templates) into individual files per role-level within each Guild
• Introduces a cross-guild criteria mechanism allowing guilds to define expectations for roles owned by another guild
• Builds a custom dual-rendering plugin (criteria-list) — following the established page-list pattern (Decision 03) — that aggregates criteria from distributed files into Evaluation Workbooks at build/render time
• Aligns Management Practice names between workbook references and actual directory names, creating 3 new practice directories
• Consolidates metadata into a standardised metadata/ subfolder within each Management Practice
• Replaces the non-functional dataviewjs auto-summary in workbooks with the new criteria-list plugin

Key benefits:

• Governance: CODEOWNERS can control who creates criteria per guild path
• Single Source of Truth: Each criterion is authored once, in the guild that owns the expectation
• Scalability: Adding new role types (Architect, Delivery Lead) requires only new criteria files — the workbook regenerates automatically
• Dual rendering: Works identically in Obsidian and on the published Quartz site

Critical dependencies:

• Decision 04 (Distributed Role Criteria Architecture) — documents the structural decision
• Decision 05 (Criteria Aggregation Rendering) — documents the rendering approach
• CODEOWNERS (deferred per docs/CODEOWNERS_DEFERRED.md) — governance enforcement comes later

2. Architecture Overview

2.1 Current State

Criteria are monolithically embedded in 5 workbook template files:

GL05 Administration Guild/Practices/HR Management/05 Templates/
├── Evaluation Workbook - L1 Engineer.md   (382 lines, 29 criteria)
├── Evaluation Workbook - L2 Engineer.md   (450 lines, 32 criteria)
├── Evaluation Workbook - L3 Engineer.md   (522 lines, 41 criteria)
├── Evaluation Workbook - L4 Engineer.md   (522 lines, 41 criteria)
└── Evaluation Workbook - L5 Engineer.md   (450 lines, 32 criteria)

Problems:

• No governance control: Anyone with write access to the HR Management practice can modify criteria owned by other practices
• No scalability: Adding Architect or Delivery Lead tracks requires duplicating hundreds of lines
• Broken rendering: dataviewjs blocks don’t render in Quartz (raw code shown on published site)
• Practice name mismatches: Workbook practice names (e.g., “Consulting”) don’t match directory names (e.g., “Business Analysis”)

2.2 Proposed State

02 Guilds/
├── GL02 Sales Guild/
│   ├── Roles/
│   │   ├── README.md
│   │   └── Cross-Guild/
│   │       ├── README.md
│   │       └── Engineer/
│   │           ├── L1 Engineer.md
│   │           ├── L2 Senior Engineer.md
│   │           ├── L3 Lead Engineer.md
│   │           ├── L4 Senior Lead Engineer.md
│   │           └── L5 Principal Engineer.md
│   └── Practices/
│       ├── Stakeholder Mgmt/   ← NEW practice directory
│       │   ├── README.md
│       │   ├── 01 Policies/
│       │   │   └── ...
│       │   └── metadata/
│       │       ├── diagrams/
│       │       ├── plans/
│       │       └── specs/
│       ├── Pipeline Mgmt/
│       └── Proposal Mgmt/
│
├── GL03 Delivery Guild/
│   ├── Roles/
│   │   ├── README.md
│   │   └── Cross-Guild/
│   │       ├── README.md
│   │       └── Engineer/
│   │           ├── L1 Engineer.md
│   │           ├── L2 Senior Engineer.md
│   │           ├── L3 Lead Engineer.md
│   │           ├── L4 Senior Lead Engineer.md
│   │           └── L5 Principal Engineer.md
│   └── Practices/
│       ├── Consulting/               ← NEW practice directory
│       ├── Business Analysis/        ← NEW practice directory
│       ├── Project Mgmt/
│       ├── Business Analysis/
│       ├── Solution Eng/
│       └── Product Mgmt/
│
├── GL04 Technology Guild/
│   ├── Roles/
│   │   ├── README.md
│   │   └── Engineer/                            ← PRIMARY role for this guild
│   │       ├── L1 Engineer.md
│   │       ├── L2 Senior Engineer.md
│   │       ├── L3 Lead Engineer.md
│   │       ├── L4 Senior Lead Engineer.md
│   │       └── L5 Principal Engineer.md
│   └── Practices/
│       ├── Software Eng/
│       ├── Solution Eng/
│       └── Platform Architecture/
│
└── GL05 Administration Guild/
    └── Practices/
        └── HR Management/
            └── 05 Templates/
                ├── Evaluation Workbook - L1 Engineer.md   ← Uses criteria-list plugin
                ├── Evaluation Workbook - L2 Engineer.md
                ├── Evaluation Workbook - L3 Engineer.md
                ├── Evaluation Workbook - L4 Engineer.md
                └── Evaluation Workbook - L5 Engineer.md

2.3 Data Flow

1. Guild owners author criteria files in their Guild's Roles/ directory
   └── YAML frontmatter contains: criterion_id, criterion, area, subarea, role, level

2. Workbook templates contain `criteria-list` code blocks:
   ┌─────────────────────────────────────────────────────┐
   │ ```criteria-list                                    │
   │ role: Engineer                                      │
   │ level: L3                                           │
   │ mode: summary | detail                              │
   │ ```                                                 │
   └─────────────────────────────────────────────────────┘

3. At render time (Quartz build OR Obsidian reading view):
   └── Plugin scans ALL `02 Guilds/*/Roles/` directories
       ├── Finds criteria files matching role + level
       ├── Reads frontmatter from each
       ├── Groups by area (Guild) and subarea (Management Practice)
       └── Renders aggregated table/sections

2.4 Criteria File Schema

Each criteria file contains all criteria that a guild defines for a specific role and level. Example file: GL04 Technology Guild/Roles/Engineer/L3 Lead Engineer.md

---
publish: true
page-status: draft
created: 2026-02-16
owner: guild-technology
type: role-criteria
guild: GL04 Technology Guild
role: Engineer
level: L3
level-title: Lead Engineer
criteria-type: primary
criteria:
  - id: L3-DEV01
    subarea: Software Eng
    criterion: >-
      Codes complex functionality across distributed applications.
      Completes code review of work done by less experienced members of the team.
  - id: L3-DEV02
    subarea: Software Eng
    criterion: >-
      Develops complex unit tests including mock objects
      and automated integration tests.
  - id: L3-DEV03
    subarea: Software Eng
    criterion: >-
      Contributes to organisational standards and applies
      peer-reviewed coding standards and best practices.
  - id: L3-DEV04
    subarea: Software Eng
    criterion: >-
      Completes full code review of work done by
      less experienced members of the team.
  - id: L3-KNO01
    subarea: Software Eng
    criterion: >-
      Is recognised as a thought leader in one or more
      areas of expertise.
  - id: L3-KNO02
    subarea: Software Eng
    criterion: >-
      Creates blog articles relevant to their area of expertise.
  - id: L3-KNO03
    subarea: Software Eng
    criterion: >-
      Demonstrates a minimum 8 contributions per year to
      community forums in their area of expertise.
  - id: L3-DD01
    subarea: Solution Eng
    criterion: >-
      Creates Design Documents that describe
      complex solution designs.
---
 
# L3 Lead Engineer — Technology Guild Criteria
 
These criteria define the Technology Guild's expectations for a Lead Engineer (L3).
They are authored and governed by the Technology Guild and aggregated into the
L3 Lead Engineer Evaluation Workbook by the HR Management practice.
 
## Criteria by Management Practice
 
### Software Eng
 
| ID | Criterion |
|---|---|
| L3-DEV01 | Codes complex functionality across distributed applications... |
| L3-DEV02 | Develops complex unit tests including mock objects... |
| L3-DEV03 | Contributes to organisational standards... |
| L3-DEV04 | Completes full code review... |
| L3-KNO01 | Is recognised as a thought leader... |
| L3-KNO02 | Creates blog articles... |
| L3-KNO03 | Demonstrates a minimum 8 contributions per year... |
 
### Solution Eng
 
| ID | Criterion |
|---|---|
| L3-DD01 | Creates Design Documents that describe complex solution designs... |

Cross-guild criteria file example: GL02 Sales Guild/Roles/Cross-Guild/Engineer/L3 Lead Engineer.md

---
publish: true
page-status: draft
created: 2026-02-16
owner: guild-sales
type: role-criteria
guild: GL02 Sales Guild
role: Engineer
level: L3
level-title: Lead Engineer
criteria-type: secondary
criteria:
  - id: L3-WA01
    subarea: Stakeholder Mgmt
    criterion: >-
      Exercises substantial personal responsibility and autonomy.
  - id: L3-WA02
    subarea: Stakeholder Mgmt
    criterion: >-
      Acts as a team lead on large engagements taking ownership
      of the project outcome and quality.
  - id: L3-WA03
    subarea: Stakeholder Mgmt
    criterion: >-
      Assists practice members in planning work, meeting goals
      and solving problems.
---
 
# L3 Lead Engineer — Sales Guild Cross-Guild Criteria
 
These criteria define what the Sales Guild expects from a Lead Engineer (L3)
who is primarily a Technology Guild role. They are authored and governed by
the Sales Guild.
 
## Stakeholder Mgmt
 
| ID | Criterion |
|---|---|
| L3-WA01 | Exercises substantial personal responsibility and autonomy. |
| L3-WA02 | Acts as a team lead on large engagements... |
| L3-WA03 | Assists practice members in planning work... |

2.5 Workbook Template (Proposed)

The refactored workbook template replaces embedded criteria with criteria-list code blocks:

---
workbook: Promotion & Performance Evaluation
level: L3 Lead Engineer
score_scale: 5
candidate:
career_coach:
review_cycle:
submission_type: Promotion | Annual Performance | Both
status: Draft
---
 
# L3 Lead Engineer — Promotion & Performance Evaluation Workbook
 
> **Scoring scale:** 0–5 (decimals allowed)
 
## Practice Summary (auto)
 
```criteria-list
role: Engineer
level: L3
mode: summary
```
 
---
 
## Detailed Criteria
 
```criteria-list
role: Engineer
level: L3
mode: detail
```

The criteria-list plugin handles two modes:

• summary: Renders an aggregated table grouped by Guild and Management Practice, showing criteria count, self-score %, assessor-score %, and delta % (replaces the current dataviewjs block)
• detail: Renders all criteria grouped by Guild → Practice with editable score fields (replaces the current inline field sections)

3. Implementation Steps

Step 1: Create Management Practice Directory Alignment

Tasks

1. Create 3 new Management Practice directories with full scaffold:

   • content/02 Guilds/GL02 Sales Guild/Practices/Stakeholder Mgmt/
   • content/02 Guilds/GL03 Delivery Guild/Practices/Consulting/
   • content/02 Guilds/GL03 Delivery Guild/Practices/Business Analysis/

2. For each new directory, create the standard scaffold:

   [Practice Name]/
   ├── README.md         (use TMP03 Practice Overview template)
   ├── 01 Policies/
   ├── 02 Processes/
   ├── 03 Procedures/
   ├── 04 Guides/
   ├── 05 Templates/
   └── metadata/
       ├── diagrams/
       ├── plans/
       └── specs/
   

3. Fix the Software Eng/README.md content:

   • Update title from “Release Management” to “Software Eng”
   • Update practice-id from TECH-REL-01 to TECH-SE-01
   • Update owner from release-manager to engineering-lead
   • Rewrite Purpose, Scope, Interfaces, KPIs to reflect Software Eng (not Release Management)

4. Update the page-list code blocks in guild Practices overview files to reflect new practice directories.

Deliverable

• 3 new practice directories with scaffold and Overview files
• Fixed Software Eng overview content
• Updated Practices listings

Verification

• Each new directory contains README.md with correct frontmatter
• page-list blocks in guild practice overviews include the new practices
• npx quartz build succeeds without errors

Step 2: Consolidate Metadata Folders

Tasks

1. Across all 12+ Management Practice directories, ensure standardised structure:

   • metadata/diagrams/
   • metadata/plans/
   • metadata/specs/

2. Add practice-level metadata/ to the Quartz ignorePatterns in quartz.config.ts:

   ignorePatterns: [
     // ... existing patterns ...
     "**/Practices/*/metadata/**",
   ],

3. Update 05 Knowledge Standards.md to document the metadata/ subfolder convention for practice-level diagrams, plans, and specs.

Deliverable

• All 15 practice directories (12 existing + 3 new) use metadata/ subfolder
• Quartz config updated to ignore practice-level metadata
• Knowledge Standards updated

Verification

• No legacy _-prefixed metadata directories remain under any practice
• npx quartz build succeeds; no metadata folders appear in the published output
• Knowledge Standards reflects the new convention

Step 3: Create Roles Directory Structure

Tasks

1. Create Roles/ directory under each guild that has role criteria:

   GL02 Sales Guild/Roles/
   ├── README.md
   └── Cross-Guild/
       ├── README.md
       └── Engineer/
           ├── L1 Engineer.md
           ├── L2 Senior Engineer.md
           ├── L3 Lead Engineer.md
           ├── L4 Senior Lead Engineer.md
           └── L5 Principal Engineer.md
   
   GL03 Delivery Guild/Roles/
   ├── README.md
   └── Cross-Guild/
       ├── README.md
       └── Engineer/
           ├── L1 Engineer.md
           ├── L2 Senior Engineer.md
           ├── L3 Lead Engineer.md
           ├── L4 Senior Lead Engineer.md
           └── L5 Principal Engineer.md
   
   GL04 Technology Guild/Roles/
   ├── README.md
   └── Engineer/
       ├── L1 Engineer.md
       ├── L2 Senior Engineer.md
       ├── L3 Lead Engineer.md
       ├── L4 Senior Lead Engineer.md
       └── L5 Principal Engineer.md
   

2. Create README.md files for each Roles directory using standard frontmatter:

   ---
   publish: true
   page-status: draft
   created: 2026-02-16
   owner: [guild-slug]
   type: section-overview
   ---

3. Create README.md for each Cross-Guild/ directory explaining that these are secondary criteria that this guild defines for roles owned by other guilds.

Deliverable

• Roles directory structure under GL02, GL03, GL04
• Overview files at each level

Verification

• Directory structure matches the proposed layout
• All README.md files have valid frontmatter

Step 4: Extract Criteria into Distributed Files

Tasks

1. Extract criteria from the 5 existing workbook templates into individual role-level criteria files.

   Source mapping (per guild):

   Source Guild	Source Workbook Subarea	Target Directory	Criteria Type
   GL04 Technology Guild	Software Eng + Solution Eng + Platform Architecture	GL04/Roles/Engineer/	primary
   GL02 Sales Guild	Stakeholder Mgmt	GL02/Roles/Cross-Guild/Engineer/	secondary
   GL03 Delivery Guild	Consulting + Project Mgmt + Business Analyst	GL03/Roles/Cross-Guild/Engineer/	secondary

2. For each of the 15 criteria files (5 levels × 3 guilds), populate YAML frontmatter with:

   • All metadata fields (publish, page-status, created, owner, type, guild, role, level, level-title, criteria-type)
   • All criteria items in the criteria: array with id, subarea, and criterion fields

3. Update the subarea field values to use the aligned Management Practice directory names:

   • “Stakeholder Mgmt” → “Stakeholder Mgmt”
   • “Software Eng” → “Software Eng”
   • “Solution Eng” → “Solution Eng”
   • “Platform Architecture” → “Platform Architecture”
   • “Consulting” → “Consulting”
   • “Project Mgmt” → “Project Mgmt”
   • “Business Analyst” → “Business Analysis”

4. Generate the markdown body for each file with a readable table rendering of the criteria (so the file is useful even without the plugin).

Deliverable

• 15 criteria files across 3 guilds (5 per guild)
• Each file contains all criteria for that guild’s expectations of the given role+level
• All criteria IDs and text preserved exactly from the original workbooks

Verification

• Total criteria count across all 15 files matches the original workbook totals:
  • L1: 29, L2: 32, L3: 41, L4: 41, L5: 32 = 175 total
• Each criterion ID appears exactly once across all files for a given level
• All subarea values match actual Management Practice directory names
• YAML frontmatter passes schema validation

Step 5: Build the criteria-list Quartz Transformer Plugin

Tasks

1. Create quartz/plugins/transformers/criteriaList.ts following the pageList.ts pattern:

   Plugin behaviour:

   Input: criteria-list code block with directives
   ┌──────────────────────────────────┐
   │ ```criteria-list                 │
   │ role: Engineer                   │
   │ level: L3                        │
   │ mode: summary                    │
   │ ```                              │
   └──────────────────────────────────┘
   
   Processing:
   1. Parse directives (role, level, mode)
   2. Scan all `content/02 Guilds/*/Roles/` directories recursively
   3. Find all .md files where frontmatter matches:
      - role == directive.role
      - level == directive.level
      - type == "role-criteria"
   4. Read frontmatter.criteria array from each matching file
   5. Group criteria by guild (area) and subarea
   
   Output (summary mode):
   | Guild | Management Practice | Criteria | Self Score (%) | Assessor Score (%) | Delta (%) |
   |-------|---------------------|----------|----------------|--------------------|-----------|
   | Technology Guild | Software Eng | 7 | — | — | — |
   | Technology Guild | Solution Eng | 8 | — | — | — |
   | ... | ... | ... | ... | ... | ... |
   
   Output (detail mode):
   For each guild → for each practice:
   ### [Guild Name]
   #### [Practice Name]
   | ID | Criterion | Self Score | Assessment Score |
   |----|-----------|------------|-----------------|
   | L3-DEV01 | Codes complex functionality... | ___ | ___ |
   | ... | ... | ... | ... |
   

2. Register the plugin in quartz/plugins/transformers/index.ts:

   export { CriteriaList } from "./criteriaList";

3. Add to quartz.config.ts plugins:

   Plugin.CriteriaList(),

4. Handle edge cases:

   • No matching criteria files → render informational message
   • Missing frontmatter fields → skip file with console warning
   • Duplicate criterion IDs → log warning, render both

Deliverable

• quartz/plugins/transformers/criteriaList.ts (~200-300 lines)
• Plugin registered and configured

Verification

• npx quartz build succeeds
• Workbook pages render criteria tables (not raw code blocks)
• Summary mode shows correct criteria counts matching original workbooks
• Detail mode shows all criteria grouped by guild and practice

Step 6: Build the criteria-list Obsidian Plugin

Tasks

1. Create content/.obsidian/plugins/obsidian-criteria-list/main.js following the obsidian-page-list pattern:

   Plugin behaviour mirrors the Quartz transformer exactly:

   • Registers criteria-list code block processor
   • Parses directives (role, level, mode)
   • Scans vault folders matching 02 Guilds/*/Roles/
   • Reads frontmatter from matching criteria files
   • Renders HTML tables in the reading view

2. Create content/.obsidian/plugins/obsidian-criteria-list/manifest.json:

   {
     "id": "obsidian-criteria-list",
     "name": "Criteria List",
     "version": "1.0.0",
     "description": "Renders criteria-list code blocks by aggregating role criteria from Guild Roles directories",
     "author": "Calab.ai",
     "isDesktopOnly": false,
     "minAppVersion": "1.0.0"
   }

3. Register the plugin in content/.obsidian/community-plugins.json:

   ["obsidian-page-list", "obsidian-criteria-list", ...]

Deliverable

• Obsidian plugin (~200 lines, plain JS)
• Plugin registered in community-plugins.json

Verification

• Open any workbook template in Obsidian reading view
• Summary table renders with correct criteria counts
• Detail view renders all criteria grouped by guild and practice
• Switching between edit and reading view works correctly

Step 7: Refactor Evaluation Workbook Templates

Tasks

1. Replace the content of all 5 existing workbook templates with the new criteria-list code block syntax.

2. For each workbook (L1 through L5):

   • Keep the existing frontmatter header (workbook, level, score_scale, candidate, career_coach, review_cycle, submission_type, status)
   • Replace the dataviewjs summary block with a criteria-list summary block
   • Replace all the inline criterion sections with a criteria-list detail block

3. Update the workbook level frontmatter values for consistency:

   • L1: level: L1 Engineer
   • L2: level: L2 Senior Engineer
   • L3: level: L3 Lead Engineer
   • L4: level: L4 Senior Lead Engineer
   • L5: level: L5 Principal Engineer

Deliverable

• 5 refactored workbook templates, each ~30 lines (down from 380-520 lines)

Verification

• Each workbook renders identically to the current inline version (same criteria, same groupings, same order)
• No dataviewjs code blocks remain in the codebase
• No inline fields (area::, subarea::, etc.) remain in workbook files
• npx quartz build succeeds and workbook pages render correctly

Step 8: Update Governance Documentation

Tasks

1. Update content/00 Governance/05 Knowledge Standards.md:

   • Add section on “Role Criteria Files” documenting the schema and conventions
   • Update “Folder Organization” section to include Roles/ under guilds and metadata/ under practices
   • Document the criteria-list code block convention alongside the existing page-list documentation
   • Remove legacy _-prefixed metadata folder references; document metadata/ convention

2. Update content/00 Governance/02 Operating Model.md:

   • Add section explaining the role → guild ownership model
   • Document the cross-guild criteria mechanism
   • Link to the relevant Roles overview pages

3. Update content/02 Guilds/GL05 Administration Guild/Practices/HR Management/01 Policies/Promotion & Performance Review Policy.md:

   • Add frontmatter (currently missing)
   • Update the “Functional Practice Involvement Model” section to reference the distributed criteria architecture
   • Explain how criteria are governed at the guild/practice level but aggregated into workbooks

4. Update content/metadata/Content Types.md:

   • Add role-criteria as a valid content type

Deliverable

• Updated governance documentation across 4 files

Verification

• All updated documents have valid frontmatter
• Cross-references resolve correctly
• criteria-list convention is documented in Knowledge Standards

Phase 2 Boundary: Human Review Required

Steps 1-8 above can be executed sequentially by the Build agent. The following steps require human review and decision-making before proceeding.

Step 9: Prepare CODEOWNERS for Role Criteria Paths

Tasks

1. When CODEOWNERS is implemented (per docs/CODEOWNERS_DEFERRED.md), add these paths:

   # Guild-level role criteria ownership
   /content/02 Guilds/GL01 Executive Guild/Roles/**    @calab-ai/guild-executive
   /content/02 Guilds/GL02 Sales Guild/Roles/**        @calab-ai/guild-sales
   /content/02 Guilds/GL03 Delivery Guild/Roles/**     @calab-ai/guild-delivery
   /content/02 Guilds/GL04 Technology Guild/Roles/**    @calab-ai/guild-technology
   /content/02 Guilds/GL05 Administration Guild/Roles/**  @calab-ai/guild-administration
   

2. This ensures that each guild controls who can create and modify criteria for their roles and cross-guild expectations.

Deliverable

• CODEOWNERS entries documented in the plan (for future implementation)

Verification

• N/A until CODEOWNERS is activated

Step 10: Extend to Additional Role Types (Future)

Tasks

Once the Engineer criteria architecture is validated, extend to:

1. Architect Track (from the career pathway in the Promotion Policy):

   • GL04 Technology Guild/Roles/Architect/L3 Lead Architect.md
   • GL04 Technology Guild/Roles/Architect/L4 Senior Lead Architect.md
   • GL04 Technology Guild/Roles/Architect/L5 Principal Architect.md

2. Delivery Track:

   • GL03 Delivery Guild/Roles/Delivery Lead/L3 Delivery Lead.md
   • GL03 Delivery Guild/Roles/Delivery Lead/L4 Senior Delivery Lead.md
   • GL03 Delivery Guild/Roles/Delivery Lead/L5 Delivery Principal.md

3. Create corresponding Evaluation Workbook templates in HR Management.

Deliverable

• New role criteria files for Architect and Delivery Lead tracks
• New workbook templates

Verification

• Workbooks for new role types render correctly with aggregated criteria

4. Decision Points & Options

4.1 Score Storage Location

Decision: Scores remain in the workbook files. The criteria-list plugin renders score input fields that candidates fill in. The criteria files themselves are templates/definitions only.

4.2 Criteria ID Namespacing

Decision: Keep existing criterion IDs unchanged. Address ID namespacing in a future revision if needed.

5. Risk Assessment

6. Success Criteria

• All 175 existing criteria are distributed across 15 criteria files (5 levels x 3 guilds)
• Each criterion appears exactly once per level across all criteria files
• All 5 Evaluation Workbooks render correctly in both Obsidian and Quartz
• criteria-list summary mode shows identical criteria counts to current dataviewjs output
• criteria-list detail mode shows all criteria grouped by Guild then Management Practice
• No dataviewjs code blocks remain in the codebase
• 3 new Management Practice directories created with standard scaffold
• All Management Practice metadata folders use standardised metadata/ subfolder convention
• Software Eng overview content corrected
• Governance documentation updated to reflect new architecture
• npx quartz build succeeds with zero errors

7. Appendices

Appendix A: Complete Criteria Extraction Map

L1 Engineer (29 criteria → 3 files)

L2 Senior Engineer (32 criteria → 3 files)

L3 Lead Engineer (41 criteria → 3 files)

L4 Senior Lead Engineer (41 criteria → 3 files)

L5 Principal Engineer (32 criteria → 3 files)

Appendix B: Management Practice Name Alignment

Appendix C: File Count Summary