dv-stage

Design or review DVOS staging views ensuring metadata-only content and hashkey/hashdiff correctness.

35|7|Updated Apr 14, 2022
One-click install
npx skills add https://github.com/PatrickCuba/the_data_must_flow --skill dv-stage
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dv-stage
Source: https://github.com/PatrickCuba/the_data_must_flow/tree/main/dvos-skills/skills/dv-stage
Command: npx skills add https://github.com/PatrickCuba/the_data_must_flow --skill dv-stage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Design or review a DVOS staging view — source staging or BV staging, focusing on metadata columns, hashkey/hashdiff computation, and enforcing the no-business-logic rule.

Core Features & Use Cases

  • Understand and apply the canonical staging doctrine (hard vs soft rules) to ensure staging remains metadata-only and free of business logic.
  • Design, validate, and troubleshoot source staging views (stg_{source_badge}{source_file}), BV staging (stg_bv{concept_name}), and secondary staging constructs (stg_ef_, stg_st_, stg_rt_, stg_xt_) to support accurate hashing and change detection.
  • Correctly implement dv_hashkey_* and dv_hashdiff_* columns, adhere to data-type inheritance rules, canonical naming, and encoding standards for hashing across multi-tenant or single-tenant configurations.

Quick Start

Design or validate a staging view by summarizing required metadata, hashing rules, and the hard/soft rule boundaries for source and BV staging.

Frequently Asked Questions about dv-stage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a Data Vault staging view with correct hashkey and hashdiff computation?

Data Vault staging views require metadata-only columns with computed dv_hashkey and dv_hashdiff values, strict data-type inheritance, and safe hash encoding to ensure accurate change detection across single or multi-tenant configurations.

What is the no-business-logic rule in Data Vault staging?

The no-business-logic rule in Data Vault staging mandates that staging views remain strictly metadata-only, enforcing canonical guidelines (DV-STG-001 through DV-STG-010) to prevent any business transformations from corrupting hashkey or hashdiff computations.

How do I handle tenant columns when building BV staging views?

Handling tenant columns in BV staging views requires correct BK and tenant handling configurations to ensure multi-tenant isolation, utilizing precise data-type inheritance and canonical column naming for secure hash encoding.

Does Data Vault staging require special hash encoding for CHAR data types?

Data Vault staging requires special safe hash encoding rules for CHAR data types, utilizing binary digests and canonical column names to ensure consistent hashkey and hashdiff computation across source and BV staging scenarios.

What is the difference between source staging and BV staging views?

Source staging views (stg_{source_badge}_{source_file}) extract raw data, while BV staging views (stg_bv_{concept_name}) and secondary staging constructs prepare concepts, both requiring strict adherence to canonical DV staging guidelines for hashing and metadata.

When should I use secondary staging constructs in a Data Vault architecture?

Secondary staging constructs like stg_ef_*, stg_st_*, and stg_rt_* are used to support accurate hashing and change detection for complex relationships, requiring validation against canonical DV staging guidelines to maintain metadata-only integrity.