Org Foundations Program Brief

Document class: Program Brief — Phase 0 deliverable
Status: Draft — awaiting Principal approval before Phase 1 or Phase 2 work begins
Author: Chief Operating Officer (COO)
Date: 2026-05-31
Gate: Principal must approve this brief before any unit authors any artifact
GR-7 notice: All Phase 2 artifacts ship in a single named milestone PR — not drip-by-drip. This is a hard constraint. See Section 6.

Executive Summary

KLMS has 19 functional units and a complete org-as-code infrastructure, but no unit has formalized the four foundational artifacts that make an operating org legible and auditable: a charter, a strategy with OKRs, SOPs for recurring activities, and reference docs. This program produces all of them across the full org in four phases. Phase 0 (this document) establishes the artifact contract, per-unit gap analysis, template specifications, and quality gate — the foundation for all subsequent work. Phase 1 produces templates and the Principal vision doc. Phase 2 fans out to all 19 units in dependency order. Phase 3 closes with a single milestone push (GR-7). Estimated scope: 6 artifact types (unit charter, OKRs, SOPs/runbooks, foundational refs, cluster strategy, Principal vision), approximately 85–90 new files across all phases, shipped in a single Phase 3 milestone PR. No unit begins authoring until the Principal approves this brief.

1. Program Overview

Purpose

KLMS has 19 functional units, 3 C-suite cluster heads, and a Principal. The org/docs layer is mature at the infrastructure level — agent definitions exist, policies exist, a few SOPs exist — but individual units lack four foundational artifacts that every operating unit requires: a unit charter, strategy and OKRs, SOPs/runbooks for core recurring activities, and foundational reference docs (glossary, standards, decision frameworks, quality bars).

This program produces those artifacts across the full org in a deliberate, sequenced way. Phase 0 (this document) establishes the contract. Phase 1 produces the enabling infrastructure (templates, standards, Principal vision). Phase 2 fans out to units. Phase 3 closes and archives.

Without this program, the org operates on implicit, unverifiable norms. With it, any agent or unit lead can answer: “What does this unit own? What are we trying to achieve this quarter? How do we execute the recurring activities? What standards do we hold?”

Scope

• In scope: All 19 functional units, the 3 C-suite cluster strategies, and the Principal-level vision. Coverage is total — no unit is exempt.
• Out of scope: Individual agent job descriptions (already owned and audited by HR), the archive specification (already mature), and the Golden Rules in CLAUDE.md (owned by Rules & Governance and co-created with the Principal per GR-3).
• Non-scope note on unit count: ORG.md v13 references “21 units” in its status block, but the chart and unit sections enumerate 19 functional units (6 direct-to-Principal + 6 CPTO cluster + 4 COO cluster + 3 CGEO cluster). The Personal Assistant (staff to Principal, not a unit) and External Review Partners (retained advisor, not an employee) bring the roster total to 21 entries but are not functional units. This brief scopes to the 19 functional units. Flagged for HR: reconcile ORG.md’s status block count with the actual unit enumeration in a future update.

Phasing

The strict sequencing constraint: Direct-to-Principal units (Archives, Rules & Governance, HR, Documentation, Finance, Legal & Compliance) have no C-suite cluster strategy above them, so they may begin Phase 2b authoring as soon as Phase 1 enabling infrastructure is ratified. All other units wait for their cluster’s Phase 2a strategy before beginning Phase 2b.

2. Artifact Contract

Four artifact types are required of every unit. The contract below defines each: what it is, what it contains, where it lives, and how it is named.

2.1 Unit Charter

What it is: A single document that makes the unit’s mission, ownership, operating rules, and boundaries explicit. The charter formalizes what is currently implicit in each agent definition — but the charter is broader: it covers the whole unit, not just the lead agent.

What it contains (required sections):

1. Mission statement — one paragraph, specific and testable (not aspirational vapor)
2. What we own — explicit list of artifacts, systems, registers, and decisions owned by this unit; cross-referenced to ORG.md
3. What we do NOT own — explicit hard boundaries that prevent lane confusion
4. Collaborators and handoff interfaces — which units this unit depends on and which depend on it, and what passes at each interface
5. Operating rules — the unit’s standing internal standards (sourced from the agent definition’s Guardrails section, expanded for the full unit)
6. Quality bar — how the unit defines “done” for its output types

Named: docs/units/<unit-slug>/charter.md

File path pattern: docs/units/archives/charter.md, docs/units/engineering/charter.md, etc. Unit slugs are derived from unit names in ORG.md (lowercase, hyphens).

