Skip to content

← 00B Internal Control Center

Evidence, Quality Control & Completion Standard

Evidence standard

Every completed lab must leave enough evidence to answer three questions:

  1. What existed before?
  2. What did you do or decide?
  3. What changed, or what did you learn?

Evidence should be lightweight but inspectable. A screenshot alone is rarely sufficient because it can hide the exact logic. Prefer source scripts, structured registers, before/after outputs, and decision records; use screenshots as visual support.

Evidence package

Evidence type Example What it proves
Executable logic sql/ch10/10_03_match_candidates.sql, SQL/Python/DDL/validation queries Exactly what operation or test was performed.
Configuration/object evidence Schema/table definitions, roles, view DDL What the environment actually contains.
Business artifact Policy, decision log, RACI, glossary, retention rule How a Data Management decision was operationalized.
Result evidence Query output, Data Quality score, reconciliation, dashboard What happened or what was discovered.
Interpretation Lab journal / DMBOK debrief That the learner understands meaning rather than only procedure.

Naming examples and rules

  • SQL: sql/ch10/10_03_match_candidates.sql — readable, commented where logic is non-obvious, rerunnable.
  • Python: python/quality/profile_customers.py — declares input/output and preserves raw input.
  • Result: evidence/ch13/dq_profile_before.csv — enough context to identify the producing script/run.
  • Diagram: diagrams/ch08_customer_lineage.png — every arrow has a defined meaning.
  • Decision: docs/DEC-014_customer_survivorship.md — issue, options, decision, rationale, owner/date.
  • Screenshot: evidence/ch07/access_denied.png — supportive evidence only; never a substitute for role/GRANT logic.
  • Lab journal: evidence/ch10/lab_debrief.md — DMBOK connection, surprises, errors, and independent rebuild result.

Technical QC

Before declaring a lab technically complete:

  • Run SQL/Python from a clean or rebuilt environment where practical; remove hidden dependencies on manual state.
  • Validate expected row counts, keys, and important constraints before and after the exercise.
  • Use deterministic synthetic data when the answer key depends on exact results.
  • For destructive SQL, test rollback/rebuild paths.
  • Avoid hard-coded personal paths when relative/project paths work.
  • Never place credentials or secrets in scripts, screenshots, or Git.
  • If the lab depends materially on a current software feature, verify that behavior against current official documentation.

DMBOK / source QC

  • Read the full controlling chapter before final lab writing.
  • Every DAMA-specific claim, role, process, metric, model, or terminology statement must be supported by that chapter or a clearly identified earlier DMBOK prerequisite.
  • Never present a Meridian schema, role name, tool feature, or implementation order as a DAMA requirement unless the source actually says so.
  • Apply the same question-resolution standard as the Mastery Lab: teaching questions receive immediate answer/explanation/source; true retrieval may hide answers only with a complete key.
  • Include an explicit DMBOK Debrief so the learner can articulate conceptual meaning after the tool work.

Independence QC

Pass test: If the learner can make the screenshot but cannot explain the query, table grain, business rule, source-to-target meaning, or governance decision, the lab is not complete.

Check Pass condition
Explain Can explain the concept and technical action without reading the step.
Modify Can change an input/condition and predict the effect.
Rebuild Can recreate the learning-critical portion from a blank file/editor.
Diagnose Can interpret a common failure or unexpected output.
Transfer Can choose the right approach in a changed Meridian scenario.

Visual / PDF QC

  • Use the established navy/teal/orange CDMP visual system and semantic emoji cues.
  • Use diagrams/screenshots only when they teach or verify something.
  • Keep commands/code in readable blocks with explanations adjacent.
  • Do not strand learner questions away from their answers in teaching sections.
  • Create the companion PDF only after content/technical QC.
  • Inspect PDFs for clipped code, broken tables, missing glyphs, orphan pages, and misplaced images.

Completion rubric

Dimension Not yet Working Mastered for this lab
DMBOK explanation Cannot explain without notes. Explains main concept with some prompting. Explains accurately, uses DAMA terminology, distinguishes nearby concepts.
Technical execution Copies without understanding. Can modify and rerun. Can rebuild core work from blank / troubleshoot common failure.
Interpretation Reports output only. Explains what output shows. Connects output to business impact, control, and DMBOK meaning.
Evidence Missing or screenshot-only. Basic saved artifacts. Reproducible logic + result + decision/context evidence.
Transfer Only recognizes exact tutorial. Handles changed input. Handles changed fact/scenario and selects the right approach.

Lab completion record

Record at minimum:

Field Record
Lab ID CH##_LAB_##
DMBOK chapter/source Chapter + section/page anchors
Technology blocks used T# list
Date completed Date
Scaffold level Guided / Faded / Diagnostic / Independent
Independent rebuild result Pass / Partial / Fail + note
DMBOK debrief score 0–3
Evidence folder/link Link/path
Mistakes / repair Notes
Next revisit Date/trigger

Source: Applied Laboratory Master Program Guide Sections 7 and 10; Applied Lab Execution, Evidence & QC Standard Sections 2–7.