des-gold-layer-design

To design Gold Layer datasets, you establish grain, aggregation, slicing, history/SCD behavior, freshness SLA, security handling, and lineage expectations mapped from trusted Silver inputs. This ensures downstream consumers receive correct, traceable, metric-consistent, contract-aware datasets without writing transformation SQL.

Gold Layer specification defines what consumer-ready datasets should exist, why they exist, and how they answer approved business questions and KPIs. You need it during Phase 11 Gold dataset or mart output design when serving direction, grain, and evidence readiness must be established.

You create explicit mappings from Business Questions, Requirements/KPIs, Data Product outputs, and trusted Silver datasets to Gold outputs. This mapping and traceability ensures downstream consumers get correct, metric-consistent datasets aligned with consumer serving direction.

No, this Gold Layer design process does not generate SQL, APIs, semantic internals, contracts in full, orchestration, or CI/CD code. It produces the Gold specification, Phase 11 support plan, evidence pack, revision notes, Done Gate result, and a safe handoff to Phase 12.

When any Gold boundary, grain, metric alignment, serving, contract expectation, or lineage decision cannot be safely inferred, the process triggers a HALT-on-unknown decision. This prevents moving too fast into implementation by forcing structured, evidence-backed design decisions.

Yes, this approach suits enterprise-scale data products requiring strict lineage by establishing explicit grain, aggregation, slicing, history/SCD behavior, freshness SLA, security/access handling, lineage expectations, and performance/cost considerations for consumer-ready Gold outputs.