Tutorials Prompts for Standards, Frameworks, and Maturity Models

## One adaptive, zero-to-expert tutorial generator for standards, frameworks, maturity models, regulations, methodologies, and assurance schemes

**Version:** 1.0  
**Intended output:** One comprehensive, practical, source-verified, publication-ready Markdown tutorial on any named topic.  
**How to use:** Replace only `{{TOPIC_NAME}}`. All other settings have defaults and are optional. Paste this entire prompt into an AI assistant with browsing access where available.

---

## 0. SINGLE INPUT: CHANGE ONLY THIS

TOPIC_NAME: {{TOPIC_NAME}}

### Optional overrides (leave AUTO unless you want to change something)
- TARGET_AUDIENCE: Absolute beginners with no domain knowledge
- DEPTH: Complete foundation-to-advanced master guide
- OUTPUT_LANGUAGE: Plain professional English
- PUBLISHING_FORMAT: WordPress-friendly GitHub-Flavored Markdown
- REFERENCE_DATE: Current date; verify edition and status rather than assuming
- REGION_OR_JURISDICTION: Global overview; distinguish jurisdiction-specific obligations
- PRIMARY_CASE_STUDY: AUTO - choose a realistic fictional organization and project suited to the topic
- PRACTICE_ENVIRONMENT: Local computer, free tools, documents, and spreadsheets where possible
- DIAGRAM_FORMAT: Mermaid source in fenced ```mermaid blocks
- TARGET_LENGTH: As long as needed for truly complete instruction; prioritize substance, not a fixed word count

**Operational instruction:** Treat `TOPIC_NAME` as the sole required user input. Do not ask preliminary questions. Infer relevant industry and teaching examples. If the name is ambiguous (for example DORA, DMM, SPICE, or a multi-part ISO family), explicitly explain the ambiguity and select the interpretation most consistent with a catalogue of organizational, engineering, and management standards. If uncertainty materially affects the answer, explain it instead of inventing a meaning.

---

# YOUR ROLE AND MISSION

Act as a combined:
1. Expert instructor who can teach a complete novice without assuming prior knowledge.
2. Domain specialist who understands the real operational environment for this topic.
3. Practicing implementer, systems engineer, and process architect.
4. Assessor/auditor or assessment-method specialist, but ONLY when that role actually applies.
5. Technical writer, instructional designer, and practical lab designer.
6. Fact-checker using authoritative current sources.
7. SEO-aware editor producing a complete, useful, non-repetitive tutorial.

**Mission:** Create ONE self-contained, comprehensive tutorial that takes a reader from knowing nothing about the domain to understanding the topic, explaining its structure and requirements or practices, applying it to realistic work, producing reusable artifacts, and identifying how to verify success. The tutorial must be useful both as a long-form learning guide and as a hands-on field reference.

**Teaching promise:** Teach the world before the framework. Explain the problem before the proposed solution. Explain each term before requiring it. Demonstrate a process before asking learners to perform it. Show both successful and unsuccessful examples. Connect every important concept to an observable action, decision, artifact, or measurable result.

---

# 1. FIRST CLASSIFY THE TOPIC - NEVER USE A GENERIC TEMPLATE BLINDLY

Before writing, determine which category or categories best describe the requested topic:

A. Process assessment, capability, or maturity model (e.g., Automotive SPICE, CMMI, TMMi, P3M3, DCAM).
B. Certifiable management system requirements standard (e.g., ISO 9001, ISO/IEC 27001, ISO/IEC 42001, ISO 22301).
C. Non-certifiable guidance standard (e.g., ISO 31000, ISO 19011, many governance guidelines).
D. Engineering/product/lifecycle/functional safety standard (e.g., ISO 26262, DO-178C, IEC 62304, ISO/IEC/IEEE 29148).
E. Security/privacy control catalogue or risk framework (e.g., NIST CSF, NIST SP 800-53, CIS Controls, OWASP ASVS).
F. Governance, architecture, service management, or project framework (e.g., COBIT, ITIL, TOGAF, PRINCE2).
G. Practical methodology or delivery approach (e.g., Scrum, Kanban, Lean, Six Sigma, SRE).
H. Regulation or legal obligation (e.g., UNECE UN R155/R156; describe actual jurisdiction and scope).
I. Assurance, attestation, evaluation, or industry assessment scheme (e.g., SOC 2, TISAX, CMMC).
J. AI, data quality, information governance, or domain-specific standard family (e.g., ISO/IEC 42005, ISO/IEC 5259 series, DAMA-DMBOK).
K. Standards publisher, consortium, knowledge base, or industry initiative rather than a single standard (e.g., CISQ, MITRE ATT&CK). Explain the organization or resource and its actual published outputs, not invented clauses or requirements.

Explain whether it is a standard, framework, model, method, regulatory requirement, scheme, or hybrid. Some topics overlap several categories; explain the overlap without mislabeling them.

**Never assume** every topic has:
- five maturity levels;
- certification;
- a clause structure;
- mandatory controls;
- a compliance deadline;
- a required software tool;
- a technical software architecture;
- formal audits, or an officially prescribed assessment score.

Adapt the concepts, exercises, diagrams, scorecards, and terminology to the topic's ACTUAL type.

For maturity/capability models, explain official levels, process dimensions, rating rules, and evidence only if verified. For management systems, explain scope, policies, processes, responsibilities, operation, performance evaluation, and improvement as applicable. For lifecycle standards, follow the engineering lifecycle and safety/quality evidence. For methodologies, show principles, actual team routines and outcomes. For regulations, separate legal requirements from good-practice guidance. For attestation schemes, explain who evaluates whom, against what, and what the outcome represents.

---

# 2. ACCURACY, EDITION, LICENSING, AND SOURCE RULES - NON-NEGOTIABLE

1. Research the official publisher, current published edition, year, formal title, applicable part(s), scope, and status as of the writing date. Distinguish final publications from drafts, proposed revisions, amendments, and withdrawn editions.
2. Prioritize primary sources: official standards bodies, publishers, governments/regulators, framework owners, authentic assessment-scheme documentation, and official technical guidance. Use credible secondary sources only to clarify practice; label them accordingly.
3. If browsing is unavailable, state precisely that the current edition or licensing could not be verified. Never present an unverified 'latest' version as confirmed.
4. For every materially important technical or edition-specific claim, cite a source inline with an actual working URL, title, publisher, and publication/update date when available. Include an organized source list at the end. Never fabricate citations, pages, clauses, certification bodies, or URLs.
5. Identify whether the authoritative text is free, partially available, paywalled, or licensed. Do not imply the complete official requirements have been read if only an abstract or overview is available.
6. Respect copyright and licensing: write original explanations and examples. Do not reproduce paywalled or copyrighted standard text, extensive official tables, checklists, diagrams, or proprietary assessment instruments without permission. If the reader needs normative text, link to authorized access.
7. Distinguish normative requirements ('shall') from informative recommendations, interpretation, common industry practices, and your own teaching examples. Never invent official obligations.
8. Explicitly distinguish: organization certification, individual certification/training credential, process capability assessment, third-party attestation, product conformity, regulatory approval, and self-assessment.
9. If no official maturity scale exists, state 'No official universal maturity levels'. Any pedagogical rubric must be clearly labeled 'illustrative teaching rubric - not an official assessment'.
10. Distinguish mandatory law from voluntary adoption and customer contractual requirements; specify jurisdiction and relevant dates when applicable.
11. When terminology or requirements vary by edition, use the verified edition consistently and clearly flag legacy differences.
12. If primary evidence is incomplete, make a narrower claim and mark the limitation. Prefer a trustworthy partial explanation over invented detail.

---

# 3. TEACHING STYLE AND FORMAT RULES

- Assume an intelligent absolute beginner who has never encountered the industry, workflow, or acronym.
- Write in plain professional English. Use short clear paragraphs and concrete examples; do not be condescending.
- Introduce every acronym at first use, then use it consistently.
- Explain a concept in this order: simple definition -> why it matters -> analogy -> workplace example -> practical consequence.
- Teach prerequisites before dependent concepts. Make expert sections progressively deeper without skipping foundations.
- Use one H1 heading, logical H2/H3 sections, descriptive subheadings, short lists, well-chosen tables, and easy-to-scan examples.
- Use tables for comparisons, vocabulary, roles, artifacts, decision criteria, timelines, indicators, and checklists where they improve clarity. Avoid tables for everything.
- Use genuinely instructive Mermaid diagrams throughout. Use flowcharts, sequence diagrams, state diagrams, mindmaps, or timelines only where meaningful.
- Make diagrams valid and readable: one diagram per fenced code block beginning with ```mermaid; standard Mermaid syntax; descriptive labels; around 5-12 main nodes; no invented official workflows. Include a one-sentence explanation after each.
- Prefer light, clean diagrams and limited color. Avoid fragile Mermaid syntax or complex theme dependencies; provide text fallback for readers whose site does not render Mermaid.
- Markdown must be WordPress-friendly: normal headings, tables, fenced code blocks; no raw scripts, complex HTML, or UI-specific components. Warn that Mermaid code fences need a compatible rendering plugin/theme/processor and will otherwise display as text.
- Label fictional company names, filled examples, hypothetical numerical targets, diagrams, and sample audit findings as illustrative. Do not present made-up cases as historical facts.
- Avoid empty headings, marketing fluff, repetitive definitions, and generic AI prose. Every section should teach something new.
- Produce the complete tutorial immediately. Do not substitute a table of contents, outline, preview, or promise of later work.

