Enterprise-Maßstab Beispiel-Warehouses.

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „Hilson“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit Hilton Inc., Hyatt Hotels Corporation noch mit einem realen Hospitality-Unternehmen verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

Hilson Hospitality Group ist ein globaler Hotelbetreiber mit ~680 Häusern über 18 Marken — von Luxury-Flags (Waldorf-Grade, Conrad-Grade) über Full-Service (Hilson, DoubleTree-Grade) bis Select-Service und Extended-Stay. Jedes Haus betreibt ein On-Premise Opera PMS und ein zentrales Amadeus CRS und bedient einen Mix aus Transient Leisure, Corporate Negotiated und Group/Convention.

Das Geschäft umfasst Loyalty (Hilson Honors mit Millionen Mitgliedern), Group- & Convention-Sales (Salesforce-Pipeline, CPQ-Zimmerblöcke), Food- & Beverage-Outlets (MICROS Simphony POS), Owner-/Franchise-Reporting (Oracle-Fusion-Statements) und Corporate-Funktionen — an einem typischen Wochentag rund 1.900 PMS-Reservierungen und 1.750 Folio-Köpfe, mit einem Sommerreise-Schub (Juni–August), der Auslastung, ADR, F&B-Umsatz und Loyalty-Aktivität über alle Häuser steigert.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäftsobjekte und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und Spezialtabellen (z. B. OTA-Kanalereignisse, Rate-Plan-Restriktionen, Franchise-Rechtsvereinbarungen, Deal-Desk-Redlines) über alle 62 Bronze-Tabellen. In V2 StayReservation und verwandte Domänenklassen erzeugen PMS-, CRS-, Folio- und Loyalty-Zeilen über Quellsystem-Adapter, während der Stay-Lebenszyklus fortschreitet.

OOP-Domänenmodell

HilsonEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

ReservationToLoyaltyAndOwnerReporting ist das primäre Prozess-Rückgrat. StayReservation.execute_lifecycle() führt Booking → PMS-Sync → Folio-Charges → Payment → Loyalty-Punkte → Occupancy-Snapshot → Owner Statement → GL. HilsonPortfolio.publish_foundation() mastert Marken, Properties und Honors-Mitglieder, bevor Reservierungen laufen.

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]
          

Gäste- und Property-Wertschöpfungskette

Vom Marken- und Property-Master über Distribution, Aufenthalt, Settlement und Owner-Reporting.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das Hilson-Ökosystem; das vollständig erzeugte EDW umfasst alle 31 Quellsysteme mit funktionsübergreifenden Integrationen, sekundären Umsatzströmen und hier nicht gezeigten Loyalty-Lebenszyklusflüssen.

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

Funktionale Organisation nach Abteilung

Enterprise-Zentrale und direkt unterstellte Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige Hilson-Organisation umfasst zusätzliches Regional Management, markenspezifische Teams und Shared-Services-Funktionen über alle 31 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 62-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Property (hotel_code) ist das Rückgrat; Gästeidentität über Honors und Stay-Tabellen.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 62 Bronze-Tabellen über 31 Vendor-Systeme mit Tausenden zusätzlicher Detailtabellen und Lineage-Zweigen.

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
          

Quellsystemlandschaft

31 Vendor-Präfixe, 62 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 31 Systeme mit ihrer vollständigen Tabellen-Lineage und den Integrationspunkten über History-Backfill und Live-Streams.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. oracle_opera__reservation, hilson_loyalty__member), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/hilson/ definiert das Operations-Rückgrat und das Entitätsmodell; HilsonEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen 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
          

Live-Bronze-Zyklus

./live-v2-hilson — 60s-Tick über HilsonEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt die Reservation-to-Loyalty-State-Machine aus — Domänenobjekte erzeugen korrelierte CRS-, PMS-, Folio-, F&B-, Payment-, Loyalty- und GL-Zeilen; die Skalierung variiert pro Tick (Standardbasis 5). Backfillen Sie jede benötigte Historie (--days N); Hilson enthält Lückenerkennung auf der Reservierungs-Ankertabelle.

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 — jeder Übergang erzeugt Vendor-Zeilen.

Prozess-Rückgrat: Definiert in kb/industries/hilson/process_model.yaml. Ausnahmezustände (No-Shows, Chargebacks, Zimmer-Upgrades) zweigen vom selben Entitätslebenszyklus ab, statt als unabhängige Zufallsinserts.

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-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert Live-Refresh vs. Micro-Batch-Append.

