Fusion Arcade
Blog / All products

How the arcade fits together, today and eventually

Five products, five codebases. What they actually share today (principles and patterns, very little code), the few concrete links between them, and the plan for Bridge and Forge OS to become the platform the others run on.

Fusion Arcade engineering4 min read

Three ecosystems, one philosophy

Fusion Arcade builds in three directions. Personal tools help you learn and live: Chamber and Lifekeep. Business intelligence helps companies understand their market: MapSight. The builder platform is how we make all of it: Forge OS decides what's worth building and builds it under test, and Bridge is the console that will watch over everything.

This post is the honest map: what connects the products today, and what's designed to connect them later. We draw a firm line between the two.

Today: shared patterns, separate code

How the products connect todayChamber, Lifekeep and MapSight are separate codebases. Chamber is the worked example in Forge OS's framework docs. Lifekeep was taken through Forge's discovery pipeline, and Bridge's prototype was built on Lifekeep's system model. MapSight stands alone. All of them share design patterns rather than code: bring-your-own model keys, AI proposals with undo, MCP surfaces for agents, and Postgres with row-level security.Shared patterns · separate codeChamberlearnLifekeepliveMapSightunderstandForge OShow we decide & buildBridgeprototypeexamplein its docsdiscovery runsystem modelBring your own modelkeys stay yoursAI proposes, you approvediffs · receipts · undoMCP for agentsChamber · Lifekeep · BridgePostgres + RLSLifekeep · MapSight · Bridge
Today: real links are few and specific. The products mostly share principles and patterns, not libraries. Tap to zoom.

Each product lives in its own repository with its own stack, picked for its job. Chamber is a browser-only TypeScript app on IndexedDB, Lifekeep is Next.js on Postgres, MapSight is Python and PostGIS with Temporal, Forge OS is an Electron desktop app, and Bridge is a Next.js shell. They don't import each other's code. What they share is a set of decisions we keep making the same way, because they keep turning out to be right:

PatternWhere it shows up
Bring your own modelChamber (browser calls providers directly, ten-plus providers), Lifekeep (ten providers, raw fetch), Forge OS (five providers per stage via the AI SDK), MapSight (a provider-neutral registry with a keyless fallback)
AI proposes, deterministic code decidesChamber's fixed policy table for card drift, Lifekeep's LCAP ChangeSets and rule-based adaptations, MapSight's rule-based resolution and scoring, Forge's validators and human-only gate approvals
Everything reversible, nothing rewrittenChamber's action batches and withdrawn answers, Lifekeep's effective-dated versions, MapSight's append-only observations and immutable dataset versions, Forge's stale-marking instead of silent overwrites
Versioned prompts and provenanceLifekeep and MapSight keep prompts as versioned files; Forge records the provenance of every artifact
MCP for agentsChamber's loopback companion, Lifekeep's MCP endpoint with its own OAuth server, Bridge's planned check-in server
Postgres with forced row-level securityLifekeep and MapSight today, Bridge by design
Two coding agents, one handoff protocolMapSight, Lifekeep and Forge OS are all developed by Claude Code and Codex working from a shared handoff file, with an independent review before merge

The concrete links are few and specific:

  • Chamber is the worked example in Forge OS. Forge's framework docs and gate definitions use Chamber's domain as their running example, and Chamber borrowed Forge's split between AI configuration and secret keys.
  • Lifekeep went through Forge. It was taken through Forge's discovery pipeline and the start of ideation. That made it the first real product to exercise Forge.
  • Bridge was born inside Lifekeep's build. Its HTML prototype modelled Lifekeep's system map (dozens of components with measured status, their edges and workflows) and its cost model. Lifekeep is "tenant zero".
  • MapSight stands alone for now. It's the most independent product, and the one most likely to supply patterns back to the others, such as its durable workflows, priced builds and per-tenant spend caps.

Eventually: Bridge in front, Forge as the engine

Where the ecosystem is headingBridge becomes the single console and front door, with Forge OS as the engine behind it. Chamber, Lifekeep and MapSight are built through Forge and report telemetry, costs and agent runs into Bridge. Chamber and Lifekeep connect for memorisation recall. A shared platform layer provides a telemetry SDK, one label system, Forge's project vocabulary, and keys and roles owned by Bridge.Shared platform · plannedBridgeone console · approvals · costs · agents report inForge OSthe engine: evidence → gates → test-gated buildfront door / engineChamberlearnLifekeepliveMapSightunderstandbuilt through ForgePulse ·runscosts ·alertsChamber ↔ Lifekeep: recall for memorisationPulse SDKtelemetry · cost eventsOne label systemtasks · costs · agentsForge vocabularyproject · release · gateKeys & rolesowned by Bridge
Eventually: dashed lines are designed in the product specs but not built yet. Tap to zoom.

The plan, written into Bridge's spec, is that Bridge becomes Forge OS's front door and Forge becomes the engine behind it. They already share a vocabulary: ecosystem, project, release boundary (R-2 through R5+), task and gate. Bridge's release gates are designed to be Forge's gates. In practice:

  1. Ideas enter through Bridge. Mention an idea in chat and it lands as a draft in the right project. Accepting it would open a Forge intake, and later a pull request to the project's plan.
  2. Forge decides and builds. Discovery, ideation and design run with their gates, and test-gated coding agents implement tickets in isolated branches.
  3. Agents report back to Bridge. Every Claude Code or Codex session reads project state from Bridge's MCP server before it starts and reports what moved when it finishes. Status is measured from the repository, not typed in by hand.
  4. Products report in too. A shared telemetry SDK, Pulse (TypeScript and Python, following OpenTelemetry conventions), would send usage and cost events from Chamber, Lifekeep and MapSight into Bridge, under one label system shared by tasks, costs, agents and alerts. Lifekeep is the planned pilot. Chamber's local-first design means its telemetry has to be opt-in and content-free.
  5. Bridge holds the keys. Secrets, roles and risky actions (deploys, key rotation, spend changes) go through Bridge's gateway with tiered approvals, so no agent or product holds standing credentials.

Between the products themselves

A few product-to-product links are designed:

  • Chamber ↔ Lifekeep. Lifekeep's domain model plans for Chamber to own the recall side of memorisation, such as Qur'an review and testing, while Lifekeep owns the plan and the daily habit. A journal insight in Lifekeep could be promoted into Chamber as something worth remembering.
  • MapSight → Bridge. MapSight already enforces per-run and per-organisation AI spend caps. Bridge would surface those alongside cloud costs and revenue for the whole studio.
  • Everything → Forge's judge. Forge's biggest open problem is a judge that calibrates itself by comparing past predictions with outcomes. Real outcomes from shipped products, reported through Pulse and Bridge, are exactly the data it needs. Lifekeep's habit of grading its own forecasts is a small version of the same idea.

What we're deliberately not doing

We aren't forcing a single stack or a shared monolith. A browser-only notebook, a multi-tenant planner and a geospatial pipeline have genuinely different needs. The platform layer will be thin: a telemetry SDK, an agent protocol, a label system and a security perimeter. Each product stays useful on its own, and each keeps working if Bridge is down, because repositories remain the source of truth.

Read the deep dives

See the products All posts