Digital Technology & Data Infrastructure

SECTION 01

Domain overview and system boundary

A service boundary is a claim about what a user can accomplish. Inventorying servers alone misses dependencies such as certificate validation, DNS resolution and identity federation. Start with one critical transaction, trace every synchronous dependency, then identify the control services required to diagnose or restore it. Separate the data path from the management path. A seemingly independent backup site may still require the same cloud account or configuration repository. This makes shared administration a candidate common cause rather than proof of redundancy. The end-to-end argument provides a disciplined reason to test correctness at the actual service boundary. [D01]

Digital infrastructure comprises the computing, telecommunications, identity, software, routing, storage and operational capabilities that make digitally mediated services possible. Its boundary includes data centres and physical networks, but also DNS, certificate authorities, cloud control planes, software dependencies and the people authorised to change them. A public-facing application can remain physically intact while becoming unreachable because a shared control service fails. The analytical unit is therefore a service and its dependency graph, rather than a count of servers.

This library studies the preservation of trustworthy service under overload, accidental change, adversarial compromise and external disruption. Availability, integrity, confidentiality and recoverability can conflict: continuing to accept writes during a partition may compromise consistency, while isolating a compromised service may interrupt essential operations. The learning case should specify which transactions matter, who depends on them, the maximum tolerable loss and the conditions for safe reconnection. Restoration includes both functional service and justified confidence in the data it carries.

A domain label is not yet a case boundary. Separate the condition of a resource or asset from the function delivered to users. A nominally available installation may fail to deliver usable service, and a system-wide average can conceal localized loss. Preserve the original physical or institutional unit alongside any normalized representation. The boundary should make it possible to ask what enters, what changes, what leaves and who experiences the consequences.

Section readings [D01]

SECTION 02

Historical development and changing conditions

The history of digital reliability is not a steady transition from failure to resilience. Distributed storage increased tolerance of individual machine failure while introducing replication, coordination and configuration complexity. MapReduce, Chubby, Dynamo and Spanner represent different workload and consistency choices, not successive universal solutions. A learning timeline should identify which failure assumptions changed, which workload was supported and which costs were accepted. Historical latency or recovery rates should not be imported into a present case without matching architecture, data scale and operational capability. Compare the engineering trade-offs before assigning a calibration value. [D05] [D06] [D07] [D08]

A historical baseline must be examined for changes in exposure, technology, operating practice and observation. Compare episodes using their mechanisms and evidence, rather than treating all events with a similar label as exchangeable observations. A reconstruction should show what was known at each time; later explanations should not be presented as information available to the original decision maker. Recovery and long-term change may require a separate timeline from the initiating incident.

Section readings [D05; D06; D07; D08]

SECTION 03

Actors, institutions and decision responsibilities

Responsibility is distributed across service owners, network operators, cloud providers, software suppliers, identity services, incident responders and public authorities. Their evidence products answer different questions. An operator postmortem can explain a technical sequence; a vulnerability advisory identifies affected products; a regulator may establish a control failure within a specific remit. None is automatically a complete causal account. For the case, record who controls each change, who can order isolation, who holds restoration keys and who informs dependent organisations. Institutional mapping becomes operational when each responsibility has an available alternate and an evidence trail. [D14] [D15]

Map actors by the function they perform and the responsibility they actually hold in the case. The same organization may observe a condition, supply a service and participate in a decision; those roles should remain distinguishable. Examine information access, resources, expertise, affected users and accountability together. A list of institution names is not an operating governance arrangement. Record the evidence for each responsibility and the process for resolving a disagreement or correcting a record.

Section readings [D14; D15; C07]

SECTION 04

Primary systemic risks

Primary digital risks must be defined as loss mechanisms at an identifiable boundary. Network unreachability, data corruption and credential compromise have different detection and recovery requirements even when all produce the same customer complaint. The risk register should record initiating conditions, affected transactions, exposed populations and plausible loss of function. Classify correlated failures separately from independent component failures. A service may be reachable but return stale or wrong information; that condition belongs in the register rather than being hidden by an uptime metric. The distributed-system literature clarifies why safety and progress need separate treatment. [D02] [D03] [D04]

The inventory is a structured set of research hypotheses. It separates a threatening condition from the mechanism of loss and from its consequences. The proposed TFP association indicates which question to investigate; it is not evidence that a particular indicator predicts the event. Risk importance depends on the defined function, exposure, duration and usable alternatives. Do not infer frequency, severity or priority from the position of a row in the table.