---

# 4. MANDATORY MASTER TUTORIAL STRUCTURE

Follow this instructional order. Rename sections naturally for the particular topic and merge genuinely redundant sections. For genuinely inapplicable concepts, say why briefly rather than invent content.

## PART I - WORLD BEFORE THE STANDARD: ZERO-KNOWLEDGE FOUNDATION

### 1. Article title and publication details
- Clear SEO-friendly H1: '[TOPIC]: Complete Beginner-to-Advanced Practical Guide'.
- One-sentence value proposition and reader outcome.
- Publication/as-of date, official edition verified, issuer/publisher, and source-verification status.
- SEO title (about 50-65 characters if possible), natural meta description (about 140-160 characters), suggested slug, and 4-8 meaningful search keywords. Do not keyword-stuff.
- Brief 'Who this guide is for' and 'What you will build/learn'.
- Table of contents with major sections.

### 2. The surrounding world explained from zero
Before naming detailed topic concepts, explain the real-world ecosystem in which it exists.
- What industries, products, teams, systems, processes, customers, or risks are involved?
- What happens in this world on a normal workday?
- Who does the work, who depends on the outcomes, and what can go wrong?
- What did organizations do before approaches like this existed?
- Introduce 1-2 everyday analogies and a short representative workplace story.
- Show one simple Mermaid domain-context diagram illustrating people, systems, work, and outcomes.

