architecture

Architecture — caesar

Caesar is the financial hub. Operational systems remain the source of their own truth and feed Caesar summarised data — no integration pushes raw per-event volume into the ledger (BRD §2, §9).

flowchart LR
  finance([Finance / Leadership]) --> cc[Command centre]
  subgraph caesar[Caesar]
    cc --> ledger[Ledger core<br/>double-entry GL + sub-ledgers]
    ledger --> db[(Postgres — MocX stack)]
  end

  hermes[Hermes<br/>telemetry] -->|daily summarised swap revenue;<br/>deployment events → capitalisation;<br/>live swap feed| caesar
  billing[Billing system] -->|rider billing & collections;<br/>KAAG revenue| caesar
  polaris[Polaris<br/>HRIS] -->|payroll journals| caesar
  banks[Banks] -->|transaction feeds → reconciliation| caesar

Notes

• Two layers (BRD §2): the ledger core (audited books — double-entry GL plus payables, procurement, fixed-asset and group-roll-up sub-ledgers) and the command centre (real-time situational view overlaying booked ledger figures with live operational feeds).
• Same stack as the platform family — Postgres foundation shared with Hermes, Polaris, Atlas and Argus. Built in-house by MocX engineering, not a vendor ERP rollout (BRD §16).
• OneWorld-shaped (BRD §2, §5–6): subsidiary tree + top elimination entity, four-segment dimensional spine (Subsidiary / Location / Class / Department), summarised journals, intercompany model — so maturation toward NetSuite OneWorld is a lift, not a rebuild.
• Inbound only, summarised — the ledger holds no raw operational volume; granularity stays upstream and Caesar receives aggregates and references (BRD §9).
• Integration set and shapes to be confirmed against the live Zoho configuration and the actual Hermes / billing / Polaris / bank-feed interfaces.