Content Types Taxonomy
Purpose
This document defines the Mutually Exclusive, Collectively Exhaustive (MECE) taxonomy for classifying knowledge artefacts in the Company Handbook. Every document must fit into exactly one of these categories.
The Seven Content Types
1. Policy (Mandatory Rule)
Definition: A binding requirement that must be followed by all applicable parties.
Characteristics:
- Prescriptive and mandatory
- Enforced through governance
- Typically derives from compliance, security, strategic mandate, or legal requirements
- Violations have consequences
- Requires formal approval (typically Leadership or Guild Lead)
Examples:
- Security Baseline Policy
- Approval Authority Policy
- Data Retention Policy
- Code of Conduct Policy
- Financial Controls Policy
When to Use: When establishing non-negotiable rules or requirements.
2. Process (End-to-End Lifecycle)
Definition: An end-to-end flow of activities that transform inputs into outputs, often crossing organizational boundaries.
Characteristics:
- Describes a complete workflow from start to finish
- Crosses multiple roles, teams, or practices
- Has defined inputs, outputs, and handoffs
- Often spans stages of the Value System
- Focuses on “what happens” and “who does it”
Examples:
- Opportunity to Contract Process
- Incident Management Process
- Employee Onboarding Process
- Release Planning Process
- Budget Approval Process
When to Use: When documenting a complete workflow that spans multiple steps or functions.
3. Procedure (Step-by-Step Execution)
Definition: Detailed, step-by-step instructions for performing a specific task or operation.
Characteristics:
- Prescriptive and sequential
- Task-specific and repeatable
- Often a subset of a larger process
- Includes specific actions, commands, or steps
- Focuses on “how to do it”
- May include screenshots, commands, checklists
Examples:
- How to Deploy to Production
- How to Create a New User Account
- Database Backup Procedure
- Onboarding Checklist for New Hires
- Security Incident Response Runbook
When to Use: When providing detailed “how-to” instructions for a specific task.
4. Guide (Advisory Best Practice)
Definition: Recommendations, best practices, and advisory guidance that helps teams make informed decisions (non-mandatory).
Characteristics:
- Advisory, not mandatory
- Provides context, rationale, and options
- Helps users understand trade-offs
- Supports decision-making
- May evolve with experience
- Focuses on “why” and “considerations”
Examples:
- Solution Design Guidelines
- API Design Best Practices
- Code Review Guidelines
- Meeting Facilitation Guide
- Remote Work Best Practices
When to Use: When providing recommendations or guidance without mandating specific approaches.
5. Template (Structured Artefact)
Definition: A pre-formatted document or structure that ensures consistency and completeness across similar deliverables.
Characteristics:
- Provides structure and placeholders
- Promotes standardization
- Ready to fill in with specific content
- May include instructions or examples
- Reduces cognitive load for authors
- Ensures required information is captured
Examples:
- Project Charter Template
- Decision Template
- Meeting Notes Template
- Status Report Template
- Job Description Template
When to Use: When creating a reusable structure for recurring document types.
6. Decision (Decision Record)
Definition: A document that captures a significant architectural or structural decision, including context, decision, consequences, and alternatives considered.
Characteristics:
- Immutable once approved (create new decision to supersede)
- Documents “why” a decision was made
- Includes alternatives considered
- Numbered sequentially
- Provides historical context
- Status: Proposed, Accepted, Deprecated, or Superseded
Examples:
- Decision 01: Use TypeScript for Frontend Development
- Decision 02: Adopt Microservices Architecture
- Decision 03: Select PostgreSQL for Primary Database
- Decision 04: Implement GitOps with ArgoCD
When to Use: When documenting significant architectural, structural, or technology decisions that have long-term impact.
7. Role Criteria (Competency Definition)
Definition: A structured file that defines the competency expectations a Guild has for a specific role at a specific seniority level.
Characteristics:
- Contains structured YAML criteria in frontmatter
- Owned and governed by the Guild that defines the expectations
- Aggregated into Evaluation Workbooks by the
criteria-listrendering plugin - Uses
type: role-criteriain frontmatter - One file per role-level per guild
- Distinguishes between
primary(owning guild) andsecondary(cross-guild) criteria
Examples:
- L3 Lead Engineer — Technology Guild Criteria
- L2 Senior Engineer — Sales Guild Cross-Guild Criteria
- L4 Senior Lead Engineer — Delivery Guild Cross-Guild Criteria
When to Use: When defining competency expectations that a Guild has for a specific role at a specific level. These files are consumed by Evaluation Workbooks, not read directly by most users.
Classification Decision Tree
Use this decision tree to classify any document:
1. Is it a binding requirement that must be followed?
→ YES: POLICY
2. Does it document a past decision with context and rationale?
→ YES: DECISION
3. Is it a blank form or structure to be filled in?
→ YES: TEMPLATE
4. Does it define competency expectations for a role at a specific level?
→ YES: ROLE CRITERIA
5. Does it prescribe exact, sequential steps for a task?
→ YES: PROCEDURE
6. Does it show an end-to-end flow across roles/teams?
→ YES: PROCESS
7. Does it provide recommendations or best practices?
→ YES: GUIDE
MECE Validation
These categories are:
Mutually Exclusive:
- Each document fits in exactly ONE category
- No overlap between categories
- Clear boundaries and definitions
Collectively Exhaustive:
- Every knowledge artefact can be classified
- No gaps in the taxonomy
- If something doesn’t fit, the taxonomy needs refinement
Edge Cases and Clarifications
”What if a document has both process and procedures?”
Split it into two documents:
- The process document shows the end-to-end flow
- The procedure documents provide step-by-step details for specific tasks
- The process links to the procedures
”What if I have a policy with procedures?”
Split it:
- The policy states the requirements (what must be done)
- The procedure explains how to comply (how to do it)
- The policy can reference the procedure
”What about standards documents?”
Standards are typically Policies (if mandatory) or Guides (if advisory):
- “Coding Standards” that must be followed → Policy
- “Coding Style Guide” with recommendations → Guide
”What about Overview files?”
Overview files (README.md) are the landing page for each folder. They provide navigation and context but shouldn’t contain the actual policy, process, or guide content. They link to content.
”Can I have a ‘Process & Procedures’ folder?”
No. Keep them separate:
02 Processes/contains process documents03 Procedures/contains procedure documents- Processes can link to procedures
Examples by Practice Area
Strategy Mgmt Practice
- Policy: “OKR Setting Policy” (mandatory OKR framework)
- Process: “Strategic Planning Process” (annual planning workflow)
- Procedure: “How to Create an OKR in the System” (step-by-step)
- Guide: “Effective OKR Writing Guidelines” (best practices)
- Template: “OKR Template” (blank OKR form)
- Decision: “Decision 01: Adopt OKR Framework Over Balanced Scorecard”
Release Management Practice
- Policy: “Production Deployment Policy” (mandatory approvals)
- Process: “Release Planning Process” (end-to-end release flow)
- Procedure: “Production Deployment Runbook” (step-by-step deploy)
- Guide: “Release Communication Best Practices” (recommendations)
- Template: “Release Notes Template” (blank release notes)
- Decision: “Decision 01: Adopt Blue-Green Deployment Strategy”
Maintaining This Taxonomy
When to Update
- New content types emerge that don’t fit
- Consistent misclassification occurs
- Feedback reveals ambiguity
Update Process
- Identify the gap or ambiguity
- Propose taxonomy refinement
- Review with Leadership Team
- Update this document
- Communicate changes to all users
Ownership
- Owner: Leadership Team
- Approver: Leadership Team
- Review Cadence: Annually, or as-needed if issues arise
Related Resources
Version: 1.0
Last Updated: 2026-02-11
Maintained By: Leadership Team