What is ISE?
ISE (Infrastructure State Engine) connects to the systems that run your organisation, pulls their state into one place, detects issues, proposes fixes, and gives you one governed place to make changes — with tiered approvals and a complete audit trail.
The problem it solves
Section titled “The problem it solves”Three things go wrong when infrastructure lives in a dozen consoles:
- Fragmentation. State is spread across separate products with separate query languages. “What changed across the estate today?” has no single answer, and a question that spans two systems means two tabs and a mental join.
- Toil. Routine detection and diagnosis — correlating an alert with the config change that caused it — is repetitive work that eats the time you meant to spend on the actual problem.
- Governance. Changes to sensitive systems happen through vendor consoles with weak change control. Who changed that, when, and who said they could?
ISE answers all three from one place: one estate, one incident queue, one approval pipeline, one audit log.
Who it is for
Section titled “Who it is for”Infrastructure operators who are technically expert and want less tab-switching and more control — not a simplified abstraction over their systems. ISE shows you real resources with real names, and it expects you to know what they are.
How it behaves
Section titled “How it behaves”Read fast, act deliberately. Observing is instant and free; mutating is explicit, tiered, and audited. The interface never makes a write feel casual.
AI proposes, policy disposes. Models produce analysis and proposals with evidence attached. What may execute — and what needs a human signature first — is decided by declared risk policy, never by the model. There is no mode in which AI mutates a sensitive system without a human approval on record.
Evidence over vibes. Every incident and proposal links to the state, events, and reasoning that produced it. You can always answer “why is ISE telling me this?”
One contract. Everything the UI can do is a versioned REST API call, so the platform is scriptable by construction.
What you get
Section titled “What you get”| Surface | What it is for |
|---|---|
| Overview | The pane of glass: one card per connected system, plus estate-wide strips for open incidents, pending approvals, and recent activity. |
| Estate | Every entity ISE knows about, joined across sources, with tags, relationships, and context. |
| Incidents | The work queue. Incident detail is a conversation — analyse, diagnose, propose, approve, execute, all on one timeline. |
| Approvals | The governance heart: what is waiting, its exact parameters, its tier, and who proposed it. |
| Dashboards | A glanceable wallboard for a TV — rolled up, latched, readable across a room. |
| Tags | The estate read by classification instead of identity, with alert heat per tag. |
| Events | The timeline of things that happened — deploys, CI runs, changes. |
| Assist | Read-only chat over the estate; answers cite the records they came from. |
| Agent runs | The full trace of any AI run — the “why did it say that” screen, not a debug page. |
| Audit log | Append-only record of every actor, action, and outcome. |
What ISE is not
Section titled “What ISE is not”- Not a SIEM. It consumes security-relevant signals; it is not log aggregation or threat detection.
- Not an ITSM. No ticket queues, SLAs, or service catalogue.
- Not a replacement for vendor consoles. ISE covers the monitored and governed surface; long-tail administration stays in the native tools.
- Not autonomous ops. Nothing sensitive changes without a human on the record.
Next steps
Section titled “Next steps”- Install ISE on a Kubernetes cluster.
- Read the core loop to see how monitoring becomes governed change.
- Connect your first system from the integrations guides.