Beispielkategorien: Alle 62 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „P&C“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit The Procter & Gamble Company noch mit einem realen CPG-Hersteller verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

P&C ist ein globaler Hersteller-Vermarkter von Konsumgütern — ein B2B2C-Modell, das Alltagsprodukte über Mass Retail, Club, Grocery und E-Commerce in ~180 Ländern verkauft. Fünf Sector Business Units (SBUs) umfassen Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care und Grooming, mit ~12 Flagship-Marken (TidalWave, ComfortWrap, BrightSmile, EdgePro und andere) sowie acht Werken und drei regionalen Distributionszentren.

Das Geschäft umfasst Demand Planning, Rohstoffbeschaffung, MES-Produktion, Qualitätsfreigabe, Fertigwarenverteilung, Retail-Kundenaufträge, Trade Marketing und Finance — und erzeugt korrelierte MES-Work-Orders, Ariba-POs, OMS-Köpfe, OTM-Sendungen und SAP-Journalzeilen an jedem Simulationstag, mit einem Spring-Clean-Schub (März–April), der die Nachfrage in Fabric/Home Care, den Werkdurchsatz und den Retail-Sell-in in Nordamerika und EMEA anhebt.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäftsobjekte und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und Spezialtabellen (z. B. IoT-Sensorwerte, Instandhaltungsaufträge, Trade Promotions, CLM-Redlines) über alle 60 Bronze-Tabellen. In V2 ProductionBatch und CustomerOrder Domänenklassen treiben das MakeToShipToSell-Rückgrat.

OOP-Domänenmodell

PcEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

MakeToShipToSell ist das primäre Prozess-Rückgrat. ProductionBatch.execute_lifecycle() führt Forecast → Procure → Produce → QC-Release → Fertigerzeugnisse; CustomerOrder.execute_lifecycle() führt OMS-Capture → WMS-Fulfill → OTM-Ship. PcPortfolio.publish_foundation() mastert SBUs, Marken, Werke, SKUs und Retail-Accounts, bevor Chargen und Aufträge laufen. Serviceobjekte (PlantOperations, CommercialProgram, FinanceAndCorporate) erzeugen unterstützende Corporate- und Marketing-Zeilen.

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-Wertschöpfungskette

Vom Markenportfolio über Plan, Make, Move, Sell und Corporate Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette über das P&C-Ökosystem; das vollständig erzeugte EDW umfasst alle 34 Quellsysteme mit funktionsübergreifenden Integrationen, IoT-Werktelemetrie und hier nicht gezeigten Trade-Marketing-Flüssen.

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

Funktionale Organisation nach Abteilung

Globale Zentrale Cincinnati und direkt unterstellte Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige P&C-Organisation umfasst regionale SBU-Teams, Werksleiter und Shared-Services-Funktionen über alle 34 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Marke (brand_code) und Werk (facility_code) bilden das Rückgrat; Materialnummern verbinden PIM mit MES.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 34 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

34 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 34 Systeme mit ihrer vollständigen Tabellen-Lineage und den Integrationspunkten über History-Backfill und Live-Streams. Gemeinsame Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — P&C ergänzt pc_brand als branchenspezifisches internes System.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. pc_brand__brand, siemens_mes__work_order), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/pnc/ definiert das Operations-Rückgrat und das Entitätsmodell; PcEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen 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
          

Live-Bronze-Zyklus

