Skip to content
oozmi
Demo

The engine underneath everything.

Your whole business — every table, field, rule and permission — lives as rows in one database, read by one program. Every change runs the same path and leaves the same audit record, whether a person, a business rule, or the AI made it. Run it on your own PostgreSQL, or let us host it.

Talk to us — 25 minSee how the AI writes

The idea

Most software is an app with a database behind it. oozmi is the database — the app is just what reads it.

Your tables, fields, forms, business rules and permissions aren’t compiled into the product. They live as rows in one PostgreSQL database that a single program reads on every request. You change how the business works by changing the rows — not by waiting on a new build.

one PostgreSQL schema + data, side by side
  • tableordersa table
  • fieldorders.delivery_notea field
  • formorder : newa form
  • aclfinance → reada rule
  • dataord-7741an order
  • auditprice €12.90→€10.90a change
renders, on every request
Form
Dashboard
API
Workflow

Schema and data are the same kind of thing — rows. One program reads them on every request and becomes your CRM, your storefront, your ledger.

One pipeline No fast path

Every change takes the same path — and the AI gets no shortcut.

A person saving a record, a business rule firing, an agent applying a proposal: all three enter one staged pipeline, inside one database transaction. If any stage fails, the whole change rolls back — the audit record included. Nothing on disk ever says something happened when it didn’t.

A person A business rule oozmi AI
one transaction
  1. Validate
  2. Security
  3. Before
  4. Compute
  5. Data-policy
  6. Write
  7. After
  8. Async
tableaudit_events
actoroozmi AI · agent_id: ai-88
changeorder.price · €12.90 → €10.90
rolled backno · committed 14:11:04

The agent is just another client of this pipeline. Same stages, same transaction, same audit row — only with agent_id filled in. There is no admin API that skips security, and no back door for the AI.

In the box

The pieces other stacks sell as add-ons — already in the box.

These aren’t line items on a roadmap. They’re how the platform is built, so every module inherits them for free — the same primitives most teams spend a year bolting on.

  • audit_events

    Change records by default

    Every write commits an audit row in the same transaction — not a sidecar log.

  • core_acl

    Field-level permissions

    Default-deny, checked by table and field before the database is touched.

  • core_field

    Operator-editable schema

    Add a field by inserting a row; the next request already sees it.

  • git · mod_count

    Versioned, diffable apps

    Export what you build as records, diff them, and ship through your git.

  • sandboxed JS

    Safe business rules

    Before, after and compute logic runs in isolated VMs — never the host.

  • OIDC · SAML

    Identity built in

    Single sign-on, MFA via TOTP and WebAuthn, role inheritance, hashed keys.

  • OpenTelemetry

    Observability you own

    Traces across every stage and metrics your Grafana already reads.

  • metadata forms

    Forms follow the schema

    A form is just a view of the table and the ACLs that apply to it.

Compliance

A subject-access request is a query — not a fire drill.

GDPR is mostly a data-architecture problem wearing a legal costume. When the customer is one row that every module writes to, the legal answers fall out of questions the database can already answer.

Erasure runs through Approvals. The DPO signs off, the platform anonymises or deletes by the retention rules declared on each field, and the erasure itself writes an audit row under the same account. Consent is a versioned record on the customer — withdrawn on the same path it was granted.

Admin Data request · DSAR-118
Subject-access request

Northgate Bakery

requested 14 Apr · account #88
29 days left
one read returns everything held on the customer
  • Orderssince 2021 38
  • Invoicesall paid 41
  • Tickets2 open 7
  • Consentsall current 3
  • Messageslast 9 Apr 112
  • Audit trailevery change all
Assembled in one query · 0.3s Export package
Admin Indicators · live
Gross margin · Spring catalog live
31.4% ↓ 0.7 pts from 32.1%
MonWedFrinow
updated the moment order #7741 was placed · 14:11
  • Orders today 128 ↑ 12%
  • Overdue invoices €8.2k ↓ 4%

Live indicators

Your numbers move the moment your business does.

Every dashboard claims to be live. The real test is whether a number is already right the instant an order is placed — instead of catching up a few minutes later from somewhere else.

  • Every figure reads the same orders, customers and invoices the rest of the business runs on — so the dashboard and the books can never quietly disagree.
  • The history sits right next to the live numbers, so you get trends without a separate warehouse or a nightly export to wait on.
  • Set a target and an alert in plain settings — and like everything else on the platform, every change is tracked.

Yours to run

One program. Your PostgreSQL, or ours.

Same software either way. The only thing that changes is who holds the connection string and who answers the page at 3 a.m.

oozmi one program, one build

Self-host

on your own machine

Your own database, wherever you keep it — on-prem, your private cloud, or fully offline. It never phones home, and the source is yours to read and verify.

oozmi-hosted

we run it for you

Managed in an EU data centre, with daily backups and recovery. Upgrades only land inside a window you choose — and it’s the exact same software.

Your AI keys stay yours. The AI runtime connects to OpenAI, Anthropic or a local model through endpoints you control. We never hold them and never proxy them.

No lock-in by construction. If oozmi disappeared tomorrow, every row still opens in standard PostgreSQL. There is no proprietary format to escape.

Lineage

We didn’t invent this pattern. We made it yours to hold.

The idea that an application’s shape can live as records the engine reads — not files a developer compiles — has serious prior art. We name it honestly, and we name where we depart.

  1. prior art · 2004

    ServiceNow Now Platform

    sys_dictionary sys_security_acl Business Rules

    The discipline of the application living in the database. We borrow the discipline.

  2. prior art · metadata API

    Salesforce

    Custom Objects Custom Fields Profiles

    An app described as records the engine reads, not compiled code. We borrow the vocabulary.

  3. today · yours to hold

    oozmi

    single-tenant one Go binary self-hostable

    The same pattern — but yours to run on your own PostgreSQL, and to verify. We make it yours to hold.

We don’t claim their distribution or partner army — two decades earns that. What we claim is the pattern, in a shape they can’t match: sovereignty, not price.

Boundary

What ships in production — and what we don’t claim yet.

The architecture is live in production today. The formal attestations around it are honest about their stage. We’d rather draw the line than oversell the edge.

In production today
  • Metadata-driven runtime — tables, fields, rules and ACLs are rows
  • One staged write pipeline; every change inside a single transaction
  • audit_events written in the same transaction as the change it records
  • Default-deny, field-level ACL for users, scripts and the AI alike
  • Self-host or oozmi-hosted on one Go binary against your PostgreSQL
Not attested yet
  • SOC 2 planned
  • ISO 27001 planned
  • Self-host support model in pilot
  • Big-4 partner ecosystem not yet
  • Confirmed third-party security audit — only once it’s real
Next step — 25 minutes

Bring one change you’d like to trace end to end.

We open the admin and run your change through every stage — validate, security, before, compute, data-policy, write, after, async — then show you the exact row in audit_events that closes the transaction. Where something is still planned, we say so and name the boundary. If the architecture survives your questions, we talk pilot.