Inspiration
A backup on paper is not the same as executable recovery.
Banking ICT resilience is often described through providers, backups and controls. But these do not necessarily show whether a critical workload can actually recover within its required tolerance.
We wanted to answer a more practical question:
Which recovery assumption fails first, and what action is actually justified next?
What it does
Systemic Resilience Copilot is an AI-assisted decision-support prototype for analysing ICT recoverability.
A user provides a recovery scenario and structured evidence about dependencies, recovery arrangements and operational constraints.
The system then:
- structures the available evidence;
- identifies the first binding or unresolved recovery stage;
- uses Apertus to interpret and explain the evidence in natural language;
- links the result back to explicit rules and evidence;
- proposes the narrowest justified next action.
The objective is not to generate another generic risk score.
It is to make the reasoning behind a resilience decision visible, traceable and auditable.
AI explains. Rules decide.
How we built it
The prototype combines two layers.
The first is a deterministic decision layer. It evaluates an ordered recovery sequence, preserves UNKNOWN states and prevents downstream conclusions when upstream evidence is missing or a prior condition has already failed.
The second is an Apertus reasoning layer. Apertus handles the language-heavy tasks: extracting explicit facts from a scenario, interpreting the supplied evidence, challenging an interpretation and explaining the deterministic result.
The language model therefore supports interpretation, while the decision logic remains transparent and authoritative.
The current public demo uses synthetic, public-safe scenarios so the complete workflow can be demonstrated without exposing sensitive banking information.
Demo scenario
In the main synthetic case, the required recovery tolerance is 60 minutes.
The recovery route is independent and supports the same workload, but observed recovery takes 95 minutes.
The deterministic engine therefore identifies:
S5 RED / B2 → REPAIR_EXECUTION
After the narrow execution fix, recovery completes in 45 minutes.
S5 then passes, but the system does not declare full resilience. The next unresolved prerequisite becomes visible:
S6 UNKNOWN
Only after simultaneous-demand evidence is established does the systemic lens open.
For three synthetic institutions sharing the same recovery fabric, assured capacity, priority and coordination remain unresolved.
The result is:
S7 UNKNOWN → MEASURE_CAPACITY
A shared recovery resource is not automatically proof of a shortage.
Why Apertus
Apertus is not used as a decorative chatbot.
Its role is to transform technical resilience evidence into understandable decision support while operating inside explicit constraints.
It can structure evidence, explain why a result follows, identify what remains unknown and challenge the interpretation.
It cannot override the deterministic decision state.
This architecture also supports a more sovereign deployment model for sensitive resilience analysis.
The key design principle
The system is deliberately allowed to return UNKNOWN.
If required evidence is missing, the engine does not manufacture certainty.
Instead, it identifies the unresolved assumption and shows what evidence or action is required next.
When the evidence stops, the inference stops.
Challenges we faced
The main challenge was preventing an AI interface from becoming more confident than the underlying evidence.
We therefore separated language reasoning from decision authority and introduced explicit stopping conditions.
A second challenge was making a technically rigorous recovery process understandable within a short interactive demo.
We reduced the workflow to:
Evidence → Recovery state → Decision → Action → Explanation
What we are proud of
The prototype demonstrates how generative AI can support critical-infrastructure analysis without turning the decision itself into a black box.
Every important conclusion remains connected to structured evidence and transparent rules.
Instead of asking the user to trust an AI-generated risk assessment, Systemic Resilience Copilot shows why the conclusion was reached and where the evidence stops.
What's next
The next step is to extend the prototype from individual recovery scenarios to larger dependency networks and multi-service resilience analysis.
This would make it possible to identify shared recovery bottlenecks while preserving the same principle:
transparent evidence, explicit rules and explainable AI-assisted reasoning.
Built With
- actions
- ai
- apertus
- css3
- explainable
- face
- fintech
- github
- html5
- hugging
- ict
- javascript
- vercel
Log in or sign up for Devpost to join the conversation.