Platform Backend — Runtime at Scale

Operates the Package capabilities at scale. Package Runtime + Services + AI Gateway + Agents + Memory + Pipelines + Governance + Execution + Observability.

The Platform Backend is where capabilities defined in packages/ are executed at production scale. It is the runtime layer that turns reusable contracts into operational reality.

Five Core Subsystems

1. Services — Workers, Pipelines, Agents

Platform Backend services run at scale. This includes:

• Workers: Cloudflare Workers serving API endpoints, connector projections, and Twin context service
• Pipelines: Governed data flow pipelines (Loader → Normalizer → Pipeline → D1 → Neon → cache invalidation → re-embed)
• Agents: Internal participants underneath the Twin and Workbench — not the headline product but essential for operation

Split rule: Capability contracts live in packages/; runtime implementations live in services/. Example: a connector capability has a contract definition in packages/ and a Worker implementation in services/.

2. AI Gateway — Model Routing and Access

The AI Gateway manages model access and routing for all AI operations within the workspace. It handles:

• Model selection and routing based on capability, cost, and latency requirements
• Rate limiting and quota management per tenant/model
• Prompt templating and variable injection
• Response filtering and safety checks
• Model fallback and spillover configurations

The Gateway ensures that no model lands without HITL approval — provenance is immutable; Twin-origin data never masquerades as native truth.

3. Memory — Continuity and Learning

The Memory system preserves continuity across sessions and sharpens future proposals through learned outcomes.

• Continuity across sessions: Work never restarts from zero. When the user returns, interrupted continuity threads resurface with the last meaningful event, the pending continuation, and the owner.
• Learning loop: Approved / adjusted / rejected outcomes update governed Memory, sharpening future proposals.
• Twin routing: Memory connects through the Spine but is distinct — both Memory and Business Context connect through the Spine but are distinct substrates.

4. Pipelines — Governed Data Flow

Every write passes through the governed Pipeline — not "straight to D1." The Pipeline is the single chokepoint that enforces all governance rules.

Universal write path:

Provider / user / Twin event
    ↓
Loader → Normalizer → Pipeline
    ↓
operational update (D1) → canonical promotion / reconciliation (Neon)
    ↓
operational refresh / cache invalidation → re-embed

No exceptions: No role writes directly to the database. No workbench component reads directly from one. All reads go through the Projection Platform API. Every write is governed.

5. Governance — Approval and Policy

Governance evaluates permissions, risk class (R0–R4), approval need, and expected effects. Nothing consequential runs without a human decision.

• Risk classes: R0 (no risk) through R4 (high risk requiring explicit approval)
• Approval flow: Pending approval → user approves → governed write tagged origin: twin, confidence: 0.xx, approved_by. Provenance is immutable.
• Twin-origin data: Governance creates pending approval → user approves → tagged origin: twin, confidence: 0.xx, approved_by. It does not become native truth.

6. Observability — Monitoring and Auditing

Observability provides the audit ledger and runtime insights across all platform surfaces.

• Audit ledger: Every action tagged origin, confidence, approved_by. Provenance is immutable.
• Runtime metrics: Continuity Score, KPI status, connector health, pipeline throughput
• Health checks: L05 status pages for each operational layer
• Whole-house oversight: Integration Manager, Capability Manager, MCP Pool dashboards

Platform Services vs. Product Package

Two rules to write down before freezing:

1. Every Package capability has a contract in packages/ and a runtime in services/ — no orchestration logic in packages, no contract redefinition in services.
2. activation, connector, and mcp-servers each split across a user surface and a platform/service home — document which routes live where, or they regrow as standalone apps.

Quick Reference

Built 2026-08-20 · Nextra 4 · Theme nextra-theme-docs