← Meridian Casebook

Stable Casebook Rules

These rules keep Meridian coherent across Chapters 1–17 rather than turning the laboratory into disconnected tutorials.

1. Keep stable IDs. Systems, datasets, defects, decisions, and incidents retain stable identifiers so evidence can be reused across chapters.
2. Data has a business-process origin. Every dataset blueprint states which process/system produced it and who uses it.
3. Business meaning ≠ technical storage. A PostgreSQL table does not automatically become the authoritative source of a business definition.
4. No tool “solves governance.” Tools expose, enforce, automate, or document decisions made through Data Management processes.
5. Preserve earlier states. When later labs improve Meridian, preserve the original state or a reproducible defect-injection script so maturity and before/after analysis remain possible.
6. Synthetic only. Never use real personal/employer data; never commit credentials/secrets.
7. Carry decisions forward. If Chapter 3 establishes a governance decision or Chapter 10 establishes survivorship logic, later work should reuse it unless a scenario deliberately changes it.
8. Separate DAMA from Meridian. DAMA controls the concept; Meridian is an instructional implementation. Label lab-specific choices rather than presenting them as universal requirements.

Decision continuity

For important changes, create a stable decision record with:

• decision ID;
• issue/trigger;
• options considered;
• decision;
• rationale;
• owner/approver;
• effective date;
• evidence/source links;
• affected systems/domains/labs;
• conditions that would cause reconsideration.

Why this matters

Persistent state makes later chapters more realistic. Data Management rarely begins from a clean slate; governance, architecture, definitions, data quality, security, integration, master data, metadata, and change decisions accumulate and interact.

Source: Meridian Commerce Group Enterprise Data Management Casebook, Section 7.