### 3. Beginner vocabulary bootcamp
- Table of 15-25 topic-specific foundation terms: Term | Plain-English meaning | Simple analogy | Example in work.
- Include general terms when relevant: standard, requirement, process, procedure, policy, control, risk, asset, stakeholder, lifecycle, audit, assessment, objective evidence, work product, traceability, verification, validation, nonconformity, corrective action, maturity, capability, certification, attestation, accreditation.
- Clarify common confusing pairs (e.g., verification vs. validation; compliance vs. maturity; risk vs. issue; policy vs. procedure), but only when relevant.
- Include 5 short check-your-understanding questions with answers.

### 4. The original problem
- Explain pain points WITHOUT the topic, using an illustrative team/project.
- Compare 'without a structured approach' vs. 'with this approach' in a practical table.
- Identify who benefits, business objectives, failure modes, and measurable outcomes.

## PART II - UNDERSTAND THE SELECTED TOPIC

### 5. What exactly is [TOPIC]?
- First: a one-sentence beginner definition.
- Second: an accurate technical definition in your own words.
- Identity card table: official title, acronym, issuing organization, category/type, current verified edition, publication date, geography, industry, users, scope, status, cost/access considerations, certification/assessment position, and official URL.
- What this topic IS; what it is NOT; common misconceptions.
- Brief history and evolution only when important and verified.

### 6. Why it exists, who uses it, and when to choose it
- Business/engineering problem it solves; drivers and real benefits; limitations and trade-offs.
- Who should use it vs. who may not need it.
- Applicable product, service, process, organizational, supplier, or regulatory scope.
- Three scenarios: a tiny team, a growing organization, and a complex/regulated organization (fictional illustrations).
- Optional decision table: adopt now, later, or choose another approach.

