Scala enterprise warehouse sample.

Profilo aziendale

Avviso sulle aziende fittizie: "Hilson" è un'azienda interamente fittizia, creata esclusivamente a scopo dimostrativo. Non è affiliata, sponsorizzata né destinata a rappresentare Hilton Inc., Hyatt Hotels Corporation o qualsiasi azienda dell'ospitalità reale.

Hilson Hospitality Group è un operatore alberghiero globale con circa 680 strutture su 18 brand — dalle insegne luxury (grado Waldorf, grado Conrad) al full-service (Hilson, grado DoubleTree) fino ai tier select-service ed extended-stay. Ogni struttura gira un Opera PMS on-premise e un Amadeus CRS centrale, servendo un mix di ospiti transient leisure, corporate negotiated e group/convention.

Il business copre loyalty (Hilson Honors con milioni di membri), group & convention sales (pipeline salesforce, room block CPQ), outlet food & beverage (MICROS Simphony POS), reporting owner/franchise (statement Oracle Fusion) e funzioni corporate — generando circa 1.900 reservation PMS e 1.750 testate folio in un giorno feriale tipico, con un picco di viaggi estivi (giugno–agosto) che alza occupancy, ADR, spesa F&B e attività loyalty su tutte le strutture.

Entità sample: La tabella sotto mostra entità di business rappresentative e i loro sistemi sorgente; l'EDW completo include entità aggiuntive, sotto-tipi e tabelle specializzate (es. eventi canale OTA, restrizioni di rate-plan, accordi legali franchise, redline deal-desk) su tutte le 62 tabelle bronze. In V2, StayReservation e le classi di domain correlate emettono righe PMS, CRS, folio e loyalty tramite adapter dei sistemi sorgente man mano che il ciclo di vita del soggiorno avanza.

Modello di domain OOP

HilsonEnterpriseSimulation sequenzia la giornata; gli oggetti di domain possiedono la logica di emissione.

ReservationToLoyaltyAndOwnerReporting è la spina dorsale di processo primaria. StayReservation.execute_lifecycle() percorre booking → sync PMS → addebiti folio → pagamento → punti loyalty → snapshot occupancy → statement owner → GL. HilsonPortfolio.publish_foundation() masterizza brand, property e membri Honors prima che partano le reservation.

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]
          

Catena del valore ospite e property

Dal master di brand e property fino a distribution, soggiorno, settlement e reporting per i proprietari.

Vista sample: Questo illustra la catena del valore primaria attraverso l'ecosistema Hilson; l'EDW generato completo include tutti i 31 sistemi sorgente con integrazioni cross-funzionali, flussi di ricavo secondari e cicli di vita loyalty non mostrati qui.

%%{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
          

Org funzionale per dipartimento

HQ enterprise e funzioni a riporto diretto con sistemi sorgente rappresentativi.

Struttura org sample: Questo mostra le linee di riporto primarie; l'organizzazione Hilson completa include management regionale aggiuntivo, team specifici di brand e funzioni di shared-services su tutte le 31 integrazioni vendor.

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]
          

Stadi di maturità EDW

Catalogo stage raggruppa le tabelle dalla foundation fino al corporate.

Ripartizione sample mostrata: Questa è una fetta rappresentativa dell'inventario completo di 62 tabelle distribuito sui layer di maturità; la distribuzione effettiva riflette il lineage dati completo dalla foundation fino alle tabelle gold corporate.

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
          

Entità di business core

Relazioni logiche e chiavi ancora. Property (hotel_code) è la spina dorsale; identità ospite tramite Honors e tabelle di soggiorno.

Diagramma sample: Questo diagramma di relazione tra entità mostra il modello logico core; l'EDW generato completo contiene 62 tabelle bronze in 31 sistemi vendor con migliaia di tabelle di dettaglio aggiuntive e rami di lineage.

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
          

Paesaggio dei sistemi sorgente

31 prefissi vendor, 62 tabelle bronze.

Sistemi sample mostrati: Il diagramma sotto illustra sistemi vendor rappresentativi; il dataset generato completo include tutti i 31 sistemi con il loro lineage di tabelle completo e i punti di integrazione su backfill storico e stream live.