./live-v2-pnc — 60s-Tick über PcEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt die MakeToShipToSell-State-Machine aus — Domänenobjekte erzeugen korrelierte Forecast-, PO-, MES-, WMS-, OMS-, OTM- und GL-Zeilen pro Produktionscharge und Retail-Kundenauftrag; die Skalierung variiert pro Tick (Standardbasis 5). Backfillen Sie jede benötigte Historie (--days N im Live-Skript oder 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 — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen erzeugt.

Prozess-Rückgrat: Definiert in kb/industries/pnc/process_model.yaml. Ausnahmezustände (Batch-Ausschuss, Qualitätssperre, Teillieferung, Lieferantenverzug) zweigen von denselben Entitätslebenszyklen ab, statt als unabhängige Zufallsinserts.

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-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „HKBC“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited noch mit einer realen Bank verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

HKBC (Hong Kong Banking Corporation) ist eine hongkonger Universalbank mit Sitz in Central, mit Wealth and Personal Banking, Commercial Banking und Global Banking and Markets. Die Franchise nimmt HKD-Einlagen entgegen, originiert HIBOR-Hypotheken und unbesicherten Kredit, gibt Karten aus, betreibt 24×7 Faster Payment System- und PearlPay-Rails (PayMe-Klasse), finanziert Greater-Bay-Area-Handel und bucht USD/HKD- und CNH-FX innerhalb des Konvertibilitätsbands 7,75–7,85.

Das Buch umfasst ~10 Filialen auf Hong Kong Island, Kowloon und den New Territories plus einen Qianhai-GBA-Wholesale-Desk und ein Londoner Markets-Desk — und erzeugt an jedem Simulationstag korrelierte FPS-Credits, Kartenautorisierungen, CHATS/SWIFT-Transfers, Core-Doppelbuchungen, AML-Alerts und SAP-Journale, mit einem Lunar-New-Year- / Q1-Steuerkredit-Surge der PearlPay-P2P-Volumen, FPS-Inkasso und Privatkredit-Origination anhebt.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäfts-Entitäten und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und spezialisierte Tabellen (z. B. AML-Fälle, ECL-Rückstellungen, Wertpapieraufträge, Facility-Redlines) über alle 60 Bronze-Tabellen. In V2 FpsPayment und verwandte Domänenklassen treiben die PayToPostToBalance-Spine.

OOP-Domänenmodell

HkbcEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

PayToPostToBalance ist das primäre Prozess-Rückgrat. FpsPayment.execute_lifecycle() (und PearlPay-, Karten-, CHATS-, SWIFT-Pendants) durchläuft Rail-Nachricht → Core-Doppelbuchung → optionales AML-Alert → EOD-Einlagenbestand → GL. HkbcPortfolio.publish_foundation() mastert Filialen, Produkte, CIF-Kunden und Konten, bevor Zahlungen laufen. Service-Objekte emittieren CMB-Trade-, GBM-FX-, Wealth-, Risiko- und Corporate-Zeilen.

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]
          

Zahlungen & Franchise-Wertschöpfungskette

Von CIF- und Produkt-Master über Rails, Core-Posting, Risiko und Finance-Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das HKBC-Ökosystem; das vollständig erzeugte EDW umfasst alle 32 Quellsysteme mit funktionsübergreifenden Integrationen, Wealth-Dealing und hier nicht gezeigten GBA-Handelskorridoren.

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

Funktionale Organisation nach Abteilung

Harbourview Tower HQ und Direktbericht-Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige HKBC-Organisation umfasst zusätzliche Bezirksfilialen, GBA-Desks und Shared-Services-Funktionen über alle 32 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Kunde (customer_id) und Konto (account_id) bilden die Spine; Zahlungen joinen über source_txn_id.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 32 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

32 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 32 Systeme mit vollständiger Tabellen-Lineage und Integrationspunkten über History-Backfill und Live-Streams. Geteilte Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — HKBC fügt hinzu hkbc_core, hkbc_pay, hkbc_trade, und hkbc_wealth als branchenspezifische interne Systeme, plus Hongkong-Markt-Rails.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. hkbc_core__account, hkicl_fps__payment), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/hkbc/ definiert das Operations-Rückgrat und das Entitätsmodell; HkbcEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen 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
          

Live-Bronze-Zyklus