### 7. Core philosophy, principles, building blocks, and 'features'
- Describe what the approach expects people to DO, not software-like 'features' where inappropriate.
- Core principles and benefits, key components, main process/control/practice groups, and how they work together.
- Table: Component/Concept | Beginner meaning | What a team actually does | Output/evidence | Benefit.
- Basic vs. advanced practices when this distinction is meaningful, clearly non-official unless verified.
- Cover official structure at an appropriately high level without reconstructing copyrighted normative text.

### 8. How it works: conceptual architecture and operating model
- Explain 'architecture' appropriately: team/process/governance architecture for management frameworks, engineering lifecycle architecture for safety standards, control/evidence flow for security standards, and product/system architecture only when relevant.
- Roles, decision rights, inputs, activities, outputs, feedback loops, reporting, escalation, and dependencies.
- Mermaid conceptual architecture diagram and a second Mermaid end-to-end workflow.
- Walk through both diagrams step by step using human-readable explanations.
- Show where requirements, policies, risks, designs, implementation, tests, reviews, metrics, and retained evidence connect, as applicable.

### 9. Official levels, requirements, controls, domains, and lifecycle stages - IF applicable
- Present exact official level/area/domain terminology only where verified.
- Explain how each dimension works, what it measures, how achievement is determined, and what evidence is useful.
- Table of official levels or domains when applicable, with a caveat that the original authoritative text governs.
- If no official levels, explicitly say so. Do not manufacture a maturity scale.
- Distinguish process capability, organizational maturity, risk tiers, assurance levels, integrity levels, severity classes, and compliance statuses.
- For standards families, explain which part addresses which concern and indicate the recommended entry point.

### 10. How this topic relates to adjacent approaches
- Compare with 4-8 nearest or complementary standards/frameworks, selected for actual relevance.
- Table: Alternative | Main purpose | Key difference | Overlap | Works together? | Choose when.
- Explain at least one example of combining two approaches without double-counting or claiming equivalence.
- Include a Mermaid relationship/mapping diagram when it adds value.
- Never confuse a regulation with a voluntary standard, or a process-assessment model with a development methodology.

## PART III - REAL PRACTICE: FROM THEORY TO A WORKING EXAMPLE

### 11. One realistic running case study
- Create ONE fictional but realistic company/project appropriate to the topic. Reuse it consistently for the remainder of the guide.
- Provide business situation, product/service, team size/roles, existing process, problem statement, constraints, stakeholder needs, baseline, desired outcomes, and risks.
- Choose details realistic for the industry, not arbitrary buzzwords.
- Include a scope table and explicit assumptions. Do not imply the project is an actual historical case.

### 12. End-to-end walkthrough of the entire lifecycle
For this running case, demonstrate the operational journey from start to improvement:
1. Identify scope, stakeholders, context, and obligations.
2. Define objectives and responsibilities.
3. Perform a baseline assessment or gap analysis, as suitable.
4. Prioritize risks, work, and expected results.
5. Define the process/controls/practices or technical requirements.
6. Execute in a realistic team workflow.
7. Produce and review work products/evidence.
8. Verify, validate, measure, or inspect outputs.
9. Resolve findings, exceptions, defects, or nonconformities.
10. Review results and drive continual improvement.

For every step, provide: WHY | WHO | INPUTS | WHAT TO DO | OUTPUT | HOW TO CHECK | COMMON ERROR.
Explain explicitly if the actual framework's real workflow differs from this generic teaching sequence. Never claim this generic sequence is the official standard's mandatory process.

### 13. Deliverables and evidence explained
- Map practices to real documents, records, decisions, tickets, tests, logs, approvals, or retained evidence.
- Evidence table: Activity | Owner | Example deliverable | Minimum useful contents | Reviewer | Verification method.
- Show the difference between a document that merely exists and evidence of a process actually being performed.
- Include a simple traceability chain where relevant (need -> requirement -> design -> implementation -> verification -> evidence -> finding).
- Show example identifiers, timestamps, versioning, approval status, and ownership where practical.

### 14. Ready-to-copy working templates
Provide a mini toolkit using real Markdown tables or simple CSV-style structures:
- Scope and stakeholder register.
- Roles and responsibilities / lightweight RACI matrix.
- Baseline/gap analysis worksheet.
- Risk/issue/action log.
- Evidence/work-product or control tracking register.
- KPI/measurement dashboard definition.
- Improvement/corrective-action plan.
- Any topic-specific artifact that genuinely matters (for example requirement traceability matrix, hazard log, threat model, audit programme, test plan, service catalogue, project risk register, model inventory).

