Skip to main content

DPCH03 — Declarative

“Defined via Declarative Specification”

What DPCH03 is really asserting​

DPCH03 is not asserting that:

“The data product is defined using YAML, JSON, or config files.”

It is asserting that:

The Data Product Owner declares the data product using business-native intent, assertions, and policy choices — not technology configuration — and the platform fully compiles that declaration into technical artifacts.

Declarative here means intent-declarative, not technology-declarative.

The Essence (HDIP + Data Mesh Interpretation)​

A Data Product is declarative if and only if:

  1. The declaration is authored by the domain, not engineers
  2. The declaration uses business constructs, not technical ones
  3. The declaration is complete enough for the platform to compile execution

If the “declarative spec” still requires the domain to think in pipelines, schemas, or tools, DPCH03 is not met, even if YAML is involved.

Positive Criteria — When DPCH03 is met​

DPCH03 is met when all of the following are true:

1. The declaration expresses what, not how​

Valid declarative elements include:

  • product purpose and audience
  • business entities, events, and measures
  • business definitions and semantics
  • quality and freshness assertions
  • policy posture (e.g. sensitivity, residency, access intent)
  • expected usage patterns

Invalid declarative elements include:

  • joins, transformations, and pipelines
  • table schemas or storage layouts
  • compute engines or runtimes
  • orchestration logic

Those belong to the platform compiler.

2. The declaration is self-service and domain-authored​

The DPRO (or delegate):

  • authors or updates the declaration directly
  • does not rely on engineers to “translate” intent
  • can evolve the declaration independently

The declaration is the product’s source of truth from the domain perspective.

3. Technical specifications are derived, not authored​

Behind the scenes:

  • DPDS, pipelines, infra, policies, and tests are generated
  • changes in business declaration recompile the product
  • the domain never edits generated artifacts

This mirrors how a content creator publishes without managing servers.

Negative Criteria — When DPCH03 is not met​

DPCH03 is not met if any of the following are true:

❌ Declarative spec is technology-centric​

Examples:

  • YAML that defines:

    • dbt models
    • Spark jobs
    • SQL statements
    • DAGs

  • “Templates” that require understanding data engineering

This is engineering-as-config, not declaration.

❌ Engineers author or own the declaration​

Examples:

  • Engineers write the spec “on behalf of” the domain
  • Domain reviews but cannot independently modify it
  • Spec lives in engineering repos owned by platform teams

This violates domain ownership.

❌ Policy and quality are embedded in code​

Examples:

  • Access rules hardcoded in pipelines
  • Quality checks written as tests by engineers
  • Policies implied by infrastructure choices

True declaration makes these explicit choices, not side effects.

Edge Cases (Important Guidance for Agents)​

Case 1: “Business-friendly YAML, but still technical”​

❌ Not met

Rationale:

  • YAML/JSON format alone is irrelevant
  • What matters is semantic level, not syntax

Case 2: “Low-code UI that produces technical specs”​

⚠️ Partial

Rationale:

  • Better than raw code
  • Still fails if users must reason about technical constructs
  • Acceptable only as a transitional state

Case 3: “Intent + assertions + policy choices only”​

✅ Met

Rationale:

  • Domain declares meaning and expectations
  • Platform compiles everything else
  • This is true declarative productization

Evidence Signals an Agent Should Look For​

Authoritative evidence:

  • Intent-based product descriptor
  • Business assertion model
  • Policy selection as explicit inputs
  • One-click regenerate/redeploy behavior

Supporting evidence:

  • Generated DPDS artifacts
  • Generated tests and pipelines
  • Clear separation between authored vs generated files

Red flags:

  • Domain-facing docs showing SQL/YAML examples
  • “Advanced” mode exposing pipelines
  • Editable technical templates in UI

How an AI Agent Should Decide​

Decision rule (simplified):

If the domain must describe how data is produced instead of what the data means and is expected to do, DPCH03 is not met.

Why DPCH03 Is Non-Negotiable​

Without DPCH03:

  • DPCH02 collapses into “self-service engineering”
  • scalability depends on domain technical skill
  • platform intelligence is never leveraged
  • governance becomes implicit and brittle

DPCH03 is what allows:

  • intent-driven automation
  • policy compilation
  • consistent governance at scale

Canonical Statement (for BPS)​

DPCH03 is satisfied only when a Data Product is defined through a domain-authored, intent-based declaration using business constructs and assertions, with all technical specifications fully derived and hidden by the platform.