À l'échelle entreprise entrepôts d'exemple.

Profil société

Avis société fictive : « Hilson » est une société entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est ni affiliée à Hilton Inc. ni à Hyatt Hotels Corporation, ni cautionnée par elles, et n'est pas destinée à représenter Hilton Inc., Hyatt Hotels Corporation, ni aucune société d'hospitalité réelle.

Hilson Hospitality Group est un opérateur hôtelier mondial avec ~680 établissements sur 18 marques — des drapeaux luxe (niveau Waldorf, niveau Conrad) au full-service (Hilson, niveau DoubleTree) jusqu'aux paliers select-service et extended-stay. Chaque établissement exploite un Opera PMS on-premise et un Amadeus CRS central, au service d'un mix de clients loisirs en transient, corporate négocié, et groupes/conventions.

L'activité couvre la fidélité (Hilson Honors avec des millions de membres), les ventes groupes et conventions (pipeline salesforce, blocs de chambres CPQ), les points de vente food & beverage (MICROS Simphony POS), le reporting propriétaire/franchise (relevés Oracle Fusion), et les fonctions corporate — générant environ 1 900 réservations PMS et 1 750 en-têtes de folio un jour ouvré typique, avec un pic de voyages d'été (juin–août) qui fait progresser l'occupation, l'ADR, les dépenses F&B et l'activité fidélité sur l'ensemble des établissements.

Entités d'exemple : Le tableau ci-dessous présente des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités supplémentaires, des sous-types et des tables spécialisées (p. ex. événements de canaux OTA, restrictions de plans tarifaires, accords juridiques de franchise, redlines deal-desk) sur l'ensemble des 62 tables bronze. En V2, StayReservation et les classes de domaine associées émettent des lignes PMS, CRS, folio et fidélité via des adaptateurs de systèmes source à mesure que le cycle de vie du séjour progresse.

Modèle de domaine OOP

HilsonEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

ReservationToLoyaltyAndOwnerReporting est l'épine dorsale processuelle principale. StayReservation.execute_lifecycle() parcourt réservation → sync PMS → charges folio → paiement → points fidélité → snapshot d'occupation → relevé propriétaire → GL. HilsonPortfolio.publish_foundation() maîtrise les marques, les établissements et les membres Honors avant l'exécution des réservations.

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]
          

Chaîne de valeur client et établissement

De la maîtrise marque et établissement jusqu'à la distribution, le séjour, le règlement et le reporting propriétaire.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème Hilson ; l'EDW généré complet inclut les 31 systèmes source avec intégrations transverses, flux de revenus secondaires et cycles de vie fidélité non représentés ici.

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

Organisation fonctionnelle par département

Siège d'entreprise et fonctions en report direct, avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting principales ; l'organisation Hilson complète inclut un management régional supplémentaire, des équipes spécifiques aux marques et des fonctions de services partagés sur les 31 intégrations fournisseurs.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 62 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables 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és métier cœur

Relations logiques et clés d'ancrage. Établissement (hotel_code) est l'épine dorsale ; identité client via Honors et les tables de séjour.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 62 tables bronze sur 31 systèmes fournisseurs avec des milliers de tables de détail supplémentaires et de branches de lignage.

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
          

Paysage des systèmes source

31 préfixes fournisseurs, 62 tables bronze.

Systèmes d'exemple affichés : Le diagramme ci-dessous illustre des systèmes fournisseurs représentatifs ; le jeu de données généré complet inclut les 31 systèmes avec leur lignage de tables complet et leurs points d'intégration sur le backfill historique et les flux live.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. oracle_opera__reservation, hilson_loyalty__member), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et 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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/hilson/ définit l'épine dorsale opérationnelle et le modèle d'entités ; HilsonEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

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

Fréquence en direct : Chaque tick exécute la machine à états réservation-vers-fidélité — les objets de domaine émettent des lignes corrélées CRS, PMS, folio, F&B, paiement, fidélité et GL ; l'échelle varie par tick (base par défaut 5). Reconstituez n'importe quelle profondeur d'historique dont vous avez besoin (--days N) ; Hilson inclut la détection de lacunes sur la table d'ancrage des réservations.

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
          

Graphe d'événements de séjour

Machine à états ReservationToLoyaltyAndOwnerReporting — chaque transition émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/hilson/process_model.yaml. Les modes d'exception (no-shows, rétrofacturations, surclassements de chambre) se ramifient à partir du même cycle de vie d'entité, plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le rafraîchissement live vs l'append en micro-batch.

Catégories d'exemple : Les 62 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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
          

Profil société

