Cambium Reality Check

Date: 2026-03-22

Purpose

This document captures the current state of the Cambium codebase against its stated architecture, non-negotiables, and subsystem PRDs.

It is intended to answer a simple question:

What is real, what is partial, and what is still aspirational?

Executive Summary

Cambium is a real system, not a repo-shaped concept. The codebase contains substantial implementation across the core orchestration engine, signal protocol, governance, health, recovery, stigmergy, provider management, adaptive orchestration, and the Loom operator surface. The test suite is broad and currently passes. Loom also production-builds successfully.

However, the project does not yet fully satisfy several of its own strongest claims:

• The repo does not currently pass a clean workspace typecheck.
• PostgreSQL is not yet the source of truth for all durable state.
• Some important runtime state still lives only in process memory.
• Package boundary enforcement is not demonstrated by tooling.
• Workspace-aware auth context is not fully threaded through the API layer.

The practical conclusion is:

• Cambium is demo-ready.
• Large parts of the domain logic are production-capable.
• The platform is not yet operationally consistent enough to claim full production readiness.

Verification Snapshot

What passes

• pnpm turbo test
• Passed across the monorepo
• Includes package tests, integration scenarios, Loom build, and Loom tests

What fails

• pnpm turbo typecheck
• Fails in @cambium/loom
• Cause: stale .next/types paths included in the TypeScript program

Relevant file:

• apps/loom/tsconfig.json

Overall Assessment

Implemented and credible

• Modular monolith structure
• TypeScript domain modeling
• Core workflow and run model
• Signal protocol with persist-before-deliver semantics
• Hardwired cascade chains
• Hypha graph execution and task progression
• Genesis template-driven agent spawning
• Seed checkpointing and recovery hooks
• Health stress evaluation
• Immune anomaly detection and trust management
• Quorum decision workflow
• Stigmergic markers and regions
• Provider registry and provider health monitoring
• Intent decomposition and capability resolution
• Lifecycle engine and autonomic loop logic
• Loom app with broad operator-facing surface area

Implemented but incomplete

• PostgreSQL-backed persistence
• API auth and workspace scoping
• OAuth end-to-end operator setup
• Budget enforcement as a durable system concern
• Audit durability
• Lifecycle durability
• Cortex intent durability

Stated as non-negotiable but not yet fully true

• TypeScript strict mode everywhere, verified by clean repo typecheck
• PostgreSQL for all durable state
• Package boundaries enforced

Subsystem Reality Check

Core

Status: strong

What is real:

• Shared domain types are extensive and central to the repo
• Core contracts are used consistently across packages

Assessment:

• Core is one of the strongest parts of the system
• The project is genuinely organized around shared contracts rather than ad hoc shapes

Signals

Status: strong

What is real:

• Signals are persisted before delivery
• Receptor matching, retries, and dead-letter handling exist
• Hardwired cascade chains are implemented
• Signal tests are substantial

Relevant files:

• packages/signals/src/signal-bus.ts
• packages/signals/src/cascade-chains.ts

Assessment:

• This subsystem materially supports one of Cambium’s core differentiators
• The “persist before delivery” claim is backed by code, not just docs

Hypha

Status: strong

What is real:

• Graph execution
• Run store abstraction
• Task runner and executor model
• Intervention manager
• Fallback and error-path test coverage

Assessment:

• Hypha is beyond skeleton status and appears credible as a workflow runtime

Workflows

Status: strong

What is real:

• Graph validation
• Workflow repository
• Definition versioning and active-state semantics

Assessment:

• This area aligns well with the PRDs

Agents and Genesis

Status: strong

What is real:

• Agent repository and lifecycle transitions
• Capability matching
• Template repository
• Agent instantiation from template
• Composting support

Assessment:

• The agent model is implemented in a meaningful way
• Genesis and composting are not just names attached to folders

Health, Immune, Quorum, Seed

Status: strong but persistence-incomplete

What is real:

• Health evaluation and receptors
• Immune anomaly detection and trust
• Quorum decisions and policy usage
• Seed checkpoint creation and recovery handling
• Integration into cascade behavior

Assessment:

• The logic is present and tested
• The main gap here is operational durability for some related stores

Stigmergy

Status: strong

What is real:

• Marker and region model
• Marker placement and querying
• Stigmergic environment service
• Tests for routing and marker behavior

Assessment:

• This is a real subsystem and one of the codebase’s more distinctive implemented ideas

Providers

Status: strong but operationally partial

What is real:

• Provider registry
• Health monitoring
• Runtime adapters
• Budget enforcement logic
• Auth profile handling
• OAuth implementation exists

