A modular library of data design patterns for building AI-Native Data Products: self-describing data assets optimised for autonomous agent discovery and operation. The library is a set of independent, composable modules; assembling a chosen subset produces a particular kind of data asset.
The framework is split along one boundary:
design/: platform-agnostic standards. Written in logical types, capabilities, and invariants; no platform SQL. This is the single source of truth for what and why.implementation/{platform}/: platform-specific bindings (the concrete DDL, queries, and grants) that satisfy the design. Teradata is the current reference; new platforms are added as sibling directories, changing no design document.
The boundary is enforced automatically by the linter in tooling/validation/: a design document that leaks platform SQL fails the build.
ai-native-data-products/
├── design/ ← platform-agnostic standards (source of truth)
│ ├── core/ MASTER_DESIGN · DESIGN_LANGUAGE · ADVOCATED_STANDARDS · GLOSSARY
│ ├── modules/ domain · search · prediction · observability · semantic · memory
│ └── patterns/ temporal-lifecycle-metadata · object-placement ·
│ physical-storage · validation · access-layer
├── implementation/
│ └── teradata/ PLATFORM_PROFILE + modules/ and patterns/ bindings
├── tooling/
│ ├── validation/ the design linter (+ tests)
│ ├── catalogue/ generates corpus navigation from frontmatter
│ ├── evals/ validates a product design against the standards
│ └── compiler/ verifies a compiled skill package
├── examples/ worked products: fixed inputs for an end-to-end run
├── prompts/ how to use the standards
└── skills/ generated agent skills (gitignored)
Start here: design/core/MASTER_DESIGN.md (the blueprint), design/core/DESIGN_LANGUAGE.md (the notation everything is written in), and design/core/ADVOCATED_STANDARDS.md (the decisions a design must settle, and the recommended answer for each).
There is no single fixed architecture. Modules declare what they provide and require (each requirement [hard] or [soft]); a composition is valid when every hard requirement is met within it, and unmet soft requirements simply disable a feature. An AI-Native Data Product is the fullest composition, not the only one.
| Composition | Modules |
|---|---|
| Data Asset | Domain + Memory (documentation) + Access Layer |
| Traditional Data Product | Domain + Semantic + Observability (+ optional Memory) |
| AI-Native Data Product | all six modules + Access Layer |
| Search / Prediction extension | added onto an existing Domain |
See design/core/MASTER_DESIGN.md#4-compositions.
| Module | Purpose | Composition role |
|---|---|---|
| Domain | Authoritative business entities: the source of truth | Root; stands alone |
| Semantic | The discovery map: entity/column/relationship catalogue + orientation | Cross-cutting (soft) |
| Search | Vector embeddings and similarity search | Hard-depends on Domain |
| Prediction | Feature store and model outputs | Hard-depends on Domain |
| Observability | Events, quality, lineage; home of validation results | Cross-cutting (soft) |
| Memory | Agent runtime state and design memory (two facets) | Cross-cutting (soft) |
Cross-cutting concerns that modules apply (referenced, never restated):
| Pattern | Concern |
|---|---|
| temporal-lifecycle-metadata | Canonical temporal/lifecycle contract; half-open SCD2; point-in-time |
| object-placement | Where objects live and who may reach them (interface spec) |
| physical-storage | Object-storage layout beneath logical containers (interface spec) |
| validation | The validation-result contract and the agent stop/go gate |
| access-layer | The three roles and phased grants that make a product reachable |
Modules deploy in dependency order: only those the composition includes:
| Phase | Deploy (if present) |
|---|---|
| 1. Infrastructure | Memory, then Semantic |
| 1.5. Access (initial) | Create roles; grant read on Semantic + Memory |
| 2. Foundation | Domain, then Observability |
| 2.5. Access (extend) | Extend grants to Domain + Observability |
| 3. Enhancement | Search, Prediction |
tooling/validation/design_lint.py enforces the platform-agnostic boundary on design/, the frontmatter schema on every design document, and the decision rules across both hierarchies:
python tooling/validation/design_lint.py design implementationtooling/evals/brief_lint.py is the other half, and the one a designer uses: design_lint checks that the standards are well formed, brief_lint checks that a product design written against them is complete and conformant. Run it on a design brief before handing it to review:
python tooling/evals/brief_lint.py path/to/design_brief.mdtooling/catalogue/build_catalogue.py regenerates the navigation tables in the hierarchy READMEs from document frontmatter: run it after adding or renaming a document:
python tooling/catalogue/build_catalogue.pytooling/compiler/verify_skills.py checks that a compiled skill package kept everything the Skill Conversion Prompt required it to keep.
python -m unittest discover -s tooling/validation/tests- Platform-neutral by construction: enforced by the design/implementation split and the linter.
- Modular and composable: modules function independently and in any valid combination.
- Zero data duplication: modules reference Domain by identifier and join back; never copy.
- Self-describing: queryable metadata, standard patterns, and multi-hop discovery enable autonomy.
- Self-contained products: discovery and documentation stores live within the product.
- Design memory: every module records its decisions into Memory during design.
Copyright © 2025-2026 Teradata Corporation. Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0). See LICENSE.md for full terms.
Developed by Teradata's Worldwide Data Architecture Team, Field Technology Organization.