Branch Post-Implementation Guide: Sunbelt Senior Insurance Client Hub and Source System Seed (Arrival and Identity)
Post-Implementation Guide
| Effort | Linear DIG-574; DIGEST Data Vault Implementation, increments 1 (arrival and identity), 1.1 (source system seed) and 2 (two sources: policies, roles, agents and satellites); branch claude_ws/dig-574-arrival-and-identity |
| Governed by | Standard: Branch Delivery Documents (K#12 I#27) |
| References | Design: Pilot item 270; implementation guide: Pilot item 272; test plan: Pilot item 271; QA certification: , open, QA not begun (design D-13 superseded on 2026-10-25) |
| Audience | Ray Serrano as reviewer; the author of increment 2; the course textbook’s part 1 |
| Author | Ray Serrano; edited by Claude, 2026-10-23 and 2026-10-25 |
| Classification | Internal — Data Management |
| Official copy method | Copied from this governed template by AGENTIC.DATASKILLS.KNOWLEDGE_ITEM_FROM_TEMPLATE; template SHA-256 recorded in the created item |
1. What shipped
| Planned deliverable | Shipped object or behavior | Repository evidence | Warehouse evidence |
|---|---|---|---|
| LANDING infrastructure | Database LANDING; schemas SUNBELT, STORAGE, CONFIG; tables CLIENT, DATA_FINDING (FINDER_NAME, FINDER_TYPE), BUILD_BASELINE; direct grants to CLAUDE_WS_ROLE | setup/infrastructure/landing.sql, commit c55b4ff | Database present; 3 tables visible to CLAUDE_WS_ROLE and, through secondary roles, to DV_ROLE |
| Two landing acts | 33 then 10 rows of Sunbelt Senior’s client file, planting paths P1 to P8 | setup/landing/sunbelt_client_load_1.sql and _2.sql, d6b2f5a | LANDING.SUNBELT.CLIENT: 43 rows, 41 distinct CRM row IDs |
| Packages | datavault4dbt fork (pinned); dbt_utils 1.4.1 from GitHub | dbt/packages.yml, dbt/package-lock.yml, 96a53dc | dbt deps: 2 packages installed |
| Ported macros and seed | landing_storage (default LANDING), merge_into (unchanged), capture_baseline and verify_build (measured set replaced), seed_build_expectations | macros/, seeds/, 9bf1ae3, ae65b16 | Baselines written to LANDING.CONFIG.BUILD_BASELINE for both acts |
| Source, staging view, hub | Source sunbelt.client with layer 1 and 2 tests; stg_sunbelt_client with hard rules D-4, D-5, D-6; client_h | dbt/models/staging, dbt/models/raw_vault, d4236cf, 06a39fe | DV.DEV_CLAUDE.STG_SUNBELT_CLIENT (view), DV.DEV_CLAUDE.CLIENT_H (36 rows) |
| Assertions, inspector, auditor | Three logic assertions; inspector_sunbelt_client_number_form; auditor_sunbelt_client_hub | dbt/tests/, dbt/models/inspectors, dbt/models/auditors, 858e6c8, 4ae7be9 | Two inspection findings, no audit finding in LANDING.CONFIG.DATA_FINDING |
| Source system seed (increment 1.1) | Seed seed_source_system (SSI, SYSTEM, ERROR) with its description and two built-in tests; client rows stamped with the code SSI; resolve assertion joining the seed. The first version built Data Vault reference objects (commits 29f7412, 8b111f7); they were removed when the design was simplified (D-21, commit 1fae2e7) | dbt/seeds, dbt/tests; commits 29f7412, 5958c9b, 1fae2e7 | DEV__DV__CLAUDE_WS.REFERENCE.SEED_SOURCE_SYSTEM, 3 rows |
| Development rebuild script and selectors (increment 1.1) | setup/scripts/dev_scoped_rebuild.sh, refusing any database not starting with DEV__; dbt/selectors.yml with v1_safe and qa_build | commits 29f7412, 9fc7f00 | Script tested on developer, QA and production names; selectors list 4 and 0 student objects as intended |
| Operational macros (increment 1.1) | dev_drop_orphans, land_act (the landing acts, from setup/landing, which is removed), vault_checks (Standard: Operations as dbt Macros, ) | dbt/macros/development, dbt/macros/operations; commits b184b8e, a8705e5 | Tested as recorded in the test plan’s coverage |
| Landing tables and acts (increment 2) | LANDING.SUNBELT.POLICY_SALE and LANDING.NORTHFIELD.POLICY; land_act extended to three tables with the 26 planted rows; the NFL row of the source system seed | setup/infrastructure/landing.sql, dbt/macros/operations/land_act.sql, dbt/seeds/seed_source_system.csv; commits beb49c9, 23b3d31 | DEV__LANDING__CLAUDE_WS: 14 sales rows and 12 carrier rows over two acts; LANDING: both tables present, empty |
| Staging (increment 2) | stg_sunbelt_policy_sale and stg_northfield_policy with D-24’s hard rules; the client list’s change hash for its satellite | dbt/models/staging; commit 23b3d31 | Views in DEV__DV__CLAUDE_WS.STAGING: 16 and 14 rows, each its landed rows and the two ghost records |
| Hubs and links (increment 2) | policy_h, insured_h and agent_h; client_h with the sales data as a second source; client_policy_l with the role as a dependent child key, insured_policy_l, agent_policy_l | dbt/models/raw_vault; commit 23b3d31 | Rows: policy_h 17, insured_h 9, agent_h 8, client_h 37; client_policy_l 15, insured_policy_l 11, agent_policy_l 19 |
| Satellites and version 1 views (increment 2) | client_sunbelt_s, client_policy_sunbelt_s, insured_northfield_s and policy_northfield_s, each with its version 1 view | dbt/models/raw_vault; commit 23b3d31 | Rows: 39, 15, 11 and 12 |
| Finders, facility and tests (increment 2) | inspector_sunbelt_policy_number_form; auditor_sunbelt_policy_hub and auditor_northfield_policy_hub; increment 1’s auditor corrected; the baseline facility over every vault table; the after-code layers 1, 2 and 4; 23 unit tests added for logic first left unproven | dbt/models/inspectors, dbt/models/auditors, dbt/macros/verification, dbt/tests; commits 23b3d31, e34dc13, 9ec06e9, 905955d, 105b22f, 94639b4 | LANDING.CONFIG.DATA_FINDING in the developer tier: three inspection findings and two retained audit findings (delta 25) |
| Release 1, The Acquired Book (Mary’s Q-9, Q-10, Q-11, Q-15), product definition | Semantic layer: MART.client_policy_fact, agent_policy_fact, policy_fact, finding_fact and time_spine_day, with seven metrics in the latest metrics spec (built before Data Product Design; rebuilt in release 2, DIG-588); D-40’s relationship tests; D-41’s case-sensitive hashdiffs; the QA identity split (DV_QA_DEPLOY with DV_QA_ROLE) and production’s (DV_DEPLOY with DV_ROLE) | Pull requests #2 to #7; main f48c24b, tagged v2026.10.1; setup/infrastructure/service_users.sql, dv_qa_role.sql, clone_landing_to_landing_qa.sql, reset_dv_qa.sql; developer_keys/DV_QA_DEPLOY.sql and DV_DEPLOY.sql | QA certified on all six gates; production built by Prod Build run 70403230861868 and identical to QA; served to Mary by DV Digest (DIG-583), the tower’s connector as the interim production connector |
2. Verified live output
| Verification | Environment and clock | Result | Evidence |
|---|---|---|---|
| Hub rows and client keys | DV.DEV_CLAUDE, 2026-10-23 02:34 UTC | 36 rows, 34 client keys (design expects 36 and 34) | SELECT COUNT(*), COUNT_IF(rsrc = ‘SUNBELT.CLIENT’) FROM CLIENT_H |
| First sightings | same | 30 keys at the act 1 load time; A-1031, A-1032, A1007, A-01008 at act 2 | GROUP BY ldts on CLIENT_H |
| Zero key ownership | same | The all-zeros key belongs to the SYSTEM ghost record | assert_client_h_ghost_keys_belong_to_ghosts passes |
| Findings | LANDING.CONFIG, 02:34 UTC | Two inspection findings (A1007, A-01008); no audit finding | SELECT FROM DATA_FINDING |
| Build verification | act 2, 02:33 UTC | LOOKOUT, zero warnings; CLIENT_H 32 to 36; inspection findings 0 to 2 | dbt run-operation verify_build |
| Baselines B-1, B-2 | 02:34 UTC | The three exploratory objects remain; STUDENT_H still 5 rows | SELECT on DV.INFORMATION_SCHEMA.TABLES and STUDENT_H |
| Record sources, increment 1.1 | Workstation DEV__DV__CLAUDE_WS, 2026-10-23 18:2x UTC | Client hub: SSI 34, SYSTEM 1, ERROR 1; none SUNBELT.CLIENT; resolve assertion passes | SELECT RSRC, COUNT(*) FROM CLIENT_H GROUP BY RSRC |
| The live rename | same | SSI’s row changed between two commits of the seed (29f7412 as acquired; 5958c9b Sunbelt Senior client file, owner Digest Insurance Distributors); every client hub row still carries SSI | git log of the seed; SELECT RSRC, COUNT(*) FROM CLIENT_H |
| Probe Q-4 | same, after the simplification | Every client hub row names its source: 34 Sunbelt Senior client file; ghosts the vault itself | Client hub joined to the source system seed; vault_checks |
| Ray’s environment | DEV__DV__RAYSERRANO (dbt Cloud, v1), 2026-10-23 18:3x UTC | Client hub SSI 34, SYSTEM 1, ERROR 1, matching the workstation | Ray’s query |
| The policy as the meeting point (increment 2, probe Q-6) | DEV__DV__CLAUDE_WS, 2026-10-25 11:1x UTC | NF-100007 has one client_policy_l row, one insured_policy_l row and one agent_policy_l row; Irene Garrity stays two keys, A-1007 and NLI-55007, joined only through the policy | Each link joined to policy_h on NF-100007 |
| Versions (increment 2) | same | NF-100003 has two versions in policy_northfield_s (status IF, then LP); NLI-55008 two in insured_northfield_s (address in letter case only) | GROUP BY parent key HAVING COUNT(*) > 1 on each satellite |
| Roles and agents (increment 2, probe Q-5) | same | client_policy_l roles: owner 9, insured 3, payor 1; A-1010 owner and insured on NF-100010; NF-100011 holds two agent rows, the sources disagreeing (path LA2) | GROUP BY role; agent_policy_l joined to policy_h |
| Findings (increment 2) | same | Inspections: A1007, A-01008, NF100009. Audits: the two findings of the auditors’ first versions, retained (delta 25); the current auditors write none | SELECT FROM DATA_FINDING GROUP BY finder |
| Build verification (increment 2) | same, commit 94639b4 | Full build 129 of 129; verify_build: 5 named warnings, no lookout: three rebuilds over unchanged acts and two audit expectations reading the retained findings | dbt build; dbt run-operation verify_build |
3. Test outcome
| Test scope | Planned | Passed | Failed | Disposition or evidence |
|---|---|---|---|---|
| Layer 1 built-ins | 6 | 6 | 0 | Two source not-null tests, hub unique and not-null; increment 1.1: the source system seed’s code unique and not-null |
| Layer 2 expectations | 3 | 2 | 0 | Compound uniqueness (dbt_utils) and the source row count (singular test); the hub row count was not built as a test and is read by the verification queries instead (delta 2) |
| Layer 3 unit tests | 12 | 12 | 0 | P7 red at 02:11:15 UTC on d4236cf (blank client numbers hashed to 9d4568c0…, a real key), green at 02:13:59 after D-4; increment 1.1: R1 to R3 pass on Fusion, written after their models, so characterization tests rather than a red-to-green cycle (delta 11) |
| Layer 4 logic assertions | 4 | 4 | 0 | Increment 1 added the ghost-key assertion after delta 5; increment 1.1 added the resolve assertion, which caught delta 9 before passing |
| Layer 5 inspector | 1 | 1 | 0 | Two findings, as specified |
| Layer 6 auditor | 1 | 1 | 0 | No finding, as specified |
| Layer 7 semantic surface | not applicable | No semantic models in the repository | ||
| Full build, act 2 | 26 nodes | 26 | 0 | dbt build, 02:33 UTC |
| Full build, increment 1.1 | 30 nodes | 30 | 0 | dbt build on the workstation after the simplification (38 before it, with the reference objects) |
| Increment 2, layer 1 | 14 | 14 | 0 | Written after the code from the branch’s diff (commit 905955d): LOADED_AT not null on both new sources; unique and not null on the hash keys of the six new hubs and links |
| Increment 2, layer 2 | 3 | 3 | 0 | The grain of each new source; staging keeps every landed row, a source query against a target query |
| Increment 2, layer 3 | 62 | 62 | 0 | 39 written first: red at 01:12 UTC on beb49c9 (seven for their content reasons, four setup errors in increment 1’s client_h tests), green on 23b3d31. 23 added on 2026-10-25 (Ray, answer 1a): each red for its content under a planted defect, then green (delta 24) |
| Increment 2, layers 4 to 6 | 1 new and 1 rewritten assertion; 1 inspector; 2 new auditors and 1 corrected | All pass | 0 | assert_increment_2_link_hub_keys_exist; the resolve assertion reads every hub and link; NF100009 inspected; the auditors’ false findings reduced to unit tests A1 to A6, red, then fixed (delta 21) |
| Full build, increment 2 | 129 nodes | 129 | 0 | dbt build on the workstation at 94639b4 |
| D-40, layer 1 relationship tests | 4 | 4 | 0 | One per satellite, to its parent; each passes on the development tier, and rel_client_sunbelt_s_hk_client_h, run read-only with a planted orphan key, returns that row. Full suite on 2026-10-26 at commit 5d5c59d: 108 of 108 pass, 34 data tests and 74 unit tests (delta 27) |
| D-41, layer 4 case-only assertion | 1 | 1 | 0 | Passes on the development tier on v2 and on dbt v1 1.12.6; run read-only against QA’s upper-cased staging, it returns Martin Lowe’s “12 ELM ST” pair. Both engines compile all four hashdiffs case-sensitive with the root setting. Full suites on 2026-10-26: v2 109 of 109, v1 QA selection 58 of 58 (delta 29) |
Finance workbook delivery and UAT evidence
For finance reporting branches, record delivered workbook revision/location, reporting period, repository generation script, query/build references, technical reconciliation evidence and consumer acceptance or pending cases under K#12 I#27. Otherwise state NA with a reason.
Not applicable: this branch is not a finance reporting branch.
4. Deltas from the plan
| Delta | Planned | Actual | Why | Canonical document or standard updated |
|---|---|---|---|---|
| 1 | Three LANDING roles, run by Ray (guide G-2) | No roles; SYSADMIN grants LANDING privileges directly to CLAUDE_WS_ROLE | The Corteza connector runs as ALBA with ALBA_ROLE and cannot create roles; one-user project (Ray, answer 3b) | Implementation record, knowledge 35 (via this document) |
| 2 | dbt_expectations from the dbt hub for layer 2 | dbt_utils from GitHub; source row count as a singular test; hub row count left to the verification queries | The container’s egress gateway re-signs TLS and the local Fusion engine cannot download from the hub; dbt_expectations depends on dbt_date through the hub (Ray, answer 1b with fallback) | Workstation canonical (Corteza knowledge 336), lessons (a) |
| 3 | Unit tests with explicit severity error | No severity key on unit tests | Fusion rejects it; unit tests always fail as errors | This document |
| 4 | Staging derived column as written in guide step 8 | The overwrite of client_number also declares src_cols_required | An overwrite removes the source column from the stage’s input; without the declaration the compiled SQL referenced a missing column | This document; a course pattern item (design D-14) |
| 5 | Build order: unit tests, then capture and build | Both models were first built empty for the unit tests, so the hub’s first real build ran incrementally, dropped its unknown ghost, and let Sunbelt Senior’s NULL client number own the all-zeros key. Rebuilt with full refresh; assertion assert_client_h_ghost_keys_belong_to_ghosts added (Ray, answer 1y) | Claude’s sequencing error, caught by verification | Workstation canonical, lessons (b) |
| 6 | Ported finder counts | COALESCE around COUNT_IF in the baseline metrics | COUNT_IF returned NULL on the empty findings table, so an expectation read NOT FOUND | This document |
| 7 | Coverage: 19 planned files | 23 files changed against main | Added: dbt/package-lock.yml, dbt/seeds/seed_build_expectations.csv (G-3), dbt/tests/expect_sunbelt_client_row_count.sql (delta 2), dbt/tests/assert_client_h_ghost_keys_belong_to_ghosts.sql (delta 5); the ported macros live in dbt/macros/verification and dbt/macros/materializations instead of the macros root | Test plan coverage table, amendment pending Ray’s approval |
| 8 | Reference table on the version-0 reference satellite (guide G-11) | A version-1 view, record_source_rs1, added between them | datavault4dbt’s reference table reads load-end dates and a current flag, which only the version-1 satellite provides (Ray, answer 1y) | Guide G-11 reversed |
| 9 | Rebuild the client hub with the scoped script (guide step 19) | The first run named client_h and rebuilt it from the old staging view, so 34 rows kept SUNBELT.CLIENT; rerun from stg_sunbelt_client it was correct | A scoped rebuild must start from the model that changed, not from the table holding stale rows; the resolve assertion caught it | This document; the lesson on development rebuilds |
| 10 | Rebuild script’s database check | Its first parsing found nothing and refused every database, failing safe; replaced with an exact match and tested on developer, QA and production names before use | Claude’s text-matching error | This document |
| 11 | Unit tests R1 to R3 before their models (test-driven development) | Written after the staging view, reference hub and satellite | Claude’s ordering error in step 14 | This document. The tests were later removed with the reference objects (delta 14) |
| 12 | Rebuild command for Ray’s v1 environment | The command omitted the fusion_only exclusion, so v1 ran unit tests it cannot run | Claude’s instruction error; fixed by the selectors v1_safe and qa_build, so exclusions live in the repository | dbt/selectors.yml; the QA runbook |
| 13 | Coverage for increment 1.1: eight added files and two changed | Ten added (the version-1 satellite view and dbt/selectors.yml beyond the plan) and two changed; the branch differs from qa in 48 files | Deltas 8 and 12 | The test plan’s coverage table, amendment pending |
| 14 | Data Vault reference objects for the source names (design D-16, D-18, D-19) | One source system seed; history in git; reference hub, satellites, dated view, reference table and unit tests R1 to R3 removed | Ray: the six objects only mapped a code to a name; a three-row file the team edits needs no vault objects to keep its history | Design D-21; the pragmatic principle in the course record |
| 15 | Removed models leave their objects behind | Objects of removed models were dropped by hand in both developer databases; then the macro dev_drop_orphans was added | A build never drops what the project no longer defines | Standard: Operations as dbt Macros |
| 16 | Words: “registry” for the seed; “link” for a Data Vault link | “registry” replaced by the source system seed; one exception added to the project instructions’ struck-words list: “link” for the Data Vault object, in this course only | The project instructions’ struck-words list | The course record and acceptance log, entry 19 |
| 17 | Landing acts as SQL scripts run with the Snowflake command line | The macro land_act, with the rows moved verbatim and the scripts removed | Ray: operational SQL against the warehouse is a dbt macro | |
| 18 | Step 22’s landing statements run against LANDING and the developer clone | Run in the workstation’s clone only (Ray, answer 1b); LANDING’s block ran from a temporary extract file, against the transport rule | Claude’s transport error for the second part | This document |
| 19 | Increment 1’s twelve unit tests kept unchanged (guide section 6) | Four client_h tests rewritten to mock the hub’s second source | The hub gained a source, so its fixtures must give the sales data’s staging model too; their setup errors at 01:12 UTC showed it | This document; the guide’s disposition is superseded here |
| 20 | Path ST4 tested on the insured satellite | Tested on stg_northfield_policy’s change hash; since 2026-10-25 the satellite side is proven by insured_northfield_s’s own ST3 | The reason for the first move was not recorded | Test plan v4, logic area M |
| 21 | Auditors comparing the counts of their own record source | Each checks that every usable source key exists in its hub, whichever record source the hub kept | A key both sources send in one load is kept under one of them (path PH3), so the count comparison raised false findings at both acts | Design D-10 and guide step 31, reworded 2026-10-25 |
| 22 | Guide G-17’s build expectations for the landing tables | Dropped from seed_build_expectations | The reason was not recorded | This document |
| 23 | Incremental unit tests dated inside the loaded acts | Dated 2099-01-01 | The toolkit’s satellite reads the latest load time from the live table, not from the mocked one, so a fixture dated inside the loaded acts is filtered out | A note proposed for the layered testing methodology (DIG-574 handover, not enacted) |
| 24 | Unit tests as the test plan v3 named them | 23 more, for the client satellites, insured_northfield_s, the four version 1 views and the three staging change hashes; layers 1, 2 and 4 written after the code | Logic left unproven by v3, found by the test plan’s compliance check (Ray, answer 1a) | Test plan v4, agreed 2026-10-25 |
| 25 | No audit finding after the build | Two findings of the auditors’ first versions remain in DATA_FINDING with status detected | Ray, answer 1b: they stay, disclosed here; a finder that agrees returns no row, so merge_into never revisits its earlier finding | This document |
| 26 | Landing acts load developer clones only (land_act refused every other database), and increment 2’s acts ran in development only (answer 1b) | land_act delivers to LANDING, as the stand-in source system; QA and developer landing receive the data by cloning LANDING. Increment 2’s acts were delivered to LANDING on 2026-10-25 and match the development clone row for row | Landing data flows down while code flows up (Ray, 2026-10-25, answer 1y); the old guard had the direction backward | Implementation guide, QA, promotion and production, step 4; QA item , section 1.3; land_act’s header, commit 0472975 |
| 27 | D-40 as first agreed: ten relationship tests, one per line of the design’s ERD, including six from the links’ hub keys | Four, on the satellites only; the six link tests were written, passed, and removed (commits df44975 and 5d5c59d) | The links’ six hub keys were already proved by the layer 4 assertion assert_increment_2_link_hub_keys_exist, which the author missed by searching only the YAML files; the test plan rule reuses existing proof (Ray, 2026-10-26, answer 1a) | Design D-40 and the test plan’s layer 1, amended |
| 28 | Every vault unit test tagged fusion_only, run only on v2 (64 of 74; v1 ran 10) | 51 tagged; the 13 that pass on dbt 1.12.6 untagged, so v1 runs 23 (commit f17b983, pull request #3) | Run on dbt v1 1.12.6 on 2026-10-26, 13 of the 64 passed; the tag was wider than the failure, which is datavault4dbt’s hub macro describing a unit test’s fixed input (Ray, answer 1b) | Implementation guide’s tagging sentence; the QA item’s scope |
| 29 | One build behavior on every engine | dbt Cloud’s QA build (version 2026.10.14+638bb1a) compiled every hashdiff upper-cased, while the workstation’s v1 1.12.6 and v2 compiled them case-sensitive from the same code and package pin; QA lost one case-only version | Found by comparing DV_QA with the development vault, table by table; the cause in dbt Cloud is not known (Ray, 2026-10-26, answer 1y) | Design D-41; test plan layer 4; implementation guide step 38 |
| 30 | Release 1 reviewed by Ray as part 1’s exam before it reached qa | Pull request #2 merged into qa without the review, 2026-10-26 | Expedited for time to market: the consumer could ask at any moment (Ray, answer 1b); release 2 follows the full process, its review being part 1’s exam (Ray, 2026-10-27) | Lesson 8, note 7; product definition , section 5; acceptance log entry 41 |
| 31 | One identity for QA and production (DBT_DEPLOY) | Split by data product: DV_QA_DEPLOY with DV_QA_ROLE, which holds nothing on DV or LANDING, and DV_DEPLOY with DV_ROLE | A QA job pointed at production by mistake must fail on privileges, not write there (Ray, answers 1b and 2y) | Object Naming standard rule 7 (, v1.3); QA item , section 3.2 |
| 32 | Promotion by swapping QA into production | Production built from main by its own job, after squash-merging qa into main and converging qa with main | The minimal route for a first release with an empty production; the swap waits for a later release (Ray, 2026-10-26 and 27) | QA item , sections 10 and 11 |
5. Known characteristics
| Characteristic | Design disclosure | Operational meaning |
|---|---|---|
| The A-1010 key’s stored spelling depends on the build: a-1010 in increment 1’s build, A-1010 in the build of 2026-10-25 | Design 6.3: the hub keeps the first sighting | When two spellings of one key arrive in the same load with the same load time, the hub keeps one and the data does not decide which; the stored spelling can be a typo |
| A1007 and A-01008 are separate hub keys | Profile P-3, open by design | They may name clients A-1007 and A-1008; the vault cannot tell; the inspector discloses both until an identity increment resolves them |
| The hub grows only | Design D-3, insert-only | A client absent from a later load stays in the hub; disappearance is not tracked in this increment |
| A record source’s name is current in the seed; earlier names are in git | Design D-21 | Asking what a source was called at a past date means reading the seed’s git history, not a vault table |
| verify_build’s increased expectation fails on a rebuild over unchanged data | Guide G-5 | Expected; it is written for landing acts |
| A sale sent with no carrier code is its own policy key | Design D-26; path PH8 | NF-100005’s sale and Northfield Life’s NF-100005 are two hub rows; the placeholder keeps the known part |
| NF100009 and NF-100009 are separate policy keys | Path PH6; design D-30 | The inspector discloses the nonconforming form; nothing unifies them |
| One person under two role keys | Design D-29, D-32; path L4 | Irene Garrity is A-1007 and NLI-55007, joined only through the policy; matching the person is later work |
| Disagreeing sources keep both agent rows | Design D-36; path LA2 | NF-100011 has two agent_policy_l rows; deciding which agent is right belongs after the raw vault |
6. Where this feeds
| Downstream consumer or process | Dependency | Handoff reference |
|---|---|---|
| DIGEST Data Vault Course, textbook part 1 (arrival and identity) | The built staging view, hub, findings and the deltas above, as real instances | Course record, Pilot knowledge 34 |
| Increment 2 (relationships) | client_h as one of the hubs a link connects: shipped in this branch, sections 1 to 3 | Master issue DIG-574 |
| Lessons 3 to 7 and part 2, then the milestone diagram | The two-source raw vault as built: the policy as the meeting point, the role keys kept apart, the satellites’ versions | Course record, Pilot knowledge 34; DIG-574 session goal |
| Course pattern items for the link and the satellite (design D-14) | Steps 29 and 30 as built, the exemplars for later increments (guide G-20) | Course record, Pilot knowledge 34 |
| Course pattern items (design D-14) | The datavault4dbt stage and hub as built, including delta 4 | Course record, Pilot knowledge 34 |
| Part 1, lesson 7 | The source system seed as built, including the live rename and the side-by-side of the Data Vault way and the pragmatic way | Course record, Pilot knowledge 34 |
| Part 1, lesson 2 (amended) | The record source as a code, named in the source system seed | Course record, Pilot knowledge 34 |
7. Follow-up work
Follow-up issues live in the post-production document; this section contains references only.
| Follow-up | Post-production reference |
|---|---|
| Record the datavault4dbt patterns as course items (design D-14) | DIG-574 |
| Amend the test plan’s coverage table to the shipped files (deltas 7 and 13) | Done: test plan v4, agreed 2026-10-25 |
| Satellite rows on the unknown key: real people’s details are versions of the all-zeros key (Felipe Duarte in insured_northfield_s; Pia Esposito, Karl Falk and Dina Guerrero in client_sunbelt_s), so the version 1 views end-date one person with the next. No document discloses it | DIG-574, logged for a later increment (Ray, answer 2b) |
| Finders that clear their own findings once the condition no longer holds (delta 25) | DIG-574, logged off the goal’s path |
| Pull request #2 into qa, made mergeable | DIG-574, the build goal’s step 5 |
| Register the workstation’s Fusion engine within 14 days of first use | Workstation canonical, open item |
| Rebuild the PILOT layer: insert procedures without status or version, the template procedure’s placeholder check that rejects dbt Jinja, the missing passage-edit procedures | DIG-576 |
8. Compliance record
Built by the author against the post-implementation guide template and Standard: Branch Delivery Documents (, post-implementation guide section), at 2026-10-25 11:15Z, on v3. Verdict: compliant for increments 1, 1.1 and 2; v3 agreed by Ray on 2026-10-25, answer 1y. Since design D-13 was superseded the same day, QA certification applies: its record, , is open, and this guide gains the QA evidence when the cycle completes.
| # | Requirement | Result |
|---|---|---|
| 1 | Header with references to the design, implementation guide, test plan and QA certification; every template section present; the write time in the Status cell | Yes: items 270, 272 and 271; QA certification , open; sections 1 to 7; the Status cell carries the write time |
| 2 | What shipped: every planned deliverable with repository and warehouse evidence | Yes for all three increments: every increment 2 deliverable with its commits and its rows in the developer tier |
| 3 | Verified live output with environment and clock; test outcome reconciling planned, passed, failed and dispositioned | Yes: increment 2 read back in DEV__DV__CLAUDE_WS on 2026-10-25, every figure regenerated from the vault for this write; test outcome per layer, 129 of 129 |
| 4 | Deltas from the plan, each with why and the document that absorbed it; known characteristics limited to disclosed behavior; where this feeds; follow-up | Yes: deltas 1 to 25, two of them stating that the reason was not recorded; characteristics cite their design disclosures; the undisclosed satellite rows on the unknown key are follow-up, not a characteristic |
| 5 | Covers the branch as built | Yes, at commit 94639b4 |