./live-v2-hkbc — 60s-Tick über HkbcEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt die PayToPostToBalance-State-Machine aus — Domänenobjekte emittieren korrelierte FPS-, PearlPay-, Karten-, CHATS-, SWIFT-, Core-Posting-, AML- und GL-Zeilen; Live-Ticks für heute emittieren nur Events bis Hongkong as_of damit das Payment-Tape über den Tag wächst. Die Skala variiert pro Tick (Standard-Base 5). Backfillen Sie jede benötigte History-Spanne (--days N im Live-Skript oder 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-Eventgraph

PayToPostToBalance-State-Machine — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen emittiert.

Prozess-Rückgrat: Definiert in kb/industries/hkbc/process_model.yaml. Late-Arrival-Modi (SWIFT-Ack-Lag, Karten-Clearing nach Auth, AML-Case-Lag, GL-Batch-Verzögerung) und Ausnahme-Modi (FPS-Reject, Kartenablehnung, AML-Hold, unzureichende Deckung, LC-Diskrepanz) zweigen von denselben Entitäts-Lebenszyklen ab statt unabhängiger Zufalls-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-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „AYA“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit AXA SA, AXA Hong Kong and Macau noch mit einem realen Versicherungsunternehmen verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

AYA ist ein hongkonger Kompositversicherer — Life & Savings, Health (inkl. VHIS und Employee Benefits) und General Insurance — vertrieben über gebundene Agenten, Bancassurance, Broker, die Aria-by-AYA-App und eingebettete E-Wallet-Partner. HQ in Quarry Bay, mit Advisory-Center in Central, AYA Medical Centre in Tsim Sha Tsui, einer Macau-Niederlassung und einem GBA-Vertriebsbüro in Qianhai.

Das Geschäft spannt Produktfabrik, Magnum-Klasse-Underwriting, split PAS (Leben auf Ingenium-Klasse, GI auf Guidewire), FPS-Prämieninkasso, Varicent-Provision, 24×7 Motor-/Reise-FNOL, FINEOS-Gesundheits-Claims, Rückversicherungszession, Prophet-IFRS-17-Bewertung und SAP-S/4-Journale — mit einem Taifun-Saison-GI-Claims-Anstieg (Juni–Oktober) und einem CNY-Reise-/Northbound-Kfz-Spike über digitale und Agenturkanäle.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäfts-Entitäten und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und spezialisierte Tabellen (z. B. Prophet BEL/CSM, Vertragzessionen, Klinikbesuche, CLM-Redlines) über alle 60 Bronze-Tabellen. In V2 LifePolicy und GiPolicy Domänenklassen treiben die QuoteToBindToPremium- und FnolToPay-Spines.

OOP-Domänenmodell

AyaEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

QuoteToBindToPremium ist die New-Business-Spine; FnolToPay ist die Claims-Spine. LifePolicy.execute_lifecycle() durchläuft Quote → Magnum-UW → Ingenium-Ausgabe → FPS-Inkasso → Provision → GL. GiPolicy.execute_lifecycle() durchläuft Quote → PolicyCenter-Bind → BillingCenter-Invoice → optionales Same-Day-FNOL auf ClaimCenter. AyaPortfolio.publish_foundation() mastert Produkte, Agenten, Offices und Versicherungsnehmer, bevor Policen laufen.

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-Wertschöpfungskette

Von der Produktfabrik über Distribution, Bind, Inkasso, Claims und Finance-Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das AYA-Ökosystem; das vollständig erzeugte EDW umfasst alle 39 Quellsysteme mit funktionsübergreifenden Integrationen, bargeldlosen Klinikbesuchen und hier nicht gezeigter Vertragsbuchhaltung.

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

Funktionale Organisation nach Abteilung

AYA Tower Quarry Bay HQ und Direktbericht-Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige AYA-Organisation umfasst zusätzliche Agenturdistrikte, Macau- und GBA-Teams und Shared-Services-Funktionen über alle 39 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Produkt (product_code) und Police (policy_number) bilden die Spine; Claims joinen über FNOL und Schadennummern.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 39 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

39 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 39 Systeme mit vollständiger Tabellen-Lineage und Integrationspunkten über History-Backfill und Live-Streams. Geteilte Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — AYA fügt hinzu aya_product, aya_agency, aya_digital, und aya_health als branchenspezifische interne Systeme, plus ein split PAS (Guidewire + Ingenium).

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. aya_product__product, guidewire_cc__claim), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/aya/ definiert das Operations-Rückgrat und das Entitätsmodell; AyaEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen 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
          

Live-Bronze-Zyklus

./live-v2-aya — 60s-Tick über AyaEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt QuoteToBindToPremium und FnolToPay aus — Domänenobjekte emittieren korrelierte Quotes, UW-Entscheidungen, PAS-Binds, FPS-Inkasso, Provisionen, FNOL und GL-Zeilen; Live-Ticks für heute emittieren nur Events bis Hongkong as_of damit Quotes, FNOL, FPS und Journals über den Tag wachsen. Die Skala variiert pro Tick (Standard-Base 5). Backfillen Sie jede benötigte History-Spanne (--days N im Live-Skript oder 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- und FNOL-Eventgraphen

QuoteToBindToPremium- und FnolToPay-State-Machines — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen emittiert.

Prozess-Rückgrat: Definiert in kb/industries/aya/process_model.yaml. Late-Arrival-Modi (PAS-Ausgabe-Lag, FPS-Clearing, Provisions-Batch, Overnight-FNOL, Rückversicherungs-Bordereau) und Ausnahme-Modi (UW-Refer/Ablehnung, Prämienverfall, Schadenabweisung, Teilstregulierung) zweigen von denselben Entitäts-Lebenszyklen ab statt unabhängiger Zufalls-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-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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