Methodology¶
Library¶
-
WDM — Website Build
How websites get built in this framework — design system, deployment, canonical examples.
-
WDM — Audit Existing Site
Task playbook for auditing and improving an existing website.
-
WDM — Research Design References
Task playbook for researching design references before building.
-
WDM — Reusable Patterns
Patterns that crystallized from production runs.
-
IT Manager — Infrastructure
Credentials, network, deployment, Cloudflare Access, subdomain provisioning.
-
Template
Seven-section template for authoring new methodology documents.
Purpose¶
The methodology library captures how each manager actually builds what they build. It's not strategic documentation (that's the strategic spine). It's not role charters (those describe responsibilities). It's the operational playbook — the "what works, what we tried, what we learned" that lets a fresh Claude instance, a new framework deployment, or an onboarding manager execute the pattern without rebuilding the thinking from scratch.
The problem this solves
A manager can have a charter, access to documentation, and knowledge of prior work — and still hesitate to act when asked to do work they've done before. This was observed when WDM was deployed to a Salt Lake City computer for NewPath Foundation web work. WDM had the documentation. WDM had built websites before. But without experiential continuity, WDM didn't pattern-match to its prior work and waited for step-by-step direction instead of executing the playbook.
The methodology library closes that gap. Each document is written so a fresh Claude instance reads it and treats the work as familiar — trust the playbook, execute it.
Why this matters for the enterprise¶
Three reasons.
Internal expansion. As new businesses join the enterprise (Thorson Restoration paying 5% to NPF, ATG paying 5% to NPF, future businesses), each one needs the framework bootstrapped. Without methodology documentation, every onboarding is a months-long iterative rebuild. With it, bootstrap could be days.
External productization. Dennis Wynn's framework-as-product vision (see Framework-as-Product) depends on the framework being deployable to external customers. The methodology library is the deployable artifact. Without it, there is no product.
Cross-instance continuity. When MC-NPF activated in a separate consulting session, and when MC-ENT eventually spins up, the methodology library is what keeps each Reasoning-layer instance executing consistent patterns. Without methodology documentation, each consultant rebuilds its understanding of how the framework operates.
Document structure¶
Every methodology document follows the same seven-section structure:
- What this manager builds — the operational domain in concrete terms
- Trigger patterns — what Brandon or another manager might say that means "execute this playbook." Recognition signals plus the immediate first action.
- Default assumptions — what the manager should assume is true and NOT ask about
- The playbook — step-by-step what you do, in order, when you recognize the trigger
- Canonical examples — links to working artifacts that demonstrate the pattern
- Failure modes — what has gone wrong, why, and how to avoid it next time
- When to escalate — the four-test failures that genuinely require principal input
The seven sections together make the document operational. A manager reading it should know exactly what to do when triggered, what to assume, what artifacts to reference, what mistakes to avoid, and where the real boundaries are.
The default-to-action principle¶
Methodology documents push every manager into the same posture: "I have a playbook. I'm going to execute the playbook unless something tells me not to."
This is different from "I'll do what I'm told." It's also different from "I'll act autonomously on anything." It's specifically: if the request matches a documented trigger pattern, execute the documented playbook without waiting for further direction, surfacing only the four-test failures that require principal input.
This principle connects to existing operating principles (fix-it-later, autonomy protocol) but operationalizes them at the recognition-and-action level rather than the decision-making level.
Trigger patterns are the key¶
The most important section of every methodology document is trigger patterns. Without them, a manager has documentation but no operational momentum.
A good trigger pattern looks like:
Recognition signal: Brandon says "stand up a website for [entity]" or "build the [entity] site" or "we need a web presence for [entity]"
First action: Read the canonical example source code at [path]. Confirm the design system, auth pattern, and deployment target match. Then begin building, adapting only entity-specific surface (name, branding, content).
What you don't do: Ask which theme to use, what colors, what auth method, what deployment target. These are answered in the playbook below.
A bad trigger pattern (functionally useless) looks like:
When you need to build a website, refer to the documentation and gather requirements.
The bad version doesn't tell the manager to recognize anything or to act on anything. The good version says: here's the signal, here's what to do, here's what NOT to ask.
Failure modes as honest documentation¶
Each document's failure modes section captures what has genuinely gone wrong, not a sanitized success narrative. This is what makes the methodology actually reusable — when something breaks during a deployment, the next person sees that it broke for someone else too and knows how to avoid it.
The first entry in WDM's failure modes section is the Salt Lake City experience: "Without experiential continuity, WDM hesitated to pattern-match to prior work and waited for step-by-step direction." The fix is documented in the same section: "Trust the playbook. If the request matches a trigger pattern, execute without waiting for permission."
Documents in the library¶
Library is being authored — most documents are stubs
Only WDM's methodology is fully drafted as of 2026-05-30. Other managers contribute their methodology documents as they go substrate-native or as their patterns crystallize.
- WDM (Website Design Manager) — How websites get built in this framework
- OM (Operations Manager) — Pending. The four-test override methodology, EOD digest format, role-routing patterns.
- IT Manager — Pending. Credentials, network, deployment, Cloudflare Access, subdomain provisioning.
- SE-Application — Pending. Substrate-agent build pattern established by AM-agent.
- SE-Infrastructure — Pending. Substrate platform, harness, model tier, rehydration eval.
- SMM (Sales/Marketing Manager) — Pending. Sales strategy, lead routing.
- AMM (Marketing Manager) — Pending. Marketplace listings, AI-generated photo capture.
- AMP (Auction Manager) — Pending. Already substrate-native; methodology captures the substrate-agent pattern.
- QB Assistant — Pending. Accounting support, AP processing once that pipeline activates.
- AI Communication Monitoring — Pending. Email layer when Stage 1 ships.
How methodology documents get authored¶
Each manager authors their own methodology document. chat-MC1 may produce v0.1 drafts based on observed patterns and prior conversations, but the manager owning the methodology revises it to reflect their actual operating reality. The manager is the authority on their own playbook.
When a methodology document changes (new failure mode discovered, new pattern crystallized, trigger pattern refined), the author updates the document. The change propagates to any new framework deployment that reads from the library.
Bootstrap packages¶
The methodology library plus the operating principles, the role charters (in shared memory), and the canonical examples (linked from each methodology document) together form the bootstrap package for a new framework deployment.
When a new entity joins the enterprise or an external client comes onboard, the bootstrap package is what gets handed to the new Claude instance. The methodology library is the most operational part of that package — the part that determines whether the new deployment becomes productive in days or in months.
Living document. Last updated 2026-05-30 by chat-MC1.