1. Executive Summary

This plan implements a governance-aligned content/ architecture for the Company Handbook based on the refined Guild → Practice → Artefact → Value Stream overlay model.

The solution formalizes:

• content/ as the isolated Obsidian root
• Numbered, enforceable folder hierarchy
• Guild-based governance aggregation (GL01–GL0X)
• Practice-level authority inheritance across 01–06 artefact categories
• Value Streams as cross-functional coordination overlays (non-owning)
• Clear separation between Policies, Processes, Procedures, Guides, Templates, and Decisions

The architecture supports:

• 20–40 management practices (initial implementation: 12 practices)
• 5 Guilds
• 7 Value Streams (all implemented in initial phase)
• GitHub CODEOWNERS enforcement (deferred to separate phase after team creation)
• Future Digital Garden publishing
• Clean separation from platform code

Key outcomes:

• Enforceable governance via path-based ownership
• Reduced GitHub team sprawl via Guild aggregation
• Explicit MECE content taxonomy
• Scalable value stream topology
• Vault remains pure markdown + assets

Critical dependencies (must be validated before execution):

• GitHub repository admin access
• GitHub Teams: DEFERRED to separate phase (teams will be created by Tylor Bunting and Ambit Kumar with guild-executive approval)
• User decisions documented in DECISIONS_SUMMARY.md (all clarifications received)

2. Architecture / Context Overview

Key Governance Principles

1. Practices own artefacts.
2. Guilds own practices.
3. Value Streams coordinate practices but do not own their artefacts.
4. Company Governance owns structural and policy-level meta content.
5. CODEOWNERS enforces the above.

Updated Governance Model

Important Correction:
Value Streams DO NOT own practice artefacts — they only own their own VS folder.

Migration Considerations

Existing Content Alignment

The vault currently contains:

• content/00 Governance/02 Operational Governance.md - A comprehensive 383-line document defining Value System Architecture with Management Practices categorized as: Executive, Sales, Delivery, Run (with 4 subcategories), and Shared Management
• content/Human Resources/ folder with promotion and performance review content
• content/_metadata/ folder (note: plan specifies _meta/)

Critical Decision Required: The existing Management Practices taxonomy must be mapped to the new Guild structure. See Section 3, Step 0 for migration approach.

Initial Value Streams

Recommended expansion for a tech professional services + product organisation:

• VS01 Lead to Cash (Sales → Contract → Delivery → Billing)
• VS02 Discovery to Deployment (Discovery → design → develop → deploy → handover)
• VS03 Request to Release (Engineering lifecycle)
• VS04 Incident to Resolution (Support & reliability)
• VS05 Hire to High Performance (People lifecycle)
• VS07 Strategy to Execution (Strategic planning → OKRs → delivery alignment)

Implementation Decision: All 7 Value Streams will be implemented in initial phase (per user clarification).

3. Implementation Steps

All steps are sequential. Prerequisites must be validated before Step 1.

Rollback Strategy: All implementation steps should be performed in a feature branch (feat/governance-structure) and tested before merging to main. If issues arise mid-implementation, the branch can be discarded without affecting production vault.

Step 0 – Validate Prerequisites and Plan Migration

Tasks

0.1 Validate Critical Dependencies:

1. Confirm GitHub repository admin access available
2. Verify GitHub Teams exist or document need to create them DEFERRED: GitHub Teams and CODEOWNERS implementation moved to separate phase
3. Note: Teams will be created by Tylor Bunting and Ambit Kumar with guild-executive approval
4. Team naming convention for future: @calab-ai/[team-name]
5. Document prerequisite validation in a checklist

0.2 Guild-to-Practice Mapping - COMPLETED:

Status: Mapping decisions documented in DECISIONS_SUMMARY.md

Key Decisions:

• Use proposed 5-guild structure (GL01-GL05)
• Create 12 initial practices distributed across guilds:
  • GL01 Executive: Strategy Mgmt, Financial Mgmt
  • GL02 Sales: Pipeline Mgmt, Proposal Mgmt
  • GL03 Delivery: Requirements Gathering, Solution Design, Project Mgmt, Product Mgmt
  • GL04 Technology: Solution Eng, Platform Architecture, Release Management
  • GL05 Administration: HR Management
• Distribute Run Management practices across guilds (Build Agent discretion)
• Distribute Shared Management practices per DECISIONS_SUMMARY.md guidance
• Update (not archive) content/00 Governance/02 Operational Governance.md to reference new structure
• Migrate content/Human Resources/ content to GL05 → HR Management practice

Reference: See content/metadata/plans/01 Governance Model & Content Structure/DECISIONS_SUMMARY.md for complete mapping details.

0.3 Folder Naming Decision - RESOLVED:

Decision Made: Keep _metadata/ folder naming (avoid breaking existing links).

Rationale: Current vault uses _metadata/ and changing to _meta/ would require updating all existing Obsidian links. The benefit of a shorter name doesn’t justify the migration effort and risk.

Actions: All plan references use _metadata/ consistently throughout.

0.4 Create README Templates:

Create the following templates in content/_templater/:

• TMP02 Guild README.md - Template for Guild README with required sections
• TMP03 Practice README.md - Template for Practice README with required sections
• TMP04 Value Stream README.md - Template for Value Stream README with required sections
• TMP05 Product README.md - Template for Product README with required sections

Each template should define minimum required sections (Purpose, Scope, Owner, Related Content, etc.)

Deliverable

• Prerequisites validation checklist completed (GitHub admin access confirmed, Teams deferred)
• Guild-to-Practice mapping decisions documented in DECISIONS_SUMMARY.md
• Folder naming decision finalized (_metadata/ retained)
• README templates created and available (12 practice templates + 7 VS templates + guild/product templates)

Verification

• GitHub admin access confirmed
• DECISIONS_SUMMARY.md exists with complete mapping guidance
• All user clarifications documented
• README templates exist in _templater/ with required sections and page-status: draft frontmatter

Step 1 – Align Vault Root to Final Structure

Tasks

1. Create feature branch feat/governance-structure for all implementation work

2. Ensure content/ matches final approved structure:

   • Create content/_99 Archive/ directory with README.md if it does not exist
   • Use _metadata/ folder naming (decision already made - keep existing)
   • Ensure all top-level numbered folders exist: 00 Governance/, 01 Value Streams/, 02 Guilds/, 03 Products/

3. Create new governance documentation files in content/00 Governance/:

   • 01 How to Contribute.md (new file)
   • 02 Knowledge Standards.md (new file)
   • 03 Decision Records.md (new file - explains decision process)
   • 04 Org Structure & Roles.md (new file)

   Note: Keep existing 01 Operating Model.md and 02 Operational Governance.md - migration addressed in Step 1.5

4. Ensure all artefact folders follow numbering convention (will be verified in Step 3 for practices):

   • 01 Policies
   • 02 Processes
   • 03 Procedures
   • 04 Guides
   • 05 Templates

5. Migrate existing Human Resources content:

   • Create target location per mapping document from Step 0.2
   • Move content/Human Resources/ content to appropriate Guild/Practice location
   • Add redirect note in original location pointing to new location
   • Move original content/Human Resources/ folder to content/_99 Archive/Human Resources (deprecated YYYY-MM-DD)/

6. Validate all internal Obsidian links still work after changes

Deliverable

Vault structure fully aligned with approved architecture, legacy content migrated or archived.

Verification

• Feature branch created and all work committed there
• Directory tree matches plan exactly
• content/_99 Archive/ exists with README explaining archival policy
• All new governance files created in 00 Governance/
• Human Resources content migrated per mapping document
• Obsidian opens without broken links

Step 2 – Implement Guild Structure

Create:

