Enterprise-scale sample warehouses.

Company profile

Fictional company notice: "AYA" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent AXA SA, AXA Hong Kong and Macau, or any real insurance company.

AYA is a Hong Kong composite insurer — Life & Savings, Health (including VHIS and employee benefits), and General Insurance — distributed through tied agents, bancassurance, brokers, the Aria by AYA digital app, and embedded e-wallet partners. HQ sits in Quarry Bay, with a Central advisory centre, AYA Medical Centre in Tsim Sha Tsui, a Macau branch, and a Qianhai GBA sales office.

The business spans product factory, Magnum-class underwriting, split PAS (life on Ingenium-class, GI on Guidewire), FPS premium collection, Varicent commission, 24×7 motor/travel FNOL, FINEOS health claims, reinsurance cession, Prophet IFRS 17 valuation, and SAP S/4 journals — with a typhoon-season GI claims lift (June–October) and a CNY travel / northbound-motor spike across digital and agency channels.

Sample entities: The table below shows representative business entities and their source systems; the complete EDW includes additional entities, sub-types, and specialized tables (e.g., Prophet BEL/CSM, treaty cessions, medical-centre visits, CLM redlines) across all 60 bronze tables. In V2, LifePolicy and GiPolicy domain classes drive the QuoteToBindToPremium and FnolToPay spines.

OOP domain model

AyaEnterpriseSimulation sequences the day; domain objects own emission logic.

QuoteToBindToPremium is the new-business spine; FnolToPay is the claims spine. LifePolicy.execute_lifecycle() walks quote → Magnum UW → Ingenium issue → FPS collection → commission → GL. GiPolicy.execute_lifecycle() walks quote → PolicyCenter bind → BillingCenter invoice → optional same-day FNOL on ClaimCenter. AyaPortfolio.publish_foundation() masters products, agents, offices, and policyholders before policies run.

flowchart LR
  PORT[AyaPortfolio.publish_foundation]
  LIFE[LifePolicy.execute_lifecycle]
  GI[GiPolicy.execute_lifecycle]
  PORT --> LIFE
  PORT --> GI
  LIFE --> Q[Aria quote]
  Q --> UW[Magnum UW]
  UW --> PAS[Ingenium / PolicyCenter]
  PAS --> FPS[FPS collect]
  GI --> FNOL[ClaimCenter FNOL]
  FNOL --> RI[reinsurance cession]
  FPS --> GL[SAP S/4 IFRS 17]
          

Quote-to-claim value chain

From product factory through distribution, bind, collection, claims, and finance close.

Sample view: This illustrates the primary value chain across the AYA ecosystem; the full generated EDW includes all 39 source systems with cross-functional integrations, medical-centre cashless visits, and treaty accounting not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph factory["Product & distribution"]
    direction TB
    PRD[aya_product]
    AG[aya_agency]
    DIG[aya_digital Aria]
    PRD ~~~ AG
    AG ~~~ DIG
  end
  subgraph bind["Underwrite & bind"]
    direction TB
    MAG[swissre_magnum]
    LIFE[dxc_ingenium]
    PC[guidewire_pc]
    MAG ~~~ LIFE
    LIFE ~~~ PC
  end
  subgraph cash["Collect & commission"]
    direction TB
    BC[guidewire_bc]
    FPS[fps]
    VAR[varicent]
    BC ~~~ FPS
    FPS ~~~ VAR
  end
  subgraph claims["Claims & health"]
    direction TB
    CC[guidewire_cc]
    FN[fineos]
    CLIN[aya_health]
    CC ~~~ FN
    FN ~~~ CLIN
  end
  subgraph corp["Investments & close"]
    direction TB
    AIM[bloomberg_aim]
    PR[prophet]
    S4[sap_s4]
    AIM ~~~ PR
    PR ~~~ S4
  end
  factory --> bind --> cash --> claims --> corp
          

Functional org by department

AYA Tower Quarry Bay HQ and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full AYA organization includes additional agency districts, Macau and GBA teams, and shared-services functions across all 39 vendor integrations.

flowchart TB
  CEO[AYA Hong Kong]
  CEO --> LIFE[Life & Savings]
  CEO --> HLTH[Health & Employee Benefits]
  CEO --> GI[General Insurance]
  CEO --> DIST[Agency / banca / digital]
  CEO --> CLM[Claims]
  CEO --> FIN[Finance & actuarial]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

EDW maturity stages

Catalog stage groups tables from foundation through corporate.

Sample breakdown shown: This is a representative slice of the full 60-table inventory distributed across maturity layers; the actual distribution reflects the complete data lineage from foundation through corporate gold tables.