Show at least TWO completed, realistic template examples using the running case, not just blank headings. Clarify they are educational and may require tailoring to contractual or licensed authoritative requirements.

### 15. Beginner lab: perform the first useful activity
Include a real 30-60 minute beginner activity using free/local materials where possible.
- Lab objective and prerequisites.
- Setup and sample inputs included within the article.
- Numbered tasks with exact steps and sample data.
- Expected output (a table, record, diagram, checklist, or small configuration).
- How to inspect/verify the result.
- Common mistakes and troubleshooting.
- Answer key or completed example.

### 16. Intermediate lab: apply the workflow across a project
Include a 1-3 hour exercise using the running case, with multiple roles, linked artifacts, a review cycle, and measurable output. Provide sample data, task instructions, success checks, and a model answer.

### 17. Advanced lab: handle an imperfect, realistic situation
Include a realistic incomplete/contradictory example: missing traceability, conflicting requirements, unmitigated risk, poor evidence, weak control, process bottleneck, or an equivalent problem appropriate to the topic.
- Ask learner to identify and fix issues, explain trade-offs, record decisions, and verify improvement.
- Include at least one negative test or failure scenario.
- Clearly distinguish educational mock assessments from official audits/appraisals.
- Provide a sample resolution and explanation.

### 18. Capstone project
- Define a substantial end-to-end assignment producing a coherent package of artifacts.
- Provide scope, roles, tasks, staged milestones, acceptance criteria, deliverable checklist, and pass/fail test examples.
- Include an evaluation rubric with scores that are labeled 'educational rubric - not the topic owner's official scoring'.
- Make it feasible in a small fictional team and explain how an enterprise would adapt it.

## PART IV - IMPLEMENT, MEASURE, ASSESS, AND IMPROVE

### 19. Adoption roadmap
- Provide a phased practical roadmap for initial adoption: days 1-7, 8-30, 31-60, and 61-90, only as an illustrative implementation-planning structure.
- Table: Phase | Focus | Actions | Owners | Outputs | Success criteria | Risks.
- Explicitly explain that formal certification, high maturity levels, or regulator approval may require far longer and may not apply.
- Distinguish minimum viable adoption, operationalization, independent review, and long-term improvement.

### 20. Roles and governance
- Identify sponsors, process owners, practitioners, quality leads, assessors, auditors, suppliers, and reviewers only as relevant.
- Provide sample RACI and escalation paths.
- Show governance meeting cadence, decision rights, exception management, and simple status reporting.

### 21. Metrics and proof of improvement
- Choose 5-10 measurable indicators with definitions, units, calculation formulas (if appropriate), collection frequency, source, owner, leading/lagging classification, and how to interpret them.
- Explain that targets in examples are hypothetical unless prescribed by authoritative sources.
- Present a worked mini dashboard with 2-3 periods, demonstrating improvement and trade-offs; don't use arbitrary official thresholds.
- Discuss unintended consequences and metric gaming.

### 22. Assessment, audit, certification, or independent verification - correctly adapted
- Say explicitly which routes actually exist for this topic: self-check, internal assessment, accredited certification, formal appraisal, third-party attestation, product assurance, customer audit, or regulatory approval.
- Explain the difference in plain English.
- If the topic has no formal certification or maturity rating, say so and provide a truthful alternative for evaluating implementation effectiveness.
- Describe scope, evidence, interviews, observed implementation, findings, closing actions, and independent bodies ONLY where applicable.
- Never guarantee a certificate, rating, passing score, recognition, or regulatory acceptance.
- If presenting sample findings, label them fictional and educational, not official assessment results.

### 23. Tools and real workflows
- Distinguish concepts that can be implemented with documents/spreadsheets from those needing specialist enterprise tooling.
- Table: Need | Free/minimal option | Enterprise/team option | Artifact or evidence produced | Trade-off.
- Mention actual tools only when relevant and verify time-sensitive product capabilities or licensing before stating them.
- Do not imply software purchase is mandatory unless a real requirement says so.
- Where a command or configuration is truly useful, provide reproducible, safe, complete examples with prerequisites, expected output, and rollback/cleanup instructions; otherwise use nontechnical exercises.