Relevant files:

• packages/providers/src/oauth.ts

Assessment:

• Provider logic is substantial
• The gap is less about missing code and more about operational completeness and persistence

Cortex

Status: strong but partially durable

What is real:

• Intent decomposition
• Capability resolution
• Orchestrator
• Integration tests covering self-wiring orchestration

Assessment:

• Cortex is materially implemented
• The main shortfall is that intent persistence remains in-memory in app wiring

Lifecycle

Status: real but still V1-scoped and memory-bound

What is real:

• Lifecycle engine
• Source scanning
• Topic accumulation
• Threshold evaluation
• Intent generation
• Composting loop

Relevant file:

• packages/lifecycle/src/scanner/scan-orchestrator.ts

Assessment:

• The autonomic loop is implemented enough to demonstrate the idea credibly
• It is not yet operationally durable
• Scanner support is intentionally narrow in V1 and currently RSS-only

Loom

Status: demo-ready, partly production-ready

What is real:

• Next.js app with broad operator surface area
• Workflow, run, provider, approval, lifecycle, budget, environment, and agent screens
• API routes for major subsystems
• Middleware auth gate
• App build passes

Assessment:

• Loom is far more than a shell
• It is good enough for product walkthroughs and internal usage
• The biggest issues are repo typecheck hygiene, API scoping consistency, and missing end-to-end coverage

Persistence Reality

This is the single biggest architecture gap between stated intent and actual system guarantees.

Persisted with PostgreSQL support

• Workflows
• Runs
• Agents
• Signals
• Events
• Markers and regions
• Health state
• Decisions
• Templates
• Compost records
• Checkpoints
• Providers
• Auth profiles
• Interventions

Relevant file:

• packages/db/src/stores/index.ts

Still in-memory in actual app wiring

• Quorum policies
• Audit trail
• Budget store
• Cortex intent store
• Lifecycle cycle store
• Lifecycle topic store
• Lifecycle autonomous intent store
• Lifecycle compost store

Relevant file:

• apps/loom/src/lib/services.ts

Explicitly acknowledged persistence gaps

• Policies do not yet have a PostgreSQL table or implementation path

Relevant file:

• packages/db/src/stores/pg-policy-store.ts

Type Safety and Build Hygiene Reality

What is good

• Most packages compile and typecheck cleanly
• The codebase is largely disciplined in its TypeScript usage
• ESLint enforces some important rules, including no explicit any

What is not yet true

• The repo does not currently satisfy “strict TS everywhere” as an operational claim because the monorepo-level typecheck fails

Root issue:

• Loom includes .next/types/**/*.ts, and stale generated entries cause tsc --noEmit to fail outside the exact build state that produced them

Relevant file:

• apps/loom/tsconfig.json

API and Auth Reality

What is real

• Middleware-based bearer token protection exists
• OAuth callback route exists
• Provider auth UI and API surfaces exist

What is partial

• Some route handlers still hardcode or infer workspace instead of receiving it from authenticated context

Relevant file:

• apps/loom/src/app/api/runs/route.ts

Assessment:

• API protection exists
• Workspace-aware identity propagation is not complete

Tooling and Enforcement Reality

Present

• Turborepo orchestration
• ESLint
• Prettier
• Vitest

Not demonstrated

• Package boundary enforcement tooling
• Circular dependency enforcement tooling
• Playwright or equivalent Loom E2E suite

Assessment:

• Several architectural constraints currently depend on team discipline, not automated enforcement

Readiness Classification

Production-ready or near-production-ready

• Core type system and shared contracts
• Signal protocol
• Workflow model and validation
• Hypha execution engine
• Large portions of provider infrastructure
• Large portions of Cortex logic

Demo-ready

• Entire cross-subsystem platform story
• Loom as operator console
• Integration scenario narratives
• Self-wiring orchestration demos
• Lifecycle/autonomic demos

Not yet production-ready

• Full durability story
• Clean repo-level verification
• Multi-workspace auth propagation
• Auditable, durable governance policy storage
• Durable lifecycle state
• Durable Cortex intent state
• Enforced architectural constraints

Bottom Line

Cambium is already a serious codebase with real subsystems and meaningful tests. It is not a rewrite candidate and not a “start over” situation.

The right interpretation is:

• Keep the architecture direction
• Stop describing some operational claims as complete when they are still partial
• Treat persistence completion, verification hygiene, and enforcement tooling as the next maturity phase

This repo is ready for a hardening pass, not a conceptual reboot.