content/02 Guilds/
├── README.md (use TMP02 Guild README template; replaces former Guild Index.md)
├── GL01 Executive Guild/
│   ├── README.md
│   └── Practices/
├── GL02 Sales Guild/
│   ├── README.md
│   └── Practices/
├── GL03 Delivery Guild/
│   ├── README.md
│   └── Practices/
├── GL04 Technology Guild/
│   ├── README.md
│   └── Practices/
└── GL05 Administration Guild/
    ├── README.md
    └── Practices/

Note: Guild names and numbers should align with the mapping document created in Step 0.2. Adjust as needed based on stakeholder agreement.

Use _templater/TMP02 Guild README.md template for each Guild README. Each Guild README must define:

• Guild purpose and scope
• Leadership/ownership
• List of practices under the guild
• Governance model

The README.md at the Guilds root serves as the Guild index, listing all guilds with their purpose and primary practices.

Deliverable

At least 5 Guilds scaffolded with proper READMEs.

Verification

• Each Guild contains empty Practices/ folder
• Each Guild has README populated from template
• README.md at Guilds root lists all guilds
• Guild structure aligns with mapping document from Step 0.2

Step 3 – Create Practice Template Structure

For each practice, create:

[NAME] Management/
├── README.md (use TMP03 Practice README template)
├── 01 Policies/
├── 02 Processes/
├── 03 Procedures/
├── 04 Guides/
├── 05 Templates/
└── metadata/           # Practice-level metadata (excluded from publish)
    ├── diagrams/
    ├── plans/
    └── specs/

Initial Practice Priority: Create minimum 1 fully compliant practice per Guild based on the mapping document from Step 0.2. Recommended initial practices:

• GL01 Executive Guild: Strategy Mgmt or Financial Mgmt
• GL02 Sales Guild: Opportunity Qualification Management or Proposal Mgmt
• GL03 Delivery Guild: Solution Eng Management or Solution Delivery Management
• GL04 Technology Guild: Architecture Management or Release Management
• GL05 Administration Guild: HR Management (migrate HR content here)

Use _templater/TMP03 Practice README.md template. Each Practice README must include:

• Name, unique ID, Owner role
• Status and version
• Scope statement (in/out of scope)
• Interfaces (dependencies and dependents)
• Links to related practices/processes/templates
• KPIs or success signals
• Review cadence

Deliverable

12 fully compliant practices created (2 per GL01-GL02, 4 for GL03, 3 for GL04, 1 for GL05).

Verification

• All 12 practices created with schema compliance (all 9 folders present)
• Each practice has README populated from template with all required sections
• Each practice README has page-status: draft frontmatter property
• Folder numbering convention followed (01-06 for artefact types)
• Human Resources content successfully migrated to GL05 HR Management practice

Step 4 – Implement Initial Value Streams

Create under:

content/01 Value Streams/

First, create:

• content/01 Value Streams/README.md - Explains value stream concept, relationship to practices, and master list of all value streams with ownership and summary

All 7 Value Streams to be implemented:

VS01 Lead to Cash
VS02 Discovery to Deployment
VS03 Request to Release
VS04 Incident to Resolution
VS05 Hire to High Performance
VS06 Capability to Market
VS07 Strategy to Execution

Note: Per user clarification, all 7 Value Streams will be created in initial implementation (not just 3).

Each Value Stream folder must contain:

README.md (use TMP04 Value Stream README template)
01 Value Stream Map.md
02 Governance & Roles.md
03 Metrics.md
04 Interfaces.md
05 Practice Links.md
metadata/           # Value Stream metadata (excluded from publish)
├── diagrams/
├── plans/
└── specs/

Use _templater/TMP04 Value Stream README.md template. Each VS README must include:

• Value Stream name and purpose
• Customer/stakeholder
• Outcomes delivered
• Boundaries (start/end triggers)
• Owner/governance
• Links to related practices

Important: Value Stream folders contain NO practice artefacts (policies, processes, etc.). The 05 Practice Links.md file should LINK to relevant practices, not duplicate their content.

Deliverable

All 7 Value Stream structures created with proper documentation (README + 5 docs + 4 folders each).

Verification

Each VS (all 7):