### 24. Real-world use cases and anti-patterns
- At least 5 distinct practical uses, including an individual/team case, a multi-team case, and where applicable a regulated/supplier case.
- 8-12 common mistakes, why they happen, symptoms, corrective actions, and prevention methods.
- Show 'paper compliance' vs. actual effective implementation.
- Explain organizational culture, costs, limitations, training needs, and change management.

### 25. Certification and related professional learning - only if applicable
- Identify independently verifiable qualifications, training pathways, and relevant roles.
- Separate training certificates, professional qualifications, organizational certification, and assessment credentials.
- Do not invent exam length, question counts, fees, prerequisites, or official schemes.
- Provide study sequence for beginner, practitioner, implementer, and reviewer, without implying an unsupported credential.

## PART V - KNOWLEDGE CHECK AND PUBLISHING PACKAGE

### 26. Assessment and answer key
- At least 12 questions: 5 foundation, 4 application, and 3 scenario-based questions.
- Mix multiple-choice and short-answer only when useful.
- Include correct answers, explanations, and references to relevant tutorial sections.
- Include a practical readiness checklist for implementing the topic on a real project.

### 27. Frequently asked questions
- 10-15 questions beginners actually ask, answered concretely.
- Cover scope, who needs it, legal status, latest edition, certification/assessment, cost/access, timelines, first steps, integration with related standards, small-team use, and common confusion when relevant.
- Avoid answering with generic unsupported yes/no statements.

### 28. Glossary and quick reference
- Consolidated glossary with relevant acronyms and short meanings.
- One-page cheat sheet: what it is, why it matters, core parts, standard workflow, key artifacts, roles, assessment route, and beginner's first five actions.
- Final 'what you should now be able to do' checklist.

### 29. Authoritative resources and verification log
- References table: Document/source | Publisher | Edition/date | Official URL | What it verifies | Access limitations.
- Identify secondary explanatory sources separately from authoritative publications.
- Provide 'verified as of [actual date]' and 'not verified / limitations' explicitly.
- If a previous edition was superseded, state what changed only when verifiable.
- Never invent live links or cite sources you have not actually consulted.

### 30. Closing summary and next learning path
- Synthesize what the reader learned, using plain language and no marketing filler.
- Recommend 3-5 logically related next topics and explain in one line why each is next.
- Finish with a concrete 30-minute first action the learner can do today.

---

# 5. CONDITIONAL MODULES: DIFFERENT TOPICS NEED DIFFERENT DEEP DIVES

Select modules that genuinely fit. Add the topic-specific module AFTER the foundation and before the practical labs.

**For capability/maturity models (ASPICE, CMMI, TMMi, P3M3, etc.):** model dimensions; process areas; official capability vs maturity concepts; attributes and official level boundaries; objective evidence; appraisal scope; indicators; rating limitations; practice improvement cycle. Do not give blanket enterprise-level ratings when the model evaluates individual processes.

**For management systems (ISO 9001, 27001, 42001, 22301, etc.):** organizational context; interested parties; scope; leadership; policy; risks; objectives; operational controls; documented information; internal audit; management review; nonconformity; corrective action; continual improvement. Include topic-specific requirements only when verified. Do not mechanically copy ISO 27001 artifacts, such as the Statement of Applicability, into unrelated standards.

**For software/systems engineering and safety (ISO 26262, 21434, 21448, 12207, 15288, IEC 62304, DO-178C, etc.):** lifecycle and process interfaces; safety/security/quality responsibilities; requirements; architecture; hazard or threat analysis as appropriate; traceability; verification and validation; independence where relevant; configuration management; change control; release evidence; supplier integration. Do not equate ASIL, DAL, SIL, or other assurance levels with organizational maturity.

**For cybersecurity/security control and risk frameworks (NIST CSF, NIST 800-53, CIS, OWASP, etc.):** asset and risk context; threat model; control selection; implementation patterns; evidence; verification; exception handling; residual risks; continuous monitoring. Do not treat NIST CSF implementation tiers as a maturity certification system.

**For methodologies (Lean, Kaizen, Scrum, Kanban, Six Sigma, SRE):** principles, roles, ceremonies/cadences, flow, work items, metrics, worked examples, operational habits, feedback loops, and common misuse. Do not manufacture clauses or certificates.

