Limen Manifesto¶

Status: Locked.
Version: 0.2
Date: 2026-08-08
Owner: Fordsworth / Limen Core Team

This document is the single source of truth. Every other document, every design decision, every line of code, and every investor pitch must align with it. If a new idea contradicts this manifesto, the manifesto wins unless the manifesto is formally revised.

1. Why this document exists¶

The project currently has three overlapping documents, a design system prototype, and a long conversational exploration. That was useful for discovery. It is now dangerous. We need one doctrine. This is it.

This document does three things:

Locks the identity. Limen is the platform. Fordsworth is the company. AIR-OS is retired as a platform name.
States the non-negotiables. These are architectural laws, not preferences.
Surfaces the hard questions. A partner tells you where the beautiful picture breaks.

2. The locked identity¶

Element	What it is	What it is not
Company	Fordsworth	Not the product name. Not the platform name.
Platform	Limen	Not a module. Not a feature. Not AIR-OS.
Tagline	Risk is just data. Run it on Limen.	Not a feature list. Not "AI-powered insurance."
Symbol	A threshold — the moment of crossing from one state to another.	Not disruption for its own sake. Not a shield icon.
Tone	Calm, precise, inevitable.	Not loud. Not playful. Not corporate-bland.
Core thesis	Insurance is a stream of data events executing against probability curves.	Not a document workflow. Not a billing system. Not a CRM.

Why "Limen" wins over "AIR-OS"¶

AIR-OS is a category claim. Every vendor claims to be an operating system. It does not distinguish Fordsworth and it does not explain why we are different.

Limen names the moment where change happens. It is quiet, meaningful, and defensible. It gives us a narrative: "Legacy insurance stops at the threshold. Limen is what is on the other side."

Retire AIR-OS from all external communication. It may live as an internal codename if useful, but never in customer-facing or investor-facing material.

3. The problem we are solving¶

Legacy insurance core systems are built on assumptions that are now false:

A policy is a web of relational tables joined at runtime. False. It is a versioned document.
Money is a mutable balance updated in place. False. It is an immutable sequence of events.
Business rules belong to developers. False. They belong to actuaries and product teams, expressed as versioned decision models.
Time is handled by overnight batches. False. Time is continuous and event-driven.
Life, short-term, credit life, and specialty risks need separate cores. False. They need one model with different configuration and rules.

The result of the old assumptions is what the market already suffers: multi-year product launches, month-end paralysis, fragile migrations, and systems that collapse under real volume.

Limen replaces those assumptions with a single coherent model.

4. The non-negotiables¶

These are laws. They are not aspirational.

Stateless compute. Compute pods hold no business state between requests. All state is explicitly read from or written to stores. (The stores hold state. The compute does not.)
Append-only money. Every financial movement is a new record. No ledger row is ever updated or deleted. Corrections are reversing entries.
Hydrated contract state. A contract is retrieved as a fully hydrated document, not reconstructed from joins.
Bi-temporal versioning. Every material change creates a new version with effective time and system time. Back-dated changes create a new fork and compensating entries.
Idempotency by default. Every command that creates or changes money or contract state carries an idempotency key. Exactly-once processing is a system property.
DMN-driven business logic. Pricing, splits, eligibility, loadings, commission rules, amortization, and claims triage are owned by decision models. Code does not hard-code insurance logic.
CQRS. Write path is optimized for correctness and speed. Read models are projected asynchronously and are specialized.
Cellular multi-tenancy. Each major client or jurisdiction runs in an isolated data cell for sovereignty (POPIA, GDPR-variants, Kenya Data Protection Act, etc.). Stateless code and rules are deployed uniformly via GitOps.
One model for all lines. Life, short-term, credit life, funeral, group, and specialty risks use the same Contract + Component + Participation + Ledger primitives. Differences are configuration and DMN behavior, not separate cores.
Events over batch. Month-end batch thinking is prohibited for core operations. Escalations, expiries, collections, and pre-alerts are scheduled and executed continuously.

If a proposed design violates any of these, it is rejected unless the non-negotiable itself is formally revised.

5. What Limen is not¶

This is as important as what Limen is.

Limen is not a CRM. Parties and relationships are part of the model, but the platform is not a customer relationship tool.
Limen is not a document management system. Documents are linked to contract versions, but documents are not the source of truth.
Limen is not a general-purpose workflow engine. BPMN may orchestrate side effects, but it never owns core contract or ledger state.
Limen is not an AI black box. AI may propose features, triage claims, or ingest unstructured data. DMN rules decide and record.
Limen is not a data warehouse. Reporting is built from projections, but the core platform is transactional and operational.
Limen is not a magic migration tool. We can make migration faster and safer than legacy vendors. We cannot promise zero effort.

6. The partner's critique: where the current claims need work¶

These are the places where the beautiful architecture must be stress-tested. They do not invalidate the vision. They define the work.

6.1 "Sub-millisecond" and "sub-atomic"¶

The claim: Reads are under a millisecond, claim settlements in 80ms, etc.

The reality: That is possible for the hot path if the state is in memory and the calculation is simple. It is not a universal guarantee.

What must be true for it to hold:

The requested contract state must be in the hot/warm tier.
The DMN rule set must be small enough to execute in memory.
The network path must be short (same region, no external API calls).
The operation must not require cross-cell coordination.

What is not sub-millisecond:

Historical snapshot reconstruction from cold storage.
Complex actuarial projections.
AI-driven document understanding.
Cross-border regulatory extracts.
The first time a contract is loaded after cache eviction.

Resolution: We will publish latency budgets by operation class. "Sub-millisecond" is the hot-path SLA, not the universal SLA.