Section readings [D02; D03; D04]

SECTION 05

Amplification mechanisms and secondary risks

Amplification occurs when response to a fault generates additional stress. Retries, cache misses, leader elections and emergency restarts can all increase work while useful capacity declines. A local component failure can consequently become an overload incident without any increase in original user demand. Compare the rate of original requests with total attempts and observe the queue age, not only request count. A protective action should be assessed for its feedback effects: restarting every replica together can erase useful caches and synchronise demand. The case should identify where load shedding preserves essential service. [D09] [D14]

An amplifier changes the consequences of an initiating condition without necessarily causing the initiating event. Useful counterfactuals hold the threat constant and vary concentration, maintenance, access, information or response capacity. Document the mechanism and the observation that would distinguish it from an alternative explanation. Several amplifiers may share the same upstream cause; counting each one as independent evidence exaggerates confidence.

Section readings [D09; D14]

SECTION 06

Emerging risks and research horizons

Emerging issues should be framed as testable exposure changes. Automated infrastructure agents may increase the speed and scope of privileged changes; cryptographic migration may expose long-lived dependencies; climate stress may reduce power and cooling margins simultaneously. These are mechanisms to investigate, not evidence that a particular failure has occurred. For each horizon item, specify the component inventory required, an observable signal and a decision that the signal could change. Preserve the distinction between a novel technology label and a new causal pathway. Existing common-mode failures often remain relevant beneath the new terminology. [D15] [D16]

A research horizon is tied to the time needed to investigate, prepare or change a system. It is not a date at which an emerging threat is predicted to occur. Record the reason for concern, the strength of evidence, the exposed function and the observation that would change the priority. Distinguish a newly observed mechanism from a known mechanism whose exposure, scale or institutional context is changing.

Section readings [D15; D16]

SECTION 07

Cascades and cross-domain dependencies

A cascade map should label both the direction and the meaning of an edge. A database may depend on DNS for discovery, identity for administration and power for operation; these dependencies have different interruption tolerances. Represent the service state and the recovery state separately because a dependency needed only during restoration can still control the total outage. Test the removal of a high-centrality control service and then inspect which alternatives remain usable. Centrality is a screening aid, not a measurement of inevitable harm. Evidence on transactions and time tolerances determines the significance of the edge. [D06] [D13]

A logical service can fail across physically separate sites when they share credentials, routing policy, a deployment pipeline or a coordination service. Geographic redundancy addresses some hazards but does not remove common control failures. A dependency map must therefore distinguish shared fate from shared location.

Load-related collapse is nonlinear. As capacity falls, queues grow; users and clients retry; retries consume the remaining capacity and increase timeouts. The resulting demand includes induced work rather than only original requests. An effective scenario tests admission control, retry budgets and degraded service together.

Data integrity may deteriorate without visible downtime. Replicas can serve stale state, duplicate transactions or reconcile incompatible histories. A service-availability percentage should consequently be paired with transaction correctness and consistency requirements.

For each directed dependency, specify the function supplied, the destination, the propagation time and the substitute. Shared-cause failure, interacting threats and cascading propagation are different structures. A directed arrow becomes an explanatory claim only when the timing and mechanism are supported. Test apparent redundancy by removing the common access route, platform, energy supply or specialist on which both alternatives depend.

Section readings [D06; D13; C01; C02]

SECTION 08

Readiness and response protocols

A response protocol should couple a measured condition with a bounded action, an authorised role and a verification step. For an overload scenario, possible actions include pausing nonessential work, reducing retries and protecting the smallest viable transaction set. For an integrity incident, the safe action may be to stop writes and preserve evidence. Those choices should not be collapsed into a single availability trigger. Define how an action can be reversed and what new evidence is required before escalation. Service objectives help express a response target, but they do not grant authority to intervene in another organisation. [D14]

Preparedness connects a signal to a responsible actor, an available measure and a condition of completion. This learning architecture does not grant emergency command or operational authority to the c-ECO Institute or a course participant. A useful protocol distinguishes checking the signal, protecting exposed functions and verifying recovery. A paper plan contributes to usable capacity only when its relevant assumptions have been tested.

Section readings [D14]

SECTION 09

Scientific review and decision records

