Your company brain.
Built with you, owned by you.

use cases

Operational resilience, mapped before the scramble.

Every important service, on one current record - what it depends on mapped before anything breaks, trouble noticed before customers feel it, and every notification deadline tracked from the moment it starts.

“When something breaks, the regulatory clock starts before we have understood what happened.”

§ 01 Is this you?

Is this you?

  • When a system goes down, your customers notice before you do.
  • In an incident, the first hour goes on working out what depends on what.
  • Monitoring, the service desk and supplier updates each show part of the picture, and nobody joins them up.
  • Nobody can say quickly whether a disruption has started a deadline to tell a regulator or your customers.
  • Your continuity plan and dependency map were last right on the day they were written.

If two or more of these sound familiar, this is the use case to start with.

§ 02 Before and after

Before and after

today with a company brain
A service starts to degrade Errors and slow responses build in monitoring until an outage or a complaint makes someone look. The drift is noticed early, and the service owner has a review of what depends on the service before customers feel it.
A security event is logged Containment is worked out under pressure, and either waits too long or runs without anyone weighing what it touches. The containment step is prepared with what it would touch, and runs only on a named person's word.
A service nears its limit The deadline to notify a regulator is found after it has started, sometimes after it has passed. It is escalated with the notification duty identified, and every deadline tracked from the moment the disruption began.
Who has the whole picture Every system has an owner. The map of what your important services depend on belongs to no one. One current record of each important service: its dependencies, its tolerances and its incidents.
§ 03 What you would see

Illustrative: the shape of what you would receive, not a client's record.

What you would see

pre-incident review

Payments service: errors and response times drifting up

what it saw
Error rates and response times rising on the payments service, ahead of any outage.
what depends on it
Online checkout, the customer app and the overnight settlement run.
likely cause
A database the service relies on is slowing under load.
recommends
Investigate now, before the disruption reaches the level you have said this service can tolerate.
how sure
Sure of the trend and of what depends on it. Less sure of the cause.

recommend opened for the service owner

containment playbook

Security event: unusual access to a production server

what it saw
Repeated sign-ins to a production server from an account that does not normally use it.
prepared
Suspend the account and isolate the server, step by step.
what it would touch
The customer portal, which runs on that server, for as long as it is isolated.
how sure
Sure the access is unusual. Not sure it is hostile.
sources
The access logs, the account record and the service map, each linked.

draft ready, held for the incident lead's word

incident brief

Important service nearing its tolerance: customer logins down

what happened
Customers have been unable to log in for part of the morning, and the disruption is nearing the limit you set for this service.
what it triggers
A duty to notify your regulator, and possibly customers, within set deadlines.
deadlines
Each one tracked from the moment the disruption began, with the time remaining shown.
owners
Head of operations for the response; head of compliance for the notification.
recommends
Escalate now, and prepare the notification for sign-off.

recommend escalated to both owners

Every output says what it saw, why it matters, what it recommends and how sure it is, and links each fact to its source.

§ 04 How it works

How it works

  1. 01 it notices Error rates, response times, security events, supplier failures and complaint spikes, where they already arrive.
  2. 02 it connects Each one to the important service it affects, and each service to what it depends on, its tolerance and its playbooks.
  3. 03 it judges Whether a service is heading for its limit, what a response would touch, and when a deadline has started.
  4. 04 it checks Every action against your rules: who may see what, and which steps need a named person before they run.
  5. 05 it acts Within the permission you have granted: it opens a review, prepares a playbook, escalates, or acts where you allow it.

It reads from your monitoring, service management, incident and security tools, and from your continuity plans. It does not replace them, and nothing is migrated.

§ 05 What it runs on

The parts of a company brain operational resilience relies on, in the framework's own terms.

What it runs on