Avis société fictive : « P&C » est une société entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est ni affiliée à The Procter & Gamble Company ni cautionnée par elle, et n'est pas destinée à représenter The Procter & Gamble Company ni aucun fabricant CPG réel.

P&C est un fabricant-marketeur mondial de biens de consommation courante — un modèle B2B2C vendant des produits d'usage quotidien via le mass retail, le club, l'épicerie et les canaux e-commerce dans ~180 pays. Cinq Sector Business Units (SBU) couvrent Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care et Grooming, avec ~12 marques phares (TidalWave, ComfortWrap, BrightSmile, EdgePro, et d'autres) et huit usines de fabrication plus trois centres de distribution régionaux.

L'activité couvre la planification de la demande, l'approvisionnement en matières premières, la production MES, la libération qualité, la distribution de produits finis, les commandes clients retail, le trade marketing et la finance — générant des ordres de travail MES corrélés, des PO Ariba, des en-têtes OMS, des expéditions OTM et des lignes de journal SAP à chaque jour de simulation, avec un Pic Spring Clean (mars–avril) qui stimule la demande fabric/home care, le débit usine et le sell-in retail en Amérique du Nord et en EMEA.

Entités d'exemple : Le tableau ci-dessous présente des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités supplémentaires, des sous-types et des tables spécialisées (p. ex. lectures de capteurs IoT, ordres de travail de maintenance, promotions trade, redlines CLM) sur l'ensemble des 60 tables bronze. En V2, ProductionBatch et CustomerOrder les classes de domaine animent l'épine MakeToShipToSell.

Modèle de domaine OOP

PcEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

MakeToShipToSell est l'épine dorsale processuelle principale. ProductionBatch.execute_lifecycle() parcourt forecast → procurement → production → libération QC → produits finis ; CustomerOrder.execute_lifecycle() parcourt capture OMS → fulfillment WMS → expédition OTM. PcPortfolio.publish_foundation() maîtrise les SBU, marques, usines, SKU et comptes retail avant l'exécution des lots et des commandes. Les objets de service (PlantOperations, CommercialProgram, FinanceAndCorporate) émettent les lignes corporate et marketing de support.

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]
          

Chaîne de valeur make-to-ship

Du portefeuille de marques au plan, make, move, sell et clôture corporate.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème P&C ; l'EDW généré complet inclut les 34 systèmes source avec intégrations transverses, télémétrie IoT d'usine et flux de trade marketing non représentés ici.

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

Organisation fonctionnelle par département

Siège mondial Cincinnati et fonctions en report direct, avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting principales ; l'organisation P&C complète inclut des équipes SBU régionales, des responsables d'usine et des fonctions de services partagés sur les 34 intégrations fournisseurs.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables 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és métier cœur

Relations logiques et clés d'ancrage. Marque (brand_code) et usine (facility_code) forment l'épine dorsale ; les numéros matière relient le PIM au MES.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 34 systèmes fournisseurs avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

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
          

Paysage des systèmes source

34 préfixes fournisseurs, 60 tables bronze.

Systèmes d'exemple affichés : Le diagramme ci-dessous illustre des systèmes fournisseurs représentatifs ; le jeu de données généré complet inclut les 34 systèmes avec leur lignage de tables complet et leurs points d'intégration sur le backfill historique et les flux live. Les manifestes de systèmes source partagés dans kb/source_systems/ sont réutilisés d'un secteur à l'autre — P&C ajoute pc_brand comme système interne spécifique au secteur.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. pc_brand__brand, siemens_mes__work_order), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et 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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/pnc/ définit l'épine dorsale opérationnelle et le modèle d'entités ; PcEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

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

Fréquence en direct : Chaque tick exécute la machine à états MakeToShipToSell — les objets de domaine émettent des lignes corrélées de forecast, PO, MES, WMS, OMS, OTM et GL par lot de production et commande client retail ; l'échelle varie par tick (base par défaut 5). Reconstituez n'importe quelle profondeur d'historique dont vous avez besoin (--days N sur le script live ou le 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
          

Graphe d'événements make-to-ship

Machine à états MakeToShipToSell — chaque transition est une méthode de domaine émettant des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/pnc/process_model.yaml. Les modes d'exception (rebut de lot, blocage qualité, expédition partielle, retard fournisseur) se ramifient à partir des mêmes cycles de vie d'entités, plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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
          

Profil société

Avis société fictive : « HKBC » est une entreprise entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est pas affiliée à HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited, ni à aucune banque réelle, n'est pas approuvée par elles et n'est pas destinée à les représenter.