Technical review should examine assumptions that materially change intervention. A proposed cross-region failover depends on replica freshness, credential availability, dependency separation and the ability of clients to reconnect. Reviewers should ask for the last demonstrated test of each assumption, not only an architectural diagram. Record unresolved disagreement and the conditions under which a provisional decision expires. For urgent incidents, distinguish immediate operational command from later scientific model review. A simulation can propose a decision workflow, but the case must identify the real service owner and the limits of any external analyst’s role. [D10] [D15]

A review record separates observation, inference and decision. Record the data version, methods, alternative explanations, relevant expertise, conflicts of interest and unresolved disagreement. Review should be matched to the question and its consequences. Scientific analysis can inform a competent actor without replacing that actor’s mandate. No membership size, quorum or institutional power is established by this teaching library.

Section readings [D10; D15; C05; C07]

SECTION 10

Communication and observation continuity

Incident communication is itself a dependency. A dashboard hosted on the affected storage platform can be unavailable at the moment it is most needed. Separate internal command, affected-customer information and interdependent-operator coordination. Each message should state the affected service, what is known, what remains uncertain and the next update time. Avoid equating a temporary workaround with verified data recovery. Accessibility matters when residents or staff cannot use the normal digital channel. The AWS incident account provides a concrete reason to test status publication independently from the production service. [D18]

Continuity of observation should be tested alongside continuity of the function itself. Losing data may increase uncertainty before the physical process visibly changes. Redundancy must be demonstrated against common causes, including power, location, communications, credentials and specialist availability. During disconnected operation, preserve the last reliable observation, record the uncertainty that follows and reconcile timestamps and authorship when information paths return.

Section readings [D18; C01]

SECTION 11

International instruments and technical references

Digital governance crosses contractual, technical and jurisdictional boundaries. A standard can guide control design without determining legal responsibility in every deployment. Begin by identifying where the service operates, which organisations control personal or sensitive data, and which contractual commitments govern service and incident reporting. Then check the applicable instruments for that case. The technical library supplies a method for asking these questions rather than a universal compliance certificate. NIST control catalogues are useful for organising evidence, while the authorised legal analysis must determine which controls or duties are binding in a particular setting. [D15] [D16]

Classify each instrument before using it. A scholarly article supports an inference, a technical guide describes a method, a standard has a defined scope, and a legal instrument may create obligations only where applicable. The case record should identify the specific provision or method, its version and the activity to which it relates. A source’s institutional reputation cannot by itself establish applicability or demonstrate compliance.

Section readings [D15; D16]

SECTION 12

Jurisdiction-specific responsibilities and requirements

An institutional baseline should identify assets, software, data classes, access paths and change authorities. The same service name may conceal materially different configurations in different countries or clients. Record version, region, tenancy and subcontracted dependencies before comparing performance. Contractual recovery objectives are not evidence that the capability has been demonstrated. A meaningful baseline includes the actual recovery test, its workload and the exceptions found. The learning case should also distinguish operational logs retained for service diagnosis from data used for a separate research purpose, with access limited accordingly. [D15] [D22]

The register should cover the actual activity and location, including interfaces between organizations and jurisdictions. Separate responsibility for observing, supervising, deciding and executing. Retain the official source, version consulted and evidence needed to assess a condition. Conflicting definitions and overlapping mandates are analytical findings to investigate. A general library cannot create a universal legal threshold for all settings.

Section readings [D15; D22]

SECTION 13

Causation, accountability and cascading consequences

Accountability requires a traceable path from a proposed change to its approval, deployment and observed effects. This is especially important when a security product or shared library affects many organisations simultaneously. Preserve who authorised the scope, what tests exercised the relevant path and how the rollout could be stopped. A postmortem should investigate organisational and technical contributing conditions instead of assuming the last operator action is the whole cause. Supplier reports are valuable primary evidence, but their scope and incentives should remain visible. Independent corroboration is necessary for claims about downstream harm or legal liability. [D20] [D21]

A technical chain of consequences is not automatically a legal allocation of liability. Separate evidence of causation from the duties, control and decisions relevant to each actor. A case may contain direct damage, dependent service interruption and persistent environmental or social consequences on different timescales. The analysis should show which links are documented and which need further investigation, without presuming an institutional restoration fund, mandatory levy or insurance mechanism.

Section readings [D20; D21]

SECTION 14

Cross-boundary coordination

