Objects
The nouns your institution 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 institution runs on a handful of things that matter and the rules about how they move. Most software buries those in features. We hold them as a description the software reads.
A university has applicants, programmes, documents, stages and a definition of “complete”. An assembly line has units, stations, checks and a definition of “passed”. A firm has matters, clients, filings and deadlines. Different words, identical shape.
So we write the words down as data rather than as code. That description — your ontology — belongs to you, is readable by your own people, and is the thing the software actually runs against.
applicantprogrammedocument
stageunitstationcheck
claimshipmentmatter
Higher education’s vocabulary, lit. The rest belong to other sectors — same engine, different description.
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 institution 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.
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 your institution has 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.
A second institution in weeks.
The engine has never heard of an applicant and does not need to. A new institution 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
What ships once.
Everything that is not your vocabulary is shared, tested, and improved for every institution 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 institution 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.