HKBC (Hong Kong Banking Corporation) est une banque universelle de Hong Kong dont le siège est à Central, avec Wealth and Personal Banking, Commercial Banking et Global Banking and Markets. La franchise collecte des dépôts HKD, origne des hypothèques HIBOR et du crédit non garanti, émet des cartes, opère 24×7 les rails Faster Payment System et PearlPay (classe PayMe), finance le commerce de la Greater Bay Area et enregistre le FX USD/HKD et CNH dans la bande de convertibilité 7,75–7,85.

Le livre couvre ~10 agences sur Hong Kong Island, Kowloon et les New Territories, plus un desk wholesale GBA à Qianhai et un desk markets à Londres — générant des crédits FPS, autorisations carte, virements CHATS/SWIFT, écritures en partie double, alertes AML et journaux SAP corrélés chaque jour de simulation, avec un Pic Nouvel An lunaire / prêt fiscal T1 qui soulève le volume P2P PearlPay, les encaissements FPS et l'origination de prêts personnels.

Entités d'exemple : Le tableau ci-dessous montre des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités, sous-types et tables spécialisées supplémentaires (p. ex. dossiers AML, provisions ECL, ordres titres, redlines de facilité) sur les 60 tables bronze. En V2, FpsPayment et les classes de domaine associées pilotent l'épine PayToPostToBalance.

Modèle de domaine OOP

HkbcEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

PayToPostToBalance est l'épine dorsale processuelle principale. FpsPayment.execute_lifecycle() (et les pendants PearlPay, carte, CHATS, SWIFT) parcourt message rail → écriture en partie double cœur → alerte AML optionnelle → solde de dépôt EOD → GL. HkbcPortfolio.publish_foundation() maîtrise agences, produits, clients CIF et comptes avant l'exécution des paiements. Les objets de service émettent des lignes CMB trade, GBM FX, wealth, risque et 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]
          

Chaîne de valeur paiements et franchise

Du master CIF et produit aux rails, posting cœur, risque et clôture finance.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème HKBC ; l'EDW généré complet inclut les 32 systèmes source avec intégrations transverses, dealing wealth et corridors commerciaux GBA non représentés ici.

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

Organisation fonctionnelle par département

Siège Harbourview Tower et fonctions en report direct avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting primaires ; l'organisation HKBC complète inclut des agences de district supplémentaires, des desks GBA et des fonctions de shared services sur les 32 intégrations fournisseur.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables 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és métier cœur

Relations logiques et clés d'ancrage. Client (customer_id) et compte (account_id) forment l'épine ; les paiements joignent via source_txn_id.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 32 systèmes fournisseur avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

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
          

Paysage des systèmes source

32 préfixes fournisseur, 60 tables bronze.

Systèmes d'exemple affichés : Le schéma ci-dessous illustre des systèmes fournisseur représentatifs ; le jeu de données généré complet inclut les 32 systèmes avec leur lignage de tables et points d'intégration sur le backfill d'historique et les flux live. Les manifests de systèmes source partagés dans kb/source_systems/ sont réutilisés entre secteurs — HKBC ajoute hkbc_core, hkbc_pay, hkbc_trade, et hkbc_wealth comme systèmes internes spécifiques au secteur, plus les rails de marché de Hong Kong.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. hkbc_core__account, hkicl_fps__payment), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et 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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/hkbc/ définit l'épine dorsale opérationnelle et le modèle d'entités ; HkbcEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

./live-v2-hkbc — tick de 60 s via HkbcEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute la machine d'états PayToPostToBalance — les objets de domaine émettent des lignes FPS, PearlPay, carte, CHATS, SWIFT, posting cœur, AML et GL corrélées ; les ticks live d'aujourd'hui n'émettent que les événements jusqu'à Hong Kong as_of afin que la bande de paiements croisse dans la journée. L'échelle varie par tick (base 5 par défaut). Remplissez toute plage d'historique dont vous avez besoin (--days N sur le script live ou le 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
          

Graphe d'événements pay-to-post