Cross-border service design can move risk without removing it. A second region may share the same global account, control plane, encryption keys or software update channel. A data-location change may also alter access obligations and operational support. Analyse failover as a complete transaction path and a complete restoration path, then identify the jurisdiction and responsible party for each. Technical replication is distinct from permission to transfer data. For the case, document which state is authoritative during partition and how conflicting records would be reconciled after connectivity returns. [D04] [D07] [D08]

Processes and dependencies often cross administrative, organizational or national boundaries. Coordination requires compatible definitions, useful timing, authorized exchange and an identifiable decision interface. Sharing data does not by itself resolve disagreements over objectives, risk allocation or resources. An exercise should expose which decision can be coordinated under existing arrangements and which would require an additional agreement or competent determination.

Section readings [D04; D07; D08; C07]

SECTION 15

Position (P): candidate observations

A candidate P indicator should describe the remaining ability to deliver a defined trustworthy service. Available request capacity alone is insufficient when writes are corrupt or authentication is unavailable. Use several observable components, such as critical-transaction success, recovery-point gap and independent management access, before constructing any composite. Preserve the raw units and denominators so a reviewer can inspect what improved and what deteriorated. Do not average away a safety-critical failure simply because unrelated components are healthy. Any normalisation should be justified by an explicit operational tolerance rather than a convenient statistical range. [D01] [D14]

P represents position relative to a specified loss of function. The raw observation, reference condition, direction of deterioration and boundary of failure must remain explicit. A candidate monotone transformation can help compare states within a defined case, but it does not establish the threshold or validate an aggregate index. Capacity, delivered performance and exposure may require different indicators even when they concern the same installation.

A didactic monotone transformation for an indicator that worsens as it rises is p = clip[(x − x_ref)/(x_failure − x_ref), 0, 1]. Reverse the direction for a reserve that deteriorates as it falls. The expression makes the reference points visible; it does not choose those points, prove comparability or establish an operational aggregate. Retain x in its original unit and justify the function separately for each case.

Section readings [D01; D14]

SECTION 16

Velocity (ΔV): rates and trajectory

Velocity is most useful when it connects a trajectory to an action window. Queue growth, replication-lag increase and faulty-rollout propagation can be compared with the time required to shed load, stop distribution or restore a quorum. A derivative calculated across a workload change can mislead, so retain the original time series and mark interventions. Sampling intervals should be shorter than the process being managed. A five-minute average may hide a rapidly expanding failure. Distinguish the speed of service deterioration from the speed at which investigators discover already affected assets. [D09] [D13]

ΔV describes direction and rate of change over a declared interval. Two systems at the same apparent position may have different reaction times because their trajectories differ. Compare rates using consistent units, observation windows and reference systems. Check seasonality, missing periods, reporting changes and process acceleration before extrapolating. A time-to-boundary calculation is conditional on its trajectory assumption; it is not a general forecast.

Section readings [D09; D13]

SECTION 17

Uncertainty (σ): evidence and model limits

Uncertainty has several sources: incomplete inventory, sampled traces, unobserved clients, ambiguous incident scope and model assumptions about independent failure. Expressing all of them as one symmetric percentage hides their different consequences. A missing dependency may change the topology of the failure path rather than only widen a confidence interval. Record observation coverage and separate measured variation from judgement. During compromise, the uncertainty about whether recovery credentials are clean can be more decision-relevant than uncertainty about outage duration. Use alternative plausible dependency maps to test whether a proposed intervention remains justified. [D12] [D22]

Uncertainty should be recorded by object and source. Measurement uncertainty, sampling limitations, parameter uncertainty, model structure, future scenarios and institutional ambiguity cannot be replaced by one unsupported percentage. More simulation samples can reduce numerical sampling error without resolving a missing mechanism. Identify which uncertainty changes the decision and which further observation, comparison or test could reduce it.

Section readings [D12; D22; C06]

SECTION 18

Reversibility liquidity (Lr): usable recovery resources

Recoverability is a demonstrated capability under stated conditions. A backup file, a spare site and a written runbook are resources; their existence does not establish how quickly a trustworthy transaction can resume. Measure restoration throughput, reconciliation work, credential recovery and client reconnection together. Include physical access, key availability and specialist coverage. The resource that constrains the sequence may change between a power interruption and a compromise. Define acceptance tests before the exercise begins so that restoration is not declared merely because processes restart or health checks turn green. [D14] [D18]

Lr examines resources that can preserve, contain or recover the defined function within the relevant time. A resource listed in an inventory is different from a resource that is accessible, compatible, staffed and mobilizable. Record capacity, useful arrival time, duration, dependencies and evidence of testing. Avoid averaging away an essential bottleneck. Recovery of a service does not necessarily restore ecological condition, accumulated losses or public trust.

