ForgeHubForgeHub is a persistent, typed event bus. Every Forge product publishes events and subscribes to events — without knowing who else is listening. WebSocket and webhook delivery. SQLite-backed persistence with configurable retention. Per-product per-event-type access tokens. Full causality chain tracing.
Why ForgeHub is the integration layer
"ForgeHub eliminates n² point-to-point integrations — one event bus that every Forge product publishes to and subscribes from."
Without ForgeHub: 8 Forge products would need up to 56 bilateral integrations. With ForgeHub: each product has one connection — publish events, subscribe to events. When ForgeProcure needs to know about a new BOM, it subscribes to ForgeCAD BOM events. It does not call ForgeCAD directly. ForgeCAD does not know ForgeProcure exists.
"SQLite-backed persistence means no event is lost — even if the subscriber is offline."
Every event is persisted to SQLite before delivery is attempted. Configurable retention — default 90 days. If ForgeMaint is offline when ForgeOps dispatches a work order event, the event waits. When ForgeMaint reconnects, it replays from the last acknowledged sequence number. No events are lost. No manual replay needed.
"Per-product, per-event-type access tokens — a subscriber can only see the event types it is authorized to receive."
ForgeHub issues a separate access token per product per event type. ForgeProcure holds a token for ForgeCAD BOM events. It cannot read ForgeKnowledge audit events or ForgeCompliance nonconformance records unless explicitly granted. Access is revoked per token, per product — revoking ForgeProcure's BOM token does not affect any other subscription.
A fault on a machine becomes a work order, a parts request, and a knowledge log entry — via ForgeHub, without any product calling another directly.
A Forge product emits an event to ForgeHub — e.g., ForgeCAD publishes BOM_REVISION_CREATED. The event carries a typed JSON payload per the event contract. ForgeHub persists it immediately.
ForgeHub checks all subscribers for BOM_REVISION_CREATED. For each authorized subscriber, it queues delivery — WebSocket push for real-time consumers, webhook POST for external systems.
Delivery is attempted per subscriber. WebSocket subscribers receive events in sequence-number order. Webhook endpoints receive a signed POST. Failed deliveries are retried with exponential backoff.
Subscriber acknowledges receipt. ForgeHub marks the event delivered and advances the subscriber's cursor. Unacknowledged events are retried until they expire per the retention policy.
Any authorized subscriber can request replay from a sequence number. The event timeline UI shows the causal chain — which event triggered which downstream event, across all products.
Every event type has a typed JSON-RPC 2.0 schema. Publishers and subscribers agree on the contract — ForgeHub enforces it on ingestion.
Every event type published across the Forge suite — what publishes it, what subscribes to it, and what the payload schema contains.
Forge products use persistent WebSocket connections. External systems receive signed webhook POSTs. Failed deliveries are retried automatically.
The event timeline shows which event triggered which downstream event — across all products. A fault on CONV-03 traces to a work order, a parts request, and a knowledge log entry.
Each subscriber holds a separate token per event type. ForgeProcure cannot read ForgeCompliance audit events unless explicitly granted. Tokens are revocable independently.
n² → n
Integration complexity
One bus instead of 56 bilateral connections
SQLite
Persistent event log
90-day default retention, configurable
Per-token
Access control
Per-product per-event-type authorization
JSON-RPC
Event contract
Typed schema for every event type
ForgeHub is the integration layer that makes the Forge suite coherent. Without it, every product would need to call every other product directly. With it, each product knows one thing: publish events, subscribe to events. The causality chain traces itself.