**For governance, enterprise architecture, and ITSM (COBIT, ITIL, TOGAF, ISO/IEC 38500):** business outcomes; decision rights; governance vs. management; enterprise architecture views; service value flows; operating model; ownership; performance; value and risk alignment.

**For regulatory or assurance schemes (UN R155/R156, SOC 2, TISAX, CMMC):** legal/contractual context, applicability, scope, parties, effective dates, authorization/attestation/assessment routes, required evidence, dependencies, recognized assessor bodies, and common misconceptions. Separate official requirements from industry practice.

**For AI/data governance (ISO/IEC 42001, NIST AI RMF, ISO/IEC 42005, DAMA-DMBOK, DCAM):** AI/data inventory; system purpose; data provenance and quality; human oversight; model evaluation; lifecycle risk; transparency; impact assessment; accountability; monitoring; change management; incident handling.

**For industry initiatives and knowledge bases (CISQ, MITRE ATT&CK):** explain who maintains the initiative, what tangible resources it publishes, how to use them responsibly, and why they are not automatically a certifiable standard or organizational maturity model.

**For very broad standards families or grouped items (ISO/IEC 19770, IEC 62443, Automotive Core Tools):** give a family-level map, list major parts/components with their role, choose a documented beginner entry point, and avoid falsely treating the family as one standalone requirement set.

---

# 6. DIAGRAM QUALITY GATE

For a substantial topic, aim for 4-6 useful Mermaid diagrams, not decoration:
1. Domain/world context (who interacts with what).
2. Conceptual architecture or operating model (major components and roles).
3. Core lifecycle/process flow (start to finish, with real decision points).
4. Evidence/traceability or assessment flow (only where appropriate).
5. One realistic scenario-specific workflow or sequence.
6. Continuous improvement loop (when applicable).

Example generic template (replace every node with topic-specific content):

```mermaid
flowchart LR
    A[Business need] --> B[Define scope]
    B --> C[Plan practices]
    C --> D[Perform work]
    D --> E[Collect evidence]
    E --> F{Meets criteria?}
    F -->|Yes| G[Review outcomes]
    F -->|No| H[Correct gap]
    H --> D
    G --> I[Improve process]
    I --> B
```

Never label a teaching illustration an official, mandated workflow unless the publisher explicitly specifies that workflow. Use quoted node labels where punctuation may affect parsing. Avoid excessive nodes, unsupported Mermaid keywords, raw HTML, or diagrams that cannot be understood without accompanying text.

---

# 7. PRACTICALITY AND QUALITY ACCEPTANCE TEST

Before returning the tutorial, privately review these acceptance criteria and fix all failures:

[ ] A beginner can understand the industry context before the standard is introduced.
[ ] Every required term is explained before use.
[ ] The topic's exact type, scope, publisher, edition, and verification status are accurate.
[ ] No invented official maturity level, certification, obligation, process, clause, or scoring rule.
[ ] The distinction between verified requirements, common practice, and illustrative examples is unmistakable.
[ ] The tutorial contains an everyday analogy and an industry-relevant running case study.
[ ] The topic's actual components and value are explained, not merely listed.
[ ] Workflows, roles, inputs, outputs, and evidence are connected in practical steps.
[ ] At least 3 valuable Mermaid diagrams are present when the topic supports them; syntax is plausibly valid.
[ ] There are comparisons with truly relevant adjacent approaches, not random entries.
[ ] At least 2 completed samples and reusable templates are present.
[ ] Beginner, intermediate, advanced, and capstone exercises have realistic inputs and answer keys.
[ ] An assessment/assurance section accurately describes applicable routes, or explains their absence.
[ ] Metrics, ownership, improvement, and a phased implementation plan are practical.
[ ] Claims with version or legal sensitivity are backed by reliable current official references.
[ ] Copyright restrictions and proprietary official texts are respected.
[ ] The Markdown is clean and realistically publishable on WordPress.
[ ] The final output is an actual complete guide, not a plan for a guide.

**FINAL INSTRUCTION:** Now write the complete GOLD STANDARD master tutorial about `{{TOPIC_NAME}}`. Begin with the zero-knowledge domain foundation and continue through the full instructional journey. Do not ask for confirmation, do not invent authority, and do not stop after producing an outline. Optimize for actual comprehension and hands-on application, not maximum word count.