FIG Data Setup — Master-Data Ownership & Demo Currency

Owner	Classification	Status	Verified against code
Kris (product)	Internal	Design + partly built	2026-09-15 — blitz/scripts/demo/, Prisma @@schema

What this page is. The data companion to FIG Design: who owns which master, and how demo data stays current so the graph (and every module) ties out. Ported from the Z-drive FINAISSE-FIG-DATA-SETUP. The re-dating clock is built for cash; the "accumulate" v2 model and full cross-module alignment are in progress.

---

1. First principle — two data populations, opposite lifecycles

Population	Examples	Lifecycle
Identity masters	GL accounts, customers, vendors, entities	Static — seeded once, never re-dated
Temporal / transactional	bank items, AR items, invoices, due dates	Slide with the calendar

Everything else follows from this split.

2. Master-data ownership (Source of Record)

Verified against Prisma @@schema. A master minted inside a module is a defect — it creates islands.

Master	SoR	Schema
Tenant	tm.tenant	mgmt
Notifications / permissions	sys.*	finance
Period, business entity, business user, cost center, entity alias, intelligencelog	finbase.*	finance (the shared spine)
Chart of accounts / GL	reconciliation.account	finance (canonical GL SoR)
AR masters (customer)	cash.*	finance

3. GL master comes from Recon

reconciliation.account is the canonical chart-of-accounts SoR. Wiring status:

• Invoice — already FKs correctly.
• CashApp — currently hops through invoice.glmaster (an AP-domain table); GH #1142 repoints it to a direct FK to reconciliation.account.
• Journal — unlinked everywhere (loose strings); wave-2.

The recon account key is accountnumber + segment1, never number alone — the same number has multiple non-duplicate rows by segment. The connected-close tie keeps breaking when tasks leave segment1 empty. Populate task.segment1 and match on number+segment1.

4. Demo currency — two competing mechanisms

4.1 The re-dating clock (✅ built, for cash)

An idempotent, tenant-scoped refresh (refresh-cashapp-demo.sh + the SQL suite in blitz/scripts/demo/): ensure masters → re-anchor every transaction date relative to NOW() → advance currentperiodid → re-run the real CID + matching engines. Never re-dates identity masters; never invents data.

4.2 "Accumulate, don't re-date" — lifecycle v2 (decision 2026-08-13)

The sliding clock has no real history — bad for a finance demo (aging, DSO, MoM close need accumulated periods). The v2 model fixes an anchor, appends forward, and never re-dates or deletes history. Two operations:

• Reset — undo the current period's mutations.
• Advance — append the next month.

First increment built: seed-ar-collection-cycle.sql (a 6-month Feb→Jul flow, DSO ≈ 44).

5. The alignment contract (§0, enforced)

verify-fig-alignment.sql produces a PASS/FAIL table of 8 checks: trial balance foots; cashapp AR = recon subledger 100051; invoice AP = recon subledger 100043; anomalies only in the live period; ≥100 customers/vendors; glmaster resolves to reconciliation.account; point-in-time AR ties.

The master setup chain (setup-demo.sh) has a strict 8-step order; the linchpin is that the recon-import generator reads cashapp/invoice live, so it must run after the align steps or silent drift results.

6. Known gaps

• Entity scoping is a platform-wide gap — Epic #1143 (cash pilot #1144; cash 0/46 tables scoped). cash.customer.businessentityid FK still pending.
• Company code was a dangling US01, restamped US_CORP (2026-08-13) to align cash ↔ recon ↔ invoice.
• Several items pending Canny's ~50-account recon chart (#1142).

Revision history

Date	Change
2026-09-15	Ported from Z FINAISSE-FIG-DATA-SETUP; kept the built-vs-design split (re-dating clock built; accumulate-v2 in progress); added the recon account-key caveat.