Template pointer: templates/unit-charter.md — to be created in Phase 1 by Documentarian.

Approver: Unit Lead (author) → COO (for COO-cluster units) or C-suite cluster head → Principal if the charter contains a new rule or redraws a boundary.

2.2 Strategy and Goals (OKRs)

What it is: A quarterly OKR document that ties the unit’s objectives to KLMS’s dual-flywheel mission (YouTube channel audience + web learning platform learner outcomes + content→signal feedback loop). C-suite cluster strategies cascade to unit OKRs — a unit’s objectives must be traceable to their cluster’s strategy.

What it contains (required sections):

1. Strategic context — one paragraph connecting this unit’s work to KLMS’s mission and the current venture phase (Ideate / Plan / Build / Grow / Operate)
2. Objectives (O) — 1–3 qualitative objectives for the quarter; each must have clear relevance to a KLMS flywheel component
3. Key results (KR) — 2–4 measurable KRs per objective; each KR must include: what is being measured, a baseline (even if “0 / not yet established”), and a target
4. Dependencies — which other units’ outputs this unit depends on to hit its KRs
5. Anti-goals — what this unit will deliberately not do this quarter (prevents scope creep)

Named: docs/units/<unit-slug>/okrs-<YYYY-QN>.md (e.g. okrs-2026-Q2.md)

Template pointer: templates/unit-okrs.md — to be created in Phase 1 by Documentarian.

Approver: Unit Lead (author) → C-suite cluster head (validates alignment to cluster strategy) → Principal (final sign-off for the first cycle; subsequent cycles may delegate to C-suite heads).

Cascade constraint: A unit cannot finalize its OKRs until the cluster strategy above it is authored and approved. The cluster strategy must name the cluster’s top objectives; unit OKRs must traceable to at least one of them.

2.3 SOPs and Runbooks

What it is: Step-by-step procedures for each unit’s core recurring activities. Existing SOP format is already established (templates/sop.md) — units are filling gaps in coverage, not reinventing the format.

What it contains (per SOP — required fields, already in templates/sop.md):

1. SOP ID and title (sequential within the unit’s range)
2. Owner (unit name)
3. Purpose — what this procedure achieves
4. When to use — the trigger condition
5. Mermaid flow diagram with text fallback (mandatory per docs/canon.md)
6. Steps — numbered, specific, actionable
7. Roles and approvers — who does what; who approves
8. Guardrails — limits, exceptions, relevant policy references
9. Definition of Done (DoD) — a testable checklist (required; Q&R audits against this)

Named: docs/sop/<SOP-NNN>-<slug>.md — global sequential SOP IDs. The next available SOP ID is SOP-005 (SOPs 001–004 are already assigned; see Section 4 gap table).

Template pointer: templates/sop.md — already exists. Phase 1 may extend it with a DoD checklist section if Documentarian determines it is missing.

Runbooks: runbooks live in docs/runbooks/ and follow the same SOP template but cover operational procedures with more operational specificity (monitoring, alerting, incident response steps). Naming: docs/runbooks/<slug>.md.

How many SOPs per unit: Each unit must produce at minimum one SOP for each core recurring activity (a “core” activity is one that recurs at least monthly or is a critical-path activity for the unit’s mission). Units with no recurring activities (unlikely but possible for a single-agent unit like Rules & Governance) must document their core process even if it is a single SOP.

Approver: Unit Lead (author) → Process Engineer (review for process design conformance) → Q&R (conformance audit).

2.4 Foundational Reference Docs

What it is: The standing reference library a unit maintains for its domain — the glossary of terms, the standards it enforces, the quality bars its outputs must meet, and the decision frameworks it applies. These docs make a unit’s domain knowledge durable and transferable.

Minimum required artifacts (at least one of the following per unit, as applicable):

• Domain glossary — key terms and concepts owned by the unit, defined precisely (e.g., Engineering’s architectural terminology, Finance’s financial definitions)
• Quality standards doc — the bar that unit outputs must meet, stated in testable terms (e.g., “a unit charter passes Q&R audit if it contains all 6 required sections and each owned artifact is cross-referenced to ORG.md”)
• Decision framework doc — how the unit makes recurring decisions (e.g., Innovation’s hypothesis evaluation framework, Legal’s risk-classification framework)
• Standards and conventions doc — if the unit owns a standard that others follow (e.g., Engineering’s coding conventions, Documentation’s writing standards)

What it contains (per reference doc — required fields):