flowchart LR
  F["foundation
~12 tables"]
  D["distribution
~10 tables"]
  P["policy & premium
~9 tables"]
  C["claims
~6 tables"]
  CO["finance & corporate
~23 tables"]
  F --> D --> P --> C
  F -.-> CO
  P -.-> CO
          

Core business entities

Logical relationships and anchor keys. Product (product_code) and policy (policy_number) are the spine; claims join via FNOL and claim numbers.

Sample diagram: This entity relationship diagram shows the core logical model; the full generated EDW contains 60 bronze tables across 39 vendor systems with additional detail tables and lineage branches. Entity instances carry entity_refs on every emitted event for joinability testing.

erDiagram
  PRODUCT ||--o{ LIFE_POLICY : tariffs
  PRODUCT ||--o{ GI_POLICY : tariffs
  AGENT ||--o{ LIFE_POLICY : sells
  AGENT ||--o{ GI_POLICY : sells
  POLICYHOLDER ||--o{ LIFE_POLICY : owns
  POLICYHOLDER ||--o{ GI_POLICY : owns
  LIFE_POLICY ||--o{ HEALTH_CLAIM : incurs
  GI_POLICY ||--o{ GI_CLAIM : notifies
  GI_POLICY ||--o{ INVOICE : bills
  LIFE_POLICY ||--o{ PREMIUM : collects
  GI_CLAIM ||--o{ CESSION : cedes
          

Source system landscape

39 vendor prefixes, 60 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 39 systems with their full table lineage and integration points across history backfill and live streams. Shared source-system manifests in kb/source_systems/ are reused across industries — AYA adds aya_product, aya_agency, aya_digital, and aya_health as industry-specific internal systems, plus a split PAS (Guidewire + Ingenium).

Each table follows the {source_system_}__{entity} naming convention (e.g. aya_product__product, guidewire_cc__claim), preserving the vendor-native column shape and foreign keys from each product's real export schema. VibeBI infers master-data conformance when it promotes records to silver and gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["aya_product · aya_agency · oracle_scm"]
    f2["salesforce · workday · sap_s4 dimensions"]
  end
  subgraph distribution["Distribution"]
    direction TB
    d1["aya_digital · salesforce_cpq"]
    d2["hubspot · marketo · google_analytics"]
  end
  subgraph policy["Policy & premium"]
    direction TB
    p1["swissre_magnum · dxc_ingenium"]
    p2["guidewire_pc · guidewire_bc · fps · varicent"]
  end
  subgraph claims["Claims"]
    direction TB
    c1["guidewire_cc · fineos · aya_health · sap_fs_ri"]
  end
  subgraph corporate["Finance & corporate"]
    direction TB
    co1["prophet · bloomberg_aim · sap_s4 journals"]
    co2["anaplan · adp · ukg · concur · coupa"]
    co3["servicenow · okta · splunk · ironclad · onetrust"]
  end
  foundation --> distribution --> policy --> claims
  foundation --> corporate
  policy --> corporate
          

End-to-end data flow

V2 OOP sim → bronze in ClickHouse; VibeBI semantic → silver → gold on the same instance.

OOP path: kb/industries/aya/ defines the operations spine and entity model; AyaEnterpriseSimulation sequences domain lifecycles; SourceSystem adapters export vendor-native rows into aya_v2.

flowchart LR
  subgraph kb["kb/industries/aya"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/aya"]
    ORCH[AyaEnterpriseSimulation]
    DOM["LifePolicy · GiPolicy
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse aya_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Live bronze cycle

./live-v2-aya — 60s tick via AyaEnterpriseSimulation.generate().

Live frequency: Each tick runs QuoteToBindToPremium and FnolToPay — domain objects emit correlated quotes, UW decisions, PAS binds, FPS collections, commissions, FNOL, and GL rows; live ticks for today emit only events up to Hong Kong as_of so quotes, FNOL, FPS, and journals grow through the day. Scale varies per tick (default base 5). Backfill any history span you need (--days N on the live script or CLI).

flowchart LR
  START([60s tick]) --> SIM[AyaEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> LIFE[LifePolicy lifecycles]
  FOUND --> GI[GiPolicy lifecycles]
  LIFE --> CORP[Health + investments + finance]
  GI --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Quote-to-bind and FNOL event graphs

QuoteToBindToPremium and FnolToPay state machines — each transition is a domain method emitting vendor rows.

Process spine: Defined in kb/industries/aya/process_model.yaml. Late-arrival modes (PAS issue lag, FPS clearing, commission batch, overnight FNOL, reinsurance bordereau) and exception modes (UW refer/decline, premium lapse, claim denied, partial settlement) branch from the same entity lifecycles rather than independent random inserts.

flowchart LR
  Q[quoted] --> UW[underwritten]
  UW --> BIND[bound]
  BIND --> BILL[billed]
  BILL --> COL[collected]
  COL --> COMM[commissioned]
  COMM --> GL[posted_to_gl]
  UW -.->|uw_decline| DEC[declined]
  BILL -.->|lapse| LAPSE[premium_lapse]
          

flowchart LR
  FNOL[fnol_submitted] --> OPEN[claim_opened]
  OPEN --> RSV[reserved]
  RSV --> PAY[paid]
  PAY --> CLOSE[closed]
  OPEN -.->|denied| DENY[claim_denied]
  PAY -.->|partial| PART[partial_settlement]
          

Bronze table categories

Same lineage envelope on every table; category drives live behavior.

Sample categories: All 60 bronze tables follow this three-category pattern (snapshot, transaction, event) with consistent metadata and state tracking; the diagram illustrates the pattern used across the full warehouse.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Product · agent · policyholder masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Policies · premiums · claims · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["Digital sessions · FNOL · clinic visits"]
    E2[Append each live tick]
  end
  BRONZE[("aya_v2 bronze row")]
          snap --> BRONZE
          txn --> BRONZE
          evt --> BRONZE
          

Company profile

Fictional company notice: "Smire" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent Swire Properties Limited, Swire Pacific Limited, or any real property company.

Smire Properties is a Hong Kong mixed-use landlord headquartered in Smire Tower, Quarry Bay — Grade-A office campuses (Eastgate Place, Harbour Place), malls (Harbourplaza, Peakgate Outlets, Eastgate Li), residential, and Harbour House hotels, plus Mainland Taikoo Li-style retail in Beijing, Shanghai, Guangzhou, and Chengdu.

The book spans leasing offers into Yardi leases and daily rent rolls, base rent plus retail turnover rent from mall POS, HK FPS / CNY collection, SAP S/4 NOI journals, near-real-time BMS, Nedap badge events, car park, and mall footfall 11:00–22:00 HKT, plus Argus GAV/NAV, CoStar-style comps, development CAPEX draws, and hotel occupancy/ADR/RevPAR — with a CNY mall trading surge that lifts Harbourplaza and Eastgate Li footfall, turnover rent, and FPS collections.

Sample entities: The table below shows representative business entities and their source systems; the complete EDW includes additional entities, sub-types, and specialized tables (e.g., ESG meters, CAPEX draws, hotel occupancy, CLM redlines) across all 60 bronze tables. In V2, Lease and Tenant domain classes drive the LeaseToCollect and MallTradingDay spines.

OOP domain model

SmireEnterpriseSimulation sequences the day; domain objects own emission logic.

LeaseToCollect is the leasing spine; MallTradingDay is the retail ops spine. Lease.execute_lifecycle() walks offer → Yardi lease and rent roll → invoice (base plus turnover rent) → FPS collect → NOI journal. Tenant.publish() masters Yardi and Salesforce before leases run. SmirePortfolio.publish_foundation() masters properties, buildings, lettable units, and sites first.

flowchart LR
  PORT[SmirePortfolio.publish_foundation]
  TNT[Tenant.publish]
  LS[Lease.execute_lifecycle]
  PORT --> TNT
  TNT --> LS
  LS --> OFF[leasing offer]
  OFF --> YAR[Yardi lease / invoice]
  YAR --> FPS[FPS collect]
  FPS --> GL[SAP S/4 NOI]
  PORT --> MALL[Mall POS + footfall]
  MALL --> YAR
          

Lease-to-collect value chain

From portfolio master through leasing, mall trading, asset ops, and finance close.

Sample view: This illustrates the primary value chain across the Smire ecosystem; the full generated EDW includes all 39 source systems with cross-functional integrations, hotel RevPAR, and development CAPEX not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph portfolio["Portfolio"]
    direction TB
    PORT[smire_portfolio]
    SCM[oracle_scm]
    PORT ~~~ SCM
  end
  subgraph lease["Lease & collect"]
    direction TB
    OFF[smire_leasing]
    YAR[yardi_voyager]
    FPS[fps]
    OFF ~~~ YAR
    YAR ~~~ FPS
  end
  subgraph ops["Operate asset"]
    direction TB
    MALL[smire_mall]
    BMS[honeywell_bms]
    AEOS[nedap_aeos]
    MALL ~~~ BMS
    BMS ~~~ AEOS
  end
  subgraph value["Value & hotels"]
    direction TB
    ARG[argus_enterprise]
    HOT[smire_hotel]
    DEV[smire_dev]
    ARG ~~~ HOT
    HOT ~~~ DEV
  end
  subgraph close["NOI close"]
    direction TB
    S4[sap_s4]
    CST[costar_analytics]
    S4 ~~~ CST
  end
  portfolio --> lease --> ops --> value --> close
          

Functional org by department

Smire Tower Quarry Bay HQ and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full Smire organization includes additional property-management offices, Mainland mall teams, and shared-services functions across all 39 vendor integrations.

flowchart TB
  CEO[Smire Properties]
  CEO --> OFF[Office]
  CEO --> RET[Retail]
  CEO --> RES[Residential]
  CEO --> HOT[Hotels]
  CEO --> DEV[Development]
  CEO --> FIN[Finance]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

EDW maturity stages

Catalog stage groups tables from foundation through corporate.

Sample breakdown shown: This is a representative slice of the full 60-table inventory distributed across maturity layers; the actual distribution reflects the complete data lineage from foundation through corporate gold tables.

flowchart LR
  F["portfolio
~10 tables"]
  L["leasing
~8 tables"]
  O["operations
~10 tables"]
  V["valuation
~8 tables"]
  CO["corporate
~24 tables"]
  F --> L --> O --> V
  F -.-> CO
  L -.-> CO
          

Core business entities

Logical relationships and anchor keys. Property (property_code) and unit (unit_id) are the spine; leases join via lease_id and FPS via invoice.

Sample diagram: This entity relationship diagram shows the core logical model; the full generated EDW contains 60 bronze tables across 39 vendor systems with additional detail tables and lineage branches. Entity instances carry entity_refs on every emitted event for joinability testing.

erDiagram
  PROPERTY ||--o{ BUILDING : contains
  BUILDING ||--o{ UNIT : lets
  UNIT ||--o{ LEASE : occupies
  TENANT ||--o{ LEASE : signs
  LEASE ||--o{ INVOICE : bills
  INVOICE ||--o{ FPS_PAYMENT : collects
  TENANT ||--o{ MALL_SALE : trades
  PROPERTY ||--o{ VALUATION : values
          

Source system landscape

39 vendor prefixes, 60 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 39 systems with their full table lineage and integration points across history backfill and live streams. Shared source-system manifests in kb/source_systems/ are reused across industries — Smire adds smire_portfolio, smire_leasing, smire_mall, and smire_hotel as industry-specific internal systems, plus Yardi Voyager and Argus.

Each table follows the {source_system_}__{entity} naming convention (e.g. smire_portfolio__unit, yardi_voyager__lease), preserving the vendor-native column shape and foreign keys from each product's real export schema. VibeBI infers master-data conformance when it promotes records to silver and gold.

flowchart TB
  subgraph foundation["Portfolio"]
    direction TB
    f1["smire_portfolio property · building · unit"]
    f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
  end
  subgraph leasing["Leasing"]
    direction TB
    l1["smire_leasing · yardi_voyager · fps"]
  end
  subgraph operations["Operations"]
    direction TB
    o1["smire_mall · honeywell_bms · nedap_aeos · smire_park"]
    o2["smire_hotel · smire_esg · smire_loyalty"]
  end
  subgraph valuation["Valuation"]
    direction TB
    v1["argus_enterprise · costar_analytics · smire_dev · smire_residential"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · anaplan · adp · ukg · concur"]
    co2["hubspot · marketo · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> leasing --> operations --> valuation
  foundation --> corporate
  leasing --> corporate
          

End-to-end data flow

V2 OOP sim → bronze in ClickHouse; VibeBI semantic → silver → gold on the same instance.

OOP path: kb/industries/smire/ defines the operations spine and entity model; SmireEnterpriseSimulation sequences domain lifecycles; SourceSystem adapters export vendor-native rows into smire_v2.

flowchart LR
  subgraph kb["kb/industries/smire"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/smire"]
    ORCH[SmireEnterpriseSimulation]
    DOM["Lease.execute_lifecycle()
Tenant · Property · Unit"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse smire_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Live bronze cycle

./live-v2-smire — 60s tick via SmireEnterpriseSimulation.generate().

Live frequency: Each tick runs LeaseToCollect and MallTradingDay — domain objects emit correlated offers, leases, invoices, FPS collections, mall POS, footfall, badge events, and GL rows; live ticks for today emit only events up to Hong Kong as_of so rent rolls, mall trading, BMS, and journals grow through the day. Scale varies per tick (default base 5). Backfill any history span you need (--days N on the live script or CLI).

flowchart LR
  START([60s tick]) --> SIM[SmireEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> TNT[Tenant.publish]
  TNT --> LS[Lease lifecycles]
  FOUND --> OPS[Mall · BMS · hotel]
  LS --> CORP[NOI + valuation + finance]
  OPS --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Lease-to-collect and asset event graphs

LeaseToCollect and OperateAsset state machines — each transition is a domain method emitting vendor rows.

Process spine: Defined in kb/industries/smire/process_model.yaml. Late-arrival modes (FPS clearing lag, GL batch posting delay, overnight BMS, work-order lag) and exception modes (vacancy, arrears, access denied, plant alarm) branch from the same entity lifecycles rather than independent random inserts.

flowchart LR
  OFF[offered] --> LS[leased]
  LS --> OCC[occupied]
  OCC --> INV[invoiced]
  INV --> COL[collected]
  COL --> GL[posted_to_gl]
  LS -.->|vacancy| VAC[vacancy]
  INV -.->|arrears| ARR[arrears]
          

flowchart LR
  MTR[metered] --> ACC[accessed]
  ACC --> WO[work_ordered]
  WO --> VAL[valued]
  ACC -.->|denied| DEN[access_denied]
  MTR -.->|alarm| ALM[plant_alarm]
          

Bronze table categories

Same lineage envelope on every table; category drives live behavior.

Sample categories: All 60 bronze tables follow this three-category pattern (snapshot, transaction, event) with consistent metadata and state tracking; the diagram illustrates the pattern used across the full warehouse.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Property · unit · tenant masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Leases · invoices · FPS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["Footfall · badge · BMS · park"]
    E2[Append each live tick]
  end
  BRONZE[("smire_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Company profile

Fictional company notice: "Hilson" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent Hilton Inc., Hyatt Hotels Corporation, or any real hospitality company.

Hilson Hospitality Group is a global hotel operator with ~680 properties across 18 brands — from luxury flags (Waldorf-grade, Conrad-grade) through full-service (Hilson, DoubleTree-grade) to select-service and extended-stay tiers. Each property runs an on-premise Opera PMS and central Amadeus CRS, serving a mix of transient leisure, corporate negotiated, and group/convention guests.

The business spans loyalty (Hilson Honors with millions of members), group & convention sales (salesforce pipeline, CPQ room blocks), food & beverage outlets (MICROS Simphony POS), owner/franchise reporting (Oracle Fusion statements), and corporate functions — generating roughly 1,900 PMS reservations and 1,750 folio headers on a typical weekday, with a summer travel surge (June–August) that lifts occupancy, ADR, F&B spend, and loyalty activity across all properties.

Sample entities: The table below shows representative business entities and their source systems; the complete EDW includes additional entities, sub-types, and specialized tables (e.g., OTA channel events, rate-plan restrictions, franchise legal agreements, deal-desk redlines) across all 62 bronze tables. In V2, StayReservation and related domain classes emit PMS, CRS, folio, and loyalty rows through source-system adapters as the stay lifecycle progresses.

OOP domain model

HilsonEnterpriseSimulation sequences the day; domain objects own emission logic.

ReservationToLoyaltyAndOwnerReporting is the primary process spine. StayReservation.execute_lifecycle() walks booking → PMS sync → folio charges → payment → loyalty points → occupancy snapshot → owner statement → GL. HilsonPortfolio.publish_foundation() masters brands, properties, and Honors members before reservations run.

flowchart LR
  PORT[HilsonPortfolio.publish_foundation]
  STAY[StayReservation.execute_lifecycle]
  PORT --> STAY
  STAY --> BOOK[CRS booking]
  BOOK --> PMS[PMS sync]
  PMS --> FOL[folio charges]
  FOL --> PAY[Adyen settlement]
  PAY --> LOY[Honors points]
  LOY --> OWN[owner statement + GL]
          

Guest & property value chain

From brand and property master through distribution, stay, settlement, and owner reporting.

Sample view: This illustrates the primary value chain through the Hilson ecosystem; the full generated EDW includes all 31 source systems with cross-functional integrations, secondary revenue streams, and loyalty lifecycle flows not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph master["Brand & property master"]
    direction TB
    BR[hilson_brand]
    PROP[oracle_opera property]
    RMS[ideas_rms rate plans]
    BR ~~~ PROP
    PROP ~~~ RMS
  end
  subgraph dist["Distribution & booking"]
    direction TB
    AMA[amadeus_hosp CRS]
    SM[siteminder OTA]
    AMA ~~~ SM
  end
  subgraph stay["Stay & revenue"]
    direction TB
    RES[oracle_opera reservation]
    FOL[folio header / charges]
    SIM[micros_simphony F&B]
    PAY[adyen payments]
  end
  subgraph loy["Loyalty & VoC"]
    direction TB
    HON[hilson_loyalty member]
    MED[medallia · qualtrics]
    HON ~~~ MED
  end
  subgraph corp["Owner & corporate"]
    direction TB
    OWN[oracle_fusion owner stmt]
    SAP[sap_s4 GL]
    GRP[salesforce group sales]
    OWN ~~~ SAP
    SAP ~~~ GRP
  end
  master --> dist --> stay --> loy
  stay --> corp
          

Functional org by department

Enterprise HQ and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full Hilson organization includes additional regional management, brand-specific teams, and shared-services functions across all 31 vendor integrations.

flowchart TB
  CEO[Hilson Hospitality Group]
  CEO --> BRAND[Brand & marketing]
  CEO --> DIST[Distribution & revenue mgmt]
  CEO --> PROP[Property operations]
  CEO --> SALES[Group sales]
  CEO --> LOY[Loyalty program]
  CEO --> FIN[Finance & owner reporting]
  CEO --> HR[Human resources]
  CEO --> GX[Guest experience]
  CEO --> LEG[IT / security / legal]
          

EDW maturity stages

Catalog stage groups tables from foundation through corporate.

Sample breakdown shown: This is a representative slice of the full 62-table inventory distributed across maturity layers; the actual distribution reflects the complete data lineage from foundation through corporate gold tables.

flowchart LR
  F["foundation
~15 tables"]
  C["commercial
~7 tables"]
  GR["guest_revenue
~17 tables"]
  PO["property_ops
~7 tables"]
  CO["corporate
~16 tables"]
  F --> C --> GR --> PO
  F -.-> CO
  GR -.-> CO
          

Core business entities

Logical relationships and anchor keys. Property (hotel_code) is the spine; guest identity via Honors and stay tables.

Sample diagram: This entity relationship diagram shows the core logical model; the full generated EDW contains 62 bronze tables across 31 vendor systems with thousands of additional detail tables and lineage branches.

erDiagram
  PROPERTY ||--o{ RESERVATION : hosts
  PROPERTY ||--o{ RATE_PLAN : offers
  BRAND ||--o{ PROPERTY : flags
  MEMBER ||--o{ RESERVATION : books
  MEMBER ||--o{ POINT_TXN : earns
  MEMBER ||--o{ REDEMPTION : redeems
  RESERVATION ||--|| FOLIO : bills
  FOLIO ||--o{ FOLIO_CHARGE : lines
  RESERVATION ||--o{ FNB_CHECK : posts
  CORP_ACCOUNT ||--o{ OPPORTUNITY : pursues
  SUPPLIER ||--o{ PO : supplies
  PROPERTY ||--o{ WORK_ORDER : maintains
          

Source system landscape

31 vendor prefixes, 62 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 31 systems with their full table lineage and integration points across history backfill and live streams.

Each table follows the {source_system_}__{entity} naming convention (e.g. oracle_opera__reservation, hilson_loyalty__member), preserving the vendor-native column shape and foreign keys from each product's real export schema. VibeBI infers master-data conformance when it promotes records to silver and gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["hilson_brand · oracle_opera property · room_type"]
    f2["amadeus_hosp · ideas_rms · hilson_loyalty member"]
    f3["salesforce account · workday · sap_s4 · coupa supplier"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce pipeline · CPQ · hubspot · marketo"]
  end
  subgraph guest_rev["Guest revenue"]
    direction TB
    g1["oracle_opera reservation · folio · events"]
    g2["amadeus_hosp · siteminder · micros_simphony"]
    g3["adyen · loyalty points · oracle_fusion owner"]
  end
  subgraph prop_ops["Property ops"]
    direction TB
    p1["housekeeping · occupancy · ibm_maximo · coupa PO"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · adp · ukg · anaplan"]
    co2["medallia · qualtrics · zendesk · concur"]
    co3["servicenow · okta · splunk · ironclad · onetrust"]
  end
  foundation --> commercial --> guest_rev --> prop_ops
  foundation --> corporate
  guest_rev --> corporate
          

End-to-end data flow

V2 OOP sim → bronze in ClickHouse; VibeBI semantic → silver → gold on the same instance.

OOP path: kb/industries/hilson/ defines the operations spine and entity model; HilsonEnterpriseSimulation sequences domain lifecycles; SourceSystem adapters export vendor-native rows into hilson_v2.

flowchart LR
  subgraph kb["kb/industries/hilson"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/hilson"]
    ORCH[HilsonEnterpriseSimulation]
    DOM["StayReservation.execute_lifecycle()
Property · GuestMember …"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse hilson_v2
62 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Live bronze cycle

./live-v2-hilson — 60s tick via HilsonEnterpriseSimulation.generate().

Live frequency: Each tick runs the reservation-to-loyalty state machine — domain objects emit correlated CRS, PMS, folio, F&B, payment, loyalty, and GL rows; scale varies per tick (default base 5). Backfill any history span you need (--days N); Hilson includes gap detection on the reservation anchor table.

flowchart LR
  START([60s tick]) --> SIM[HilsonEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> STAY[StayReservation lifecycles]
  STAY --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Guest stay event graph

ReservationToLoyaltyAndOwnerReporting state machine — each transition emits vendor rows.

Process spine: Defined in kb/industries/hilson/process_model.yaml. Exception modes (no-shows, chargebacks, room upgrades) branch from the same entity lifecycle rather than independent random inserts.

flowchart LR
  BOOK[booked] --> SYNC[synced_to_pms]
  SYNC --> CHKIN[checked_in]
  CHKIN --> HOUSE[in_house]
  HOUSE --> CHKOUT[checked_out]
  CHKOUT --> SET[settled]
  SET --> PTS[points_posted]
  PTS --> OCC[occupancy_snapshotted]
  OCC --> OWN[owner_reported]
  OWN --> GL[posted_to_gl]
  SYNC -.->|no_show| NS[no_show]
  SET -.->|chargeback| CB[chargeback]
          

Bronze table categories

Same lineage envelope on every table; category controls live refresh vs micro-batch append.

Sample categories: All 62 bronze tables follow this three-category pattern (snapshot, transaction, event) with consistent metadata and state tracking; the diagram illustrates the pattern used across the full warehouse.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Property · brand · member masters"]
    S2[Daily full refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Reservations · folios · payments"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["HK · OTA · surveys · access"]
    E2[Append each live tick]
  end
  BRONZE[("hilson_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Company profile

Fictional company notice: "Cathea" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent Cathay Pacific Airways Limited, Cathay Pacific Group, or any real airline.

Cathea Pacific is a Hong Kong hub carrier headquartered at Cathea City, Chek Lap Kok — premium passenger (HP), air cargo and Cathea Cargo Terminal, Peak Express LCC (PX), and Air Harbour Express freighters (AH), plus Pacific Miles lifestyle. The network is HKG-timed: long-haul A350/777 rotations, night 747-8F waves, and A321neo regional hops.

The day runs NDC order → Altéa-class PNR and 168-prefix e-ticket → Adyen card capture → DCS check-in and bag scans → Navblue OFP, AIMS crew duty, and SITA MVT (including night cargo 01:00–05:00 HKT) → Pacific Miles accrual and Accelya rating → SAP S/4 journals. Cargo walks Cargospot booking → AWB → terminal acceptance → ULD scan → movement → OTM trucking → FPS collect — with a CNY travel / typhoon IRROPS lift that spikes Peak Express load factor, bag scans, and cargo waitlists.

Sample entities: The table below shows representative business entities and their source systems; the complete EDW includes additional entities, sub-types, and specialized tables (e.g., fuel uplifts, TRAX work orders, ULD scans, loyalty accruals) across all 60 bronze tables. In V2, Pnr and AirWaybill domain classes drive the OfferToFlyToRevenue and BookToDeliverCargo spines.

OOP domain model

CatheaEnterpriseSimulation sequences the day; domain objects own emission logic.

OfferToFlyToRevenue is the passenger spine; BookToDeliverCargo is the cargo spine. Pnr.execute_lifecycle() walks NDC order → Altéa PNR and e-ticket → Adyen capture → DCS check-in → flown coupon → Pacific Miles → Accelya → GL. AirWaybill.execute_lifecycle() walks Cargospot booking → AWB → CHT acceptance → ULD → SITA movement → OTM trucking → FPS collect. CatheaPortfolio.publish_foundation() masters aircraft, routes, stations, and HKG-timed flights before PNRs and AWBs run.

flowchart LR
  PORT[CatheaPortfolio.publish_foundation]
  PNR[Pnr.execute_lifecycle]
  AWB[AirWaybill.execute_lifecycle]
  PORT --> PNR
  PORT --> AWB
  PNR --> NDC[NDC order]
  NDC --> PSS[Altéa PNR / ticket]
  PSS --> DCS[DCS check-in]
  DCS --> GL[SAP S/4 journal]
  AWB --> CS[Cargospot AWB]
  CS --> CHT[CHT + ULD]
  CHT --> FPS[FPS collect]
          

Offer-to-fly and cargo value chain

From network master through passenger, cargo, ops, and finance close.

Sample view: This illustrates the primary value chain across the Cathea ecosystem; the full generated EDW includes all 40 source systems with cross-functional integrations, night cargo waves, and TRAX MRO not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph network["Network"]
    direction TB
    NET[cathea_network]
    SCM[oracle_scm station]
    NET ~~~ SCM
  end
  subgraph fly["Offer to fly"]
    direction TB
    NDC[cathea_ndc]
    PSS[amadeus_altea]
    DCS[amadeus_dcs]
    ADY[adyen]
    NDC ~~~ PSS
    PSS ~~~ DCS
  end
  subgraph cargo["Cargo"]
    direction TB
    CS[champ_cargospot]
    CHT[cathea_cht]
    OTM[oracle_otm]
    FPS[fps]
    CS ~~~ CHT
    CHT ~~~ OTM
  end
  subgraph ops["Ops"]
    direction TB
    NAV[navblue]
    AIMS[aims_crew]
    SITA[sita_typeb]
    NAV ~~~ AIMS
    AIMS ~~~ SITA
  end
  subgraph close["Revenue & close"]
    direction TB
    PM[cathea_loyalty]
    RA[accelya_ra]
    S4[sap_s4]
    PM ~~~ RA
    RA ~~~ S4
  end
  network --> fly --> cargo --> ops --> close
          

Functional org by department

Cathea City Chek Lap Kok HQ and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full Cathea organization includes additional outstations, GBA cargo desks, and shared-services functions across all 40 vendor integrations.

flowchart TB
  CEO[Cathea Pacific]
  CEO --> PREM[Premium Travel]
  CEO --> CARGO[Cargo & Logistics]
  CEO --> LCC[Peak Express LCC]
  CEO --> LIFE[Pacific Miles]
  CEO --> OPS[Flight ops]
  CEO --> FIN[Finance]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

EDW maturity stages

Catalog stage groups tables from foundation through corporate.

Sample breakdown shown: This is a representative slice of the full 60-table inventory distributed across maturity layers; the actual distribution reflects the complete data lineage from foundation through corporate gold tables.

flowchart LR
  F["network
~8 tables"]
  P["passenger
~10 tables"]
  C["cargo
~8 tables"]
  O["operations
~6 tables"]
  CO["corporate
~28 tables"]
  F --> P --> C --> O
  F -.-> CO
  C -.-> CO
          

Core business entities

Logical relationships and anchor keys. Flight (flight_id) and PNR (pnr_locator) are the passenger spine; AWB (awb_number) joins cargo via booking and FPS.

Sample diagram: This entity relationship diagram shows the core logical model; the full generated EDW contains 60 bronze tables across 40 vendor systems with additional detail tables and lineage branches. Entity instances carry entity_refs on every emitted event for joinability testing.

erDiagram
  AIRCRAFT ||--o{ FLIGHT : operates
  ROUTE ||--o{ FLIGHT : schedules
  FLIGHT ||--o{ PNR : carries
  PNR ||--o{ TICKET : issues
  TICKET ||--o{ CHECKIN : boards
  FLIGHT ||--o{ AWB : uplifts
  AWB ||--o{ FPS_PAYMENT : collects
  PNR ||--o{ LOYALTY_ACCRUAL : earns
          

Source system landscape

40 vendor prefixes, 60 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 40 systems with their full table lineage and integration points across history backfill and live streams. Shared source-system manifests in kb/source_systems/ are reused across industries — Cathea adds cathea_network, cathea_ndc, cathea_cht, and cathea_loyalty as industry-specific internal systems, plus Altéa PSS and Cargospot.

Each table follows the {source_system_}__{entity} naming convention (e.g. cathea_network__flight, amadeus_altea__pnr), preserving the vendor-native column shape and foreign keys from each product's real export schema. VibeBI infers master-data conformance when it promotes records to silver and gold.

flowchart TB
  subgraph foundation["Network"]
    direction TB
    f1["cathea_network aircraft · route · flight"]
    f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
  end
  subgraph passenger["Passenger"]
    direction TB
    p1["cathea_ndc · amadeus_altea · amadeus_dcs"]
    p2["adyen · cathea_loyalty"]
  end
  subgraph cargo["Cargo"]
    direction TB
    c1["champ_cargospot · cathea_cht · oracle_otm · fps"]
  end
  subgraph operations["Operations"]
    direction TB
    o1["navblue · aims_crew · sita_typeb · trax_mro · cathea_fuel"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["accelya_ra · sap_s4 journals · anaplan · adp · ukg"]
    co2["hubspot · marketo · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> passenger --> cargo --> operations
  foundation --> corporate
  cargo --> corporate
          

End-to-end data flow

V2 OOP sim → bronze in ClickHouse; VibeBI semantic → silver → gold on the same instance.

OOP path: kb/industries/cathea/ defines the operations spine and entity model; CatheaEnterpriseSimulation sequences domain lifecycles; SourceSystem adapters export vendor-native rows into cathea_v2.

flowchart LR
  subgraph kb["kb/industries/cathea"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/cathea"]
    ORCH[CatheaEnterpriseSimulation]
    DOM["Pnr · AirWaybill
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse cathea_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Live bronze cycle

./live-v2-cathea — 60s tick via CatheaEnterpriseSimulation.generate().

Live frequency: Each tick runs OfferToFlyToRevenue and BookToDeliverCargo — domain objects emit correlated NDC orders, PNRs, tickets, DCS scans, cargo AWBs, SITA movements, FPS collections, and GL rows; live ticks for today emit only events up to Hong Kong as_of so check-ins, bag scans, night cargo, and journals grow through the day. Scale varies per tick (default base 5). Backfill any history span you need (--days N on the live script or CLI).

flowchart LR
  START([60s tick]) --> SIM[CatheaEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> PNR[Pnr lifecycles]
  FOUND --> AWB[AirWaybill lifecycles]
  PNR --> CORP[Loyalty + RA + finance]
  AWB --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Offer-to-fly and cargo event graphs

OfferToFlyToRevenue and BookToDeliverCargo state machines — each transition is a domain method emitting vendor rows.

Process spine: Defined in kb/industries/cathea/process_model.yaml. Late-arrival modes (DCS scan lag, MVT lag, RA batch lag, GL batch posting delay) and exception modes (no-show, IRROPS delay, card refuse, short shipment, capacity waitlist) branch from the same entity lifecycles rather than independent random inserts.

flowchart LR
  OFF[offered] --> PNR[pnr_created]
  PNR --> TKT[ticketed]
  TKT --> CKIN[checked_in]
  CKIN --> BRD[boarded]
  BRD --> FLN[flown]
  FLN --> ACC[accrued]
  ACC --> RA[rated]
  RA --> GL[posted_to_gl]
  TKT -.->|card_refuse| REF[card_refused]
  CKIN -.->|no_show| NS[no_show]
          

flowchart LR
  BK[booked] --> AWB[awb_issued]
  AWB --> ACC[accepted]
  ACC --> ULD[uld_built]
  ULD --> DEP[departed]
  DEP --> TRK[trucked]
  TRK --> DLV[delivered]
  DLV --> COL[collected]
  COL --> GL[posted_to_gl]
  BK -.->|waitlist| WL[capacity_waitlist]
  ACC -.->|short| SH[short_shipment]
          

Bronze table categories

Same lineage envelope on every table; category drives live behavior.

Sample categories: All 60 bronze tables follow this three-category pattern (snapshot, transaction, event) with consistent metadata and state tracking; the diagram illustrates the pattern used across the full warehouse.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Aircraft · route · station · loyalty masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["PNRs · tickets · AWBs · FPS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["DCS scans · SITA MVT · bag events"]
    E2[Append each live tick]
  end
  BRONZE[("cathea_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Company profile

Fictional company notice: "P&C" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent The Procter & Gamble Company or any real CPG manufacturer.

P&C is a global consumer packaged goods manufacturer-marketer — a B2B2C model selling daily-use products through mass retail, club, grocery, and e-commerce channels across ~180 countries. Five Sector Business Units (SBUs) span Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care, and Grooming, with ~12 flagship brands (TidalWave, ComfortWrap, BrightSmile, EdgePro, and others) and eight manufacturing plants plus three regional distribution centers.

The business spans demand planning, raw-material procurement, MES production, quality release, finished-goods distribution, retail customer orders, trade marketing, and finance — generating correlated MES work orders, Ariba POs, OMS headers, OTM shipments, and SAP journal lines on each simulation day, with a Spring Clean surge (March–April) lifting fabric/home care demand, plant throughput, and retail sell-in across North America and EMEA.

Sample entities: The table below shows representative business entities and their source systems; the complete EDW includes additional entities, sub-types, and specialized tables (e.g., IoT sensor readings, maintenance work orders, trade promotions, CLM redlines) across all 60 bronze tables. In V2, ProductionBatch and CustomerOrder domain classes drive the MakeToShipToSell spine.

OOP domain model

PcEnterpriseSimulation sequences the day; domain objects own emission logic.

MakeToShipToSell is the primary process spine. ProductionBatch.execute_lifecycle() walks forecast → procure → produce → QC release → finished goods; CustomerOrder.execute_lifecycle() walks OMS capture → WMS fulfill → OTM ship. PcPortfolio.publish_foundation() masters SBUs, brands, plants, SKUs, and retail accounts before batches and orders run. Service objects (PlantOperations, CommercialProgram, FinanceAndCorporate) emit supporting corporate and marketing rows.

flowchart LR
  PORT[PcPortfolio.publish_foundation]
  BATCH[ProductionBatch.execute_lifecycle]
  ORDER[CustomerOrder.execute_lifecycle]
  PORT --> BATCH
  PORT --> ORDER
  BATCH --> FCST[BlueYonder forecast]
  FCST --> PO[Ariba PO]
  PO --> MES[SIEMENS MES work order]
  MES --> QC[MasterControl release]
  QC --> WMS[WMS finished goods]
  ORDER --> OMS[OMS order]
  OMS --> SHIP[OTM shipment]
  SHIP --> GL[SAP S/4 journal]
          

Make-to-ship value chain

From brand portfolio through plan, make, move, sell, and corporate close.

Sample view: This illustrates the primary value chain across the P&C ecosystem; the full generated EDW includes all 34 source systems with cross-functional integrations, IoT plant telemetry, and trade marketing flows not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph portfolio["Portfolio & R&D"]
    direction TB
    PCB[pc_brand SBU ladder]
    PIM[akeneo_pim SKU]
    PCB ~~~ PIM
  end
  subgraph plan["Plan & procure"]
    direction TB
    BY[blueyonder forecast]
    ARB[sap_ariba PO]
    BY ~~~ ARB
  end
  subgraph make["Make & quality"]
    direction TB
    MES[siemens_mes work order]
    MC[mastercontrol QC]
    MES ~~~ MC
  end
  subgraph move["Store & ship"]
    direction TB
    WMS[manhattan_wms inventory]
    OTM[oracle_otm TMS]
    WMS ~~~ OTM
  end
  subgraph sell["Sell to retail"]
    direction TB
    SF[salesforce trade]
    OMS[manhattan_oms orders]
    SF ~~~ OMS
  end
  subgraph corp["Corporate"]
    direction TB
    WD[workday]
    S4[sap_s4 GL]
    WD ~~~ S4
  end
  portfolio --> plan --> make --> move --> sell --> corp
          

Functional org by department

Global HQ Cincinnati and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full P&C organization includes regional SBU teams, plant managers, and shared-services functions across all 34 vendor integrations.

flowchart TB
  CEO[P&C Global]
  CEO --> SBU[SBU portfolio & R&D]
  CEO --> MFG[Supply chain & manufacturing]
  CEO --> COMM[Commercial & retail sales]
  CEO --> MKT[Marketing & brand]
  CEO --> FIN[Finance & controller]
  CEO --> HR[Human resources]
  CEO --> QUAL[Quality & regulatory]
  CEO --> LEG[IT / legal / security]
          

EDW maturity stages

Catalog stage groups tables from foundation through corporate.

Sample breakdown shown: This is a representative slice of the full 60-table inventory distributed across maturity layers; the actual distribution reflects the complete data lineage from foundation through corporate gold tables.

flowchart LR
  F["foundation
~13 tables"]
  SC["supply_chain
~10 tables"]
  D["distribution
~6 tables"]
  C["commercial
~16 tables"]
  CO["corporate
~15 tables"]
  F --> SC --> D --> C
  F -.-> CO
  C -.-> CO
          

Core business entities

Logical relationships and anchor keys. Brand (brand_code) and plant (facility_code) are the spine; material numbers link PIM to MES.

Sample diagram: This entity relationship diagram shows the core logical model; the full generated EDW contains 60 bronze tables across 34 vendor systems with additional detail tables and lineage branches. Entity instances carry entity_refs on every emitted event for joinability testing.

erDiagram
  BRAND ||--o{ PRODUCT : owns
  PRODUCT ||--o{ PRODUCTION_BATCH : produces
  PLANT ||--o{ PRODUCTION_BATCH : runs
  SUPPLIER ||--o{ PO : supplies
  PRODUCTION_BATCH ||--o{ PO : triggers
  PLANT ||--o{ INVENTORY : stocks
  RETAIL_CUSTOMER ||--o{ CUSTOMER_ORDER : places
  PRODUCT ||--o{ ORDER_LINE : contains
  CUSTOMER_ORDER ||--|{ ORDER_LINE : lines
  CUSTOMER_ORDER ||--o{ SHIPMENT : ships
  CUSTOMER_ORDER ||--o{ JOURNAL : posts
          

Source system landscape

34 vendor prefixes, 60 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 34 systems with their full table lineage and integration points across history backfill and live streams. Shared source-system manifests in kb/source_systems/ are reused across industries — P&C adds pc_brand as an industry-specific internal system.

Each table follows the {source_system_}__{entity} naming convention (e.g. pc_brand__brand, siemens_mes__work_order), preserving the vendor-native column shape and foreign keys from each product's real export schema. VibeBI infers master-data conformance when it promotes records to silver and gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["pc_brand · akeneo_pim
oracle_scm · workday"]
    f2["sap_s4 dimensions"]
  end
  subgraph supply_chain["Supply chain"]
    direction TB
    s1["blueyonder · sap_ariba
siemens_mes · mastercontrol"]
    s2["ibm_maximo · aws_iot"]
  end
  subgraph distribution["Distribution"]
    direction TB
    d1["manhattan_wms
oracle_otm"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce · manhattan_oms
hubspot · marketo"]
    c2["google_analytics · qualtrics · zendesk"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · coupa
adp · ukg · concur"]
    co2["servicenow · okta · splunk
ironclad · onetrust · greenhouse"]
  end
  foundation --> supply_chain --> distribution --> commercial
  foundation --> corporate
  commercial --> corporate
          

End-to-end data flow

V2 OOP sim → bronze in ClickHouse; VibeBI semantic → silver → gold on the same instance.

OOP path: kb/industries/pnc/ defines the operations spine and entity model; PcEnterpriseSimulation sequences domain lifecycles; SourceSystem adapters export vendor-native rows into pnc_v2.

flowchart LR
  subgraph kb["kb/industries/pnc"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/pnc"]
    ORCH[PcEnterpriseSimulation]
    DOM["ProductionBatch · CustomerOrder
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse pnc_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Live bronze cycle

./live-v2-pnc — 60s tick via PcEnterpriseSimulation.generate().

Live frequency: Each tick runs the MakeToShipToSell state machine — domain objects emit correlated forecast, PO, MES, WMS, OMS, OTM, and GL rows per production batch and retail customer order; scale varies per tick (default base 5). Backfill any history span you need (--days N on the live script or CLI).

flowchart LR
  START([60s tick]) --> SIM[PcEnterpriseSimulation.generate]
  SIM --> FOUND[PcPortfolio.publish_foundation]
  FOUND --> BATCH[ProductionBatch lifecycles]
  FOUND --> ORDER[CustomerOrder lifecycles]
  BATCH --> CORP[PlantOps + Finance + Commercial]
  ORDER --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Make-to-ship event graph

MakeToShipToSell state machine — each transition is a domain method emitting vendor rows.

Process spine: Defined in kb/industries/pnc/process_model.yaml. Exception modes (batch scrap, quality hold, partial shipment, supplier delay) branch from the same entity lifecycles rather than independent random inserts.

flowchart LR
  FCST[forecasted] --> PROC[materials_procured]
  PROC --> PROD[production_started]
  PROD --> QC[quality_released]
  QC --> FG[finished_goods_received]
  FG --> ORD[customer_ordered]
  ORD --> FUL[fulfilled]
  FUL --> SHIP[shipped]
  SHIP --> GL[posted_to_gl]
  PROD -.->|scrap| SCRAP[batch_scrap]
  QC -.->|hold| HOLD[quality_hold]
  FUL -.->|short| PART[partial_shipment]
          

Bronze table categories

Same lineage envelope on every table; category drives live behavior.

Sample categories: All 60 bronze tables follow this three-category pattern (snapshot, transaction, event) with consistent metadata and state tracking; the diagram illustrates the pattern used across the full warehouse.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Brand · plant · SKU masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["POs · work orders · OMS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["IoT · WMS movement · OTM tracking"]
    E2[Append each live tick]
  end
          BRONZE[("pnc_v2 bronze row")]
          snap --> BRONZE
          txn --> BRONZE
          evt --> BRONZE