01The record
Every important service, what it depends on, how much disruption it can tolerate, its playbooks and its incidents.
02Finding the answer
Each question answered with its sources, or a plain "I can't answer that well".
03The company manual
Which services are important, the limits you have set for each, and who must be told when they are reached.
04The way in for AI tools
How your people ask it from the AI assistant they already use, on the same permissions as everyone else.
05Connectors
Your monitoring, service desk, incident and security tools, and supplier updates.
06Who may see and do what
Who may see security events, checked before every answer.
07Agents and actions
Preparing a playbook or escalating, only through actions agreed in advance. Nothing touches production on its own.
08Where people use it
Where the incident lead gives the word and owners sign a notification.
09Testing it on your own questions
Tested against your own past incidents before it is trusted with live ones.
the company brain keeping it trustworthy, under all of it your systems documents email, calendar business systems your ai tools your people namedsources checked,then kept checkedfirst read in your terms a question,and its answer approvals acting, througha second door 05 connectors 01 the record 06 who may see and do what 02 finding the answer 03 the company manual 04 the way in for ai tools 08 where people use it 07 agents and actions 09 testing on your questions 10 keeping it running 11 keeping every brain current 12 before anythingis built
The twelve parts of a company brain, with the ones operational resilience runs on drawn in red. Read left to right: what comes in, what it knows, and who and what uses it.

what this shows about a company brain

It works through the AI tools you already use

Your people reach it from the assistant they already have, on the same permissions. They might ask:

“If the payments service went down now, what else would stop, and which deadlines would start?”

It compounds

It reads the supplier map that supplier risk keeps and the duties that compliance records, so in an incident the dependencies and the notification duties are already known.

It is yours

The record, the rules and the permissions it builds belong to you, not to a vendor: handed over to your team or run for you. The same company brain runs every use case you add.

§ 06 You stay in control

You stay in control

  1. observeIt reads silently and measures its own accuracy against what really happened.
  2. recommendIt puts the case and a proposed action to a named owner.
  3. draftIt prepares the action, and holds it for a person to sign.
  4. actIt acts within the bounds you set, and logs everything it does.

Each permission is granted or withheld, taken back as easily as it was given, and expires unless someone renews it. Everything starts at observe, and a permission is granted on the measured record, never on a promise. Every action is checked against your rules before anything goes out.

Regulatory incident notifications, customer communications and any containment that touches production stay behind a named person's word, permanently if that is your policy.

§ 07 Where it starts

Where it starts

first scope
One important business service: the one whose disruption would cost you most.
how it proves itself
It runs at observe against your own past incidents first, so you see how it would have done before it is allowed to do anything.
what it connects to
The systems you already run: monitoring, the service desk, incident and security tools, and your continuity plans. Connectors are built for you, as part of the work. How it connects.
what you own
You own the result: the service record, the rules and the permissions, handed over to your team or run for you.
§ 08 Questions

Questions

Does it replace our incident management or continuity tool?
No. It reads from it, and from the monitoring, security and supplier updates it cannot see. Your tools stay where they are; the company brain joins them up around each important service.
Which regulations does it cover?
The ones you choose. It starts with the duties you name: a regulator's operational resilience or incident reporting rules, a standard such as ISO 22301, or the service levels in your contracts.
Who can see what?
Only what each person is allowed to see. Security events stay with the people cleared to work them, permissions are checked before every answer, and every question is recorded.
Will it notify a regulator or contact customers on its own?
No. Notifications and customer messages wait for a named person to sign them, and so does any step that touches production. You can keep it that way for good.
Is this available today?
It is built for each company that runs it, on that company's own brain, not installed off a shelf. The question audit comes first and shows what it would and would not do for you before anything is built.
§ 09 Start

Start

try this on your own record

Take three past incidents: one contained within tolerance, one that surprised you, and one where the regulatory clock started before you understood what had happened. What did your own systems know, and when?

Questions like this are what the question audit answers: about two hundred real questions from your business, each answered in writing, so you know what operational resilience on a company brain would and would not do for you before anything is built. It is a small fixed fee, credited against the build or the service if you go ahead.

book a discovery call → take the diagnostic · 10 min (opens in a new tab)