Entity
ATM-10442
Terminal at Wuse 2, tied to its location, cash state, and vendor.
Ollandi Platform
Architecture
Explore how Ollandi 5 normalizes telemetry, maintains an entity graph, coordinates domain agents, and separates action proposals from execution. Each layer preserves the context needed to inspect a decision.
Overview
From source telemetry to an execution gate
The architecture separates ingestion, reasoning, coordination, validation, and evidence. These boundaries make system behavior inspectable.
One ingestion and control plane across public cloud, private data centers, edge, and on-premises systems. Supported signals are normalized with provenance and correlated into a live entity graph.
- Cloud and on-premises in one view
- Cross-domain entity correlation
- One plane for telemetry and action
Neural encoders identify patterns in telemetry. Symbol grounding and logical inference relate those patterns to entities, temporal sequences, and security constraints.
- Pattern recognition with logical inference
- A justification for every assessment
- Security-native model training
Intent hypotheses and infrastructure graph traversal identify feasible attack paths. Candidate countermeasures are assessed for coverage, disruption, resource cost, and reversibility.
- Adversary intent modeling
- Next-step prediction
- Pre-positioned countermeasures
Domain agents exchange hypotheses, supporting and refuting evidence, and confidence. Quorum requirements vary by action class; disagreement and participation failures remain visible.
- Domain-specialized agents
- Action-class quorum requirements
- Dissent preservation and escalation
Action descriptors pass schema, policy, impact, confidence, timing, and approval checks. Reversible and semi-reversible actions need defined recovery procedures; high-impact actions require human approval.
- Five action classes
- Automatic rollback
- Separation of duties
Decision records preserve observations, inferences, agent contributions, and outcomes. Feedback informs tested, staged model updates; learning cannot override hard safety constraints or expand authority.
- Evidence as a first-class output
- Learning from every encounter
- Governed, testable updates
Shared infrastructure context
One picture, updated whenever evidence changes
Illustrative ATM state: an entity, a service condition, a dependency check, an obligation, an owner, and a permitted workflow action.
Condition
Not dispensing
Service state changed and the change is time-stamped.
Dependency
Network available
Communication confirmed, so connectivity is ruled out.
Obligation
Service window
Exposure is developing against the agreed service level.
Owner
ATM operations
A vendor route is available for the next action.
Action
Vendor case opened
Routed automatically under the bank's policy, with the evidence attached.
Action classes
Control matched to impact
Every action Ollandi can take falls into one of five classes, and your policies set how each class runs.
| Class | Examples | How it runs |
|---|---|---|
| Observational | Evidence collection, increased monitoring | Within authorized observation scope |
| Reversible containment | Session revocation, temporary network block, privilege suspension | Within policy, with rollback |
| Semi-reversible enforcement | Credential rotation, workload quarantine, host isolation | Within policy, with safety verification |
| High-impact | Account disablement, broad network isolation | Explicit human approval |
| Emergency | Site-wide containment, mass session termination | Pre-authorized emergency protocols |
Enterprise adoption
Start with the operating question
Then choose the context needed to answer it. A disciplined introduction proves the quality of the explanation before Ollandi is given any authority.
Resources
Go deeper into the architecture
Technical paper
Ollandi 5
The production architecture behind security-native, policy-bounded defense.
Read the paperResearch
Glemad research
The ADT and CDA research that informed the Ollandi model class.
Explore the researchPlatform
The platform workflow
See how the architecture shows up in the Ollandi Platform.
Explore the platformFAQ
Frequently asked questions
A pack that gives Ollandi depth in one infrastructure domain: it reads live state, detects threats and failures, explains what they mean, and adds that domain's response actions.
Assets, identities, services, owners, dependencies, policy, and previous conditions, with each piece of evidence keeping its source and time.
The paper reports sub-500 ms consensus in critical scenarios. Timing depends on topology, quorum, and action class. A partition without sufficient quorum requires escalation rather than an unsupported decision.
Your organization, through policy. You decide which classes run on their own, typically observational and reversible actions, and how higher-impact classes run, with separation of duties built in.
Get started
Bring your architecture questions
We will walk through the packs, shared context, and authority model against your own environment.