Machine d'états PayToPostToBalance — chaque transition est une méthode de domaine qui émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/hkbc/process_model.yaml. Les modes d'arrivée tardive (lag d'ack SWIFT, compensation carte après auth, lag de dossier AML, délai de lot GL) et les modes d'exception (rejet FPS, refus carte, hold AML, fonds insuffisants, discordance LC) partent des mêmes cycles de vie d'entité plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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
          

Profil société

Avis société fictive : « AYA » est une entreprise entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est pas affiliée à AXA SA, AXA Hong Kong and Macau, ni à aucune compagnie d'assurance réelle, n'est pas approuvée par elles et n'est pas destinée à les représenter.

AYA est un assureur composite de Hong Kong — Life & Savings, Health (y compris VHIS et avantages salariés) et General Insurance — distribué via agents liés, bancassurance, courtiers, l'application Aria by AYA et des partenaires e-wallet embarqués. Le siège est à Quarry Bay, avec un centre de conseil à Central, l'AYA Medical Centre à Tsim Sha Tsui, une succursale à Macao et un bureau commercial GBA à Qianhai.

L'activité couvre l'usine produit, la souscription classe Magnum, un PAS scindé (vie sur Ingenium, IARD sur Guidewire), l'encaissement de primes FPS, la commission Varicent, le FNOL auto/voyage 24×7, les sinistres santé FINEOS, la cession de réassurance, la valorisation Prophet IFRS 17 et les journaux SAP S/4 — avec un hausse des sinistres IARD en saison des typhons (juin–octobre) et un pic voyage CNY / motorisation northbound sur les canaux digitaux et agence.

Entités d'exemple : Le tableau ci-dessous montre des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités, sous-types et tables spécialisées supplémentaires (p. ex. Prophet BEL/CSM, cessions de traités, visites de centre médical, redlines CLM) sur les 60 tables bronze. En V2, LifePolicy et GiPolicy les classes de domaine pilotent les épines QuoteToBindToPremium et FnolToPay.

Modèle de domaine OOP

AyaEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

QuoteToBindToPremium est l'épine new business ; FnolToPay est l'épine sinistres. LifePolicy.execute_lifecycle() parcourt devis → UW Magnum → émission Ingenium → encaissement FPS → commission → GL. GiPolicy.execute_lifecycle() parcourt devis → bind PolicyCenter → facture BillingCenter → FNOL same-day optionnel sur ClaimCenter. AyaPortfolio.publish_foundation() maîtrise produits, agents, bureaux et souscripteurs avant l'exécution des polices.

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]
          

Chaîne de valeur quote-to-claim

De l'usine produit à la distribution, au bind, à l'encaissement, aux sinistres et à la clôture finance.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème AYA ; l'EDW généré complet inclut les 39 systèmes source avec intégrations transverses, visites cashless du centre médical et comptabilité de traités non représentées ici.

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

Organisation fonctionnelle par département

Siège AYA Tower Quarry Bay et fonctions en report direct avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting primaires ; l'organisation AYA complète inclut des districts d'agence supplémentaires, des équipes Macao et GBA, et des fonctions de shared services sur les 39 intégrations fournisseur.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables 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és métier cœur

Relations logiques et clés d'ancrage. Produit (product_code) et police (policy_number) forment l'épine ; les sinistres joignent via FNOL et numéros de sinistre.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 39 systèmes fournisseur avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

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
          

Paysage des systèmes source

39 préfixes fournisseur, 60 tables bronze.

Systèmes d'exemple affichés : Le schéma ci-dessous illustre des systèmes fournisseur représentatifs ; le jeu de données généré complet inclut les 39 systèmes avec leur lignage de tables et points d'intégration sur le backfill d'historique et les flux live. Les manifests de systèmes source partagés dans kb/source_systems/ sont réutilisés entre secteurs — AYA ajoute aya_product, aya_agency, aya_digital, et aya_health comme systèmes internes spécifiques au secteur, plus un PAS scindé (Guidewire + Ingenium).

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. aya_product__product, guidewire_cc__claim), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et 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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/aya/ définit l'épine dorsale opérationnelle et le modèle d'entités ; AyaEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

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

Fréquence en direct : Chaque tick exécute QuoteToBindToPremium et FnolToPay — les objets de domaine émettent des devis, décisions UW, binds PAS, encaissements FPS, commissions, FNOL et lignes GL corrélés ; les ticks live d'aujourd'hui n'émettent que les événements jusqu'à Hong Kong as_of afin que devis, FNOL, FPS et journaux croissent dans la journée. L'échelle varie par tick (base 5 par défaut). Remplissez toute plage d'historique dont vous avez besoin (--days N sur le script live ou le 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
          

Graphes d'événements quote-to-bind et FNOL

Machines d'états QuoteToBindToPremium et FnolToPay — chaque transition est une méthode de domaine qui émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/aya/process_model.yaml. Les modes d'arrivée tardive (lag d'émission PAS, compensation FPS, lot de commissions, FNOL de nuit, bordereau de réassurance) et les modes d'exception (référé/refus UW, laps de prime, sinistre refusé, règlement partiel) partent des mêmes cycles de vie d'entité plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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