Why this exists
The hard part is not how to use a model. The hard part is deciding whether AI should be used at all, and if it is used, what evidence, context, provenance, validation, observability, change control, and sustainment discipline must exist before it can support real work.
The playbook focuses on correctness-matters AI: AI-infused work where poor grounding, weak evidence, uncontrolled context, unreliable output, or weak operating controls can create bad decisions, wasted spend, operational risk, compliance exposure, quality defects, or downstream rework. Regulated and high-consequence settings are obvious examples, but the same posture applies whenever AI output drives business decisions, operational action, architecture choices, security posture, financial decisions, quality outcomes, or downstream work.
Use it to separate model intelligence from the scaffolding required to make AI useful, safe, and sustainable. Some problems need deterministic rules, workflow automation, search, reporting, or AI-assisted design support instead of AI-infused runtime behavior. The durable product is the governed knowledge package: source, metadata, receipts, hashes, and portable artifacts. The public site is a reading surface, not the product boundary, and a future chatbot would be another interface rather than the durable asset.
Start Here Reader Paths
Start where your current question is. Each path names what to read first, what to use next, what question it helps answer, what it does not approve, and where future source-grounded assistant answers should link readers back into the package.
Executive or sponsor
First: Playbook Map.
Next: AI Capability Discipline and the executive brief.
Answers: should AI be used here, what outcome matters, and what proof is needed before funding or scale?
Does not approve: broad pilots, production routing, tool access, data use, or supplier paths.
Enterprise architect
First: Shared Foundations.
Next: AI Capability Discipline, then EA Review Assistant.
Answers: what source authority, evidence, schema, eval, review, and sustainment controls are missing?
Does not approve: architecture decisions, data classes, workflow exceptions, or production readiness.
Governance, risk, or compliance reviewer
First: AI Capability Discipline policy-boundary and provenance sections.
Next: Grounding rules, claim posture, source maps, and receipts.
Answers: what is field guidance, what is owner-validated, and what still needs formal review?
Does not approve: company policy, regulated use, security posture, privacy posture, or data movement.
Product or platform owner
First: Playbook Map.
Next: MLL WESS and product architecture.
Answers: is this an idea, prototype, pilot, operational capability, or deferred infrastructure path?
Does not approve: hosting, Cloudflare, Supabase, Copilot Studio, backend, or platform deployment work.
Builder or implementation lead
First: Shared Foundations.
Next: MLL WESS, EA Review Assistant, and validation receipts.
Answers: what contracts, evals, telemetry, review loops, and package checks are needed before build commitment?
Does not approve: runtime behavior, provider calls, connector ingestion, private-data workflow, or enterprise integration.
Practitioner or learner
First: AI Capability Discipline.
Next: Shared Foundations and worked examples.
Answers: why are prompts, agents, evals, and demos only components, and how does capability formation work?
Does not approve: use of any AI tool, data class, workflow, or production process.
Assistant or context-package user
First: Context pack manifest and grounding rules.
Next: source map, glossary, sections, claims, and source-grounded explainer notes.
Answers: which package sources may ground future Find, Explain, or Assess answers, and where should cited answers link readers?
Does not approve: model-memory answers, runtime chat, provider execution, or generated assessment output as source truth.
Playbook Map
Shows what the playbook pieces are, which one to read first, and which artifact helps which kind of decision.
Shared Capability Foundations
Reusable terms, control concepts, and architectural primitives used across the broader playbook.
AI Capability Discipline
The teaching layer for governed AI capability formation, preserved here as the real `v0.9` HTML experience.
MLL WESS Build Readiness
Applies the discipline to scarce team capacity, preflight, contractor effort, Jira epics, and operationalization.
Enterprise Architecture Review Assistant
A concrete governed assistant blueprint with source authority, evidence states, evals, and human review.
Prompt Packs
Renderer-ready prompt packs for explaining, visualizing, and communicating the playbook family.
Artifact identity, context pack, and portable exports
The public site helps readers navigate the playbook, but the durable product is the governed knowledge package rather than this website or a future chatbot surface. Root `context-pack/` remains canonical; this site publishes its deterministic mirror at `/context-pack/`. Use the manifests and hash receipts when package files need to travel outside the full repository context.
Field guidance boundary
This is field guidance, not final policy. It does not approve any enterprise tool, data class, workflow, supplier path, or production use case. The public site frames the playbook family while keeping the official AI Capability Discipline `v0.9` release-of-record preserved in `releases/v0.9/` inside the repository.