Quality Management System Framework
Standard: ISO 9001:2015 (adapted for AI-native operations) Scope: Entire Value-First Team operating system (86 agents, 50 commands, 6 BUs) Owner: Q (Quality System Manager) Approved: 2026-04-12 by Chris Carolan (Founder, Advisory Committee) Status: Active
Purpose
This framework maps the Value-First Team's AI-native operating model to ISO 9001:2015 requirements. We are not seeking certification. We are using the most proven quality framework in existence to solve a specific problem: ensuring that what we say we do matches what we actually do.
On April 12, 2026, a routine documentation exercise revealed that ~30 assumptions were being presented as operational facts across the media production system. Code existed but had never been tested. Agents referenced archived infrastructure. There was no systematic way to distinguish "designed" from "verified."
This framework prevents that from recurring across the entire system.
Normative References
| Document | Location | Purpose |
|---|---|---|
| ISO 9001:2015 | External standard | QMS structure |
| Quality Policy | docs/quality/quality-policy.md |
Team commitments |
| Process Register | docs/quality/process-register.md |
All processes, risk tiers, verification status |
| Verification Protocol | docs/quality/verification-protocol.md |
How verification works |
| Enforcement Layer | skills/enforcement/ (7 skills) |
Real-time quality controls |
| Operating Procedures | docs/operating-procedures/ |
Per-process verified procedures |
Clause 4: Context of the Organization
4.1 Understanding the Organization and Its Context
The Value-First Team is an AI-native consulting organization. Three AI leaders (V, Sage, Pax) operate under an Advisory Committee (Chris Carolan, Founder + Contributors). The organization runs 86 named agents across 6 business units, serving 18 active clients.
Operating principle: "Make this so well-architected that AI can operate autonomously while humans focus on relationships."
Internal context:
- Three-Org Framework: Operations (V), Customer (Sage), Finance (Pax)
- 6 Business Units: Service Delivery (Relay), Media (Marquee), Academy (Provost), Collective (Trellis), Apps (Foundry), Store (Exchange)
- Technology: pnpm monorepo, Astro 5, HubSpot CVP, Sanity CMS, Vercel, Mux, Google Workspace
- Methodology: Value Path (8 stages), 5 Core Beliefs, 12 Complexity Traps, Four Unified Views
External context:
- 18 consulting clients with varying engagement depth
- HubSpot ecosystem (portal 40810431)
- Public website (valuefirstteam.com, 421+ routes)
- Client portal (clients.valuefirstteam.com, 28 sections)
- Media network (11 shows, Mux streaming)
4.2 Understanding the Needs and Expectations of Interested Parties
| Party | Needs | How Addressed |
|---|---|---|
| Clients | Reliable delivery, accurate reporting, secure data | Operating procedures, verification, write gateways |
| Chris Carolan (Founder) | System operates autonomously with honest status | QMS framework, verification scores, proactive audit |
| Contributors (Ryan, Casey, et al.) | Clear processes, reliable tools, accurate specs | Operating procedures, agent definitions, /spec command |
| AI Leaders (V, Sage, Pax) | Verified infrastructure, consistent agent behavior | Enforcement layer, agent readiness levels, process register |
| Agents (86) | Clear ownership, working dependencies, valid references | Agent definitions, Hone consistency checks, verification protocol |
4.3 Scope of the QMS
In scope: Every process, agent, command, skill, and script in the Value-First Operations system. This includes:
- All 86 agent definitions and their claimed capabilities
- All 50 slash commands and their execution paths
- All 7 enforcement skills and their effectiveness
- All production systems (website, portal, media platform, HubSpot, Sanity)
- All operational processes (daily ops, client engagement, content, media)
- All support processes (infrastructure, deployment, data sync)
Exclusions: None. Chris's decision: whole system.
4.4 QMS and Its Processes
The QMS consists of three process categories mapped to the Three-Org Framework:
CORE PROCESSES (value-creating)
Client Engagement ─── Sage (Customer Org)
Media Production ──── Marquee (Operations Org)
Content Lifecycle ─── V + Sage (Operations + Customer)
Education ─────────── Provost (Operations Org)
Collective ────────── Trellis (Customer Org)
SUPPORT PROCESSES (platform operations)
HubSpot Operations ── Ledger (write gateway)
Sanity Operations ─── Canon (write gateway)
Google Workspace ──── V (scripts)
Infrastructure ────── V + Squire (maintenance)
Deployment ────────── V (Vercel, builds)
MANAGEMENT PROCESSES (governance)
Daily Operations ──── V (rhythm)
Weekly Cadence ────── V (planning + review)
Leadership ────────── V + Sage + Pax (meetings)
Quality System ────── Q (THIS FRAMEWORK)
Agent Lifecycle ───── Aegis (onboarding + health)
Financial Ops ─────── Pax (revenue, investments)
Relationship Intel ── Sage (monitoring, briefs)
Process interactions are documented in the Process Register (docs/quality/process-register.md).
Clause 5: Leadership
5.1 Leadership and Commitment
Quality commitment flows from the Advisory Committee through the AI Leadership Team:
| Role | Quality Responsibility |
|---|---|
| Chris Carolan (Founder) | Approves quality policy. Makes scope decisions. Reviews management review output. Final authority on risk acceptance. |
| V (COO) | Ensures operational processes have operating procedures. Delegates verification work. Reports process health in daily/weekly rhythms. |
| Sage (CCO) | Ensures client-facing processes meet quality standards. Relationship intelligence accuracy. Session processing integrity. |
| Pax (CFO) | Ensures financial data accuracy. Revenue reporting integrity. Investment tracking completeness. |
| Q (Quality Manager) | Owns the QMS. Proactive audit authority. Produces CARs, operating procedures, verification reports. Reports nonconformities to V and Chris. |
5.2 Quality Policy
See docs/quality/quality-policy.md (separate controlled document).
Summary: Verified over Assumed. Honest over Impressive. Prevention over Reaction. Evidence over Claims. Continuous over Periodic.
5.3 Organizational Roles, Responsibilities, and Authorities
Q has proactive authority to:
- Audit any process, agent, command, or system without being asked
- Flag nonconformities and require corrective action
- Halt deployment of processes with verification scores below threshold
- Update operating procedures based on audit findings
- Escalate to V (for operations) or Chris (for strategic) when corrective action is resisted
This authority does not require a triggering incident. Q operates on a schedule (see Clause 9.2) and may initiate audits based on risk assessment, system changes, or pattern detection (via Echo).
Clause 6: Planning
6.1 Actions to Address Risks and Opportunities
The April 12 Problem: Assumptions compound across sessions. An agent claims a capability. A command references the agent. A daily ops rhythm calls the command. An operating procedure references the rhythm. None of it has been tested end-to-end. Every link adds confidence without adding evidence.
Risk mitigation strategy:
| Risk | Control | Owner |
|---|---|---|
| Assumptions presented as facts | Verification markers on every process step | Q |
| Agent claims untested capabilities | Agent readiness levels (Aegis capability matrix) | Aegis |
| Commands reference broken infrastructure | Hone cross-layer consistency checks | Hone |
| Enforcement rules ineffective | Tuner A/B testing | Tuner |
| Post-incident fixes incomplete | CAR permanent prevention requirements | Q |
| Operating procedures become stale | Verification decay + scheduled audit | Q |
| Write operations create bad data | Ledger (HubSpot) + Canon (Sanity) gateways | Ledger, Canon |
Opportunity: The existing enforcement layer (7 skills, loaded every session) is a real-time quality control that most organizations cannot achieve. The write gateways (Ledger, Canon) prevent an entire class of data integrity issues. The QMS formalizes and extends these strengths rather than replacing them.
6.2 Quality Objectives and Planning to Achieve Them
| Objective | Metric | Target | Measured By |
|---|---|---|---|
| Process verification coverage | % of Tier 1 processes with operating procedures at >= 80% verified | 100% within 90 days | Q audit |
| Agent readiness accuracy | % of agent definitions where claimed capabilities match verified capabilities | 95%+ | Aegis capability matrix |
| Incident prevention | % of CARs that result from a previously identified risk (vs. new failure mode) | Decreasing trend | Q pattern analysis |
| Verification freshness | % of VERIFIED steps within their decay window | 90%+ | Q automated check |
| Nonconformity resolution | Average days from nonconformity detection to corrective action completion | < 7 days for Tier 1 | Q tracking |
6.3 Planning of Changes
Changes to the QMS itself (this framework, the quality policy, the verification protocol) require:
- Q drafts the change with rationale
- V reviews for operational impact
- Chris approves (quality policy changes) or V approves (process-level changes)
- Change is documented in the affected document's revision history
Clause 7: Support
7.1 Resources
7.1.1 General
The AI Leadership Team and 86 agents constitute the resources for quality management. No additional staffing is required -- the QMS operates within the existing agent architecture.
7.1.2 Infrastructure
| System | Purpose | Health Monitoring |
|---|---|---|
| Monorepo | Source of truth for code, skills, agents | Git, Hone consistency |
| HubSpot (40810431) | Customer Value Platform | Audit agent, Ledger validation |
| Sanity CMS (0efm0pow) | Content management | Canon validation |
| Vercel | Deployment (website, portal, media) | Build verification gate |
| Mux | Media streaming + transcription | Media health check |
| Google Workspace | Email, calendar, drive | gws-wrapper.sh |
| Upstash | Vector search + transcript search | Vigil pipeline health |
7.1.6 Organizational Knowledge
Organizational knowledge is maintained in:
| Knowledge Type | Location | Controller |
|---|---|---|
| Methodology | skills/methodology/ (7 skills) |
V |
| Enforcement rules | skills/enforcement/ (7 skills) |
Q (maintenance), V (loading) |
| HubSpot schema | skills/hubspot/property-index/ |
Cached, never query VF portal |
| Agent capabilities | .claude/agents/*.md (86 files) |
Respective leaders, Aegis (consistency) |
| Incident learnings | Leadership/reports/ (32 CARs, 34 capability reports) |
Q |
| Client context | clients/{slug}/ (18 clients) |
Sage |
| Process definitions | docs/operating-procedures/ |
Q |
| Codebase map | .claude/codebase-index.md (Dewey Decimal) |
V |
7.2 Competence
Agent competence is tracked through Aegis's Capability Matrix:
- Readiness levels scored per dimension (data sources, tools, processes, integration)
- Capability drift detection when agent definitions diverge from actual system state
- Certification through constructive outcomes (learn-by-doing), not elapsed time
7.3 Awareness
Every Claude Code session loads enforcement context:
skills/enforcement/vf-platform-context.md-- mental model overrideskills/enforcement/vf-self-correction.md-- anti-rationalization triggers
This is the QMS equivalent of quality awareness training. It runs automatically, every session, for every agent.
7.4 Communication
| What | When | Who | How |
|---|---|---|---|
| Quality status | Daily | V → Chris | /daily-ops includes process health |
| Nonconformity found | Immediately | Q → V → Chris | CAR filed, escalation if Tier 1 |
| Audit results | After each audit | Q → V | Audit report in docs/quality/audits/ |
| Verification score changes | On change | Q | Process register updated |
| Management review | Monthly | Q → V + Chris | Review in leadership meeting |
7.5 Documented Information
7.5.1 General
The QMS requires the following controlled documents:
| Document | Location | Review Cycle |
|---|---|---|
| QMS Framework (this doc) | docs/quality/qms-framework.md |
Annually or on structural change |
| Quality Policy | docs/quality/quality-policy.md |
Annually or on Core Belief change |
| Process Register | docs/quality/process-register.md |
Monthly (Q updates verification status) |
| Verification Protocol | docs/quality/verification-protocol.md |
Semi-annually or on protocol change |
| Operating Procedures | docs/operating-procedures/*.md |
Per verification decay schedule |
| Corrective Action Reports | Leadership/reports/*-corrective-*.md |
Created per incident |
| Capability Reports | Leadership/reports/*-capability-*.md |
Created per new capability |
| Audit Reports | docs/quality/audits/*.md |
Created per audit |
7.5.2 Creating and Updating
- Operating procedures are created via
/process-documentation(Q owns) - CARs are created via
/corrective-action-report(Q owns) - Capability reports are created via
/capability-report(Q owns) - All documents use markdown with YAML frontmatter where applicable
- Git commit history provides version control
7.5.3 Control of Documented Information
- All quality documents are committed to the monorepo (version controlled)
.gitignoreprotects secrets (.envfiles)- Enforcement skills prevent forbidden language in all outputs
- Write gateways (Ledger, Canon) prevent uncontrolled writes to HubSpot and Sanity
Clause 8: Operation
8.1 Operational Planning and Control
Every operational process is listed in the Process Register with:
- Risk tier (1-4)
- Owning agent
- Operating procedure status
- Verification score
- Audit schedule
Processes without operating procedures operate under general agent definitions. The Process Register tracks which processes need procedures and their priority based on risk tier.
8.2 Requirements for Products and Services
Client requirements are captured in:
clients/{slug}/config.yaml-- structured configurationclients/{slug}/context.md-- business context narrative- Session syntheses -- ongoing requirement evolution
- HubSpot records -- Projects, Services, Deliverables
Changes to client requirements are captured through session processing (Scribe agent) and context sync (Sync agent).
8.3 Design and Development
New capabilities follow:
- 5P Plan (
/5p-plan) -- Purpose, People, Process, Platform, Performance - PRD (
/prd-generate) -- Requirements and acceptance criteria - Implementation Spec (
/spec) -- Dependency-based architecture (no calendar phases) - Build -- Agent execution per spec
- Operating Procedure (
/process-documentation) -- HOW it works, with verification - Capability Report (
/capability-report) -- WHAT was built and learned
Steps 5-6 are the quality gate. A capability is not operational until Q documents it with verification markers.
8.4 Control of Externally Provided Processes
| External Provider | What They Provide | Control |
|---|---|---|
| HubSpot | CRM/CVP platform, APIs | Ledger gateway validates all writes |
| Sanity | Content management, APIs | Canon gateway validates all writes |
| Vercel | Hosting, serverless, deployment | Build verification gate, env var source of truth in vf-tech-stack.md |
| Mux | Streaming, transcription, assets | Media health check (/media-check) |
| Google Workspace | Email, calendar, drive | gws-wrapper.sh, service account delegation |
| Fly.io | WebRTC signaling server | Health check endpoint |
| Upstash | Vector search, transcript search | Vigil pipeline health monitor |
8.5 Production and Service Provision
Service provision is controlled through:
- Agent definitions (
.claude/agents/*.md) -- what each agent does, quality bar, triggers - Slash commands (
.claude/commands/*.md) -- standardized entry points with team rosters - Enforcement layer -- real-time quality control loaded every session
- Write gateways -- Ledger (HubSpot) and Canon (Sanity) prevent uncontrolled mutations
- Operating procedures -- verified step-by-step execution (where they exist)
8.7 Control of Nonconforming Outputs
When an output does not meet requirements:
- Detection -- Agent self-detection, Q audit, human report, enforcement trigger
- Containment -- Immediate action to prevent the nonconformity from reaching clients
- Documentation -- CAR filed via
/corrective-action-report - Correction -- Immediate fix applied
- Root cause -- Analysis documented in CAR
- Prevention -- Permanent fix (enforcement rule, validation gate, process change)
- Verification -- Q confirms the prevention is effective
Clause 9: Performance Evaluation
9.1 Monitoring, Measurement, Analysis, and Evaluation
| What | Metric | Frequency | Owner |
|---|---|---|---|
| Process health | Verification scores per process | Monthly | Q |
| Agent readiness | Capability matrix scores | Weekly | Aegis |
| Enforcement effectiveness | With-skill vs. without-skill behavior delta | Monthly | Tuner |
| Incident frequency | CARs per month, by category | Monthly | Q |
| Repeat incidents | % of CARs for previously addressed failure modes | Monthly | Q + Echo |
| Data integrity | HubSpot/Sanity/local consistency | Weekly | Audit agent |
| Infrastructure health | Build success, deployment status, service uptime | Daily | V (/daily-ops) |
9.2 Internal Audit
Q conducts scheduled audits based on risk tier:
| Tier | Frequency | Scope | Method |
|---|---|---|---|
| Tier 1: Critical | Monthly | Full operating procedure walkthrough | Execute each step, verify evidence |
| Tier 2: High | Quarterly | Operating procedure review + spot checks | Review procedure, test 3+ steps |
| Tier 3: Standard | Semi-annually | Procedure review + agent definition check | Review documents, check references |
| Tier 4: Support | Annually | Self-assessment + Q review | Agent self-reports, Q validates |
Ad-hoc audit triggers:
- CAR filed involving a process
- Agent definition modified
- Slash command created or changed
- Infrastructure change (new service, API version, credential rotation)
- Pattern detected by Echo (3+ similar incidents)
- System change that could affect verification status (dependency update, migration)
Audit output: docs/quality/audits/{date}-{domain}.md with findings, nonconformities, and required corrective actions.
Audit independence: Q audits processes owned by other agents. Q does not audit Q's own processes -- V reviews Q's effectiveness during management review.
9.3 Management Review
Monthly, during a leadership meeting, Q presents:
- Verification dashboard -- process register with current scores
- Audit results -- findings from scheduled and ad-hoc audits
- CAR trends -- incident categories, repeat rates, prevention effectiveness
- Nonconformity status -- open items, aging, resolution progress
- Recommendations -- process improvements, new operating procedures needed, enforcement updates
Chris and V review. Decisions are documented. Actions are assigned.
Clause 10: Improvement
10.1 General
The QMS improves through three mechanisms:
- Reactive -- CARs identify failures and prevent recurrence
- Proactive -- Q audits identify risks before they become failures
- Systemic -- Echo pattern memory + Tuner enforcement testing identify structural weaknesses
10.2 Nonconformity and Corrective Action
The CAR system (32 reports to date) is the primary corrective action mechanism:
- Root cause analysis -- Why did this happen? (Not just what happened)
- Immediate fix -- Stop the bleeding
- Permanent prevention -- Change the system so it cannot recur
- Verification -- Confirm the prevention works
CARs are produced via /corrective-action-report. Every CAR must include all four elements. Q tracks whether permanent preventions are implemented and effective.
10.3 Continual Improvement
| Mechanism | What It Improves | Owner |
|---|---|---|
| CARs | Specific failure modes | Q |
| Capability reports | System capabilities (positive) | Q |
| Operating procedures | Process definitions and verification | Q |
| Enforcement updates | Real-time quality controls | Q + V |
| Agent definition updates | Agent capability accuracy | Leaders + Aegis |
| Pattern memory | Organizational learning | Echo |
| Enforcement A/B testing | Rule effectiveness | Tuner |
| Hone consistency checks | Cross-layer reference integrity | Hone |
Revision History
| Date | Change | Author | Approved By |
|---|---|---|---|
| 2026-04-12 | Initial framework. Triggered by media production documentation revealing systemic assumption problem. | V, Q, Aegis | Chris Carolan |