6.2 "Stateless compute"¶

The claim: No service holds business state in memory between requests.

The reality: This is true for compute pods but not for the system as a whole. Redis holds state. PostgreSQL holds state. The DMN engine has its rule cache. The distinction matters because a Google engineer will ask: "If you are stateless, why do I need Redis?"

Resolution: We say: "Compute is stateless. State lives in purpose-built stores. The compute layer is horizontally elastic; the stores are tiered and cell-bound."

6.3 "One model for all lines"¶

The claim: Life, short-term, and specialty risks use the same model.

The reality: This is the right ambition, but it is unproven. Long-term life has cohorts, CSM, VFA, mortality tables, and 30-year liabilities. Short-term has perils, deductibles, UPP/EPP, and high claim frequency. Credit life has group-linked cover, retrenchment triggers, and rapid cancellations.

The primitives (Contract, Component, Participation, Ledger) can model all of these. But the rules and reporting are very different. The model is shared; the rule libraries and projections are line-specific.

Resolution: We treat "one model" as a shared foundation, not a uniform product. We will prove it by building one line first (Term Life), then a second line (Short-Term Property), then demonstrating that the core did not fork.

6.4 "Migration in 60 days"¶

The claim: Legacy to Limen in 60 days via shadow ingest, shadow execution, and zero-downtime cutover.

The reality: This is a credible migration pattern for greenfield books or simple short-term portfolios. It is not credible for a 30-year life book with embedded options, guaranteed benefits, and thousands of product variations. Those migrations require parallel running, actuarial sign-off, and reconciliation periods measured in months, not days.

Resolution: We offer a migration spectrum. Simple books: 60-90 days. Complex long-term books: 12-24 months of parallel running with controlled cutover. The 60-day claim applies to well-defined portfolios only.

6.5 "Zero locks"¶

The claim: The append-only ledger eliminates database locking.

The reality: Appends are mostly lock-free. But ordering, idempotency, and cross-store consistency still require coordination. The ledger table does not lock rows for updates, but the command pipeline must ensure causal ordering and prevent duplicate processing.

Resolution: We say: "Zero in-place updates. Zero balance locking. The ledger is append-only. The command layer uses idempotency and sagas for consistency, not row locks."

6.6 AI and underwriting¶

The claim: AI ingests documents, proposes decisions, and DMN rules enforce compliance.

The reality: AI is not deterministic. It can misread a medical report, misinterpret a building photo, or hallucinate. In insurance, a wrong decision is a regulatory and reputational risk.

Resolution: AI is confined to assistance and proposal. The DMN rule is the decision authority. The audit trail records both the AI proposal and the DMN outcome. High-risk decisions require human triage. We never claim "AI underwriting" without a human or DMN gate.

6.7 Cost and infrastructure¶

The claim: 40 million policies × 5 KB = 200 GB, manageable with tiered storage.

The reality: 5 KB is a tight estimate for the active contract document. Add history, documents, ledger entries, search indexes, and projections, and the real footprint is much larger. The cost optimization is real, but the headline number is misleading.

Resolution: We publish transparent sizing models. Active document: ~5 KB. Historical versions: ~2 KB per version. Ledger: depends on frequency. Projections: 2-5x raw size. We do not promise a cheap system; we promise a predictably scalable system.

7. The core engines¶

Everything Limen does is powered by a small set of engines. No capability is a separate core.

Engine	Responsibility
Graph-E	Party identity, roles, hierarchies, and relationships. One party model. Edges are relationships, not table joins.
Quantum-Tree	Contract and component tree. Fully hydrated document state. Temporal versions. Supports any insurable item.
Kinetic	Lifecycle, time, and amortization. Escalations, expiries, renewals, UPP/EPP, cover-on-demand.
Fluid-GL	Append-only financial ledger. Premiums, splits, commissions, reinsurance shares, claims, reversals, adjustments.
Decisioning (DMN + Synapse)	Kogito DMN for deterministic rules. Synapse for AI-assisted ingestion, triage, and proposal. DMN decides.
Projections	CQRS read models: operational, financial, actuarial, search.

All capability domains (sales, underwriting, claims, reinsurance, finance, collections, commissions) operate on these shared engines. We do not build a separate Claims Service, Reinsurance Service, or Commission Service core.

8. The product experience principles¶

Limen must feel the same no matter who is using it.

One policy is one truth. A broker, a policyholder, an actuary, and a finance user see the same contract from different angles. Never different data.
Time is visible. The timeline is a first-class interface, not a history log. Every state is explorable.
Money is transparent. Every rand, dollar, or shilling is traceable from receipt to split to ledger entry.
Rules are explainable. A user can see why a premium was calculated the way it was: which DMN version, which inputs, which outputs.
Channels are thin. WhatsApp, portals, USSD, and agent dashboards are presentation layers. The engines are the same.

9. The one-line truth¶

Risk is just data. Run it on Limen.

That is the only phrase that matters. It removes complexity. It names the category. It explains why the platform exists.

Use it in the technical pitch deck, the website, the API docs, and the engineering conversation.

For business audiences, translate it to the outcome: Run insurance like a modern business. The technical tagline is the why-it-works. The business tagline is the why-it-matters. Both lead to the same platform.

10. Next decisions this manifesto requires¶

Approve or revise the non-negotiables.
Approve or redesign the logo against the criteria in the brand doctrine.
Approve the engine map and the line-by-line proof plan.
Lock the first vertical slice (Party → Contract → Version → Premium → Reverse).
Reject the remaining AIR-OS references in old documents and migrate them to archive.

Until these are locked, we cannot start building the backend.