Skip to content

← 00B Internal Control Center

Scope, Difficulty, Governance & Maintenance Rules

Scope controls

In scope

  • Relational SQL and database concepts that directly support DMBOK understanding.
  • Python scripting and pandas for profiling, transformation, reconciliation, validation, and repeatability.
  • Local workstation setup and reproducibility.
  • Light BI and metadata platforms when a chapter gains real learning value.
  • Synthetic data and safe simulated incidents.

Out of scope unless a later explicit learning goal requires them

  • Production database clustering, high-availability engineering, deep tuning, and replication administration.
  • Application-development frameworks, algorithm-heavy computer science, and advanced package engineering.
  • Complex cloud architecture, Kubernetes, and enterprise CI/CD.
  • Tool certification or product-feature memorization disconnected from DAMA/Data Governance goals.
  • Real PII, real credentials, real employer data, or unsafe production experiments.

Career guardrail: Technology exists to make Data Management/Data Governance concepts visible and employable. The program must not quietly become a Data Engineering, DBA, software-engineering, cloud-platform, or Data Science curriculum.

Lab difficulty progression

Level Scaffolding Expectation
Guided Detailed steps and hints. Understand and explain each action.
Faded guidance Milestones/checks; fewer commands. Choose commands/techniques yourself.
Diagnostic Problem statement and evidence only. Investigate, identify cause, propose and perform repair.
Cross-domain Ambiguous real-world case. Identify lead/supporting DMBOK areas and sequence the response.
Independent capstone Business objective, constraints, acceptance criteria. Design the work, produce evidence, defend decisions.

How chapter labs are built safely

  1. Read the relevant DMBOK chapter completely and update the chapter blueprint.
  2. Identify concepts that benefit from doing, observing, deciding, or diagnosing.
  3. Select the minimum technology needed to make the concept visible.
  4. Check the Technology Competency Roadmap prerequisite gate.
  5. Create the Meridian business situation and synthetic data required.
  6. Write the lab without inventing DAMA rules; clearly label Meridian-specific design choices as lab-specific.
  7. Create the DMBOK debrief and source map from the same controlling chapter.
  8. Test all SQL/Python/database actions in the lab environment.
  9. Run learner-independence QC: can the learner explain and reproduce the core idea?
  10. Produce the visually formatted guide and companion PDF; inspect both.

Program governance

The current main-level architecture is:

  • Main 00 — START HERE: short navigation doorway.
  • Main 00A — DMBOK Mastery: source fidelity, chapter study, retrieval, exam preparation.
  • Main 00B — Meridian Applied Laboratory: applied practice, technology, company context, evidence, capstones.
  • Main 00C — Step-by-Step Execution: integrated learner sequence across 00A and 00B.
  • 00B Internal 00A: build/evidence/QC rules for the Applied Laboratory only.

Maintenance rules

  • Preserve stable company/entity identifiers so later labs can reuse prior evidence.
  • When a recurring learner mistake appears, add a targeted lab variation or break-it exercise rather than merely more reading.
  • Do not build every possible lab. Every lab must add a distinct learning function.
  • Update software versions, lab implementation, or Meridian defects when doing so improves learning, but do not silently change DMBOK meaning.
  • Place new material under the functional area it belongs to rather than creating unnecessary root-level peer folders.

Folder-separation rule

Inside 00B, use the established functional areas:

  • 00 — START HERE
  • 00A — Applied Lab Internal Program Control & Build Specification
  • 01 — Program Curriculum & Roadmaps
  • 02 — Meridian Company & Casebook
  • 03 — Technology Training & Competency Roadmap
  • 04 — Lab Environment, Data & Setup
  • 05 — Applied Labs
  • 06 — Evidence, Portfolio, Trackers & Templates
  • 99 — Reference Sources & Borrowed Patterns

Source-parity note

The current Drive Master Program Guide contains legacy wording in its later folder-architecture section that refers to Main 00 as though it were the integrated execution controller. That wording predates restoration of Main 00C. The GitHub working version follows the current canonical architecture above. The Drive Doc and companion PDF should be patched together during the later source-parity cleanup so they no longer contradict the active program structure.

Source: Applied Laboratory Master Program Guide Sections 6, 8, 9, 11, and 12; current main-program architecture established by 00/00A/00B/00C control documents.