Ogni tabella segue la {source_system_}__{entity} convenzione di naming (es. oracle_opera__reservation, hilson_loyalty__member), preservando la forma nativa delle colonne e le foreign key dello schema di export reale di ciascun prodotto. VibeBI inferisce la conformità dei master data quando promuove i record a silver e 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
          

Flusso dati end-to-end

Sim OOP V2 → bronze in ClickHouse; semantica VibeBI → silver → gold sulla stessa istanza.

Percorso OOP: kb/industries/hilson/ definisce la spina dorsale delle operations e il modello di entità; HilsonEnterpriseSimulation sequenzia i cicli di vita di domain; SourceSystem gli adapter esportano righe native del vendor in 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
          

Ciclo bronze live

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

Frequenza live: Ogni tick esegue la state machine reservation-to-loyalty — gli oggetti di domain emettono righe correlate di CRS, PMS, folio, F&B, pagamento, loyalty e GL; la scala varia per tick (base predefinita 5). Faccia backfill di qualsiasi arco di storia di cui ha bisogno (--days N); Hilson include il rilevamento dei gap sulla tabella ancora delle reservation.

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
          

Grafo eventi del soggiorno ospite

State machine ReservationToLoyaltyAndOwnerReporting — ogni transizione emette righe vendor.

Spina dorsale di processo: Definito in kb/industries/hilson/process_model.yaml. Le modalità di eccezione (no-show, chargeback, upgrade di camera) si ramificano dallo stesso ciclo di vita dell'entità, invece di insert casuali indipendenti.

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]
          

Categorie delle tabelle bronze

Stesso envelope di lineage su ogni tabella; la categoria controlla refresh live vs append in micro-batch.

Categorie sample: Tutte le 62 tabelle bronze seguono questo schema a tre categorie (snapshot, transaction, event) con metadati e tracciamento di stato coerenti; il diagramma illustra il pattern usato sull'intero 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
          

Profilo aziendale

Avviso sulle aziende fittizie: "P&C" è un'azienda interamente fittizia, creata esclusivamente a scopo dimostrativo. Non è affiliata, sponsorizzata né destinata a rappresentare The Procter & Gamble Company o qualsiasi produttore CPG reale.

P&C è un produttore-marketer globale di beni di largo consumo — un modello B2B2C che vende prodotti di uso quotidiano attraverso mass retail, club, grocery e canali e-commerce in circa 180 Paesi. Cinque Sector Business Unit (SBU) coprono Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care e Grooming, con circa 12 brand di punta (TidalWave, ComfortWrap, BrightSmile, EdgePro e altri) e otto impianti di produzione più tre centri di distribuzione regionali.

Il business copre demand planning, procurement di materie prime, produzione MES, rilascio qualità, distribuzione finished-goods, ordini clienti retail, trade marketing e finance — generando work order MES correlati, PO Ariba, testate OMS, spedizioni OTM e righe giornale SAP in ciascun giorno di simulazione, con un Picco Spring Clean (marzo–aprile) che alza la domanda di fabric/home care, il throughput di impianto e il sell-in retail in Nord America ed EMEA.

Entità sample: La tabella sotto mostra entità di business rappresentative e i loro sistemi sorgente; l'EDW completo include entità aggiuntive, sotto-tipi e tabelle specializzate (es. letture di sensori IoT, work order di manutenzione, trade promotion, redline CLM) su tutte le 60 tabelle bronze. In V2, ProductionBatch e CustomerOrder le classi di domain guidano la spina dorsale MakeToShipToSell.

Modello di domain OOP

PcEnterpriseSimulation sequenzia la giornata; gli oggetti di domain possiedono la logica di emissione.

MakeToShipToSell è la spina dorsale di processo primaria. ProductionBatch.execute_lifecycle() percorre forecast → procure → produce → rilascio QC → finished goods; CustomerOrder.execute_lifecycle() percorre capture OMS → fulfill WMS → ship OTM. PcPortfolio.publish_foundation() masterizza SBU, brand, impianti, SKU e account retail prima che partano lotti e ordini. Gli oggetti di servizio (PlantOperations, CommercialProgram, FinanceAndCorporate) emettono le righe di supporto corporate e marketing.

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]
          

Catena del valore make-to-ship

Dal portafoglio brand fino a plan, make, move, sell e chiusura corporate.

