The commitments behind the system. Not negotiable.

The decisions below are not implementation details. They are choices made before the first line of code, written down so the system can't drift away from them. We will not relax them under pressure.

Per-tenant isolation.

Every organization gets its own logical Postgres database and its own object-storage bucket. Tenant boundaries are physical, not column filters. There is no shared `organization_id` to leak across, no row-level security policy to misconfigure, no global table where a bug in one tenant can affect another.

A shared control-plane database holds only global identity — user accounts, organization registry, tenant routing. Nothing business-domain lives there.

What this gives you

Tenant deletion is `DROP DATABASE` — irreversible, complete, auditable.
A bug in our application code that forgets a `WHERE org_id = ?` is impossible to write — there is no column to forget.
Per-tenant performance characteristics: one heavy tenant doesn't starve a light one.
Per-tenant backups, restores, and point-in-time recovery without affecting anyone else.

Trade-off we accept

Higher per-tenant infrastructure cost than row-level isolation. We accept this in exchange for a tenant boundary that cannot be coded around.

Computed values, never stored.

Budget remaining, PO committed, invoice balance, master-agreement consumption — calculated at read time from underlying transactions. The ledger is always the source of truth.

Stored aggregates rot. The moment the underlying rows change — through a correction, a reversal, a status transition — the cached number becomes a lie. Most ERPs paper over this with overnight reconciliation jobs that nobody reads. We don't store the cache in the first place.

What this gives you

Every figure on every screen reflects the live state of the underlying ledger.
There is no "out-of-sync" state to reconcile.
Append-only correction rows (reversals) are first-class — corrections never overwrite history.
Audit-grade financial trails are a property of the data model, not a feature on top of it.

Trade-off we accept

Slightly higher read cost than pre-aggregated rollups. We mitigate with selective caching that has event-driven invalidation — we never store a number we can't invalidate the instant its inputs change.

Uniform document lifecycle.

Every business document — budget, requisition, RFQ, purchase order, goods receipt, invoice, payment — has a status lifecycle, an audit history, an attachment slot, and an activity timeline. This is not a feature of the documents that happened to need it; it is a property of every document the system understands.

When we add a new document type, these four capabilities are inherited from the platform layer. We do not decide which documents get an audit trail. They all do.

What this gives you

A complete operational record per document — who did what, when, with which policy state.
Cross-document transaction trails: export a budget allocation and you receive every PO, GRN, and payment it touched, in a single signed bundle.
Attachments are tied to the document role they fulfil — primary, supporting, signature — and survive the document's closure.
Notifications, search, and reporting all read the same uniform substrate.

See it in your own tenant.

Read the architecture, then create a real one in your browser.

Start your organization

SettriumStart your organizationStart

The commitments behind the system. Not negotiable.

The decisions below are not implementation details. They are choices made before the first line of code, written down so the system can't drift away from them. We will not relax them under pressure.

Per-tenant isolation.

A shared control-plane database holds only global identity — user accounts, organization registry, tenant routing. Nothing business-domain lives there.

What this gives you

Tenant deletion is `DROP DATABASE` — irreversible, complete, auditable.
A bug in our application code that forgets a `WHERE org_id = ?` is impossible to write — there is no column to forget.
Per-tenant performance characteristics: one heavy tenant doesn't starve a light one.
Per-tenant backups, restores, and point-in-time recovery without affecting anyone else.

Trade-off we accept

Higher per-tenant infrastructure cost than row-level isolation. We accept this in exchange for a tenant boundary that cannot be coded around.

Computed values, never stored.

Budget remaining, PO committed, invoice balance, master-agreement consumption — calculated at read time from underlying transactions. The ledger is always the source of truth.

What this gives you

Every figure on every screen reflects the live state of the underlying ledger.
There is no "out-of-sync" state to reconcile.
Append-only correction rows (reversals) are first-class — corrections never overwrite history.
Audit-grade financial trails are a property of the data model, not a feature on top of it.

Trade-off we accept

Uniform document lifecycle.

When we add a new document type, these four capabilities are inherited from the platform layer. We do not decide which documents get an audit trail. They all do.

What this gives you

A complete operational record per document — who did what, when, with which policy state.
Cross-document transaction trails: export a budget allocation and you receive every PO, GRN, and payment it touched, in a single signed bundle.
Attachments are tied to the document role they fulfil — primary, supporting, signature — and survive the document's closure.
Notifications, search, and reporting all read the same uniform substrate.

See it in your own tenant.

Read the architecture, then create a real one in your browser.

Start your organization