Goal
Model a concrete manufacturing-IT problem: changes to test master data can silently break downstream analytics, alerting, traceability, and customer reporting.
Core layers
- Reference layer — master registry and downstream asset definitions
- Scenario layer — seeded change requests for rename, remap, delete, add, and owner updates
- Impact analysis layer — deterministic rule engine that emits impact findings
- Governance layer — release gates across traceability, analytics, alerting, customer reporting, and ownership readiness
- Approval layer — required/advisory owner workflow
- Recovery layer — rollback instructions with success signals
- Benchmark layer — seeded expectation checks across representative scenarios
- Exception-management layer — queueing and remediation hints for blocking/review items
- Owner-impact layer — blast-radius summaries for accountable teams
- Export layer — markdown, JSON, and signed zip bundles
- Presentation layer — Streamlit review surfaces
Why deterministic rules
This project is intended to be independently reviewable. Deterministic rules are preferable because they:
- produce repeatable outputs,
- make seeded scenario tests meaningful,
- let reviewers inspect why the gate blocked a release,
- avoid dependence on secrets or external inference services.
Extension path
A future version could replace static registry definitions with database-backed lineage and real pipeline metadata, but the current system is intentionally self-contained and testable.