The platform
Software that stays coherent as it grows
Kellith is an operating system for business software: 2 products today, assembled from 6 business modules that stand on 5 shared platform capabilities. This page is the architecture, told in business language.
Assembled, not reinvented
Most business software suites are separate products wearing the same logo — an HR system, a project tool and a payroll product that each keep their own copy of who works here. The copies drift, and reconciling them quietly becomes somebody's job.
Kellith products are assembled from the same business modules. The directory your HR system trusts is — literally, not metaphorically — the directory your project board trusts. There is nothing to reconcile because there is only one of each fact.
One owner for every fact
Every module owns one business concern outright — attendance owns attendance, leave owns leave — and shares it only through its contract. No other part of the platform can reach into a module's data, so no other part can corrupt it or depend on its internals.
For an organisation, that discipline surfaces as answers that agree. How much leave someone has left has one answer. Whether a project can be completed has one answer. Who may do what has one answer.
Facts, not commands
Modules announce what happened — an employee left, a leave was approved, a project closed — and the rest of the platform reacts to the fact. Nothing orders another module around, which is what keeps products independent enough to run alone and coherent enough to run together.
It is also why an approved leave shows up in attendance as an explained absence, and why work can never be assigned to someone who has left: the fact travelled; nobody had to remember to copy it.
The foundations every product stands on
Five platform capabilities, shared by every module and every product — listed here exactly as the platform registry declares them.
Activity trail
Audit: an append-only, attributable record of what happened — who did what to which target in which organization, when, and under whose support-grant. A technical concern; it records outcomes and never gates them.
auth
Authentication: resolve caller credentials to a Principal. A technical concern — never a business domain.
Accounts
The principal ↔ business-identity linkage (ADR-0013). A technical concern: it maps who authenticated to who the organization knows, and models nothing about either. Never a profile store, never a directory.
organizations
Organizations: tenancy lookup and existence checks. A technical concern — never a business domain.
permissions
Permissions: authorization checks for a principal within an organization. A technical concern — never a business domain.
What the architecture buys you
- People exist once. Add someone to the directory and every product that runs on it — HR, projects, whatever comes next — already knows them. Terminate them and nothing anywhere can assign them work again.
- The audit trail is everywhere by default. Modules record what happened in human words, naming the actor, because the trail is a platform capability rather than a per-product afterthought.
- Access is decided per product, enforced everywhere. Your organisation defines its own permission tiers for each product; the platform makes sure a permission means the same thing wherever it is checked.
- Your shape is an assembly, not a rewrite. Because products are compositions, a product for your organisation's exact shape is assembled from proven parts — that is its own story.
See it carrying real products: Kellith HRMS and Kellith PMS