Section readings [D14; D18]

SECTION 19

Stress scenarios and comparative strategies

Scenario design should vary mechanisms rather than only increase incident size. Compare a single-zone hardware failure, a global configuration error, a trusted-update compromise and an energy-cooling disruption. For each, describe which replicas, management services and evidence sources remain usable. Include a scenario in which the nominal fallback shares the failed dependency. The objective is to identify robust actions and discriminating observations, not to predict a universal outage probability. Operator postmortems provide plausible sequences, but their exact durations should not be reused as forecasts for a different architecture. [D17] [D19] [D20]

A stress scenario states the initiating condition, prior state, time sequence, exposed function, shared dependencies and feasible responses. Its purpose is to reveal when a strategy loses usefulness and why. Compare alternatives across several conditions, including absent substitutes and simultaneous demand. Scenarios should lead to observations, tests and resource questions; assigning a precise event probability requires a separate justified model and evidence.

Section readings [D17; D19; D20]

SECTION 20

Reproducible simulation and sensitivity analysis

A stochastic exercise can sample repair times, demand and component failures, but it must represent shared causes explicitly. Independent Bernoulli failures for every replica will overstate redundancy when all replicas receive the same update. Separate ordinary component faults from regional and global control events, then compare outcomes under alternative dependence assumptions. Retain the random seed, distributions, workload definition and validation checks. The result is conditional on those choices. Report the frequency of missing the defined service target alongside the amount of unreconciled data, because an apparently fast recovery can preserve the wrong state. [D07] [D10]

Simulation is an explicit transformation of assumptions. Input distributions, dependencies, parameter estimation, output definition and testing must be documented. Numerical convergence does not establish model validity. Examine sensitivity to the function used, the weights selected, dependence assumptions and conditions outside the fitting data. The reproducible laboratory below is a synthetic exercise, separated from SPS and from any claim about real-event frequency.

The factor loadings define association on the latent scale. Correlations after the nonlinear transform should be estimated from the simulated samples. Q is a teaching index and is not SPS. Its exceedance fraction concerns the generated sample under these assumptions; it is not the probability of a real event or a forecast over a stated number of years. A temporal forecast would require a separately specified process and observation model.

from random import Random
from math import log, exp, sqrt
from statistics import mean
rng = Random(3955090826)
m = [.72, .62, .40, .38]
s = [.40, .45, .30, .40]
a = [.65, .55, .35, -.45]
q = []
for _ in range(10000):
    g = rng.gauss(0, 1)
    x = []
    for mj, sj, aj in zip(m, s, a):
        z = aj*g + sqrt(1-aj*aj)*rng.gauss(0, 1)
        x.append(1/(1+exp(-(log(mj/(1-mj))+sj*z))))
    p, v, u, lr = x
    q.append(.35*p+.25*v+.15*u+.25*(1-lr))
q.sort()
print(mean(q), q[499], (q[4999]+q[5000])/2, q[9499])
print(sum(x >= .70 for x in q)/len(q))

Sensitivity exercise: remove the common factor, vary one dispersion, change the weight of recovery resources, and compare the ranking of the selected strategies. Then state which domain observations would be needed to replace each illustrative assumption. Use a suitable estimator when inputs are dependent; the common-factor experiment is a dependence check, not a claim that a particular Sobol estimator applies unchanged.

Section readings [D07; D10; C03; C06]

SECTION 21

Restoration and performance verification

Restoration simulation should model ordering constraints. Identity, DNS and coordination services may need to recover before applications can start, while their own recovery tools may depend on those applications. Identify these loops before assigning task durations. Test a minimum viable recovery path with independent credentials and a small verified dataset. Then expand load gradually while observing queues, replication and client errors. A tabletop exercise can reveal a circular dependency, but only a controlled technical test can establish the performance of a particular restart or reconciliation procedure. Distinguish those two forms of evidence. [D06] [D14]

Restoration follows prerequisites and verification conditions rather than a universal fixed clock. Tasks may proceed in parallel only where they do not compete for the same people, access, equipment or information. Protect essential functions while the critical path is addressed. Define what is measured before returning service, who can make that determination and which effects require continued observation after a technical restart.

Section readings [D06; D14]

SECTION 22

Recovery provider capability

