# Zeus

> Zeus is the Boltcliq ontology platform: one model of your organization for business intelligence, workflows and AI agents.

Canonical URL: https://www.boltcliq.com/products/zeus
Part of: https://www.boltcliq.com/llms.txt

One shared model of your organization, for people, software and agents.
- One: definition of each business object, shared by every Boltcliq product
- Mixed: human and AI steps in a single workflow
- Traceable: every number links back to its source through lineage
- Sector packs: starting ontologies for banking, health, agriculture, public sector and logistics
- Define the business once. Let every person, system and agent work from it.
### Overview
- Most organizations do not have one definition of 'customer'. Core banking holds one version, the mobile channel holds another, and the branch keeps a third in a paper file. The same is true of a shipment, a patient, a farmer or a permit. Each report is correct inside its own system and wrong when set beside the others. Teams spend their weeks reconciling numbers instead of acting on them.
- Zeus fixes this at the root. It holds an ontology: the objects that matter to the organization, the properties and links between them, the rules that govern them and the actions people and software may take on them. You define 'loan', 'borrower' and 'branch' once. The definition is versioned and reviewed like code, and every application, report and AI agent reads from it. Other Boltcliq products refer to Zeus objects by ID. Nobody keeps a private copy.
- On top of that model Zeus gives you three things. You can analyse the business with governed metrics and plain-language questions whose answers trace back to source. You can design workflows that mix human approvals and AI steps, with escalations and service levels. And you can build operational applications, including mobile and low-bandwidth views, on the same objects. Zeus sits above your existing core banking, ERP and spreadsheets. It does not ask you to replace them.
### Zeus in one picture
- One shared model of your organization, for people, software and agents.
- Define 'customer', 'shipment' or 'patient' once, versioned and reviewed, and reuse it everywhere.
- Ask questions in plain language and see exactly where each number came from.
- Design workflows that mix approvals, people and agents, then run them on Argus.
- Schematic of Zeus. Illustrative, not a product screenshot.
### How it works
**Connect what you already have**
- Zeus connects to the systems you run today: databases, ERPs, core banking systems, spreadsheets, APIs, files and scanned documents. Data stays where it is until a use case needs it. Each connection is a recorded, reviewed source, so you always know what feeds the model.
- Read the loan book from core banking and the branch reports from PDF.
**Model the business**
- In the ontology studio your modelers define objects, properties, links, rules and actions. Changes are versioned, reviewed by a second person and promoted from development to staging to production. Nothing changes the meaning of a business term without a record of who changed it and why.
- Loan, Borrower, Branch; action: Approve loan.
**Ask and analyse**
- Governed metrics define a number once, so two teams cannot report two answers to the same question. Analysts ask in plain language and get an answer with its lineage. Anyone can click through from a figure to the records and the source system behind it.
- Which branches have slowing approvals this month?
**Design the work**
- Process owners design workflows with approvals, escalations and service levels. Steps can be done by a person, a rule or an agent. Workflows run on Argus, access is checked through Odin, and every decision is emitted to Cyclopes.
- Escalate any approval over the limit to a credit officer within four hours.
**Build and improve**
- Operational views, forms and queues are built on the same objects, including mobile and low-bandwidth versions for field staff. As you learn what works, you change the ontology or the workflow and promote it through environments, with the previous version kept for rollback.
- A branch supervisor works the approval queue from a phone on a weak connection.
### Capabilities
**Ontology studio**
- The workspace where objects, properties, links, rules and actions are defined. Every change is a versioned proposal that a second person reviews before it is promoted. Modelers can see what depends on an object before they change it. The result is a model the business trusts because it has an owner and a history.
- Objects, properties, links, rules and actions
- Versioning, review and rollback
- Impact view before a change is promoted
- A shared definition only works if people can see who changed it and what it affects.
**Data integration**
- Connectors to databases, ERPs, core banking systems, spreadsheets, APIs, files and scanned documents. Zeus maps each source onto ontology objects and keeps the mapping visible. Handwriting is a known hard case and is scoped per project.
- Relational databases and ERP exports
- Spreadsheets, CSV and PDF files
- OCR for scanned documents
- In most African organizations the data is spread across legacy systems and paper. Getting it in is the hardest part.
**Semantic and query layer**
- Governed metrics sit on top of the ontology, so a measure such as active borrower or on-time delivery is defined once. People can ask questions in natural language and get answers they can verify. The same layer serves SQL users and applications through one set of definitions.
- Metrics defined once and reused
- Natural-language questions with cited sources
- SQL access for existing BI tools
- It ends the argument about whose number is right.
**Workflow designer**
- Design processes that mix human and AI steps. Add approvals, escalations, service levels and fallbacks. A step can wait for a person, run a rule, or hand work to an agent registered in Monolith. Workflows run on Argus, so they inherit its isolation and recording.
- Approvals, escalations and service levels
- Human, rule and agent steps in one flow
- Decisions emitted to Cyclopes as events
- Agents are only useful when they fit into a process that people already own and can audit.
**Applications on the ontology**
- Operational views, forms and work queues built directly on ontology objects. Because they use the same model, a new application does not need its own data layer. Mobile and low-bandwidth views are a design requirement, so field staff and branch teams can use them on the connections they actually have.
- Forms, queues and operational views
- Mobile and low-bandwidth layouts
- Actions that write back through governed rules
- Software that matches how the work is done gets used. Software that does not gets bypassed.
**Lineage, quality and catalog**
- Every number can be followed back through the metric, the objects and the source system. Quality checks flag missing, late or inconsistent data at the point it enters the model. A catalog lists every object, metric and source with its owner.
- Click-through from figure to source record
- Quality rules and alerts on inputs
- A catalog with named owners
- Auditors, regulators and executives all ask the same question: where did this come from?
**Vertical templates**
- Starting ontologies for banking, health, agriculture, public sector and logistics, with sample workflows. We expect to develop them with design partners. They are a starting point, not a finished product. You adapt them to your own terms rather than starting from a blank page.
- Banking, health, agriculture, public sector, logistics
- Sample objects, links and workflows
- Edited and owned by you
- A small first model that people actually use is what makes a pilot realistic.
**Environments and promotion**
- Development, staging and production environments for ontologies, workflows and applications. Changes move forward only after review, and each promotion can be rolled back. The environments run on Argus, so isolation and quotas apply to them too.
- Dev, staging and production
- Reviewed promotion with rollback
- Per-environment access through Odin
- The business model is production infrastructure. It needs the same discipline as code.
### What an ontology looks like in practice
- An ontology is easier to understand through an example than a definition. Take a lender. The objects are Borrower, Loan, Branch and Officer. Links say that a Loan belongs to a Borrower, is held at a Branch and is approved by an Officer. Rules say that a Loan above a limit needs a second approver. Actions say what can be done: Approve loan, Request documents, Escalate.
- Once that exists, a report is a question over objects, a workflow is a series of actions, and an agent is another actor that is allowed some of those actions. The lender does not need a new data model for each tool. It changes the ontology, and everything that reads it changes too.
- Objects describe the things that matter.
- Links describe how they relate.
- Rules describe what must hold.
- Actions describe what can be done, and by whom.
### Use cases across Africa
- Banks
- A bank holds customers in core banking, a mobile banking channel and branch paper files. Credit officers cannot see one view of a borrower. Approvals stall because each team checks a different system.
- Zeus models Customer, Account and Loan once and maps core banking, the mobile channel and scanned branch forms onto them. A credit approval workflow routes each application, with an escalation rule when the amount is over a limit. Every step is recorded as a decision event.
- The credit committee sets the limits and the rules. A credit officer approves or declines each case. Modelers decide when a change to the Loan definition is ready to promote.
- Telecoms
- An operator distributes airtime and data through thousands of dealers and sub-agents. Sales, field and finance teams each count an active agent differently, so targets and commissions are disputed.
- Zeus models Dealer, Agent, Outlet and Distribution as linked objects with one definition of active. Distribution data from the billing system and field visit logs are mapped to it. Analysts and field managers read the same numbers, and a workflow flags outlets that fall behind.
- Commercial leadership defines what active means. Regional managers decide which outlets to visit and what support to offer.
- Agriculture
- A cooperative keeps farmer registers, plot sizes, input loans and delivery records in spreadsheets and notebooks kept by different field officers. Export buyers ask for traceability the records cannot give.
- Zeus models Farmer, Plot, Season, Input and Delivery as linked objects. Spreadsheets and scanned register pages are mapped onto them, with quality checks on missing plot data. A traceability view follows a delivered lot back to the plots it came from.
- The cooperative board decides what records are required for each season. Field officers confirm or correct flagged records on site.
- Government
- A ministry runs permits, service requests and revenue collection in separate systems. Citizens are asked for the same documents several times, and oversight bodies cannot easily trace a case end to end.
- Zeus models Citizen Request, Permit, Payment and Case once across the agencies involved. Lineage shows which system each fact came from, and a workflow tracks each request against its service level. Applications for officers run on the same objects.
- Officers approve or reject requests under existing law. Agency heads decide what data may be shared between departments.
### Interfaces
- REST ontology API
- Read objects, links and metrics; invoke actions.
- GraphQL ontology API
- SQL access
- For existing BI tools and analysts.
- MCP server
- Lets agents query and act on the ontology under policy.
- SDKs
- Database and ERP connectors
- Core banking connectors
- Scoped per partner and system.
- Spreadsheets and files
- Scanned documents (OCR)
- SMS
- USSD
- WhatsApp
- The lists describe target interfaces and are confirmed per release and per design partner. Nothing on this list is a claim that an integration with a named third party exists today.
### Security and sovereignty
**Access through Odin**
- Zeus has no login or permission engine of its own. Every read of an object and every action is checked through Odin.
**Governed actions**
- Actions such as approving a loan run under rules you define. Each one is recorded with the person or agent behind it.
**Inside your boundary**
- Zeus runs on Argus, in your AWS account, a Boltcliq-managed single tenant or portable infrastructure. Data does not need to leave your jurisdiction.
**Tenancy and environments**
- Each customer, environment and project is isolated. Development changes cannot reach production without review.
### What Zeus does and does not do
- Define business meaning: objects, links, rules and actions.
- Integrate and map data from existing systems.
- Expose governed metrics, queries and actions.
- Run mixed human and AI workflows on Argus.
- Record lineage and emit decision events.
- Run its own login or permission engine (Odin does).
- Hold agent memory or govern what an agent may know (Monolith and Argus do).
- Observe system health or agent quality (Cyclopes does).
- Replace your core banking, ERP or spreadsheets.
- Claim a certification it does not hold. None is claimed today.
### Questions
- What is an ontology, and how is it different from a data warehouse?
- A warehouse stores tables. An ontology models the things in the business, how they relate and what can be done to them, so applications and agents share one meaning. It can sit over a warehouse and use it as a source.
- Do we need to replace our core banking system, ERP or spreadsheets?
- No. Zeus connects to them and maps their data onto the ontology. The ontology is a layer above your systems, not a replacement.
- How do you handle paper and scanned documents?
- Printed forms are the easier case. Handwriting is a known hard case, so we scope it per project and keep a human review step.
- Does it work on low bandwidth or offline?
- Low-bandwidth views are a design requirement for applications built on Zeus. Offline-first components are also a design requirement and are scoped per deployment. We will not claim offline support for a given use case until it has been tested there.
- Can we start with one department or one sector?
- Yes. The recommended start is a single department or vertical with a sector template, then expand. A small first model that people use is better than a large one nobody trusts.