Vista sample: Questo illustra la catena del valore primaria nell'ecosistema P&C; l'EDW generato completo include tutti i 34 sistemi sorgente con integrazioni cross-funzionali, telemetria IoT di impianto e flussi di trade marketing non mostrati qui.

%%{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
          

Org funzionale per dipartimento

HQ globale a Cincinnati e funzioni a riporto diretto con sistemi sorgente rappresentativi.

Struttura org sample: Questo mostra le linee di riporto primarie; l'organizzazione P&C completa include team SBU regionali, plant manager e funzioni di shared-services su tutte le 34 integrazioni vendor.

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]
          

Stadi di maturità EDW

Catalogo stage raggruppa le tabelle dalla foundation fino al corporate.

Ripartizione sample mostrata: Questa è una fetta rappresentativa dell'inventario completo di 60 tabelle distribuito sui layer di maturità; la distribuzione effettiva riflette il lineage dati completo dalla foundation fino alle tabelle gold corporate.

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
          

Entità di business core

Relazioni logiche e chiavi ancora. Brand (brand_code) e impianto (facility_code) sono la spina dorsale; i numeri materiale collegano PIM a MES.

Diagramma sample: Questo diagramma di relazione tra entità mostra il modello logico core; l'EDW generato completo contiene 60 tabelle bronze in 34 sistemi vendor con tabelle di dettaglio aggiuntive e rami di lineage. Le istanze di entità portano entity_refs su ogni evento emesso per i test di joinability.

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
          

Paesaggio dei sistemi sorgente

34 prefissi vendor, 60 tabelle bronze.

Sistemi sample mostrati: Il diagramma sotto illustra sistemi vendor rappresentativi; il dataset generato completo include tutti i 34 sistemi con il loro lineage di tabelle completo e i punti di integrazione su backfill storico e stream live. Manifest condivisi dei sistemi sorgente in kb/source_systems/ sono riutilizzati tra i settori — P&C aggiunge pc_brand come sistema interno specifico di settore.

Ogni tabella segue la {source_system_}__{entity} convenzione di naming (es. pc_brand__brand, siemens_mes__work_order), preservando la forma nativa delle colonne e le foreign key dello schema di export reale di ciascun prodotto. VibeBI inferisce la conformità dei master data quando promuove i record a silver e 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
          

Flusso dati end-to-end

Sim OOP V2 → bronze in ClickHouse; semantica VibeBI → silver → gold sulla stessa istanza.

Percorso OOP: kb/industries/pnc/ definisce la spina dorsale delle operations e il modello di entità; PcEnterpriseSimulation sequenzia i cicli di vita di domain; SourceSystem gli adapter esportano righe native del vendor in 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
          

Ciclo bronze live

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

Frequenza live: Ogni tick esegue la state machine MakeToShipToSell — gli oggetti di domain emettono righe correlate di forecast, PO, MES, WMS, OMS, OTM e GL per lotto di produzione e ordine cliente retail; la scala varia per tick (base predefinita 5). Faccia backfill di qualsiasi arco di storia di cui ha bisogno (--days N sullo script live o sulla 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
          

Grafo eventi make-to-ship

State machine MakeToShipToSell — ogni transizione è un metodo di domain che emette righe vendor.

Spina dorsale di processo: Definito in kb/industries/pnc/process_model.yaml. Le modalità di eccezione (scarto di lotto, blocco qualità, spedizione parziale, ritardo fornitore) si ramificano dagli stessi cicli di vita delle entità, invece di insert casuali indipendenti.

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]
          

Categorie delle tabelle bronze

Stesso envelope di lineage su ogni tabella; la categoria guida il comportamento live.

Categorie sample: Tutte le 60 tabelle bronze seguono questo schema a tre categorie (snapshot, transaction, event) con metadati e tracciamento di stato coerenti; il diagramma illustra il pattern usato sull'intero 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
          

Profilo aziendale

Avviso sulle aziende fittizie: «HKBC» è un'azienda interamente fittizia, creata esclusivamente a fini dimostrativi. Non è affiliata a, approvata da, né destinata a rappresentare HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited o qualsiasi banca reale.

HKBC (Hong Kong Banking Corporation) è una banca universale di Hong Kong con sede a Central, con Wealth and Personal Banking, Commercial Banking e Global Banking and Markets. Il franchise raccoglie depositi HKD, origina mutui HIBOR e credito unsecured, emette carte, gestisce 24×7 i rail Faster Payment System e PearlPay (classe PayMe), finanzia il commercio della Greater Bay Area e registra FX USD/HKD e CNH nella banda di convertibilità 7,75–7,85.