A restoration provider should be evaluated against the specific failure mechanism. Network repair competence does not establish the ability to rebuild a compromised identity environment; cloud expertise does not establish safe handling of sensitive incident evidence. Ask for relevant test results, staffing availability, access requirements and the interfaces with the service owner. The engagement should define what information can be shared and who accepts the restored system. Record vendor dependencies so a supplier-wide incident does not invalidate every provider simultaneously. Qualification concerns demonstrated task capability rather than a generic claim of technological sophistication. [D15] [D21]

Capability assessment must be specific to the task, place and stress conditions. A training certificate cannot demonstrate that a team can mobilize and deliver the required function. Inspect competence, safety, compatibility, relevant experience and actual availability. Define the verification method and limits of recognition. This teaching library does not establish a c-ECO provider certification scheme or substitute for professional or regulatory requirements.

Section readings [D15; D21]

SECTION 23

Recovery sequencing and time constraints

Recovery sequencing should first preserve safety and evidence, then contain propagation, establish trusted administration, restore core dependencies and validate a minimal transaction. Only afterwards should capacity and nonessential functions expand. The sequence is conditional: an overload incident may permit rapid traffic shedding, whereas an integrity compromise may require a prolonged isolation step. Record the evidence that permits each transition and the condition that forces a return to containment. A rollback that restores availability while reintroducing corrupted state has not completed recovery. Keep a separate ledger of data reconciliation tasks that remain after service resumes. [D14] [D20]

A recovery time objective is a decision criterion to test against real capacity. Distinguish mobilization, work, verification and decision time, and identify dependencies between tasks. Shared resources can prevent apparently parallel activities from proceeding together. Repeating the sequence with unavailable access, a specialist or a verification service reveals where a target relies on an untested assumption.

Section readings [D14; D20]

SECTION 24

Equipment, inputs and replenishment

A resource inventory should state compatibility, custody, location and demonstrated usability. Spare network equipment may have the wrong firmware; encrypted backups may be inaccessible without a key service; replacement credentials may rely on the failed identity provider. For each item, record a test date and the conditions under which it was tested. Include human resources and physical access, not only hardware quantities. An inventory becomes analytically useful when it can be joined to the recovery sequence and reveal a task with no available resource or no authorised operator. [D14] [D16]

Inventory analysis connects each item to a protected function. Use condition, compatibility, accessibility and consumption under stress rather than a nominal stock count alone. Replenishment time must include procurement, transport, installation and verification where relevant. A substitute that depends on the same supplier or platform may disappear in the same event. Keep the last inspection date and the evidence supporting usable availability.

Section readings [D14; D16]

SECTION 25

Mutual aid and cooperation arrangements

Mutual aid in digital incidents requires carefully bounded access. An external specialist may help diagnose a routing failure without receiving unrestricted production credentials or personal data. Pre-arrange contact channels, authorisation, evidence handling and revocation procedures. Verify that partner organisations do not share the same affected platform or supplier. Exercises should test how assistance arrives when normal messaging and identity tools are unavailable. The relevant capacity is the aid that can be delivered within the decision window under the scenario conditions, rather than the number of organisations that have signed a general cooperation document. [D15] [D17]

Cooperation contributes to recovery when its scope, activation, resources and practical availability are demonstrated. Record who requests support, who authorizes it, the useful arrival time, responsibility for the work and conditions of return. Consider simultaneous demand across participants. A reference to an organization or network in the literature does not imply that c-ECO or a case partner has joined it or secured a deployment commitment.

Section readings [D15; D17]

SECTION 26

Source classification and evidence quality

Source classification should describe the producer and the evidentiary function of a record. A peer-reviewed consensus paper supports a theorem under assumptions; an operator postmortem documents an incident from a particular perspective; an advisory identifies affected software; a monitoring dataset records observations with coverage limits. These classes are complementary rather than a single ranking. Attach version, date and scope to each item. The historical Estonian voting study, for example, evaluates an implementation and procedure in its study period; it cannot by itself establish the properties of a later deployment. [D11] [D12]

Source classes organize origin and function; they do not form an automatic hierarchy of evidential strength. An official statistic, an operational record and a causal study answer different questions. Classify the product, not only the organization. Detect shared data origins so that a dashboard, article and secondary report based on one observation are not counted as three independent confirmations.

Section readings [D11; D12; C04; C05]

SECTION 27

Institutional, regulatory and technical sources

