Objects
The nouns your own team actually uses. An applicant, a batch, a claim, a shipment. Named the way your own people name them, not the way a vendor decided.
The ontology
Your organisation,
Your organisation,
described once.
Every organisation runs on a handful of things that matter and the rules about how they move. Most software buries those in features. This keeps them in the open, as a description the software reads.
An assembly line has units, stations, checks and a definition of “passed”. A clinic has patients, appointments, records and a definition of “seen”. A university has applicants, stages and a definition of “complete”. A firm has matters, filings and deadlines. Different words, identical shape.
So the words stay words — written down as data rather than buried in code. That description — your ontology — belongs to you, is readable by your own people, and is the thing the software actually runs against.
unitstationpatientappointment
applicantstagematterfiling
shipmentcheckpointclaimadjuster
One object and one of its states, from six sectors. Same engine underneath every one of them.
The work
Decisions made, actions taken, answers returned, every one recorded.
↑
The engine
Orchestration, grounding, guardrails, evaluation, channels, tenancy. Shared by every sector.
↑
Your ontology
The objects your organisation runs on, the states they move through, the rules that govern them, and who may see what.
↑
Your systems of record
The ERP, the CRM, the document store, the four spreadsheets. Untouched.
One engine
Three vocabularies. Identical shape.
The same queue, the same states, the same escalation rule — running for three sectors that share no words at all. Only the description changed.
Applicant 2214complete
Applicant 2215needs a person
Applicant 2216waiting on a document
Applicant 2217complete
done means complete
Higher education
Unit 88-041passed
Unit 88-042needs a person
Unit 88-043waiting on a check
Unit 88-044passed
done means passed
Manufacturing
Visit 5108seen
Visit 5109needs a person
Visit 5110waiting on a record
Visit 5111seen
done means seen
Clinic
Representative interfaces — real structure, client data replaced.
What is in a description
Four things, and nothing else.
States
What each object can be, and what “done” means. The definition of complete is a decision you have already made; we write it down rather than invent it.
Rules
What moves an object forward, what holds it, what raises an exception and to whom. Your policy, expressed once, applied everywhere.
Permissions
Who may see and change what, inherited from the identity system you already run. The ontology carries this, so every answer respects it by construction.
Sources
Where the truth about each object lives — which system of record, which field. Answers cite it, so an answer can always be checked.
Tests
Real situations with the right outcome recorded. Every release runs against them. Fast deployment is only honest when a test catches the regression first.
Why it matters
What the description buys you.
Change without a release.
When your policy changes, the description changes. No rebuild, no deployment window, no ticket raised with us and waited on.
The second one in weeks.
The engine has never heard of an applicant, a patient or a batch, and does not need to. Another organisation in a sector you already run is a new description, not a new build.
An answer you can audit.
Because every object names its source, every answer carries a citation back to your own record. When it cannot ground an answer, it escalates rather than improvises.
An exit that works.
The description is data, in your accounts, in a format your own engineers can read. If we disappeared, you would still have it — which is the point.
The engine
Sector-neutral by construction.
Everything that is not your vocabulary is shared, tested, and improved for everyone running it, at the same time.
It answers from your records, or it says nothing.
Every answer is grounded in your source of truth and carries a citation. Where it cannot ground one, it escalates to a person. No invented number ever reaches a customer.
It runs in your accounts.
Your cloud, your database, your credentials, documented. Data exportable whenever you ask, and never used to train anyone else’s model.
Nothing ships without passing its tests.
Every release runs the suite built from real situations in your operation. The suite is written as we build and stays yours.
Resident in India, by design.
Data stays in-region and the schema was built for DPDP rather than retrofitted. Official platform APIs only — the unofficial kind gets an account banned within weeks.
Tell us what your week looks like.
Thirty minutes. We will tell you what we would build first, roughly what it costs, and where this will not help.