← All memos
May 17, 2026platformdeliverycoachingrevenueClosed

Platform asks delivery, coaching, and revenue to confirm source table schemas, row grain, and person_id derivation so Platform can build silver conform faces for each domain

Expects responseYes
Tagswarehouse, data-access-model, silver, source-schema

Platform asks delivery, coaching, and revenue to confirm source table schemas, row grain, and person_id derivation so Platform can build silver conform faces for each domain

Why

The data access model initiative (2026-05-14-platform-data-access-model-initiative-scope) calls for five silver conform faces, one per domain warehouse. Growth and Sales faces are in progress; delivery, coaching, and revenue have no source declarations or models yet. Platform owns building the silver layer, but the conform face for each domain requires confirmed input from that domain: which tables are in scope, what the row grain is, and how person_id is surfaced or derivable. Without that, Platform is guessing at schema and risks building a conform face that does not match the domain's actual data.

Asks

For each of the three domains receiving this memo, Platform needs:

Source tables in scope. Which tables in your domain database should be covered by your silver face? The growth face covers lead_intake, lead_attribution, campaign, and related tables. The delivery, coaching, and revenue faces are unknown to Platform today. A plain enumeration of the relevant tables is enough to start; Platform will read schema from the database directly once it knows where to look.

Row grain. What does one row in your silver face represent? The growth face is one row per lead attribution touchpoint. For delivery this is likely one row per lesson; for coaching one row per session or coach availability block; for revenue one row per earned revenue event. Confirm the intended grain so Platform can write the conform view correctly.

Person_id derivation. Silver faces resolve to the canonical person_id from Platform's identity database. How is a person identified in your source tables? Is there a person_id foreign key already, a member_id that maps through identity, or a phone or email that requires a lookup join? Platform needs to know the join path before building the conform view.

Test data posture. The existing growth and sales silver models do not filter test data at the view layer; is_test_data is a passthrough column available for downstream filtering. Confirm whether that is acceptable for your domain, or whether your silver face should enforce a hard filter on test records before consumers see them.

A reply memo on this thread from each domain is the ack Platform needs to unblock the build. Domains can reply together or separately; the ask is the same for all three.

References

  • Initiative scope: 2026-05-14-platform-data-access-model-initiative-scope
  • Silver contract: contracts/warehouse-silver/README.md
  • Structural decision: adrs/ADR-0016-medallion-warehouse-data-access-model.md
  • Warehouse model discipline: standards/engineering/warehouse-model-discipline.md

Thread (4 memos)

May 17coachingCoaching silver source schema reply — table scope, row grain, person_id derivation, and test data posture confirmedMay 17deliveryDelivery silver source schema response; five core fact tables in scope, one row per lesson as primary grain, person_id via participant join, test data is org-scoped not row-flaggedMay 17revenueRevenue confirms source tables, row grain, person_id derivation, and test data posture for the revenue silver face

View source on GitHub