Enterprise-scale sample warehouses.

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: "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
          

Company profile

Fictional company notice: "HKBC" is an entirely fictitious company created solely for demonstration purposes. It is not affiliated with, endorsed by, or intended to represent HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited, or any real bank.

HKBC (Hong Kong Banking Corporation) is a Hong Kong universal bank headquartered in Central, with Wealth and Personal Banking, Commercial Banking, and Global Banking and Markets. The franchise takes HKD deposits, originates HIBOR mortgages and unsecured credit, issues cards, runs 24×7 Faster Payment System and PearlPay (PayMe-class) rails, finances Greater Bay Area trade, and books USD/HKD and CNH FX inside the 7.75–7.85 convertibility band.

The book spans ~10 branches across Hong Kong Island, Kowloon, and the New Territories, plus a Qianhai GBA wholesale desk and a London markets desk — generating correlated FPS credits, card authorizations, CHATS/SWIFT transfers, core double-entry postings, AML alerts, and SAP journals on each simulation day, with a Lunar New Year / Q1 tax-loan surge that lifts PearlPay P2P volume, FPS collections, and personal-loan origination.

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., AML cases, ECL provisions, securities orders, facility redlines) across all 60 bronze tables. In V2, FpsPayment and related domain classes drive the PayToPostToBalance spine.

OOP domain model

HkbcEnterpriseSimulation sequences the day; domain objects own emission logic.

PayToPostToBalance is the primary process spine. FpsPayment.execute_lifecycle() (and PearlPay, card, CHATS, SWIFT counterparts) walks rail message → core double-entry posting → optional AML alert → EOD deposit balance → GL. HkbcPortfolio.publish_foundation() masters branches, products, CIF customers, and accounts before payments run. Service objects emit CMB trade, GBM FX, wealth, risk, and corporate rows.

flowchart LR
  PORT[HkbcPortfolio.publish_foundation]
  PAY[FpsPayment.execute_lifecycle]
  PORT --> PAY
  PAY --> RAIL[FPS / PearlPay / card / CHATS / SWIFT]
  RAIL --> CORE[post_pair in hkbc_core]
  CORE --> AML[Actimize AML]
  CORE --> EOD[EOD deposit balance]
  EOD --> GL[SAP S/4 journal]
          

Payments & franchise value chain

From CIF and product master through rails, core posting, risk, and finance close.

Sample view: This illustrates the primary value chain through the HKBC ecosystem; the full generated EDW includes all 32 source systems with cross-functional integrations, wealth dealing, and GBA trade corridors not shown here.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph master["CIF & product master"]
    direction TB
    CORE[hkbc_core CIF / account]
    SF[salesforce]
    CORE ~~~ SF
  end
  subgraph rails["Payments rails"]
    direction TB
    FPS[hkicl_fps]
    PP[hkbc_pay PearlPay]
    CARD[fiserv_visionplus]
    CHATS[hkicl_chats · swift]
  end
  subgraph book["Core & risk"]
    direction TB
    POST[hkbc_core posting]
    AML[nice_actimize]
    ECL[moodys_risk]
    POST ~~~ AML
    AML ~~~ ECL
  end
  subgraph franchise["CMB · GBM · WPB"]
    direction TB
    TRD[hkbc_trade]
    FX[murex]
    WLT[hkbc_wealth]
    TRD ~~~ FX
    FX ~~~ WLT
  end
  subgraph corp["Corporate"]
    direction TB
    WD[workday]
    S4[sap_s4 GL]
    WD ~~~ S4
  end
  master --> rails --> book --> franchise --> corp
          

Functional org by department

Harbourview Tower HQ and direct-report functions with representative source systems.

Sample org structure: This shows the primary reporting lines; the full HKBC organization includes additional district branches, GBA desks, and shared-services functions across all 32 vendor integrations.

