View raw markdown

PRISM/D — Data Architecture Landscape Framework

Version: 1.0
Status: Active
Licence: CC BY-SA 4.0
Family: PRISM Frameworks

§ 1 Overview

Most organizations have data catalogs, governance policies, quality tools, and lineage diagrams — all in separate systems, all out of sync. PRISM/D is not another catalog. It's a landscape view of your data architecture: who owns what data, how it moves, where it lives, what governs it, and how those pieces connect.

PRISM/D treats data architecture the way PRISM treats enterprise architecture: as a living landscape committed to git, with explicit ownership, cross-cutting blast radius, and no orphaned artifacts.

What PRISM/D replaces (and what it doesn't)

The core assertion

Data architecture has exactly five concerns. Every data architecture decision maps to one of them.

1. Who owns what data — without domain ownership, data governance is theater
2. How data moves — pipelines, streams, and syncs are architecture decisions, not plumbing
3. Where data lives — platform choice has cascade effects on cost, compliance, and performance
4. What agreements govern exchange — schemas and SLAs are contracts; contracts have states
5. Who can access what, under what rules — access, retention, PII, lineage: the governance layer

These five concerns become five dimensions.

§ 2 Foundational Principles

Git-native (Architecture as Code)

Every PRISM/D landscape lives in a directory committed to source control. Data architecture decisions are first-class code — architecture as code applied to data: reviewed, versioned, merged. A schema deprecation, a domain ownership transfer, a new pipeline — all committed, all traceable.

Domain ownership as a first-class concept

Data Mesh taught the industry that domain ownership matters more than centralized data teams. PRISM/D operationalizes this: every dataset and data product has a declared owning team. Ownership determines SLA accountability, access policy authority, and incident response routing.

Data products over raw datasets

PRISM/D distinguishes raw datasets from data products — intentionally designed, versioned, and served datasets with a declared consumer, schema contract, and SLA. A raw claims dump is a dataset. A curated feature vector served to an AI model is a data product.

Lineage as architecture

End-to-end lineage — from source domain to pipeline to platform to consumer — is an architecture concern, not a metadata search result. PRISM/D captures lineage as explicit depends_on links, making blast radius traversal possible: change a source schema → see every downstream consumer at risk.

PII/SPII/PHI are first-class fields

Sensitive data classification isn't a compliance checkbox bolted on later. data_sensitivity, data_classification, and compliance_frameworks are required fields on any artifact that touches regulated data. The landscape renders them visually.

Schema version: "1.0"

§ 3 Five Dimensions — The Why

Each dimension answers exactly one question. Together they answer everything about a data architecture.

Why five, not more?

A sixth dimension always reduces to one of these five. "Data quality" belongs in Contracts (quality rules are contract terms). "Data observability" belongs in Contracts or Governance (breach detection is contract enforcement). "MDM" belongs in Domains (master data is a domain concern). "Reporting" belongs in Flows and Platforms. Every proposed sixth dimension was an artifact type within an existing dimension, not a new dimension.

Why not fewer?

Four dimensions loses the distinction between Contracts and Governance — they look similar but aren't. Contracts define the rules of exchange between producer and consumer. Governance defines who is allowed to exchange at all. Merging them hides accountability.

§ 4 Dimensions and Artifact Types

4.1 Domains

The question: What data exists and who owns it?

Domains define the bounded contexts of data ownership. A domain owns its source data, publishes data products for consumers, and is accountable for the SLAs of its products. This is the Data Mesh ownership model operationalized.

Key fields:

domain_type explained:

• source — originates data from a system of record (CRM, claims system, IoT)
• derived — computed from one or more source domains (feature store, ML features)
• aggregate — combines multiple domains into a unified view (customer 360, MDM)
• event — produces event streams rather than stored datasets

4.2 Flows

The question: How does data move from source to consumer?

Flows are the pipelines, event streams, and syncs that move data between domains, platforms, and consumers. They are architecture decisions: frequency, latency SLA, transformation pattern, and failure mode all matter.

Key fields:

4.3 Platforms

The question: Where is data stored and processed?

Platforms are the storage and compute systems that data moves through. Platform choice determines compliance scope, cost model, query capability, and operational complexity.

Key fields:

4.4 Contracts

The question: What agreements govern data exchange?

A contract defines the mutual commitment between a data producer and a data consumer. Schema version, quality thresholds, SLAs, and change management protocol are all contract terms. Contracts have states: a breached contract is an incident, not a footnote.

Key fields:

Contract state lifecycle:

draft → proposed → agreed → enforced
                         ↘ breached → (remediate) → enforced
                                    ↘ retired

4.5 Governance

The question: Who can access what, under what rules?

Governance covers the four enforcement mechanisms that protect data: access control, PII/SPII/PHI classification, retention rules, and regulatory compliance obligations. These aren't policy documents — they're architecture artifacts that link to specific domains, platforms, and flows.

Key fields:

§ 5 File Structure

data-architecture/
└── examples/
    └── acme-insurance/
        ├── .prism-d/
        │   └── config.yaml          # meta: org, product, temporal_state, as_of
        ├── domains/
        │   └── landscape.yaml       # data_domain, data_product artifacts
        ├── flows/
        │   └── landscape.yaml       # pipeline, event_stream, sync artifacts
        ├── platforms/
        │   └── landscape.yaml       # data_lake, warehouse, feature_store artifacts
        ├── contracts/
        │   └── landscape.yaml       # data_contract, sla, quality_rule artifacts
        └── governance/
            └── landscape.yaml       # pii_register, access_policy, retention_rule, lineage_map

config.yaml example

prism_d_version: "1.0"
organization: "ACME, INC"
product: "Enterprise Data Architecture"
domain: multi-domain
scope: enterprise
temporal_state: baseline
as_of: "2025-01-01"
active_dimensions: [domains, flows, platforms, contracts, governance]
data_mesh_topology: federated-with-central-platform
primary_cloud: aws

§ 6 The Data Governance Loop

Data governance isn't a checkpoint — it's a continuous loop connecting domains, flows, platforms, and contracts.

Domain declares ownership
    ↓
Pipeline moves data (Flow)
    ↓
Data lands on Platform
    ↓
Contract governs the exchange
    ↓
Governance enforces access, retention, and compliance
    ↓
Lineage map proves the chain → audit / incident response
    ↑
Schema change → contract version bump → consumers notified

Blast radius in PRISM/D:

Select a source domain → see every downstream flow, platform, and consumer that depends on it. Select a data contract → see which AI model, BI report, or analytics pipeline breaks if the schema changes. The depends_on field on flows, contracts, and governance artifacts creates the traversable graph.

§ 7 Data Product Model

PRISM/D distinguishes between data domains (ownership units) and data products (served outputs). A data product is:

• Intentionally designed for a specific consumer
• Versioned with a schema contract
• Served with a declared SLA
• Owned by a domain team that is accountable for its quality

This is the Data Mesh data-as-a-product principle made concrete. The data product artifact links:

• Its owning domain
• Its upstream dependencies (source datasets/pipelines)
• Its consumers (downstream models, reports, APIs)
• Its active contract

§ 8 Cross-Referencing

PRISM/D connects to the broader PRISM framework family:

Cross-referencing uses soft links — reference the ID of an artifact in the other framework. No circular imports, no tight coupling.

§ 9 PII / SPII / PHI Classification

All four sensitivity tiers are first-class in PRISM/D:

data_classification sets the baseline access tier:

§ 10 What PRISM/D Does Not Cover

§ 11 Glossary

Paper

Palakurthi, V.G. (2026). PRISM: Enterprise architecture frameworks for the source-first era.

• Site: https://prism-framework.org/
• PDF: https://prism-framework.org/PRISM_Framework_V1.0.pdf
• SSRN: https://ssrn.com/abstract=7037719
• Zenodo (DOI): https://doi.org/10.5281/zenodo.21325668