Il book copre ~10 filiali su Hong Kong Island, Kowloon e New Territories, più un desk wholesale GBA a Qianhai e un desk markets a Londra — generando crediti FPS, autorizzazioni carta, trasferimenti CHATS/SWIFT, posting in partita doppia, alert AML e journal SAP correlati ogni giorno di simulazione, con un Surge Capodanno lunare / tax-loan Q1 che alza il volume P2P PearlPay, gli incassi FPS e l'origination di prestiti personali.

Entità sample: La tabella sotto mostra entità di business rappresentative e i loro sistemi sorgente; l'EDW completo include entità, sottotipi e tabelle specializzate aggiuntive (es. casi AML, accantonamenti ECL, ordini titoli, redline di facility) su tutte le 60 tabelle bronze. In V2, FpsPayment e le relative classi di domain guidano lo spine PayToPostToBalance.

Modello di domain OOP

HkbcEnterpriseSimulation sequenzia la giornata; gli oggetti di domain possiedono la logica di emissione.

PayToPostToBalance è la spina dorsale di processo primaria. FpsPayment.execute_lifecycle() (e le controparti PearlPay, carta, CHATS, SWIFT) percorre messaggio rail → posting in partita doppia core → alert AML opzionale → saldo depositi EOD → GL. HkbcPortfolio.publish_foundation() masterizza filiali, prodotti, clienti CIF e conti prima che girino i pagamenti. Gli oggetti di servizio emettono righe CMB trade, GBM FX, wealth, rischio e corporate.

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]
          

Catena del valore pagamenti e franchise

Dal master CIF e prodotto attraverso rail, posting core, rischio e chiusura finance.

Vista sample: Questo illustra la catena del valore primaria attraverso l'ecosistema HKBC; l'EDW generato completo include tutti i 32 sistemi sorgente con integrazioni cross-funzionali, wealth dealing e corridoi commerciali GBA non mostrati qui.

%%{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
          

Org funzionale per dipartimento

HQ Harbourview Tower e funzioni in riporto diretto con sistemi sorgente rappresentativi.

Struttura org sample: Questo mostra le linee di reporting primarie; l'organizzazione HKBC completa include filiali distrettuali aggiuntive, desk GBA e funzioni shared services su tutte le 32 integrazioni vendor.

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]
          

Stadi di maturità EDW

Catalogo stage raggruppa le tabelle dalla foundation fino al corporate.

Ripartizione sample mostrata: Questa è una fetta rappresentativa dell'inventario completo di 60 tabelle distribuito sui layer di maturità; la distribuzione effettiva riflette il lineage dati completo dalla foundation fino alle tabelle gold corporate.

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
          

Entità di business core

Relazioni logiche e chiavi di ancoraggio. Cliente (customer_id) e conto (account_id) sono lo spine; i pagamenti si uniscono via source_txn_id.

Diagramma sample: Questo diagramma di relazione tra entità mostra il modello logico core; l'EDW generato completo contiene 60 tabelle bronze in 32 sistemi vendor con tabelle di dettaglio aggiuntive e rami di lineage. Le istanze di entità portano entity_refs su ogni evento emesso per i test di joinability.

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
          

Paesaggio dei sistemi sorgente

32 prefissi vendor, 60 tabelle bronze.

Sistemi sample mostrati: Il diagramma sotto illustra sistemi vendor rappresentativi; il dataset generato completo include tutti i 32 sistemi con lineage tabelle e punti di integrazione su history backfill e stream live. I manifest dei sistemi sorgente condivisi in kb/source_systems/ sono riutilizzati tra i settori — HKBC aggiunge hkbc_core, hkbc_pay, hkbc_trade, e hkbc_wealth come sistemi interni specifici del settore, più i rail di mercato di Hong Kong.

Ogni tabella segue la {source_system_}__{entity} convenzione di naming (es. hkbc_core__account, hkicl_fps__payment), preservando la forma nativa delle colonne e le foreign key dello schema di export reale di ciascun prodotto. VibeBI inferisce la conformità dei master data quando promuove i record a silver e 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
          

Flusso dati end-to-end