flowchart TB
  CEO[HKBC Hong Kong]
  CEO --> WPB[Wealth & Personal Banking]
  CEO --> CMB[Commercial Banking]
  CEO --> GBM[Global Banking & Markets]
  CEO --> RISK[Risk & AML]
  CEO --> FIN[Finance & ALM]
  CEO --> HR[Human resources]
  CEO --> OPS[Operations & branches]
  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"]
  P["payments
~11 tables"]
  M["markets & risk
~12 tables"]
  C["commercial
~6 tables"]
  CO["corporate
~18 tables"]
  F --> P --> M --> C
  F -.-> CO
  P -.-> CO
          

Core business entities

Logical relationships and anchor keys. Customer (customer_id) and account (account_id) are the spine; payments join via source_txn_id.

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

erDiagram
  CUSTOMER ||--o{ ACCOUNT : holds
  PRODUCT ||--o{ ACCOUNT : defines
  BRANCH ||--o{ ACCOUNT : books
  ACCOUNT ||--o{ PAYMENT : pays
  ACCOUNT ||--o{ POSTING : ledgers
  ACCOUNT ||--o{ DEPOSIT_BALANCE : snapshots
  PAYMENT ||--o{ AML_ALERT : screens
  COMMERCIAL_CLIENT ||--o{ TRADE_CREDIT : finances
  ACCOUNT ||--o{ FX_TRADE : hedges
  ACCOUNT ||--o{ WEALTH_ORDER : deals
          

Source system landscape

32 vendor prefixes, 60 bronze tables.

Sample systems shown: The diagram below illustrates representative vendor systems; the complete generated dataset includes all 32 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 — HKBC adds hkbc_core, hkbc_pay, hkbc_trade, and hkbc_wealth as industry-specific internal systems, plus Hong Kong market rails.

Each table follows the {source_system_}__{entity} naming convention (e.g. hkbc_core__account, hkicl_fps__payment), 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["hkbc_core branch · product · CIF · account"]
    f2["salesforce · workday · sap_s4 dimensions"]
  end
  subgraph payments["Payments"]
    direction TB
    p1["hkicl_fps · hkbc_pay · fiserv_visionplus"]
    p2["hkicl_chats · swift · core posting"]
  end
  subgraph markets["Markets & risk"]
    direction TB
    m1["murex · bloomberg · hkbc_trade · hkbc_wealth"]
    m2["nice_actimize · moodys_risk"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce pipeline · hubspot · marketo"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · anaplan · adp · ukg"]
    co2["genesys · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> payments --> markets --> commercial
  foundation --> corporate
  payments --> corporate
          

End-to-end data flow

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

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

flowchart LR
  subgraph kb["kb/industries/hkbc"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/hkbc"]
    ORCH[HkbcEnterpriseSimulation]
    DOM["FpsPayment.execute_lifecycle()
Account · Customer · FxTrade …"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse hkbc_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-hkbc — 60s tick via HkbcEnterpriseSimulation.generate().

Live frequency: Each tick runs the PayToPostToBalance state machine — domain objects emit correlated FPS, PearlPay, card, CHATS, SWIFT, core posting, AML, and GL rows; live ticks for today emit only events up to Hong Kong as_of so the payment tape grows 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[HkbcEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> PAY[Payment lifecycles]
  FOUND --> MKT[Trade · FX · wealth · risk]
  PAY --> EVT[SourceSystem events]
  MKT --> EVT
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Pay-to-post event graph

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

Process spine: Defined in kb/industries/hkbc/process_model.yaml. Late-arrival modes (SWIFT ack lag, card clearing after auth, AML case lag, GL batch delay) and exception modes (FPS reject, card decline, AML hold, insufficient funds, LC discrepancy) branch from the same entity lifecycles rather than independent random inserts.

flowchart LR
  OPEN[account_opened] --> INIT[payment_initiated]
  INIT --> POST[core_posted]
  POST --> AML[aml_screened]
  AML --> CLR[cleared]
  CLR --> BAL[balance_snapshot]
  BAL --> GL[posted_to_gl]
  INIT -.->|fps_reject| REJ[fps_rejected]
  INIT -.->|card_decline| DEC[card_declined]
  POST -.->|aml_hold| HOLD[aml_hold]
          

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["CIF · product · branch · account"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Payments · postings · LC · FX · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["AML · card auth · access · NPS"]
    E2[Append each live tick]
  end
  BRONZE[("hkbc_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

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