1. Title and scope — what this reference covers and who it applies to
2. Owner — the unit that maintains this reference
3. last-reviewed: metadata field at top of document
4. Content organized by the reference type above
5. Cross-links — references to related docs in docs/, hr/policies/, and CLAUDE.md
6. Review cadence — how often this reference is reviewed and updated

Named: docs/units/<unit-slug>/refs/<slug>.md

Template pointer: templates/unit-ref.md — to be created in Phase 1 by Documentarian.

Approver: Unit Lead (author) → Documentarian (review for documentation standards conformance) → Archivist (archive).

2.5 Right-Sizing for Sole-Member Units

Six units currently have a single agent (Rules & Governance, HR, Documentation, Delivery/PMO, Product, Quality & Risk). Mandating four separate artifact files for every unit regardless of size adds ceremony without adding coordination value — the opposite of what this program intends. The COO makes the following right-sizing call:

Sole-member units may consolidate two artifact types into a single document when consolidation does not compromise Q&R’s ability to audit against the conformance criteria. The permitted consolidation:

• A sole-member unit may combine its unit charter (Section 2.1) and its foundational reference docs (Section 2.4) into a single file at docs/units/<unit-slug>/charter-and-refs.md, provided all required sections of both artifact types are present in the combined file.
• A sole-member unit may not consolidate its OKRs or its SOPs — OKRs require a standalone file for cascade traceability; SOPs require individual files for the SOP ID and Process Engineer conformance review.

Condition: Q&R audits the combined file against the full conformance criteria for both artifact types. “Consolidated” is not an exemption from the criteria — it is a format accommodation.

Units that elect consolidation must state the consolidation choice in the combined file’s header. Units that prefer separate files may always produce them separately.

3. Template Specifications

Templates are outlines that Documentarian and HR will refine before Phase 2b begins. The COO owns the structural specification; Documentarian and HR own the prose standards and final formatting. What follows is the required structure for each template — not finished prose.

3.1 Unit Charter Template (templates/unit-charter.md)

Commissioned to: Documentarian (doc standards/voice) + HR (charter/org-structure alignment).

Required structure:

# <Unit Name> — Unit Charter

> Layer: Foundational | Owner: <Unit Lead> | Last reviewed: <YYYY-MM-DD>

## Mission
[One paragraph. Specific. Testable. Avoids vague aspiration.]

## What we own
[Bulleted list. Each item cross-references its location in ORG.md or the file path 
where the artifact lives. Be specific — "the risk register at reports/risk-register.md",
not "risk management".]

## What we do NOT own (hard boundaries)
[Bulleted list. Name the adjacent unit that owns each thing. Prevents confusion.]

## Collaborators and handoff interfaces
[Table: Collaborator unit | What we receive from them | What we hand to them | 
Frequency/trigger]

## Operating rules
[Numbered list. Each rule is testable. Sourced from the agent definition's Guardrails, 
expanded to cover the full unit. No aspirational language.]