• Has all required files and folders
• Links to minimum 3 practices in 05 Practice Links.md
• Contains governance owner defined in 02 Governance & Roles.md
• README populated from template with page-status: draft frontmatter
• Contains NO duplicated practice artefacts (linking only)

Step 5 – Verify GitHub Teams and Implement CODEOWNERS

Status: Implemented with later simplification

The GitHub team / CODEOWNERS work was originally addressed via Plan 10, but the active operating model has since been simplified. See docs/OWNERSHIP_MODEL.md for the live ownership and review configuration, and see Decision 09 for the rationale.

Tasks

5.1 Verify GitHub Teams Exist:

Before creating CODEOWNERS file, verify all required GitHub teams exist and are properly configured (see Appendix C for full list). Required teams:

• @calab-ai/guild-executive
• @calab-ai/owners-value-stream
• @calab-ai/owners-product
• Guild-specific teams (e.g., @calab-ai/guild-technology)
• Practice-specific teams as needed (e.g., @calab-ai/team-release-mgmt)

If teams don’t exist, document which teams need creation and confirm with stakeholders before proceeding.

5.2 Create CODEOWNERS File:

Create .github/CODEOWNERS aligned with:

# Company Governance - Executive Guild only
/content/00 Governance/** @calab-ai/guild-executive

# Value Streams - VS owners (can be overridden by practice-specific teams)
/content/01 Value Streams/VS01 Hire to High Performer/** @calab-ai/vs-team-vs01-hthp
/content/01 Value Streams/** @calab-ai/owners-value-stream

# Guilds - Guild owners (practices can override)
/content/02 Guilds/GL01 Executive Guild/** @calab-ai/guild-executive
/content/02 Guilds/GL02 Sales Guild/** @calab-ai/guild-sales
/content/02 Guilds/GL03 Delivery Guild/** @calab-ai/guild-delivery
/content/02 Guilds/GL04 Technology Guild/** @calab-ai/guild-technology
/content/02 Guilds/GL05 Administration Guild/** @calab-ai/guild-administration

# Practice-specific overrides (example)
/content/02 Guilds/GL04 Technology Guild/Practices/Release Management/** @calab-ai/team-release-mgmt

# Products
/content/03 Products/** @calab-ai/owners-product

# Archive - Executive Guild only (prevents accidental restoration)
/content/_99 Archive/** @calab-ai/guild-executive

Rules:

• Practice path overrides Guild path
• Guild path overrides general VS path
• Company Governance restricted to Leadership
• More specific paths always take precedence in CODEOWNERS

5.3 Create .github/ Directory Structure:

If .github/ directory doesn’t exist, create it with:

.github/
├── CODEOWNERS
└── README.md (explaining governance model)

Deliverable

• All required GitHub teams verified or creation documented
• CODEOWNERS file active and properly structured
• .github/ directory properly configured

Verification

• All referenced teams in CODEOWNERS exist in GitHub
• Teams are linked to appropriate Entra ID groups
• Test PR created and confirms correct reviewers assigned based on changed files
• CODEOWNERS file syntax is valid (GitHub validates on commit)

Step 6 – Create Content Types Taxonomy

Create _metadata/Content Types.md with clear MECE taxonomy definitions:

Required Definitions

Policy (mandatory rule)

• Binding requirement that must be followed
• Typically derives from compliance, security, or strategic mandate
• Examples: “Security Baseline Policy”, “Approval Authority Policy”

Process (end-to-end lifecycle)

• End-to-end flow of activities that transform inputs to outputs
• Crosses stages of Value System Chain
• Examples: “Opportunity to Contract Process”, “Incident Management Process”

Procedure (step-by-step execution)

• Detailed instructions for performing a specific task
• Prescriptive, sequential, repeatable
• Examples: “How to Deploy to Production”, “New Hire Onboarding Checklist”

Guide (advisory best practice)

• Recommendations and best practices (non-mandatory)
• Provides context and decision support
• Examples: “Solution Design Guidelines”, “API Design Best Practices”

Template (structured artefact)

• Pre-formatted document or structure for standardization
• Ensures consistency across similar deliverables
• Examples: “Project Charter Template”, “Decision Template”, “README Template”

Decision (decision record)

• Documents significant architectural or structural decisions
• Includes context, decision, consequences, and alternatives
• Immutable once approved (new decision supersedes if needed)
• Examples: “Decision 01: Site Rendering Technology”

Classification Decision Tree

Include flowchart or decision tree to help authors classify documents:

1. Is it a binding requirement? → Policy
2. Does it document a past decision? → Decision
3. Is it a blank form/structure? → Template
4. Does it prescribe exact steps? → Procedure
5. Does it show end-to-end flow? → Process
6. Does it provide recommendations? → Guide

Deliverable

Clear MECE taxonomy documentation that enables unambiguous classification.

Verification

• File exists in _metadata/ folder (confirmed naming decision)
• All 6 content types clearly defined
• Examples provided for each type
• Decision tree or classification guidance included
• Random existing document can be classified without ambiguity

Step 7 – Archive Legacy Structure and Finalize

Tasks

7.1 Create Archive Directory:

If not already created in Step 1, create:

content/_99 Archive/
└── README.md

README.md must explain:

• Purpose of archive (historical reference only)
• Archival policy: Governance-based approval required (Guild must approve moving their content to archive)
• How to reference archived content
• Warning that archived content may be outdated
• Note: Folder uses _ prefix so it will be hidden from site rendering (Digital Garden will not publish folders prefixed with _)

7.2 Move Deprecated Content:

Move deprecated content to content/_99 Archive/:

• Content superseded by new Guild/Practice structure
• Legacy folders no longer in use
• Obsolete documentation

Preserve folder structure within archive with date stamps:

content/_99 Archive/
├── README.md
├── Human Resources (deprecated 2026-02-11)/
└── [Other Legacy Folders] (deprecated YYYY-MM-DD)/

Important: Do NOT delete content. Archive only.

7.3 Add Redirect Notes:

In locations where content moved, add a markdown note:

# [Content Name] - MOVED
 
This content has been moved to: [[new-location]]
 
Archived copy available at: [[_99 Archive/old-location]]
 
Date moved: YYYY-MM-DD
Reason: Migration to Guild-Practice structure per Plan 01 rev1.1

7.4 Final Validation:

• Run link checker to find broken Obsidian links
• Verify all READMEs are properly formatted
• Confirm vault structure matches architecture diagram
• Test opening vault in Obsidian (no errors)

7.5 Merge Feature Branch:

• Create PR from feat/governance-structure to main
• Have appropriate reviewers approve per CODEOWNERS
• Merge to main once approved
• Tag release as v1.0-governance-structure

Deliverable

• Primary vault structure clean and compliant
• Legacy content properly archived with dates
• Redirect notes in place
• Feature branch merged to main

Verification

• content/_99 Archive/ exists with proper README and dated folders
• No content deleted (only moved to archive)
• Obsidian opens vault without errors or broken links
• PR merged and tagged

4. Decision Points & Options

Option A – Minimal Value Streams (3 Core)

Pros:

• Simpler initial governance
• Lower overhead

Cons:

• Misses cross-functional visibility

Option B – Expanded Strategic Value Streams (Recommended)

Pros:

• Better alignment with scaling
• Supports productisation
• Aligns to strategy execution

Cons:

• Slightly more upfront documentation

Recommendation: Start with 3–4 core, roadmap to 6–7.

5. Risk Assessment

Rollback Plan:

If critical issues discovered during implementation:

1. Do NOT merge feature branch to main
2. Document issues found
3. Revise plan to address issues
4. Re-implement in new feature branch
5. Main branch remains unchanged and vault stays functional

6. Success Criteria

Implementation successful when:

• Prerequisites validated (Step 0 checklist complete)
• Guild-to-Practice mapping document created and approved
• README templates created in _templater/
• Vault structure exactly matches approved architecture
• At least 5 Guilds scaffolded with proper READMEs
• At least 5 Practices compliant with schema (1 per Guild minimum)
• At least 3 Value Streams implemented with proper documentation
• GitHub Teams verified and exist for all CODEOWNERS references
• CODEOWNERS file created and assigns correct reviewers
• Content Types taxonomy documented with clear definitions
• Legacy content migrated per mapping document
• Human Resources content moved to appropriate Guild/Practice location
• No backend code in vault
• No duplication of practice artefacts inside VS folders (linking only)
• All Obsidian links functional (no broken links)
• Feature branch merged to main after approval
• content/_99 Archive/ exists with properly documented archived content

7. Appendices

A. Required Practice Folder Schema

README.md
01 Policies/
02 Processes/
03 Procedures/
04 Guides/
05 Templates/
metadata/           # Practice-level metadata (excluded from publish)
├── diagrams/
├── plans/
└── specs/

No deviations permitted.

B. Governance Model Summary

Company Governance → defines rules
Guild → governs practices
Practice → owns artefacts
Value Stream → overlays and coordinates
Product → owns product artefacts
CODEOWNERS → enforces authority
Content dir → pure content only

C. Required GitHub Teams

Historical note: The more detailed team registry was later proposed in Plan 10, but the active operating model has since been simplified. See docs/OWNERSHIP_MODEL.md for the live ownership and review configuration. The list below remains the original Plan 01 draft.

All teams should use naming convention: @calab-ai/[team-name]

Core Governance Teams:

• @calab-ai/guild-executive - Owns Company Governance
• @calab-ai/owners-value-stream - General VS ownership
• @calab-ai/owners-product - Owns Company Products

Guild Teams (one per guild):

• @calab-ai/guild-executive (GL01)
• @calab-ai/guild-sales (GL02)
• @calab-ai/guild-delivery (GL03)
• @calab-ai/guild-technology (GL04)
• @calab-ai/guild-administration (GL05)

Value Stream Teams (create as needed):

• @calab-ai/vs-team-vs01-hthp (VS01)
• @calab-ai/vs-team-vs02-dtdp (VS02)
• @calab-ai/vs-team-vs03-rtrl (VS03)

Practice-Specific Teams (examples - create as needed):

• @calab-ai/team-release-mgmt
• @calab-ai/team-architecture
• @calab-ai/practice-team-security

Note: All teams must be linked to appropriate Entra ID security groups for access control.

D. README Template Requirements

Guild README Template (TMP02 Guild README.md)

Required sections:

• Guild Name and Code (e.g., GL01 Executive Guild)
• Purpose and Scope
• Leadership and Ownership
• List of Practices (with links)
• Governance Model
• Review Cadence

Practice README Template (TMP03 Practice README.md)

Required sections:

• Practice Name and Unique ID
• Status and Version
• Owner Role
• Purpose and Objectives
• Scope (In/Out of Scope)
• Interfaces (Dependencies and Dependents)
• Related Practices/Processes/Templates (with links)
• KPIs and Success Signals
• Review Cadence
• Change Log

Value Stream README Template (TMP04 Value Stream README.md)

Required sections:

• Value Stream Name and Code
• Purpose and Outcomes
• Customers and Stakeholders
• Boundaries (Start/End Triggers)
• Owner and Governance Model
• Related Practices (with links to 05 Practice Links.md)
• Review Cadence

Product README Template (TMP05 Product README.md)

Required sections:

• Product Name
• Purpose and Stakeholders
• Architecture Overview (link to 02 Architecture.md)
• Current Status
• Roadmap (link to 03 Roadmap.md)
• Owner and Team
• Review Cadence

E. Guild-to-Practice Mapping Guidance

Note: Actual mapping must be created in Step 0.2 based on existing content and stakeholder agreement.

Example Mapping Template:

Key Decisions Required:

1. Should Shared Management practices be centralized in one guild or distributed based on domain?
2. How to handle Run Management subcategories - keep together or split across multiple practices?
3. Which practices should be prioritized for initial implementation (Step 3)?