Sim OOP V2 → bronze in ClickHouse; semantica VibeBI → silver → gold sulla stessa istanza.

Percorso OOP: kb/industries/hkbc/ definisce la spina dorsale delle operations e il modello di entità; HkbcEnterpriseSimulation sequenzia i cicli di vita di domain; SourceSystem gli adapter esportano righe native del vendor in 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
          

Ciclo bronze live

./live-v2-hkbc — tick da 60s tramite HkbcEnterpriseSimulation.generate().

Frequenza live: Ogni tick esegue la state machine PayToPostToBalance — gli oggetti di domain emettono righe FPS, PearlPay, carta, CHATS, SWIFT, posting core, AML e GL correlate; i tick live di oggi emettono solo eventi fino a Hong Kong as_of così il nastro pagamenti cresce durante il giorno. La scala varia per tick (base predefinita 5). Faccia backfill di qualsiasi arco di history di cui ha bisogno (--days N sullo script live o sulla 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
          

Grafo eventi pay-to-post

State machine PayToPostToBalance — ogni transizione è un metodo di domain che emette righe vendor.

Spina dorsale di processo: Definito in kb/industries/hkbc/process_model.yaml. I modi di arrivo tardivo (lag ack SWIFT, clearing carta dopo auth, lag caso AML, ritardo batch GL) e i modi di eccezione (rifiuto FPS, declino carta, hold AML, fondi insufficienti, discrepanza LC) si ramificano dagli stessi cicli di vita dell'entità invece che da insert casuali indipendenti.

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]
          

Categorie delle tabelle bronze

Stesso envelope di lineage su ogni tabella; la categoria guida il comportamento live.

Categorie sample: Tutte le 60 tabelle bronze seguono questo schema a tre categorie (snapshot, transaction, event) con metadati e tracciamento di stato coerenti; il diagramma illustra il pattern usato sull'intero 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
          

Profilo aziendale

Avviso sulle aziende fittizie: «AYA» è un'azienda interamente fittizia, creata esclusivamente a fini dimostrativi. Non è affiliata a, approvata da, né destinata a rappresentare AXA SA, AXA Hong Kong and Macau o qualsiasi compagnia assicurativa reale.

AYA è un assicuratore composito di Hong Kong — Life & Savings, Health (incluso VHIS e employee benefits) e General Insurance — distribuito tramite agenti vincolati, bancassurance, broker, l'app Aria by AYA e partner e-wallet embedded. HQ a Quarry Bay, con advisory centre a Central, AYA Medical Centre a Tsim Sha Tsui, una filiale a Macao e un ufficio vendite GBA a Qianhai.

Il business copre product factory, underwriting classe Magnum, PAS diviso (vita su Ingenium, danni su Guidewire), incasso premi FPS, commissione Varicent, FNOL auto/viaggio 24×7, sinistri salute FINEOS, cessione riassicurativa, valutazione Prophet IFRS 17 e journal SAP S/4 — con un rialzo sinistri danni in stagione tifoni (giugno–ottobre) e un picco viaggi CNY / motor northbound sui canali digitali e agenzia.

Entità sample: La tabella sotto mostra entità di business rappresentative e i loro sistemi sorgente; l'EDW completo include entità, sottotipi e tabelle specializzate aggiuntive (es. Prophet BEL/CSM, cessioni trattato, visite medical centre, redline CLM) su tutte le 60 tabelle bronze. In V2, LifePolicy e GiPolicy le classi di domain guidano gli spine QuoteToBindToPremium e FnolToPay.

Modello di domain OOP

AyaEnterpriseSimulation sequenzia la giornata; gli oggetti di domain possiedono la logica di emissione.

QuoteToBindToPremium è lo spine new business; FnolToPay è lo spine sinistri. LifePolicy.execute_lifecycle() percorre quote → UW Magnum → emissione Ingenium → incasso FPS → commissione → GL. GiPolicy.execute_lifecycle() percorre quote → bind PolicyCenter → fattura BillingCenter → FNOL same-day opzionale su ClaimCenter. AyaPortfolio.publish_foundation() masterizza prodotti, agenti, uffici e contraenti prima che girino le polizze.

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]
          

Catena del valore quote-to-claim

Dalla product factory attraverso distribuzione, bind, incasso, sinistri e chiusura finance.