## Quality bar — how we define done
[Per output type. E.g., "An SOP is done when it has a Mermaid flow, text fallback, 
numbered steps, DoD checklist, and has passed Q&R conformance review."]

Phase 1 refinement owners: Documentarian finalizes voice and formatting; HR verifies charter structure conforms to ORG.md unit definition standards. Neither author content for units — they refine the template shell.

3.2 Unit OKR Template (templates/unit-okrs.md)

Commissioned to: Documentarian (doc standards) + COO (OKR structural standard).

Required structure:

# <Unit Name> — OKRs <YYYY-QN>

> Layer: Foundational | Owner: <Unit Lead> | Cluster: <CPTO/COO/CGEO/Direct-to-Principal>
> Cascade from: <cluster strategy doc path or "Principal vision"> | Status: Draft/Approved

## Strategic context
[One paragraph. Connect this unit's work to: (a) KLMS dual-flywheel mission, 
(b) current venture phase, (c) the cluster strategy objective this unit serves.]

## Objectives and Key Results

### Objective 1: [Qualitative statement of what matters this quarter]
- **KR 1.1:** [What is measured] — Baseline: [X or "not yet established"] → Target: [Y]
- **KR 1.2:** [What is measured] — Baseline: [X] → Target: [Y]

### Objective 2: [...]
[...]

## Dependencies
[What does this unit need from other units to hit its KRs? Name the unit and the 
specific artifact or decision needed, and when.]

## Anti-goals (what we will NOT do this quarter)
[Explicit scope guardrails. Prevents mission creep. Reviewed at end of quarter.]

Phase 1 refinement owner: Documentarian finalizes formatting. COO validates OKR structural standard aligns with cascade logic before refinement begins.

3.3 SOP Template (existing: templates/sop.md)

The SOP template already exists and is in use (SOPs 001–004 are authored against it). Phase 1 assessment: Documentarian should verify the existing template includes a Definition of Done (DoD) checklist section — the Q&R conformance audit requires one, and the current template’s Guardrails section is not a DoD equivalent. If missing, Documentarian adds the section. No new template is commissioned.

DoD checklist section to add (if absent after Documentarian review):

## Definition of Done
- [ ] Mermaid flow validated and carries a text fallback
- [ ] All steps are numbered and specific enough to execute without judgment
- [ ] Roles and approvers are named (not generic)
- [ ] Guardrails reference the relevant policy by file path
- [ ] Archived by the Archivist (first immutable, latest refreshed)
- [ ] Listed in `docs/operations.md` runbook table (if applicable)
- [ ] Reviewed by Process Engineer for process design conformance

3.4 Foundational Reference Doc Template (templates/unit-ref.md)

Commissioned to: Documentarian.

Required structure:

# <Unit Name> — <Reference Type>: <Title>

> Layer: Foundational | Owner: <Unit Lead> | Last reviewed: <YYYY-MM-DD>
> Reference type: Domain glossary / Quality standards / Decision framework / Standards & conventions

## Scope
[What this reference covers. Who it applies to. What it does NOT cover.]

## [Content organized by reference type]
[For glossary: alphabetical terms with definitions.
For quality standards: per-output-type quality bars, stated as testable criteria.
For decision frameworks: the decision categories, the evaluation criteria, the 
 decision rules, and examples of past decisions.
For standards and conventions: the rules, their rationale, and how to apply them.]

## Cross-references
[Related docs in docs/, hr/policies/, CLAUDE.md. Use file paths.]

## Review cadence
[How often this reference is reviewed. Who triggers the review. What "reviewed" means 
(at minimum: verified still accurate; any outdated section updated).]

Phase 1 refinement owner: Documentarian finalizes voice, formatting, and ensures it conforms to docs/canon.md layer conventions.

3.5 Cluster Strategy Template (templates/cluster-strategy.md)

A cluster strategy is not a unit charter and not an OKR doc. It describes what the cluster is for, where it is taking the org this period, and how the units within it relate to each other and cascade from the cluster’s direction. This is a distinct artifact type.

Commissioned to: Documentarian (doc standards) + each C-suite agent (content author in Phase 2a).

Required structure:

# <CPTO/COO/CGEO> Cluster — Strategy <YYYY-QN>

> Layer: Foundational | Author: <C-suite agent> | Last reviewed: <YYYY-MM-DD>
> Cascade from: docs/vision.md | Status: Draft/Approved by Principal

## Cluster mission
[One paragraph. What this cluster's purpose is within KLMS. Traceable to Principal vision.]

## Strategic orientation — <YYYY-QN>
[What the cluster is focused on this quarter, and why. 3–5 paragraphs. 
Specific: names the venture phase, the flywheels, and the cluster's role in advancing them.
Not aspirational — evidence-grounded (what has been learned; what the next move is).]

## Cluster objectives
[2–4 qualitative objectives for the quarter. These cascade directly from Principal vision 
statements. Unit OKRs must trace to at least one of these.]

### Objective 1: [...]
**Units that serve this objective:** [names]
**How we will know progress is being made:** [leading indicator, not a final KR]

### Objective 2: [...]
[...]

## Unit coordination model
[How the units within this cluster relate to each other. Which units are upstream 
dependencies for which. The key handoff interfaces between units this quarter.
Reference: ORG.md cluster section.]

## Cross-cluster interfaces
[What this cluster receives from or delivers to the other two C-suite clusters this quarter.
Name the specific artifacts or decisions, not generic collaboration language.]

## Cluster risks and mitigations
[1–3 structural risks the cluster faces this quarter, with named mitigations.
Not individual unit risks — those live in the risk register. Cluster-level only.]

Named: docs/units/<cluster-slug>/strategy-<YYYY-QN>.md (e.g. docs/units/coo-cluster/strategy-2026-Q2.md)

Approver: C-suite cluster head (author) → Principal (review and approval before cluster’s units begin Phase 2b).

3.6 Principal Vision Doc (docs/vision.md)

The Principal vision doc is the top of the cascade. Every C-suite strategy references it; every unit OKR traces through it. It is not a venture concept doc (docs/concept.md covers what KLMS builds). It is the organizational vision: what kind of org is KLMS, toward what end, with what principles.

Author: Principal (direct chat); PA facilitates and drafts; Principal approves. Not authored by any unit.

Required structure (PA to draft to these headings):

# KLMS — Organizational Vision

> Author: Kevin Wong (Principal) | Facilitated by: Personal Assistant | Date: <YYYY-MM-DD>
> Status: Approved by Principal

## Vision statement
[2–4 sentences. What KLMS is trying to be, for whom, over what horizon.
Specific enough that a reader could test whether a decision aligns with it.]

## 3–5 year orientation
[What "winning" looks like at a medium-term horizon. Not a roadmap — 
an orientation. What has been built, who it serves, what it has proven.]

## Organizational principles
[3–5 numbered principles that govern how KLMS operates as an org — 
independent of product decisions. Examples: "Research before building," 
"Operate transparently," "AI workforce at full breadth." 
These are the organization's operating values, not product principles.]

## The flywheels and their relationship
[Explicit description of the dual-flywheel model: 
  Flywheel 1 — YouTube channel → audience → content signal
  Flywheel 2 — web learning platform → learner outcomes → feedback → content improvement
How the two flywheels interact. What the org's role is in sustaining each.]

## What the Principal expects from the org
[1–2 paragraphs. How the Principal intends to engage with the org: 
what decisions flow to the Principal; what is delegated; what the Principal's 
operating norms are. Sets expectations for C-suite coordination model.]

Named: docs/vision.md (singleton; no date suffix — this is the living organizational vision, versioned through git and the archive).

Approver: Principal only.

4. Per-Unit Gap Analysis

Coverage assessment methodology

For each unit, existing coverage is assessed across the four artifact types against actual files in the repository. “Partial” means the content exists implicitly in the agent definition but is not formalized as a standalone artifact at the required file path. “Missing” means neither the artifact nor a functional equivalent exists.

Existing SOP assignments (already issued IDs):

• SOP-001: Access request (docs/sop/access-request.md) — owner: Operations
• SOP-002: Document change management (docs/sop/change-management.md) — owner: Operations
• SOP-003: Deploy the intranet (docs/sop/deploy-intranet.md) — owner: Operations
• SOP-004: Secrets management (docs/sop/secrets-management.md) — owner: Security & Privacy

Next available SOP ID: SOP-005. Phase 2b unit SOP authoring begins from SOP-005 upward in the order units author their artifacts.

Direct-to-Principal Units (can begin Phase 2b alongside Phase 2a)

CPTO Cluster Units (Phase 2b begins after Phase 2a CPTO strategy lands)

COO Cluster Units (Phase 2b begins after Phase 2a COO strategy lands)

CGEO Cluster Units (Phase 2b begins after Phase 2a CGEO strategy lands)

C-Suite Layer (Phase 2a — before unit fan-out)

5. Handoff Map

Supporting providers do not author unit content — they provide the standards, templates, and infrastructure that units author into. This boundary must be enforced.

Principal’s authoring role: The Principal vision doc (docs/vision.md) is not authored by a unit. The PA facilitates a directed session with the Principal (direct chat), captures the stated vision, drafts the doc, and the Principal reviews and approves it. The Principal is the sole approver of this artifact. It is the top of the cascade and nothing below it can be finalized until it is approved.

6. Phase Sequencing — Recommended Order for Phase 2 Fan-Out

Principle: dependency-first ordering

The authoring order within Phase 2 follows two constraints:

1. Cascade constraint: C-suite strategies before cluster units; Principal vision before C-suite strategies.
2. Audit-readiness constraint: Q&R must publish its quality standards doc before auditing any other unit’s artifacts. Process Engineer must publish its SOP process conformance standard before reviewing any other unit’s SOPs.

Phase 2a: C-suite strategies (in parallel; all cascade from Principal vision)

Once docs/vision.md is approved, all three C-suite agents author in parallel:

• CPTO: docs/units/cpto-cluster/strategy.md + docs/units/cpto-cluster/okrs-2026-Q2.md
• COO: docs/units/coo-cluster/strategy.md + docs/units/coo-cluster/okrs-2026-Q2.md
• CGEO: docs/units/cgeo-cluster/strategy.md + docs/units/cgeo-cluster/okrs-2026-Q2.md

Each C-suite strategy is reviewed by the Principal individually before its cluster’s units begin Phase 2b.

Phase 2b: Unit fan-out — recommended sequencing

Wave 1 — Enabling infrastructure units and high-dependency units (begin immediately after Phase 1):

These units either have no C-suite cascade dependency (direct-to-Principal) or are blocking for other units’ SOP conformance review. They should begin and complete before Wave 2.

1. Q&R Director — quality standards doc (own artifact); must publish the conformance audit criteria before anyone else submits for Q&R review
2. Rules & Governance — own charter, OKRs, SOP (rule co-creation process), and rule standards doc; needed for any unit that surfaces a new rule during authoring
3. The Archives — own charter, OKRs, SOP (document intake SOP), and foundational ref (archive specification formalized at new path); all other units hand off to Archives
4. Operations — own charter, OKRs, remaining SOPs (identify gaps against SOP inventory), and foundational ref; Process Engineer must publish SOP conformance standard before reviewing Wave 2 SOPs
5. HR — own charter, OKRs, HR SOPs (hiring, onboarding), and foundational ref; needed before any new hiring during program
6. Security & Privacy — own charter, OKRs, security incident runbook (SOP-005 or next available), and threat model / tool-grant policy as foundational refs; security posture docs are cross-referenced by Engineering, AI Systems, and Legal

Wave 2 — CPTO and COO cluster units (begin after Wave 1 is complete and cluster strategies are approved):

7. Design Research — charter, OKRs, research protocol SOPs, research standards foundational ref; it is the Standard Flow’s spine
8. Engineering — charter, OKRs, build/code-review SOPs, coding conventions foundational ref
9. Innovation — charter, OKRs, hypothesis evaluation SOP, competitive intelligence framework foundational ref
10. Delivery (PMO) — charter, OKRs, delivery cadence SOP, milestone standards foundational ref
11. Documentation — charter, OKRs, document authoring SOP, writing standards foundational ref (Documentarian’s own artifacts — authored after templates are ratified)

Wave 3 — remaining CPTO and CGEO cluster units:

12. AI Systems — charter, OKRs, prompt review SOP, prompt standards / model selection framework foundational refs
13. Product — charter, OKRs, backlog management SOP, product decision framework foundational ref
14. Data & Analytics — charter, OKRs, telemetry standards SOP, data quality framework foundational ref
15. Finance — charter, OKRs, financial review SOP, financial system foundational ref
16. Legal & Compliance — charter, OKRs, compliance review SOP, regulatory framework foundational ref
17. Growth — charter, OKRs, content commissioning SOP + launch notification SOP, audience segment standards foundational ref
18. Customer Success — charter, OKRs, onboarding SOP, learner success playbook foundational ref
19. Creative — Brand & Marketing — charter, OKRs, brand review SOP, brand guidelines foundational ref (verify docs/brand/ contents first)

Wave 4 — C-suite own unit artifacts (these are the cluster strategy docs produced in Phase 2a, plus the cluster’s own operational charter):

The three C-suite agents author their own unit-level charter documents (docs/units/cpto-cluster/charter.md, docs/units/coo-cluster/charter.md, docs/units/cgeo-cluster/charter.md) after their subordinate units are complete. C-suite charters describe the cluster coordination model, not the individual C-suite agent’s operating rules (those are in the agent definitions). These are the last artifacts produced before Phase 3.

7. Quality Gate — Conformance Criteria for Q&R Audit

The Q&R Director audits each unit’s four artifacts against the following criteria. Each criterion is testable by reading the artifact. “Conforms” / “Does not conform” / “Partially conforms” is the verdict per criterion; the audit is structured per the Q&R process (Step A of the Q&R agent definition).

7.1 Unit Charter — conformance criteria

7.2 Strategy and OKRs — conformance criteria

7.3 SOPs and Runbooks — conformance criteria

7.4 Foundational Reference Docs — conformance criteria

7.5 Program-level pass criteria

A unit’s Phase 2b work earns a Pass verdict when:

• All four artifact types are present at correct paths
• Each artifact scores “Conforms” or “Partially conforms — minor” on all Q&R criteria above
• No artifact scores “Does not conform” on any single criterion
• All artifacts have been handed off to and archived by the Archivist

A Pass with conditions is issued when: 1–2 criteria score “Partially conforms” with documented remediation actions and a named timeline.

Does not pass when: any artifact is missing, or any criterion scores “Does not conform.”

8. Open Issues Flagged for Principal Review

The following items emerged during Phase 0 analysis and require Principal input or direction before the program proceeds. None of these block Phase 1 work, but all must be resolved before Phase 2b fan-out.

End of Phase 0 Program Brief — awaiting Principal approval.