Documentation · Orbis Atlas
Orbis Atlas concepts
Atlas is the map at the heart of ForgeOrbis. This page explains the three things it holds, and how a single question uses all of them.
What Atlas is
Your warehouse, your ticket system, your logs and your ERP each hold part of the truth. Atlas connects them and describes what their records mean: which things exist, how they relate, what may be changed, and how all of it changed over time. It does this in place. Objects are live views over the systems that own the data, never second copies.
Objects and links
An object is one typed thing your operation cares about, with properties. A link is a typed relationship between two objects. Together they form the map a question can travel across.
A starting map for operations teams uses these object types: Station, Process, Incident, Ticket, Operator. Typical links read like plain English: a station runs a process, an incident affects a station, a ticket tracks an incident, and an incident is assigned to an operator. Your deployment adds the objects your business uses, such as orders, shipments or suppliers.
Actions
Actions are the only way Atlas changes anything. Each action is typed and takes checked parameters, and every object it names must exist. Before it runs, a person approves it. It can only reach systems on your allow-list, and every run, approved or refused, is written to a hash-chained audit trail you can verify.
The ontology defines these actions: Open incident, Assign owner, Create ticket, Notify, Resolve incident.
Create ticket and Notify run today. The others are defined but not yet wired, and Atlas refuses them rather than pretending they ran.
Time
Atlas keeps an append-only history of every object and link. That means you can ask what the map looked like at a past moment, see exactly what changed between two moments, and trace any value back to the system it came from. History cannot be edited, so it can be trusted.
A question, end to end
Take the question: which critical incidents have no ticket yet, and who owns them? No single system can answer it. Alerting knows the incidents, the tracker knows the tickets, and the ownership map knows the owners.
- Atlas follows the links: incident to station, ticket to incident, incident to owner.
- Orbis AI answers, citing the record behind every claim and the system it came from.
- If the answer calls for a change, the Cognitive Kernel proposes an action, such as creating a ticket and assigning the owner.
- A person approves it. The Executor writes it to the tracker and records it in the audit trail.
- Ask again, and the incident no longer appears: the map reflects the change.
Using Atlas in the app
Open Atlas from the left rail. It has six views.
- Overview. The home dashboard: how many objects and links the model holds, which critical incidents need a decision, the latest actions, how many ran or were refused, whether the audit verifies, and every Atlas capability with its real status. Anything live opens the screen behind it.
- Explorer. Search every object or filter by type. Open one to see its properties, the system it was read from, what it links to, and what changed. Follow a link to the object at the other end, and act on the object from the same panel.
- Ontology. Every object type with its properties and how many exist, how the types link, and the actions allowed on them with the governance each carries.
- Questions. See the incidents that no ticket tracks yet, with where each happened and who owns it, and propose a ticket from any of them.
- Actions. Propose an action, then review it before it runs. The review is a dry run by the executor itself: it shows the change the action will make and every check it must pass, from its inputs to whether the destination is on your allow-list, while nothing has run yet. If a check would fail, the action cannot be run until you change it. Approve and run it, and you see the result.
- Audit. Every attempt, newest first, with who made it, the outcome, and whether the chain of records still verifies.
When a deployment is showing fictional demo data instead of your systems, Atlas says so at the top of every view.
What is available today
Every capability is marked with its real status. Capabilities marked mapped at deployment are set up for your systems by our team as part of your deployment.
- Live
Data integration
Logs, tickets, chat and paging tools, and any system with an MCP server, connected in place.
- Live
Streaming ingestion
An edge collector streams new records from your servers over mutual TLS, as they are written.
- Live
Real-time alerting
Monitors detect a condition, route it to the responsible owner, and open and update the ticket.
- Live
Governed write-back
Approved actions reach the system that owns them through allow-listed connectors, every one audited.
- Live
Action simulation
A dry run of every check an action faces, and the change it would make, before anything runs.
- Live
Cited answers
Plain-language questions answered with the record behind every claim, on Orbis, our own model.
- Live
Explorer
Search every object, see which system it came from, what it links to and how it changed, and act on it with approval.
- Mapped at deployment
Databases, ERP and CRM
Connectors built for your specific systems as part of deployment.
- Mapped at deployment
Cross-system questions
One query across every connected system, such as critical incidents that no ticket tracks.
- Mapped at deployment
History and lineage
As-of questions, change diffs, and the source of every value.
- Coming
Source-to-object pipelines
Declarative mappings that turn any new source into objects, without code.
- Coming
Studio
Build apps on your objects and actions without writing code.
- Coming
Process mining
See how work actually flows through your systems, and where it stalls.
- Coming
Simulation
Test a decision against a copy of the map before you commit to it.
- Coming
Developer SDK
Typed access to objects and actions from your own code.
Live means shipping in the product today. Mapped at deployment means the capability exists, and our team sets it up for your systems during deployment. Coming means on the roadmap and not built yet. We never show it as available.