Vista sample: Questo illustra la catena del valore primaria attraverso l'ecosistema AYA; l'EDW generato completo include tutti i 39 sistemi sorgente con integrazioni cross-funzionali, visite cashless del medical centre e contabilità di trattato non mostrate qui.

%%{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
          

Org funzionale per dipartimento

HQ AYA Tower Quarry Bay e funzioni in riporto diretto con sistemi sorgente rappresentativi.

Struttura org sample: Questo mostra le linee di reporting primarie; l'organizzazione AYA completa include distretti agenzia aggiuntivi, team Macao e GBA e funzioni shared services su tutte le 39 integrazioni vendor.

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]
          

Stadi di maturità EDW

Catalogo stage raggruppa le tabelle dalla foundation fino al corporate.

Ripartizione sample mostrata: Questa è una fetta rappresentativa dell'inventario completo di 60 tabelle distribuito sui layer di maturità; la distribuzione effettiva riflette il lineage dati completo dalla foundation fino alle tabelle gold corporate.

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
          

Entità di business core

Relazioni logiche e chiavi di ancoraggio. Prodotto (product_code) e polizza (policy_number) sono lo spine; i sinistri si uniscono via FNOL e numeri di claim.

Diagramma sample: Questo diagramma di relazione tra entità mostra il modello logico core; l'EDW generato completo contiene 60 tabelle bronze in 39 sistemi vendor con tabelle di dettaglio aggiuntive e rami di lineage. Le istanze di entità portano entity_refs su ogni evento emesso per i test di joinability.

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
          

Paesaggio dei sistemi sorgente

39 prefissi vendor, 60 tabelle bronze.

Sistemi sample mostrati: Il diagramma sotto illustra sistemi vendor rappresentativi; il dataset generato completo include tutti i 39 sistemi con lineage tabelle e punti di integrazione su history backfill e stream live. I manifest dei sistemi sorgente condivisi in kb/source_systems/ sono riutilizzati tra i settori — AYA aggiunge aya_product, aya_agency, aya_digital, e aya_health come sistemi interni specifici del settore, più un PAS diviso (Guidewire + Ingenium).

Ogni tabella segue la {source_system_}__{entity} convenzione di naming (es. aya_product__product, guidewire_cc__claim), preservando la forma nativa delle colonne e le foreign key dello schema di export reale di ciascun prodotto. VibeBI inferisce la conformità dei master data quando promuove i record a silver e 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
          

Flusso dati end-to-end

Sim OOP V2 → bronze in ClickHouse; semantica VibeBI → silver → gold sulla stessa istanza.

Percorso OOP: kb/industries/aya/ definisce la spina dorsale delle operations e il modello di entità; AyaEnterpriseSimulation sequenzia i cicli di vita di domain; SourceSystem gli adapter esportano righe native del vendor in 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
          

Ciclo bronze live

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

Frequenza live: Ogni tick esegue QuoteToBindToPremium e FnolToPay — gli oggetti di domain emettono quote, decisioni UW, bind PAS, incassi FPS, commissioni, FNOL e righe GL correlati; i tick live di oggi emettono solo eventi fino a Hong Kong as_of così quote, FNOL, FPS e journal crescono durante il giorno. La scala varia per tick (base predefinita 5). Faccia backfill di qualsiasi arco di history di cui ha bisogno (--days N sullo script live o sulla 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
          

Grafi eventi quote-to-bind e FNOL

State machine QuoteToBindToPremium e FnolToPay — ogni transizione è un metodo di domain che emette righe vendor.

Spina dorsale di processo: Definito in kb/industries/aya/process_model.yaml. I modi di arrivo tardivo (lag di emissione PAS, clearing FPS, batch commissioni, FNOL notturno, bordereau riassicurativo) e i modi di eccezione (UW refer/rifiuto, lapse premio, sinistro negato, liquidazione parziale) si ramificano dagli stessi cicli di vita dell'entità invece che da insert casuali indipendenti.

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]
          

Categorie delle tabelle bronze

Stesso envelope di lineage su ogni tabella; la categoria guida il comportamento live.

Categorie sample: Tutte le 60 tabelle bronze seguono questo schema a tre categorie (snapshot, transaction, event) con metadati e tracciamento di stato coerenti; il diagramma illustra il pattern usato sull'intero 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