Limen Decision Log
Status: Living document.
Version: 0.1
Date: 2026-08-08
This document records every major decision that shapes Limen. Every entry must answer three questions: what was decided, why, and what was rejected.
How to add a decision
Use this format:
| Field |
Content |
| ID |
LIMEN-XXX |
| Date |
YYYY-MM-DD |
| Decision |
The choice made. |
| Context |
Why the decision was needed. |
| Options considered |
What else was on the table. |
| Decision rationale |
Why the chosen option won. |
| Consequences |
What this forces or enables. |
| Status |
Proposed / Locked / Revisited |
Decisions
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The platform is named Limen. The company remains Fordsworth. The internal codename AIR-OS is retired from external use. |
| Context |
Multiple names were used in early documents: Fordsworth NextGen PAS, AIR-OS, Limen. The project needs a single, ownable platform name. |
| Options considered |
AIR-OS, Limen, Fordsworth Core, Threshold. |
| Decision rationale |
AIR-OS is a category claim, not a brand. Limen is unique, meaningful, and globally pronounceable. It names the moment of transformation without being aggressive. |
| Consequences |
All external materials, UI, docs, and investor decks use Limen. AIR-OS references in old documents are moved to archive. |
| Status |
Locked |
LIMEN-002: Tagline is "Risk is just data. Run it on Limen."
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The primary tagline is "Risk is just data. Run it on Limen." |
| Context |
The platform needs a single phrase that explains why it is different from legacy PAS. |
| Options considered |
"Insurance, reimagined." "The operating system for risk." "Cross the threshold." "Risk is just data. Run it on Limen." |
| Decision rationale |
The phrase removes the artificial complexity of legacy insurance. It positions the platform as a data infrastructure play, not a feature list. |
| Consequences |
Use this tagline in the pitch deck, website, API docs, and product UI hero sections. Do not introduce competing taglines. |
| Status |
Locked |
LIMEN-003: One core model for all insurance lines
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Life, short-term, credit life, funeral, group, and specialty risks share the same Contract + Component + Participation + Ledger primitives. Differences are configuration and DMN rules, not separate cores. |
| Context |
Legacy insurance runs separate systems for life and short-term, leading to duplicated logic and integration cost. |
| Options considered |
Separate cores per line. A common core with line-specific extensions. One universal model. |
| Decision rationale |
A shared core forces discipline. If the model cannot represent a line, the model is wrong, not the line. DMN rules handle line-specific behavior without forking code. |
| Consequences |
We must prove the model works for at least two lines (Term Life and Short-Term Property) before declaring success. IFRS 17 and reinsurance rules remain line-specific libraries. |
| Status |
Locked |
LIMEN-004: Append-only financial ledger is mandatory
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Every financial movement in Fluid-GL is a new record. No ledger row is ever updated or deleted. Corrections are reversing entries. |
| Context |
Mutable balances make audit, reconciliation, and migration hard. Database locking on balance updates causes bottlenecks. |
| Options considered |
Mutable balances with audit log. Append-only ledger. Hybrid approach with current balance and history table. |
| Decision rationale |
Append-only is the only model that gives true auditability, eliminates balance locking, and makes reversals naturally safe. |
| Consequences |
Running balances are computed. Read models may pre-compute them. Reversals must reference the original entry. |
| Status |
Locked |
LIMEN-005: DMN rules own insurance logic
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Pricing, splits, eligibility, loadings, commission rules, amortization, and claims triage are expressed in DMN decision models. Code does not hard-code insurance logic. |
| Context |
Legacy systems bury rules in code, making actuaries dependent on developers for product changes. |
| Options considered |
Rules in code. Rules in configuration files. Rules in a custom rule engine. Rules in DMN. |
| Decision rationale |
DMN is a standard, auditable, visual format. It is owned by actuaries and business analysts, deployed via Git, and versioned by default. |
| Consequences |
Every ledger entry must reference the DMN version that produced it. DMN rules must be tested in CI. The development workflow changes from code releases to model deployments. |
| Status |
Locked |
LIMEN-006: Compute is stateless; state lives in stores
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Quarkus compute pods hold no business state between requests. All state is read from or written to Redis, PostgreSQL, and event streams. |
| Context |
Stateful services are hard to scale, migrate, and recover. |
| Options considered |
Stateful services with in-memory caching. Stateless compute with distributed stores. |
| Decision rationale |
Stateless compute enables horizontal scaling, fast recovery, and uniform deployment. The stores are purpose-built for their roles. |
| Consequences |
The system is not "stateless overall" — Redis and PostgreSQL hold state. We must be precise: compute is stateless. Cross-store consistency uses outbox and sagas. |
| Status |
Locked |
LIMEN-007: Hydrated contract state in Redis
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
A contract and its components are stored as a fully hydrated JSON document, primarily in Redis. The ledger is in PostgreSQL. |
| Context |
Legacy systems reconstruct policies from many joined tables at runtime, which is slow and fragile. |
| Options considered |
Pure relational model. Document store for state, relational for ledger. Fully hydrated document with relational ledger. |
| Decision rationale |
A hydrated document gives sub-millisecond reads and a single source of truth for the current contract state. The ledger provides financial immutability. CQRS separates the two concerns. |
| Consequences |
Contract documents must be kept lean. Party details are referenced, not embedded. Historical versions may be offloaded to cold storage. Redis must be rebuilt from the ledger if lost. |
| Status |
Locked |
LIMEN-008: Bi-temporal versioning with forks for backdated corrections
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Every material change creates a new contract version with effective time and system time. Backdated corrections create a new fork from the historical version; the original timeline remains intact. |
| Context |
Insurance contracts change retroactively. Legacy systems overwrite history, destroying auditability. |
| Options considered |
Overwrite with audit log. Versioning with latest-only view. Full bi-temporal versioning with forks. |
| Decision rationale |
Bi-temporal forks preserve the original audit trail, allow replay and recalculation, and make actuarial analysis correct. |
| Consequences |
Version storage grows. Historical versions may be offloaded. Replay must be deterministic. Delta calculation must be correct. |
| Status |
Locked |
LIMEN-009: Idempotency by default
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Every command that creates or changes money or contract state carries an idempotency_key. The gateway enforces exactly-once processing. |
| Context |
Networks, clients, and message consumers retry. Duplicate financial entries are unacceptable. |
| Options considered |
Idempotency only for financial commands. Idempotency for all mutating commands. |
| Decision rationale |
Idempotency for all mutating commands is simpler and safer. It also covers contract modifications, versions, and lifecycle events. |
| Consequences |
Idempotency keys must be durable enough to survive retries. They should be scoped to cell and operation. Results must be cached with a TTL. |
| Status |
Locked |
LIMEN-010: CQRS with projections for read models
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The write path is optimized for correctness and speed. Read models (operational, financial, actuarial, search) are projected asynchronously from the write-side events. |
| Context |
Running heavy reports on the transactional database slows down live operations. |
| Options considered |
Single database for reads and writes. Read replicas. Full CQRS with specialized projections. |
| Decision rationale |
Specialized projections allow each use case to use the right store. The write path stays fast and unburdened. |
| Consequences |
Read models are eventually consistent. Critical operations must not depend on them. We must define bounded lag SLAs. |
| Status |
Locked |
LIMEN-011: Cellular multi-tenancy with GitOps deployment
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Each major client or jurisdiction runs in an isolated data cell with local PostgreSQL, Redis, and event store. Stateless code and DMN rules are deployed uniformly via GitOps. |
| Context |
POPIA, GDPR-variants, and the Kenya Data Protection Act require data residency. Corporate clients demand isolation. |
| Options considered |
Single multi-tenant database. Logical separation within a shared database. Isolated data cells with shared code. |
| Decision rationale |
Isolated cells give true sovereignty and blast-radius isolation. GitOps keeps code uniform across cells. |
| Consequences |
Cross-cell data movement is denied by default. Data migrations are cell-specific. The control plane manages deployment but never stores PII. |
| Status |
Locked |
LIMEN-012: Events over batch for core operations
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Month-end batch processing is prohibited for core operations. Escalations, expiries, collections, and pre-alerts are scheduled and executed continuously. |
| Context |
Batch processing creates month-end paralysis, reconciliation backlogs, and long recovery times. |
| Options considered |
Nightly batch. Continuous event processing. Hybrid: some events continuous, some batch. |
| Decision rationale |
Continuous processing distributes load, improves cash flow, and removes the month-end bottleneck. |
| Consequences |
Scheduling infrastructure must be reliable. Read models are designed for continuous updates, not batch reconciliations. Regulatory extracts may still be periodic. |
| Status |
Locked |
LIMEN-013: AI is bounded by DMN rules
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
AI (Synapse) may ingest unstructured data and propose decisions. DMN rules make the final decision. AI never directly appends ledger entries or changes coverage. |
| Context |
AI is powerful but non-deterministic. Insurance decisions must be auditable and defensible. |
| Options considered |
AI as the primary decision maker. AI for ingestion only. AI proposes, DMN decides. |
| Decision rationale |
AI proposes, DMN decides combines adaptability with compliance. The audit trail records both the AI proposal and the DMN outcome. |
| Consequences |
AI outputs are inputs to DMN rules, not decisions. High-risk AI proposals require human triage. We do not market "AI underwriting." |
| Status |
Locked |
LIMEN-014: Stack is Quarkus + Redis + PostgreSQL + Kogito + Kafka/Debezium
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The reference stack is Quarkus (GraalVM native), Redis Enterprise, PostgreSQL or distributed SQL (YugabyteDB/CockroachDB), Kogito DMN, and Kafka/Redpanda/Debezium for events. |
| Context |
The platform must be fast, cloud-native, and auditable. The stack must be defensible to Google engineers and database experts. |
| Options considered |
Spring Boot, Node.js, Python, MongoDB, Cassandra, custom rule engine, RabbitMQ. |
| Decision rationale |
Quarkus + GraalVM gives fast startup and low memory. Redis gives sub-millisecond state access. PostgreSQL/distributed SQL gives strong consistency for the ledger. Kogito DMN is the standard for decision models. Kafka/Debezium is the standard for event streaming and CDC. |
| Consequences |
The team must build Quarkus expertise. DMN rules must be tested and versioned. Distributed SQL may be chosen over plain PostgreSQL for very large cells. |
| Status |
Locked |
LIMEN-015: First vertical slice is Party → Contract → Version → Premium → Reverse
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The first engineering milestone is a single end-to-end flow: create a party, create a contract with components, create a version, record a premium, reverse the premium, and view the timeline and ledger. |
| Context |
The project needs a provable foundation before adding capabilities. The hardest problems are contract state, versioning, and the ledger. |
| Options considered |
Start with a product configurator. Start with claims. Start with quoting. Start with the contract core. |
| Decision rationale |
The contract core is the foundation for every other capability. If it is wrong, everything else is wrong. |
| Consequences |
No other major capability (claims, reinsurance, advanced reporting) is built until the vertical slice passes functional, performance, and audit tests. |
| Status |
Locked |
LIMEN-016: Migration is a spectrum, not a fixed timeline
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
Migration timelines vary by book complexity. Simple short-term books: 60-90 days. Complex long-term life books: 12-24 months of parallel running. |
| Context |
Early documents claimed "migration in 60 days" for all books, which is not credible for complex life portfolios. |
| Options considered |
Universal 60-day migration. Tailored timelines by book type. |
| Decision rationale |
Credibility matters more than a catchy timeline. A migration pattern can be safe and fast for simple books without being a lie for complex ones. |
| Consequences |
Sales and investor materials must use the spectrum. We must define the criteria for each band. |
| Status |
Locked |
LIMEN-017: Logo is a candidate, not yet final
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The current doorway-with-I logo is a working mark. It is locked for use for 90 days while alternatives are tested against defined criteria. |
| Context |
The logo is good but may not be distinctive enough for global recognition. |
| Options considered |
Finalize the current logo. Treat it as a candidate and test alternatives. |
| Decision rationale |
A logo is expensive to change later. Better to validate it against criteria before committing. The brand system (color, type, voice) is more important than the mark alone. |
| Consequences |
No investor deck or public website is finalized without the logo test. Alternatives must be explored within 90 days. |
| Status |
Locked |
LIMEN-018: Business tagline is "Run insurance like a modern business."
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
For business audiences, the lead tagline is "Run insurance like a modern business." The technical tagline "Risk is just data. Run it on Limen." remains the primary tagline for engineering and product contexts. |
| Context |
The technical tagline is accurate but can feel reductive to business audiences. A 55-year-old COO cares about operational outcomes, not data abstractions. |
| Options considered |
"Turn risk into revenue." "Insurance that moves at the speed of your customer." "Run insurance like a modern business." |
| Decision rationale |
"Run insurance like a modern business" directly addresses the COO's mandate: operational efficiency, speed, and profitability. It does not trivialize the human side of insurance. |
| Consequences |
The business pitch deck uses the business tagline. The technical deck uses the technical tagline. The website and product may use either depending on the page. Both taglines lead to the same platform. |
| Status |
Locked |
Proposed decisions (pending approval)
LIMEN-019: Default dark mode for the UI
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The primary UI expression is dark mode with gold accents. Light mode is supported but secondary. |
| Context |
The current design system uses dark mode as default. |
| Options considered |
Light mode default. Dark mode default. System preference. |
| Decision rationale |
Dark mode with gold feels more authoritative and distinctive for an infrastructure platform. |
| Consequences |
All demos and screenshots use dark mode by default. Light mode must be maintained for accessibility. |
| Status |
Proposed |
LIMEN-020: First two lines to prove the model are Term Life and Short-Term Property
| Field |
Content |
| Date |
2026-08-08 |
| Decision |
The first two lines used to validate the one-model claim are Term Life and Short-Term Property. |
| Context |
We need to prove the universal model works across different insurance disciplines. |
| Options considered |
Term life and credit life. Short-term and funeral. Term life and short-term property. |
| Decision rationale |
Term life and short-term property are structurally different enough (long-term mortality risk vs. peril-based asset risk) to stress the model. Credit life can be built after the universal model is proven. |
| Consequences |
Phase 1 focuses on term life. Phase 2 adds short-term property as a second line. DMN rule libraries are built for both. |
| Status |
Proposed |
How to revisit a decision
A locked decision can be revisited only if:
- New evidence shows it is wrong.
- A non-negotiable in the manifesto would be violated otherwise.
- The change is approved by the core team.
When a decision is revisited, add a new entry with a higher version number. Do not delete the old entry. The history of decisions is part of the audit trail.