Public technical bodies provide useful common vocabularies for access control, incident handling and risk management. Their publications should be cited by edition and scope, with the distinction between guidance and a binding requirement preserved. For a learning case, extract the control objective and the evidence that would demonstrate it. Avoid copying an entire checklist without identifying which assets and failure paths matter. A voluntary architecture document can sharpen an identity-boundary analysis, but it does not prove that a particular service has implemented the design or that the implementation is effective. [D15] [D16]

Institutional sources should be selected by product, method and scale. Record whether the source defines a requirement, observes a condition, reports an investigation or synthesizes a literature. A current portal may contain several editions and methods; cite the actual version used. Public access does not establish accuracy for a different question, and a restricted source can still be used only under its authorized conditions.

Section readings [D15; D16]

SECTION 28

Operational observations and monitoring products

Operational evidence should include telemetry, deployment history, configuration changes, tickets and postmortems. It is strongest when identifiers allow those records to be aligned in time without exposing unnecessary sensitive information. An operator account can establish that a control action occurred, while external probes can test the resulting reachability. Record which observations disappear during the incident. The diagnostic challenge is often to reconcile inconsistent signals rather than choose one authoritative dashboard. Preserve raw data and transformation steps so another reviewer can reproduce the event timeline and identify the effect of delayed logging or clock error. [D13] [D17]

Operational observations should show what the system delivered, not merely that an asset was declared available. Inspect the acquisition process, sensor or reporting changes, gaps, coverage and quality controls. Compare records with independent observations where feasible. Aggregated performance, a status dashboard and user experience can diverge because they concern different units, locations, periods or definitions of availability.

Section readings [D13; D17]

SECTION 29

Academic research and independent evidence

Academic contributions are most useful when their assumptions are translated into questions for the case. The consensus impossibility result concerns a particular asynchronous setting; Raft offers an operational algorithm under its own model; an end-to-end design argument addresses where correctness should be checked. None should be reduced to a slogan that all distributed systems face an identical trade-off. Compare model assumptions with the actual network, failure detectors and recovery procedures. Research can identify a hidden assumption worth testing even when it does not provide a ready-made performance forecast for the deployed service. [D01] [D02] [D10]

Read the research design before transferring a conclusion. Identify the question, unit of analysis, method, comparison, result, limitations and conditions that matter for the case. Foundational concepts, empirical studies, critical replications and technical syntheses serve different functions. A literature-supported mechanism may justify a hypothesis without validating a local threshold, forecasting performance or a complete TFP application.

Section readings [D01; D02; D10]

SECTION 30

Source–variable correspondence

A source-to-variable matrix must distinguish direct observations from derived metrics and judgement. Logs can count errors but may omit clients that never reach the service. External probes observe reachability but rarely establish write correctness. A backup test measures restoration under its tested conditions, not every future incident. For each candidate variable, record the raw source, transformation, sampling interval, unit and coverage limitation. Provenance should connect the observation to the metric version and the person or process that produced it. This makes a later correction traceable without rewriting the historical record. [D12] [D22]

The source–variable matrix exposes the path from an observation to an analytical representation. Preserve the raw unit, time, location, method, transformation and uncertainty. Multiple derived variables may share one observation and therefore share its limitations. Record the code or reproducible procedure, authorized access and version. A score should remain inspectable through its originating evidence rather than replacing that evidence.

Section readings [D12; D22; C04; C05]

SECTION 31

Source–risk correspondence

A source-to-risk mapping should show which mechanism a source can support and what it cannot rule out. A routing monitor may detect prefix withdrawal while missing an application integrity failure. A vulnerability advisory can establish exposure but cannot prove exploitation at a particular organisation. Incident triage should therefore combine mechanism-specific observations with coverage information. Mark a risk as unobserved when evidence is absent, rather than interpreting a missing alert as a negative finding. The same telemetry stream may inform several risks, but that reuse does not make those observations statistically independent. [D13] [D21]

A source–risk matrix should cover the threat, the observed state, the mechanism and the consequences separately. Evidence that an event occurred does not alone show why a function failed or who was affected. Use a chronology and alternative explanations to test the chain. A citation becomes useful when the specific part of the claim it supports and its limits are visible.

Section readings [D13; D21]

SECTION 32

Monitoring gaps and research priorities

