Dependency and tested fallback exercise
Which declared functions remain retained, unavailable or unknown after the supplied outage?
Worked example
A public agency can document which essential functions can continue on local systems when a shared service is unavailable. Enter exercised fallback evidence for the required duration.
In this fictional exercise, one function can continue, two are unavailable, and one remains unknown. Look at the function rows to see which fallback was tested and which evidence is missing.
Try it yourself
The calculator opens with the fictional example already filled in. Change one input, choose Calculate locally, and compare the result to the original values below. Use Reset fictional fixture to start over.
An unknown result means the available inputs do not support a value. Check the calculator’s Warnings tab for what is missing or uncertain.
- Retained functions 1 functions
- Unavailable functions 2 functions
- Unknown functions 1 functions
- All-function supplied restoration upper bound Undefined for these inputs
Import local JSON or CSV
Files stay in this browser. Maximum 1 MiB. JSON imports are recalculated. CSV supports flat observation tables, with column types taken from the displayed fixture. Empty cells become null.
Compare the arrangements
Keep physical resources and evaluation conditions equal. With identical inputs, all three approaches produce identical arithmetic. The comparison refuses material differences in declared conditions; it does not verify those declarations.
Privacy: comparison inputs may contain sensitive notes or operational details. Storage is off by default. Do not enter personal records or sensitive infrastructure details. Reproduction exports include supplied inputs and notes, including raw small-cell inputs suppressed from CORE-009 result tables. Suppression of displayed results does not make a reproduction export safe to publish.
Executive brief and reproducible export
Review for personal, confidential or sensitive material before saving or sharing. No automatic submission occurs.
Read the generated brief
Method, inputs and limits
Propagate declared availability through a public or fictional function graph and independently evidenced substitutes. Method version 0.2.0. Infer recovery duration, hostile cause or resilience from provider nationality.
| Input | Unit / type | Required interpretation |
|---|---|---|
| functions — Functions and dependencies | functions / json | id, label, state (available/unavailable/unknown), dependencies IDs; fallback state (tested/untested/none), dependencies IDs and evidenceId for tested fallback. |
| unavailableIds — Outage function IDs | function IDs / json | Use the supplied schema and declared units. |
| exerciseHorizonHours — Optional exercise horizon | hours after exercise start / number | Function and tested fallback restoreAfterHours are optional supplied elapsed times from the same start; missing recovery/activation times remain unknown. Horizon status is separate from the untimed dependency result. Minimum 0. |
Visible mathematics / decision rules
primary retained only when declared available and all dependencies retained
a failed primary is retained only when a tested, source-referenced substitute and all its dependencies are retained
route retained-by bound = max(its supplied elapsed restoration/activation time, dependency retained-by bounds); earliest known route bound = min(known primary and tested-fallback bounds)
What this result cannot establish
- Results depend on the completeness of declared dependency and fallback-test evidence.
- Untested substitutes yield unknown, never assumed continuity. No recovery times are invented.
- Every dependency on a route is required. A known blocker stops that route even if another dependency is unknown. Untimed retention means a tested route exists under the stated outage; use the exercise horizon to check when it can be available.
What would falsify the assumptions?
- Run an authorized continuity exercise and compare retained function to actual performance.
- A newly discovered dependency or failed substitute test can invalidate retained status.
- A simpler offline process may retain more service than a shared portal.
- Assumptions fail if the supplied definitions, units, period, scope or source records are wrong or incomplete.
- An independent source audit or replication may contradict an input or the recorded dependency.
- This method creates no resources. Physical conservation is checked in the inventory and transfer ledgers; descriptive graphs and checklists are not resource-flow models.
- The same equations and review checklist can be reproduced with a spreadsheet or structured human-only process.
- This is deterministic arithmetic, a descriptive comparison or a structured governance check, not a fitted causal effect or forecast. Fictional inputs remain an exercise.
- Equal or worse measured errors, net review effort, disclosure burden or fallback under MAR would show no added benefit or added risk; no improvement is assumed.
Reproducible fictional fixture and independently calculated expectations
This fixture is synthetic. It does not describe a country, government, company or event.
{
"observations": {
"unit": "functions",
"origin": "synthetic",
"sources": [
{
"id": "SYN-001",
"kind": "synthetic",
"label": "Fictional paper fallback exercise",
"url": null
}
],
"functions": [
{
"id": "portal",
"label": "Shared portal",
"state": "available",
"dependencies": [],
"fallback": {
"state": "none",
"dependencies": []
}
},
{
"id": "A",
"label": "Service A",
"state": "available",
"dependencies": [
"portal"
],
"fallback": {
"state": "tested",
"dependencies": [],
"evidenceId": "SYN-001"
}
},
{
"id": "B",
"label": "Service B",
"state": "available",
"dependencies": [
"portal"
],
"fallback": {
"state": "none",
"dependencies": []
}
},
{
"id": "C",
"label": "Service C",
"state": "available",
"dependencies": [
"portal"
],
"fallback": {
"state": "untested",
"dependencies": []
}
}
]
},
"parameters": {
"unavailableIds": [
"portal"
]
}
}Expected checks
{
"retainedCount": 1,
"unavailableCount": 2,
"unknownCount": 1
}Download input fixtureAuthoritative background references
- NIST: Cybersecurity Framework 2.0 — Outcome taxonomy, not a calculated national risk score. Reviewed 2026-11-09. Reference, not endorsement or validation.
These sources inform definitions or review practices. They do not validate this implementation or endorse MAR.