01
One team builds a CRM
The agent writes the code and, following forty years of habit, its own database with its own Customer and Employee tables.
Jiwari
Business world infrastructure
Many schemas. One World.
Jiwari keeps one governed model of your enterprise: its customers, employees, products and contracts, and how they connect. Every application, person and AI agent works through a focused Schema over that same World, so new software starts from what the enterprise already knows.
Schema. API. MCP. No AI in the data path Runs on a database you operate
Three applications, one World
CRMSchema
Customer
Contact
Opportunity
Product
Employee
Project managementSchema
Project
Task
Milestone
Customer
Product
Employee
Contract operationsSchema
Contract
Obligation
Customer
Supplier
Product
Employee
WorldOne Customer. One Product. One Employee.
Sharedthe same underlying entity wherever it appears
The problem
The application is now the cheap part.
Coding agents can build a working application in hours, and a database to go with it. But a generated database is not a data architecture. Screens and workflows have become close to disposable. The data underneath them cannot be.
02
Another builds a project tracker
The agent works in a vacuum, so it builds a second database and creates the same customers and employees again.
03
A third builds vendor management
Now every employee exists three times, and a change in one place quietly contradicts the other two.
By the tenth application, the architecture is a web of duplicated records and integration work, and nobody can say which system holds the truth. If building software becomes nearly free, the silo problem grows at exactly the rate the software does.
How it works
The World contains the entity. Schemas project it.
Jiwari has two ideas at its core. A World is the connected model of everything your organisation knows. A Schema is a governed window onto part of it, shaped for one team, one application or one agent.
World
The complete model of the things your organisation knows, their properties and how they relate. Customers have contracts, contracts depend on suppliers, employees work on projects. The model can be large. Each person's working context stays small.
Schema
A focused projection of the World: its entities, properties, relationships and constraints, what may be seen and changed, and by whom. Each Schema also generates its own API and MCP surface. To a team, it feels like their own database.
Shared entities
When two Schemas genuinely mean the same Customer, they project the same record rather than keeping copies to reconcile. Jiwari can suggest where concepts overlap. People confirm what they mean, because a CRM Account and a finance Account may be different things.
Borrowed entities
A Schema can borrow a type another Schema owns: see it, reference it and relate to it, without being able to redefine or overwrite it. The owner decides what borrowing allows.
Use what you borrow. Don't change what you borrow.
The World emerges
Model what you need. Connect it when it overlaps.
You don't need an enterprise ontology programme before you can ship your first application. Start with one Schema. Each new application reuses what is already there and adds only what is genuinely new.
Traditional development starts every application with an empty database. Jiwari starts it with everything your organisation has already established. By the tenth application, there may be almost nothing left to add.
Because it is one connected model rather than ten, a question that used to need an integration project becomes a query. The path from a customer, to the contract they signed, to the employee accountable for it, is one traversal across what were three separate applications.
Five applications, one growing World
App 1Projects
EmployeeProjectTask
App 2Sales
EmployeeCustomerContactOpportunity
App 3Releases
CustomerEmployeeProductRelease
App 4Vendor risk
ProductSupplierRisk
App 5Contracts
CustomerSupplierContractObligation
Reusedalready in the World Addedintroduced by that application
For AI agents and builders
Notice what the agent did not create.
Coding agents are extraordinarily capable when they understand the environment they work in. Jiwari describes that environment to them through MCP. Before an agent creates another Customer type, it can ask whether Customer already exists, inspect the Schema, and find out what it is allowed to do.
When the application genuinely needs something new, the agent proposes it. Jiwari validates the change, checks ownership, compatibility and permissions, versions the Schema and records who asked. Only then does it become part of the model.
AI does the labour. Jiwari keeps the governance.
A coding agent, asked for a new application
"Build an application for managing customer product implementations."
Already existsReused from the World
CustomerProductEmployeeContractProject
ProposedGenuinely new
ImplementationDeploymentGoLive
With Jiwari
Discover. Reuse. Extend.
Without it
Guess. Duplicate. Integrate.
One model, every interface
Your application gets an API. Your agents get MCP.
Keep building the experience however you like: React, Next.js, native mobile, internal tools, generated interfaces. Host it wherever you want. Jiwari sits underneath and provides the durable data layer you would otherwise design, build and run yourself.
Applications and agents are two first-class ways into the same governed data. There is no privileged agent back door and no separate AI copy of your enterprise. Both:
- see the Schema appropriate to them
- operate under the same authority
- pass the same validation
- change the same underlying data
- leave the same history
Your applicationAny framework, hosted anywhere
API
Jiwari
SchemasRelationshipsAuthorisationValidation
TransactionsHistoryGovernanceVersioning
MCP
Your coding agentsYour models, running where you run them
Governance
Part of the substrate, not a workflow around it.
Governance usually arrives after the application is built. In Jiwari it is part of the model. Whether a change comes from a person, an application or an AI agent, the same rules apply.
| Mechanism | What it decides |
|---|---|
| Schema ownership | Who controls the model. You cannot edit a Schema you do not own. |
| Permissions | Who and what may read or change each type and each field. A field outside your projection is withheld, and the response says so. |
| Validation | Whether a change keeps the data intact. Every write is checked against the Schema before it lands. |
| Versioning | How the model evolves. Every change is classed as additive, compatible or breaking, computed from the change itself. |
| History | What changed. Every write is a change set: atomic, attributed, idempotent and reversible. |
| Provenance | Who, or what, changed it, and through which surface. |
An agent never exceeds its person
An agent can do what the person whose token it carries can do, or less. Never more. A read-only agent is not even shown the tools that write.
Prompt injection can't widen access
An agent's authority is settled before it reads anything, from roles your administrators granted. Text inside a record cannot talk it into more.
Every change can be undone
An undo is the change run backwards: itself a governed, attributed, versioned change, not a silent rewind.
Starter Schemas
Start from a Schema, not a blank page.
Pick a starter Schema for a common domain, then adapt it. Once it is in your World it belongs to you: rename types, add properties, remove what you don't need. Jiwari itself holds no opinion about your business. Individual Schemas can.
Organisation
Employees, departments, roles, locations
Customers
Customers, contacts, opportunities
Projects
Projects, tasks, milestones
Products
Products, releases, features
Suppliers
Suppliers, products, risks
Contracts
Contracts, terms, obligations, parties
A small product, on purpose
The durable layer, and nothing else.
Jiwari doesn't provide your CRM screens or your customer portal, and it doesn't tell your developers which framework to use. Build the software your business needs, change it whenever you want, or replace it entirely. The World stays.
The application can change. The enterprise state endures.
| Jiwari is not | Because |
|---|---|
| A low-code builder | It gives you a usable interface from a Schema, not a form or workflow designer. |
| A rules engine | Decisions belong in Kebiki, which reads the same World. |
| An AI assistant | It serves your agents. No language model sits in the data path. |
| An ontology programme | The model grows from real applications, not a design exercise up front. |
| An ETL platform | Integration reconnects silos after they exist. Jiwari stops many from being created. |
| A BI or dashboard tool | It holds connected operational state. Reporting tools can read it. |
Part of Archiveris
Jiwari holds what exists.
Jiwari works on its own, and it is the ground the other Archiveris products stand on. Kebiki determines what follows from the world Jiwari holds, and Teban reads the same state to answer what an actor may do next. Archiveris composes all three into governed Business Operations your workflows and agents invoke.
Jiwari used to be called Vertex, then KotoDB. What changed?
Only the name. Jiwari is the same product, now one of three from Archiveris. Your Worlds, Schemas and integrations carry on as they are.
How do we get started?
Start with one application and the Schema it needs, either your own or a starter Schema adapted to fit. We set up your World, on our infrastructure or against a database you operate. Then your developers connect the application through the API and their coding agents through MCP.
Evaluating for an enterprise? We will take your security, privacy and architecture teams through how authority, history and data residency work in Jiwari.
Is this a graph database?
A graph database stores the data, and Jiwari decides what may be done to it. The product is the governed model on top: Worlds, Schemas, shared and borrowed entities, authority, and the API and MCP surfaces generated from them. Nobody using Jiwari needs to know graph query languages.
Why not just give each application its own Postgres?
Postgres is a great database for one application. Jiwari addresses what happens across many: if every new application creates its own Customer, Employee and Contract, you speed up software and speed up fragmentation with it.
Do we need to design an enterprise model first?
No. That is what Jiwari is designed to avoid. Start with the Schema one real application needs. Add another when there is another need. Where concepts overlap, Jiwari suggests the match and your people confirm it.
Can an AI agent change anything it wants?
No. An agent works through the same authority model as everything else, and never holds more authority than the person it acts for. Changes to the model are proposed, validated and versioned, and every change it makes to data is attributed and reversible.
Does our data train anyone's model?
No. Nothing in Jiwari sends your records to a model provider. Your agent is yours, runs where you run it, and reaches your data through tools that enforce your permissions.
Can we keep the data in our own infrastructure?
Yes. Jiwari can run against a database you already operate, so every record stays inside your infrastructure and the credential never leaves it.
Start with one application. Let the World emerge.
Bring an application you run today, or one you are about to build. We will show you its Schema, the API and MCP surfaces Jiwari generates from it, and what the next application inherits from the first.