Monitoring gaps are often structured by service geography, client connectivity and privilege. External probes may overrepresent well-connected locations; privileged audit logs may omit inherited access paths; application traces may sample away rare but consequential failures. Build a gap register with the affected inference, a temporary alternative and a plan to improve coverage. Changes in the monitored population should be marked on every trend chart. Otherwise a falling error rate can reflect loss of affected clients from the dataset. Data stewardship principles help make these limits inspectable rather than hiding them inside a composite confidence score. [D12] [D22]

Prioritize a gap by its consequence for the decision. The next observation may be a targeted measurement, an independent comparison, a capability test or a correction of incompatible definitions. More data of the same kind may not resolve structural uncertainty. Specify the question, required observation, responsible custodian, time of collection and condition under which the gap is considered sufficiently addressed.

Section readings [D12; D22; C03]

SECTION 33

Dependency matrix and propagation tests

Cross-domain dependency analysis should identify the transaction that crosses a boundary. A hospital needs access to records; a water utility needs trustworthy telemetry; an emergency dispatcher needs communications during demand surges. Their tolerance of a digital interruption is not identical. Map the service, time tolerance, fallback and responsible operator for each edge. Then test whether the physical restoration of digital infrastructure depends on the same affected energy, transport or communications service. The result is a sequence of coordination questions, not an automatic transfer of responsibility or an assumption that every connected sector fails at once. [D14] [D17]

Security incidents can invalidate the recovery environment itself. A backup copied from a compromised identity domain or restored through the same exposed administration channel may reintroduce the incident. Recovery resources must include clean credentials, trusted installation media and verified data lineage.

Small rollout defects can propagate rapidly through a large installed base. Blast radius depends on deployment scope, shared software versions and the ability to stop or reverse distribution before the defect reaches all service groups. A canary is informative only when its workload and configuration exercise the failing path.

Digital services depend on physical energy, cooling, water, access and fuel. The dependence is bidirectional: power and water operators may need the affected networks for dispatch or remote control. Restoration sequencing should include those cross-domain loops.

A dependency matrix should be directional and time-specific. Record the supplying function, receiving function, mechanism, useful delay, substitute and evidence. Test the destination when the origin becomes unavailable for different periods. Then remove a common prerequisite of the substitute. The resulting structure describes the case; it does not establish all connections in a global architecture or validate an edge weight.

For each relationship, add the measured delay, duration of tolerable interruption, substitute and observation supporting the directed edge. Repeat the test for short, intermediate and extended unavailability. A generic list of linked sectors is not an estimated network, and no edge weight is validated by inclusion in this table.

Section readings [D14; D17; C01; C02]

SECTION 34

Documented cases, near misses and recovery

Historical cases should be compared by mechanism, observability and restoration constraints. Meta, AWS, Cloudflare and CrowdStrike illustrate different common-mode pathways: backbone configuration, operational command scope, rule deployment and content distribution. SolarWinds adds the problem of re-establishing trust after a supply-chain compromise. The useful comparison asks which control could have detected or bounded the propagation in the present case. Do not aggregate these unlike incidents into a single empirical failure rate without a defined population and exposure denominator. Their value here is structured causal learning and stress-test design. [D17] [D18] [D19] [D20] [D21]

Historical analysis distinguishes observed loss, protective response, near miss and recovery. Several records can concern one event without becoming independent events. Preserve what the source actually investigated and avoid adding unsupported casualty, cost or restoration-time estimates. Compare cases by mechanism and evidence quality; the fact that one response was associated with an outcome does not alone establish a general causal effect.

Section readings [D17; D18; D19; D20; D21]

SECTION 35

Integrated review, transfer and learning portfolio

Digital evidence crosses every SIL domain, but digital monitoring is not equivalent to scientific validation. A sensor reading can be securely transmitted and still be miscalibrated; an immutable log can preserve an incorrect input. Separate transport integrity, data provenance, measurement quality and the causal model that interprets the measurement. A cross-domain evidence package should retain all four layers and specify who can correct each one. This distinction prevents a sophisticated infrastructure stack from becoming a substitute for domain expertise, while allowing dependable digital services to support reproducible review and accountable updates. [D12] [D22]

The integrated portfolio should allow a reviewer to move from the question to observations, transformations, mechanism tests, scenarios and proposed monitoring. Make the strongest competing explanation and the most consequential unresolved gap visible. Transfer requires checking mechanisms, exposure and recovery resources in the new setting. Formation, optional credentialing, submission permission and licensing remain distinct processes; no case or data contribution enters the SIL without an associated fellow and applicable review.

Section readings [D12; D22; C04; C05]