ForceDream OS Architecture: 36 Products, L828, and the Sovereign Stack

The ForceDream Intelligence OS spans 36 live products. Here is how the architecture is organised, what each layer does, and why the design choices were made.

The layered architecture

ForceDream is organised as a layered stack. L828 is the foundational earnings enforcement layer — running before any business logic and enforcing the 78/19.5/2.5 split on every transaction. Above it are inference routing, payment processing, fraud detection, WORM audit, marketplace mechanics, and developer tooling layers.

Each layer has a defined interface and a defined responsibility. The inference routing layer knows nothing about payment processing. The fraud detection layer knows nothing about inference routing. This separation means each layer can be updated and deployed independently.

The 69 automated smoke tests verify every layer interface on every deployment. A change that breaks an expected response format fails the tests for every dependent layer, catching regressions before production.

The 36 products

Five functional categories. Inference: routing engine, cache, model fallback chain, context window management. Payments: collection, FX routing, Africa corridors, Stripe Connect, Payoneer, withdrawal processing. Compliance: fraud detector (8 signals, under 100ms), WORM audit, FCA reporter, GDPR scanner, SOC2 evidence collector. Developer tooling: API key management, marketplace, agent studio, earnings dashboard, sandbox. Enterprise: SAML SSO, RBAC, data residency controls, audit log export.

Each product is independently callable. An enterprise buyer can use ForceDream exclusively for fraud detection without touching the marketplace. The products are composable — they work together when needed but are independently valuable.

The marketplace is the integration layer where products combine into agent workflows. A payment agent uses inference routing, Africa payment rails, fraud detection, and WORM audit. The marketplace handles the orchestration.

Why 148 routes

The 148 API routes reflect genuine platform complexity rather than sprawl. Each route addresses a specific non-overlapping function. The count grew from 110 to 148 across the Bucket 14 build cycle, with every addition accompanied by new smoke tests.

The test count grew from 55 to 69 over the same period. Multiple tests per route verify different conditions — happy path, error cases, authentication, and rate limiting.

Every route returns a consistent JSON structure with success, data, and error fields. Error responses include machine-readable codes and human-readable messages. Rate limits are returned in response headers.