CIIA-Based BIA — Consequence-Side Extension to TLCTC v2.1

Document status	Working Draft
Version	0.4.1
Date	20 June 2026
Prepared by	Bernhard Kreinz
Depends on	TLCTC v2.1 (normative). This document is a consequence-side extension, not a standalone framework.
Purpose	Velocity-aware CIIA BIA and consequence-chain control specification, fully conformant with the TLCTC Cyber Bow-Tie.

Document control

Item	Specification
Normative language	SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY are used in their ordinary specification sense.
Relationship to TLCTC	This specification consumes the TLCTC v2.1 Cyber Bow-Tie, its consequence chain, its DRE vocabulary (C / I / Av / Ac) and its notation. It adds BIA-specific velocity, damage-class and control-engineering layers on the consequence side only, and does not modify the cause-side cluster taxonomy.
Primary audience	Business continuity, operational risk, enterprise architecture, data risk, cyber risk, application ownership, process ownership and control engineering.
Scope	CIIA-based Business Impact Analysis; minimal TOGAF-inspired decomposition; SRE → data-state event → BRE consequence chains; damage classes; transition velocity; intervention windows; consequence-side containment circuit breakers.
Out of scope	The cause-side threat taxonomy itself (clusters #1–#10, defined normatively in TLCTC v2.1); full control catalogue; quantitative capital modelling; product-specific fraud rules; the complete TOGAF metamodel.
v0.4.1 change	Six conformance and clarity corrections (see correction summary) plus publication-layout repair. Not a structural redesign; the v0.4 conceptual core is preserved.

Executive summary

This specification defines a Business Impact Analysis method for the right (consequence) side of the TLCTC Cyber Bow-Tie. It assesses all four CIIA dimensions — Confidentiality, Integrity, Availability and Accessibility — expressed as Data Risk Event annotations in the canonical TLCTC vocabulary. It begins with a business service and its possible final consequences, traces the Business Risk Event (BRE) chain backward, and derives the data-state event, the central System Risk Event (SRE), the architecture dependencies and the controls required to explain or interrupt the path.

The model inherits the TLCTC semantic separation: clusters #1–#10 are the cause side; the SRE (Loss of Control) is the pivot; the data-state event and BRE chain are the consequence side; final consequences are terminal valuation or viability effects classified DC-A Existential, DC-B Severe, DC-C Material or DC-D Absorbable. Intermediate BREs are preserved as events and are never collapsed into consequences — consistent with the TLCTC principle that Business Impact (BI) is a role a BRE holds at the organization’s Risk Appetite boundary, not a separate event type.

Version 0.4.1 adds transition-specific velocity classes and control positions to the consequence chain. It recognizes that in VC-3 Operational and VC-4 Real-Time scenarios the Δt between the SRE and the data-state event may be too short for manual response. This specification engineers that interval into an explicit automated circuit breaker (CP-1) that can block, hold, isolate, limit, quarantine or redirect an operation before an adverse data state becomes authoritative.

A circuit breaker does not automatically extend the natural propagation interval. It preserves, creates or expands an effective intervention window by introducing an enforceable decision point. Its activation latency, scope, fail mode, reset authority, evidence and secondary BRE paths must be modelled explicitly.

1. Purpose, scope and TLCTC dependency

1.1 Purpose

The purpose of this specification is to establish a precise and reusable method for connecting business-process analysis with the consequence side of the TLCTC Bow-Tie. It enables a BIA to determine not only how serious a disruption may become, but which sequence of consequence-side events creates the damage, how rapidly the sequence propagates, where intervention remains possible and when automation is required.

1.2 TLCTC dependency (normative)

This document is an extension to TLCTC v2.1 and inherits the following without modification:

• The Cyber Bow-Tie structure and its strict cause/consequence separation.
• The cause side as exactly ten clusters #1–#10. For cyber-originating scenarios, the cause of every SRE is a named cluster step; this document references but does not redefine that taxonomy.
• The central event SRE (“Loss of Control”), always abbreviated SRE — never “LoC”, which TLCTC reserves for Loss of Confidentiality.
• The DRE vocabulary C / I / Av / Ac and the rule that a DRE is an outcome annotation, never a threat and never a standalone attack step.
• BI as a role, not an event type, set at the Risk Appetite boundary.

1.3 Objectives

• Assess all four CIIA dimensions (C, I, Av, Ac) for each relevant business function and business object.
• Keep cause, the SRE pivot, the data-state event, its DRE annotation, BREs and final consequences semantically separate.
• Qualify integrity DREs as incorrect or manipulated where the BIA requires it, without leaving the canonical I code.
• Model Δt and velocity for SRE → data-state event, data-state event → BRE and BRE → BRE transitions.
• Preserve chained BREs rather than misclassifying them as consequences.
• Assign final consequences to DC-A, DC-B, DC-C or DC-D.
• Derive path-specific architecture criticality rather than applying automatic inheritance.
• Identify control positions along the chain and define the required intervention deadline.
• Specify automated circuit breakers, acting within Δt(SRE → data-state event), for paths in which manual intervention cannot act in time.
• Model the secondary event paths created by circuit-breaker activation, false positives and failure.

1.4 Analysis and causal directions

Direction	Sequence	Purpose
Analytical derivation	Business service → consequence/DC → BRE chain → data-state event [DRE] → SRE → cause	Identifies relevant dependencies and control needs without starting from a technology inventory.
Actual causation	Cause → SRE → data-state event [DRE] → BRE₁ → … → final consequence	Represents the event sequence as it unfolds in time, mirroring the TLCTC consequence chain.
Control derivation	Protected transition → intervention deadline → control action → secondary path	Places controls at the point where they can still change the reachable event chain or damage class.

1.5 v0.4 → v0.4.1 correction delta

Area	v0.4	v0.4.1
Consequence node	DRE shown both as a chain node and as an annotation (contradiction)	Data-state event is the timed node; DRE is strictly its [DRE: …] annotation
SRE boundary	SRE sometimes stated at the data-impairment point; CP-1 then acted pre-SRE	Normative boundary test (§3.2); SRE = loss of control over capability/behaviour, before the data-state event
Entry paths	R0 required every scenario to be TLCTC-classified	R0 split: cyber-originating = TLCTC-classified; non-cyber = TLCTC-compatible consequence projection
Unresolved operator	9.2 used SRE? for a possibly-non-cyber cause	Removed; ? is reserved for an unresolved cluster step, not an absent cyber event
Damage escalation	Single “maximum reachable class” per state (mixed manifested with reachable)	Two fields: manifested class and maximum credible reachable class
Δt semantics	“Each Δt is a detection and intervention window”	Δt is a propagation interval; intervention window is conditional, W_effective formula added
Layout	Empty TOC, mid-row page splits	TOC populated; keep-with-next, no row splits, page-break control

2. Normative concepts and definitions

2.1 Business architecture terms

Term	Definition
Business service	A business outcome or value offered to a customer, stakeholder or other business party.
Business process	An ordered flow of activities that contributes to the delivery of a business service.
Business function	A stable unit of business behaviour that performs a defined purpose and can be reused across processes.
Business object	Information or a logical business entity consumed, changed, produced, stored or communicated by a business function.
Application service	Logical application behaviour that supports a business function.
Application component	A deployable or manageable software component that realizes an application service.
Authoritative data state	The data state accepted by the organization as operationally effective, legally relevant, accounting-relevant or otherwise relied upon for business execution.

2.2 Consequence-chain terms

The consequence chain has three event-node types and one annotation. This separation is the central v0.4.1 correction: the DRE is the annotation, not a node.

Term	Definition
Cause	The initiating mechanism. For cyber-originating scenarios this is a TLCTC cluster (#1–#10), defined in TLCTC v2.1 and referenced, not redefined. For non-cyber operational scenarios it is a separately identified operational cause (§2.6).
System Risk Event (SRE)	Loss of Control / System Compromise — the central Bow-Tie event and pivot. The SRE is loss of control over system behaviour, privilege, capability or trust relationship. It is a node; it precedes the data-state event.
Data-state event	The observable occurrence in which the adverse data state of a business object arises, is exposed, or becomes authoritative. This is a timed node on which Δt and CP-1 operate. It is NOT the DRE itself.
Data Risk Event (DRE) annotation	The canonical C / I / Av / Ac classification attached to a data-state event, written + [DRE: …]. A DRE is an outcome annotation: never a standalone node, never a threat category, and it never changes the cause classification (TLCTC rule).
Business Risk Event (BRE)	A discrete, observable business-level event triggered by a data-state event or a preceding BRE. A node. BREs may cascade.
Business Impact (BI)	A role a BRE holds at the organization’s Risk Appetite boundary — the terminal BRE beyond which further decomposition is not operationally useful. Not a separate event type.
Final consequence	The terminal financial or viability effect produced by one or more BREs (e.g. realized loss, capital/liquidity erosion, loss of viability).

2.3 Δt and the intervention window

Δt on a transition is the propagation interval — the occurrence time of the consequent node minus that of the preceding node. Δt is NOT, by itself, an intervention window. A transition may be unobservable, observable only after completion, or technically impossible to interrupt. Δt creates only a potential window.

W_effective = Δt − (T_detect + T_decide + T_actuate)

This holds only when (a) the preceding event is observable, (b) an enforceable control point exists, and (c) the action can affect the transition. Where any condition is absent, W_effective = 0 even when the physical Δt is long.

Time element	Definition
Δt(SRE, data-state event)	Propagation interval from Loss of Control to the data-state event (creation, exposure or authoritative acceptance of the adverse state).
Δt(data-state event, BRE₁)	Propagation interval from the data-state event to the first resulting business event.
Δt(BREᵢ, BREᵢ₊₁)	Propagation interval between successive business events.
T_detect	Time from event occurrence until the relevant signal is available and recognized.
T_decide	Time required to decide that intervention is warranted.
T_actuate	Time required for the control action to become effective.
W_effective	Usable intervention window after subtracting control time, conditional on observability, an enforceable control point and actionability.

2.4 Damage-class terms

Term	Definition
Damage class	A scenario-specific classification of the FINAL consequence: DC-A, DC-B, DC-C or DC-D. Damage classes classify final consequences only, never intermediate states.
Manifested class	The consequence severity already realized at a given point in the chain.
Maximum credible reachable class	The highest final consequence still reachable from the current state along a credible path.
Derived criticality	A projection of the reachable damage class onto a function, object, service or component only where it participates in the documented path.
Damage escalation threshold	An event transition or point in time at which the manifested class crosses into a more severe class.

2.5 Velocity and control terms

Term	Definition
Velocity class (VC)	An ordinal classification of how rapidly a specific transition propagates and therefore how quickly intervention must occur.
Control position (CP)	The transition or node at which a control acts. CP-0 is cause-side (prevents the SRE); CP-1–CP-4 are consequence-side.
Circuit breaker	A consequence-side containment control that, operating within Δt(SRE → data-state event), automatically blocks, holds, isolates, limits, quarantines, redirects or safely degrades an operation before the adverse data state becomes authoritative.
Activation latency	Elapsed time from the availability of a trigger signal until the control action becomes effective (T_actuate component plus decision).
Fail-open / Fail-closed	Control failure permits the operation to continue (open) or blocks/suspends it (closed).
Safe degradation	A restricted operating mode that preserves essential business capability while preventing or limiting the adverse path.
Secondary event path	A separate SRE / data-state event / BRE path caused by control activation, false positive, failure, override or recovery.

2.6 Cyber and non-cyber entry paths

The consequence-side machinery (data-state event → DRE annotation → BRE → DC) is cause-agnostic: it works for any cause. Only the cause side is TLCTC-classified. Two entry patterns are therefore defined.

Entry path	Pattern	Status
Cyber-originating	#X (#1–#10) → SRE → data-state event + [DRE: …] → BRE*	TLCTC-classified cause path. Fully conformant.
Non-cyber operational	Operational cause → SRE or data-state event + [DRE: …] → BRE*	TLCTC-compatible consequence projection. Reuses the consequence model; SHALL NOT be assigned an artificial cluster.

2.7 Event versus consequence test

3. Causal, temporal and control model

3.1 The Bow-Tie spine

The model is anchored to the TLCTC Cyber Bow-Tie. The SRE is the non-negotiable pivot. Everything to its left is cause side (clusters #1–#10 for cyber scenarios, prevention); everything to its right is consequence side (data-state event, BRE, consequence).

CAUSE SIDE	PIVOT	CONSEQUENCE SIDE
Cause (cyber: cluster #1–#10; non-cyber: operational cause)	SRE Loss of Control	data-state event [DRE] → BRE chain → final consequence / DC

3.2 The SRE / data-state-event boundary (normative)

This test prevents the SRE from being stated “too late”. If the candidate SRE already describes the impaired data (e.g. “feed emits duplicated obligations”), it has collapsed the SRE into the data-state event. Re-state the SRE as the loss of control over the capability (“the feed-processing service loses control over completeness and duplicate suppression”), and let the data-state event be the resulting impairment.

3.3 Timed event graph

Cause → SRE →[Δt] (data-state event + [DRE: …]) →[Δt₀] BRE₁ →[Δt₁] … → BREₙ ⇒ Consequence / DC

For every material transition, the propagation interval is the occurrence time of the consequent node minus that of the preceding node. Detection delay, decision time and actuation time SHALL be recorded separately where they affect control feasibility (§2.3).

3.4 Transition-specific velocity

Velocity belongs to a transition, not to a process or system in the abstract — consistent with the TLCTC treatment of Δt as a per-transition property. One scenario may contain a VC-4 SRE → data-state event transition, a VC-3 data-state event → BRE transition and a VC-1 BRE → consequence escalation. Each material transition SHALL be classified independently or assigned a measured Δt.

3.5 Velocity classes

Class	Name	Indicative interval	Control implication
VC-1	Latent	Days, weeks or longer	Periodic detection and manual intervention can normally act before the next event, subject to hidden accumulation.
VC-2	Managed	Hours to days	Monitored workflows, defined escalation and semi-automated action are generally feasible.
VC-3	Operational	Minutes to hours	Pre-authorized intervention, automated detection and rapid actuation are usually required for DC-A/DC-B paths.
VC-4	Real-Time	Milliseconds to seconds, or effectively immediate	Inline validation, pre-commit controls, transaction holds, quarantine or automatic isolation are required when the path must be prevented.

The indicative intervals are default guidance. An organization MAY calibrate them, but the class definitions and thresholds SHALL be documented and applied consistently.

3.6 Control positions

CP-0 is the only cause-side position; it acts on the cause to prevent the SRE. CP-1 through CP-4 are consequence-side positions.

Position	Side / transition	Primary purpose	Typical controls
CP-0	Cause → SRE	Prevent the cause from reaching Loss of Control.	Hardening, input validation, authorization, segregation, capacity protection, egress prevention, MFA — cause-side PREVENT controls.
CP-1	SRE → data-state event (within Δt)	After Loss of Control, prevent the adverse data state from being created, exposed or becoming authoritative.	Circuit breaker, pre-commit gate, transaction hold, account lock, isolation, quarantine, write block.
CP-2	data-state event → BRE₁	Prevent business use or acceptance of the impaired data.	Reconciliation, secondary validation, approval hold, rollback, last-known-good data.
CP-3	BREᵢ → BREᵢ₊₁	Interrupt business-event propagation.	Settlement stop, recall, customer contact, contingency execution, legal intervention.
CP-4	BRE / consequence	Reduce terminal loss or viability effect.	Insurance, liquidity support, capital measures, compensation, crisis management.

3.7 Circuit-breaker effectiveness at the SRE → data-state-event transition

A CP-1 circuit breaker is effective only when its total control time is shorter than the time available before the adverse data state is created, disclosed or accepted as authoritative.

T_control = T_detect + T_decide + T_actuate

Effective containment requires: T_control < Δt(SRE, data-state event), i.e. W_effective > 0

Where Δt is approximately zero, post-event automation is insufficient. The control SHALL operate inline, before commit, before disclosure, or through a quarantine state that is not yet authoritative — or move to CP-0.

3.8 Natural versus effective intervention window

Concept	Meaning
Natural window	Time available without modifying the process or state transition; equals Δt only when the transition is observable and actionable.
Preserved window	A control prevents the window from collapsing, e.g. by holding a transaction before settlement.
Created window	A control introduces a non-authoritative quarantine or pending state that did not otherwise exist.
Expanded window	A control slows or limits propagation, e.g. by rate limiting or restricting the affected scope.

3.9 Control outcomes

Outcome	Effect on event path
Block	The transition is prevented; the protected data-state event does not occur.
Hold	The transition is suspended pending validation or authorization.
Isolate	The affected identity, account, host, interface, batch or component is separated from the normal path.
Limit	The number, value, rate or scope of affected objects is capped.
Quarantine	Output is stored in a non-authoritative state until released.
Redirect	Processing moves to an alternate service, data source or manual path.
Safe degradation	Non-essential functions are disabled while essential processing continues under tighter constraints.

3.10 Branching, convergence and secondary paths

A data-state event may cause several BRE branches, and several SREs or data-state events may converge on the same BRE. Circuit-breaker activation can create a separate availability, customer or obligation path. The model SHALL therefore support directed graphs rather than only a single linear chain, consistent with the variable-length consequence chains of TLCTC.

SRE	→	CB activates	→	primary data-state event blocked
CB activation	→	processing suspended	→[Δt]	secondary BRE / DC

4. CIIA, damage and velocity classification for BIA

4.1 Mandatory four-dimensional assessment

A conformant BIA SHALL assess all four CIIA dimensions for every relevant business function–business object relationship, expressed in the canonical DRE vocabulary. A dimension may be documented as not relevant only with an explicit rationale.

DRE code	Dimension	Meaning
C	Confidentiality	Data becomes accessible, observable or transferable beyond its authorized audience or purpose.
I	Integrity	Data is wrong, inconsistent, or has undergone an unauthorized state transition. BIA MAY qualify as I(inc) or I(man) — see 4.2.
Av	Availability	Data is gone or unreachable — the resource no longer exists or cannot be technically accessed (deletion, storage failure, system offline).
Ac	Accessibility	Data is present but unusable — exists and reachable, but cannot be used for its intended purpose (encryption, corruption, permission lockout).

4.2 Integrity refinement: incorrect versus manipulated (qualifier on I)

This refinement is a qualifier on the canonical DRE code I, not a new code. It captures a control-relevant distinction in the data state while remaining fully conformant. The cause of the integrity loss — a malicious cluster step vs. a non-malicious software/process failure — is recorded separately on the cause side, exactly as TLCTC requires.

Question	[DRE: I(inc)] — incorrect	[DRE: I(man)] — manipulated
Core test	Is the data unsuitable for the intended business use?	Did an unauthorized data state or state transition occur?
Intent required?	No.	No. Unauthorized manipulation may be established even when actor intent is unknown.
Typical cause side	Often non-malicious: faulty mapping, transformation defect, stale source (may still trace to a cluster if a flaw was exploited).	A cluster step — e.g. #1 Abuse of Functions, #2/#3 implementation flaw, #4 Identity Theft enabling an authorized-looking change.
Typical controls	Validation, reconciliation, source quality, transformation testing, freshness checks.	Authorization, authenticity, provenance, segregation, tamper evidence, replay protection.
Default when origin unknown	Classify as I(inc) and record manipulation status as unknown/under investigation.	Use only when the unauthorized transition is evidenced or sufficiently established.

4.3 CIIA requirement profile

Dimension	Required specification
C	Permitted audience, purpose, disclosure boundary, onward-transfer restrictions and irreversibility considerations.
I(inc)	Accuracy, completeness, consistency, freshness, validation source and acceptable error tolerance.
I(man)	Authorized origin, permitted state transitions, approval authority, authenticity, provenance and replay protection.
Av	Required delivery time, latency, maximum period without data, recovery-point requirement.
Ac	Required usability of present data, protection against encryption/corruption/lockout, recovery of usable state.

4.4 Consequence damage classes and derived criticality

Class	Formal	Plain-language	Normative interpretation
DC-A	Existential	Existential	Threatens continued organizational viability, licence, systemic role, capital, liquidity or the ability to continue critical operations.
DC-B	Severe	High / severe impact	Major financial, regulatory, customer, liquidity or strategic damage but does not by itself cross the existential threshold.
DC-C	Material	Bad hit	Significant and management-relevant loss or disruption that remains within established recovery and capital capacity.
DC-D	Absorbable	Easy to take	Remains within normal operating tolerance and can be absorbed without exceptional strategic or financial measures.

The organization SHALL define quantitative and qualitative thresholds for each class. Thresholds MAY differ by legal entity, business service, jurisdiction or scenario type, but the selected threshold set SHALL be documented.

4.5 CIIA-specific scenario vector

⟨ DRE code, damage class, transition velocity, Δt, BRE path, control position ⟩

DRE	Reachable class	Critical transition	Velocity	Illustrative path
C	DC-C	SRE → data-state event [C]	VC-4	Unauthorized export → disclosure BREs → material loss.
I(inc)	DC-C	data-state event → first business use	VC-2	Incorrect value → incorrect decision → remediation and loss.
I(man)	DC-B	SRE → data-state event [I(man)]	VC-4	Unauthorized state accepted → payment settled → severe loss.
Av	DC-B	data-state event [Av] → cutoff BRE	VC-3	Data unavailable → cutoff missed → major obligation failure.
Ac	DC-B	SRE → data-state event [Ac]	VC-3/4	Data encrypted/locked → processing halts → obligation failure.

4.6 Time-dependent damage escalation (manifested vs. reachable)

Damage classes classify final consequences. An intermediate state therefore carries two distinct values: the class already realized (manifested), and the highest final consequence still reachable on a credible path. A quarantined adverse state may have a low manifested class yet a high reachable class.

Event state	Manifested class	Maximum credible reachable
Adverse data state exists but quarantined or unused	DC-D	Up to DC-A if a credible path to existential outcome remains
Adverse state has influenced a business decision	DC-C	Up to DC-A
A material obligation or customer outcome has failed	DC-B	Up to DC-A
Capital, liquidity, licence or viability threshold crossed	DC-A	DC-A

4.7 Velocity × damage-class control expectation

This matrix is driven by the maximum credible reachable class, not the manifested class.

Velocity	DC-D	DC-C	DC-B	DC-A
VC-1 Latent	Periodic/manual	Defined manual	Assured manual or semi-auto	Assured controls and escalation
VC-2 Managed	Manual	Monitored/semi-auto	Pre-authorized response	Pre-authorized and tested response
VC-3 Operational	Monitored	Rapid semi-auto	Automated control normally required	Automated circuit breaker or documented equivalent
VC-4 Real-Time	Inline where useful	Inline for material paths	Inline/pre-commit or accepted residual risk	Inline/pre-commit circuit breaker and tested safe-failure

The binding requirement is that the selected control demonstrably acts before the protected transition completes (W_effective > 0). Where it cannot, the organization SHALL redesign the process, reduce the reachable class, provide an alternative intervention point or explicitly accept the residual risk.

5. Minimal TOGAF-inspired architecture decomposition

5.1 Minimal element set

Element	Question answered
Business service	What value or outcome is delivered?
Business process	Through which flow is the outcome delivered?
Business function	Which stable business behaviour performs the work?
Business object	Which information is consumed, changed, produced or communicated?
Application service	Which logical application behaviour supports the function?
Application component	Which system or component implements the service and control?

5.2 Business function as decomposition anchor

The business function SHOULD be the central reusable unit. Processes provide sequence, context and deadlines; functions provide stable behaviour reusable across processes. CIIA requirements and DRE annotations attach to the relationship between a business function and a business object.

5.3 Business object and authoritative state

For CP-1 design, the decomposition SHALL identify when and where a business object becomes authoritative. A circuit breaker that acts after authoritative acceptance may no longer prevent the data-state event, even when it reacts within milliseconds.

State	Treatment
Proposed / staged	May be validated, held, rejected or modified without creating the authoritative data-state event.
Quarantined	Separated from normal use and not relied upon until released.
Authoritative	Accepted for operational, legal, accounting or decision use; adverse acceptance constitutes the data-state event.
Propagated copy	May create additional data-state event branches if downstream use occurs before correction.

5.4 Control-bearing application services

The architecture model SHOULD distinguish the service that performs the business operation from the service that enforces the control — e.g. a payment service and a transaction-hold service, a data feed and a validation gateway, or an identity service and an automated session-revocation service.

5.5 Boundaries and external dependencies

Technology components, infrastructure services, locations, third parties and outsourcing boundaries SHALL be added where they affect timing, authority, control ownership, evidence or the ability to activate a circuit breaker. Where the cause-side step crosses a responsibility sphere (TLCTC bridge clusters #8, #9, #10), the relevant domain boundary SHOULD be noted. The owner of a business service remains accountable for demonstrating effective intervention even when the control is operated by a third party.

5.6 Decomposition depth guided by damage and velocity

Scenario	Minimum decomposition expectation
DC-D / VC-1 or VC-2	Coarse function-object mapping and proportionate control evidence may be sufficient.
DC-C or VC-3	Identify decision points, authoritative state, key interfaces, timing assumptions and control owner.
DC-B	Identify every decisive function, object, application service, external boundary and intervention point.
DC-A or VC-4	Model the full critical path, pre-commit state transitions, control implementation, fail mode, reset, alternate route and secondary event chains.

6. BIA derivation and control-design method

6.1 Overview

The derivation is top-down from business relevance and backward from possible consequences. The process SHALL NOT begin by assigning undifferentiated criticality scores to applications.

1. Define the business service and intended outcome.
2. Identify the relevant business process and decompose it into business functions.
3. Identify the business objects consumed, changed, produced or communicated by each function.
4. Define the CIIA requirement profile for each function-object relationship (C, I, Av, Ac).
5. Define the final consequences and applicable damage-class thresholds.
6. Identify the last BRE that directly produces each consequence.
7. Trace the BRE chain backward to the first business event caused or enabled by a data-state event.
8. Derive the data-state event and annotate its DRE as C, I, Av or Ac (qualify I as inc/man where relevant).
9. Identify the application service, component and SRE capable of producing the data-state event, and the cause (cyber cluster #1–#10, or a non-cyber operational cause).
10. Record Δt and velocity class for every material transition.
11. Identify all feasible control positions CP-0 through CP-4.
12. For VC-3 and VC-4 transitions, determine whether manual intervention can complete in time (W_effective > 0).
13. Where manual intervention is insufficient, derive a CP-1 circuit breaker (within Δt(SRE → data-state event)) or an alternative process design — or strengthen CP-0 cause-side prevention.
14. Model circuit-breaker activation, false-positive, failure, override and recovery paths.
15. Project damage class backward as derived criticality only onto participating elements.
16. Document evidence, assumptions, test criteria and residual-risk acceptance.

6.2 Backward derivation from final consequence

DC ← final consequence ← BREₙ ← … ← BRE₁ ← data-state event [DRE] ← SRE ← cause

Backward derivation prevents arbitrary application criticality and reveals which data property, transition and control position are actually relevant to the high-damage scenario.

6.3 Time horizons and transition deadlines

Horizon type	Example
Pre-commit horizon	Time until a beneficiary change becomes authoritative.
Processing-cycle horizon	Time until an incorrect rate is consumed by a calculation.
Market or settlement horizon	Time until a settlement cutoff is missed.
Contractual horizon	Time until a legal or customer obligation is breached.
Notification horizon	Time until a mandatory notification deadline expires.
Accumulation horizon	Time until repeated small errors aggregate into a material consequence.
Viability horizon	Time until capital, liquidity, licence or operational-continuity thresholds are crossed.

6.4 Velocity-aware control derivation

1. Identify the protected transition and its measured or bounded Δt.
2. Assign the transition velocity class VC-1 to VC-4.
3. Confirm observability and an enforceable control point; otherwise W_effective = 0 regardless of Δt.
4. Estimate T_detect, T_decide and T_actuate for manual, semi-automated and automated options.
5. Choose the earliest proportionate control position that yields W_effective > 0; prefer CP-0 cause-side prevention where feasible and sufficient.
6. Where Δt(SRE → data-state event) is effectively zero, move the control before commit, create a non-authoritative quarantine state, or shift to CP-0.
7. Determine whether the control reduces probability, affected volume, propagation speed or maximum reachable damage class.

6.5 Circuit-breaker design procedure

Step	Required design question
1. Protected transition	Which exact SRE → data-state event transition is blocked, held, isolated, limited or redirected?
2. Trigger	Which signal or rule initiates the control, and what is its expected quality and latency?
3. Decision	Is the decision deterministic, rules-based, model-based or human-confirmed?
4. Action	What technical action occurs: block, hold, isolate, limit, quarantine, redirect or degrade?
5. Scope	Is the action applied to a transaction, account, identity, batch, interface, host, service or process?
6. Timing	Can T_detect + T_decide + T_actuate complete before the data-state event becomes authoritative (W_effective > 0)?
7. Fail mode	Does the control fail open, fail closed or enter safe degradation, and why is that acceptable?
8. Reset	Who or what may restore normal processing, under which evidence and approval conditions?
9. Evidence	Which signals, decisions, timestamps, affected objects and overrides are preserved?
10. Secondary path	Which BREs can activation, false positive, failure or prolonged hold cause?
11. Damage effect	Which damage class or affected volume does the control prevent or reduce?
12. Test	How will timing, volume, fail mode, recovery and false positives be demonstrated?

6.6 Path comparison and proportionality

The prevented path and the control-induced path SHALL be compared. A circuit breaker that prevents one manipulated payment but suspends an entire systemic payment service may create a more severe availability path. The control scope SHOULD therefore be the smallest scope that effectively changes the protected transition.

6.7 Evidence and validation

• Timestamps from event occurrence, detection, decision and actuation.
• Proof that the adverse state was blocked, quarantined or limited before authoritative acceptance.
• Maximum affected object count or value before activation.
• Test results for fail-open, fail-closed and degraded modes.
• Reset and override records, including authority and justification.
• False-positive rate and business-event effects.
• Evidence from third-party or outsourced controls where relevant.

7. Normative modelling rules

Rules R0–R28 are normative for this extension. They presuppose, and never override, the TLCTC v2.1 axioms and notation.

Rule	Normative requirement
R0 – Entry-path conformance	Every cyber-originating scenario SHALL conform to TLCTC v2.1 (cause = cluster #1–#10, pivot = SRE, consequence = data-state event/DRE/BRE). A non-cyber operational scenario MAY enter the consequence model through a separately identified operational cause or SRE as a TLCTC-compatible consequence projection, but SHALL NOT be assigned an artificial TLCTC cluster. No new DRE codes or cause-side categories SHALL be introduced.
R1 – Four-dimensional BIA	Every relevant function-object relationship SHALL be assessed for C, I, Av and Ac.
R2 – Node separation	Cause, SRE, data-state event and BRE SHALL be represented as distinct nodes and SHALL NOT be collapsed into one generic incident or impact.
R3 – DRE is an annotation	A DRE SHALL be recorded as a C/I/Av/Ac annotation on the data-state event using + [DRE: …]. A DRE SHALL NOT be a standalone node, SHALL NOT be a threat category, and SHALL NOT change the cause classification.
R4 – SRE / data-state boundary	The SRE SHALL describe loss of control over system behaviour or capability; the data-state event SHALL describe the resulting impairment of the business object. The SRE SHALL precede the data-state event.
R5 – Consequence separation	Intermediate BREs SHALL NOT be classified as final consequences merely because they are severe; BI is a role at the Risk Appetite boundary.
R6 – Damage classifies finals	Damage classes SHALL classify final consequences only, using documented thresholds. Intermediate states SHALL be described by manifested class and maximum credible reachable class, not by a damage class of their own.
R7 – Path-specific criticality	Derived criticality SHALL be projected only along an explicit CIIA-specific event path.
R8 – No automatic inheritance	A process or service damage class SHALL NOT automatically apply to every supporting element.
R9 – Transition timing	Every material transition SHALL have a measured, bounded or explicitly unknown Δt, recorded as a propagation interval.
R10 – Δt is not a window	Δt SHALL NOT be assumed to be an intervention window. An effective window SHALL be computed as W_effective = Δt − (T_detect + T_decide + T_actuate), conditional on observability, an enforceable control point and actionability; otherwise W_effective = 0.
R11 – Velocity classification	Velocity SHALL be assigned to transitions, not indiscriminately to processes, systems or scenarios.
R12 – Detection separation	Detection time SHALL be distinguished from event occurrence time.
R13 – Control position	Each material control SHALL identify the side and the node/transition on which it acts (CP-0 cause-side; CP-1–CP-4 consequence-side).
R14 – Cause vs containment	A control that prevents the SRE SHALL be recorded as CP-0; a control acting after the SRE within Δt(SRE → data-state event) SHALL be recorded as CP-1. The two SHALL NOT be conflated.
R15 – VC-3/VC-4 evaluation	For VC-3/VC-4 transitions whose maximum credible reachable class is DC-A or DC-B, an automated or pre-authorized intervention capability SHALL be evaluated.
R16 – Timing demonstration	A CP-1 control SHALL demonstrate W_effective > 0 against the time to authoritative data-state creation.
R17 – Zero-time transition	Where Δt(SRE → data-state event) is effectively zero, the control SHALL operate inline, pre-commit, via a non-authoritative quarantine state, or be moved to CP-0.
R18 – Authoritative state	The model SHALL identify when the affected business object becomes authoritative.
R19 – Circuit-breaker scope	A circuit breaker SHOULD use the smallest effective scope consistent with the protected damage-class path.
R20 – Fail behaviour	Fail-open, fail-closed or safe-degradation behaviour SHALL be explicitly defined and justified.
R21 – Reset authority	The authority, evidence and conditions required to reset or override a circuit breaker SHALL be documented.
R22 – Secondary paths	Activation, false-positive, failure, override and recovery paths SHALL be modelled where they can produce material BREs.
R23 – Control-induced damage	A control SHALL NOT be considered effective solely because it blocks the primary data-state event; its maximum secondary reachable class SHALL also be evaluated.
R24 – Branching and convergence	The model SHALL support multiple outgoing and incoming event paths.
R25 – Confidentiality timing	Disclosure and the first confidentiality BRE may be nearly simultaneous; late discovery SHALL NOT shift their original occurrence times.
R26 – Deletion/lockout duality	Unauthorized deletion MAY create both [DRE: I(man)] and a consequent [DRE: Av]; encryption/lockout creates [DRE: Ac]. Distinct data-state events SHALL be modelled separately.
R27 – Unknown manipulation	Known incorrect data with unconfirmed unauthorized manipulation SHALL default to [DRE: I(inc)] with investigation status recorded.
R28 – Third-party, residual, versioning	Outsourcing SHALL NOT remove the requirement to demonstrate control timing, ownership and evidence. Where no control yields W_effective > 0, the process SHALL be redesigned, the reachable class reduced or residual risk explicitly accepted. Assumptions, thresholds and time bounds SHALL be versioned.

8. Required information model

8.1 Core scenario record

Field	Requirement
Record identifier	Unique identifier for the scenario or graph.
Entry path	Cyber-originating (TLCTC-classified) or non-cyber operational (TLCTC-compatible projection).
Business service / process / function / object	The architecture elements on the path.
Authoritative-state point	Where and when the object becomes operationally effective.
Cause	Cyber cluster #1–#10, or a named non-cyber operational cause.
SRE statement	Loss of control over capability/behaviour capable of producing the data-state event.
Data-state event statement	The observable adverse data-state occurrence, annotated + [DRE: C/I/Av/Ac].
BRE nodes	Ordered or graph-based business-event statements.
Final consequence / damage class	Terminal effect and DC-A…DC-D.
Transition Δt / velocity / W_effective	Propagation interval, VC-1…VC-4, and the computed effective window per material edge.
Manifested / reachable class	Manifested class and maximum credible reachable class at key states.
Control position / owner	CP-0…CP-4 and accountable owner.
Circuit-breaker action / latency / scope	Action, T_detect/T_decide/T_actuate, and target granularity.
Fail mode / reset authority	Fail-open/closed/degradation and restoration authority.
Secondary paths	Activation, false-positive, failure, override and recovery paths.
Maximum affected volume	Objects, transactions or value exposed before control effectiveness.
Assumptions and evidence	Source, test result, confidence and version.

8.2 Event statement syntax

Layer	Preferred syntax	Example
Cause (cyber)	#X (per TLCTC)	#4 Identity Theft yields a compromised authenticated session.
Cause (non-cyber)	Operational cause (named)	Reference-rate mapping defect in the calculation routine.
SRE	System/component + loss-of-control verb + capability	An unauthorized authenticated session obtains the capability to submit beneficiary changes.
Data-state event	Business object + impairment + [DRE: …]	Beneficiary change becomes authoritative + [DRE: I(man)].
BRE	Business subject + business event verb + object/outcome	Payment is settled to a beneficiary not authorized by the customer.
Consequence	Valuation or viability effect + measure	Realized unrecoverable financial loss of CHF X.
Control	Control + action + scope + timing + CP	Payment hold (CP-1) blocks the transaction within 300 ms before authorization commit.

8.3 Suggested identifiers

SRE-<domain>-<nnn> DSE-<C|I|Av|Ac>-<nnn> BRE-<process>-<nnn> CB-<domain>-<nnn>

DSE denotes the data-state event node (carrying its DRE annotation). Identifiers are optional but useful when nodes, transitions or controls are reused across several processes and scenario graphs.

9. Worked examples

9.1 Manipulated payment beneficiary — VC-4 / DC-B (cyber-originating)

#4 → SRE →[Δt] (data-state event + [DRE: I(man)]) → BRE₁ → BRE₂ → BRE₃ ⇒ DC-B

Item	Specification
Business service	Execute customer-authorized payments.
Cause (cyber)	#4 Identity Theft — a compromised authenticated session.
SRE	The unauthorized session obtains the capability to submit beneficiary changes (Loss of Control).
Data-state event	Beneficiary change becomes authoritative + [DRE: I(man)].
Damage path	Unauthorized settlement → recall failure → unrecoverable loss, DC-B.
Critical transition	SRE → data-state event, VC-4.
Node / control	Statement	Timing / class	Control opportunity
SRE	Unauthorized authenticated session gains capability to submit beneficiary changes.	—	CP-0 would prevent the session (e.g. MFA, anomaly logout).
CB-1 (CP-1)	Transaction hold quarantines the submitted change before it becomes authoritative.	T_control ≤ 300 ms	Block; lock session; preserve evidence.
Data-state event	Beneficiary change becomes authoritative + [DRE: I(man)].	Prevented when CB succeeds	If it occurs, move to CP-2 validation/hold.
BRE₁	Unauthorized payment is approved.	VC-4 / seconds	Approval revocation or settlement hold (CP-3).
BRE₂	Funds are settled to unauthorized beneficiary.	VC-3 / minutes	Recall or interbank intervention (CP-3).
BRE₃	Normal recovery window expires.	VC-2 / hours-days	Legal recovery and consequence mitigation (CP-4).
Consequence	Unrecoverable financial loss.	DC-B	Loss reduction only (CP-4).

9.1.1 Secondary circuit-breaker path

Path	Event sequence	Max reachable
Successful narrow hold	Single payment held → customer validation → legitimate payment released.	DC-D
False positive	Legitimate urgent payment held → cutoff missed → obligation breached.	DC-C or DC-B
Over-broad action	Entire payment batch suspended → multiple settlement failures.	DC-B or DC-A
Control failure	Unauthorized change commits → primary manipulated-payment path continues.	DC-B

9.2 Incorrect interest rate — VC-2 / DC-C (non-cyber operational)

Operational cause → SRE → (data-state event + [DRE: I(inc)]) → BRE₁ → BRE₂ → BRE₃ ⇒ DC-C

Node	Event statement	Indicative Δt / control
Cause (non-cyber)	A calculation/mapping routine applies the wrong reference-rate transformation (defect, not exploit).	—
SRE	The calculation service loses control over transformation correctness for the rate object.	Immediate.
Data-state event	The stored or calculated customer interest rate is incorrect + [DRE: I(inc)].	Hours until first processing cycle.
CP-2 control	Independent plausibility and source reconciliation blocks business use.	Semi-automated within VC-2 window.
BRE₁	Customer interest is calculated incorrectly.	Hours to daily cycle.
BRE₂	Incorrect statement or charge is issued.	Days.
BRE₃	Customer remediation and correction programme begins.	Days to weeks.
Consequence	Material remediation cost and revenue correction.	DC-C.

A CP-1 circuit breaker is not proportionate when cause and data-state event are inseparable inside a calculation (W_effective ≈ 0 at SRE → data-state event). The usable intervention point is CP-2, before the incorrect value is consumed.

9.3 Confidential customer export — VC-4 / DC-B (cyber-originating)

#1/#2 → SRE →[Δt] (data-state event + [DRE: C]) → BRE₁ → BRE₂ ⇒ DC-C/DC-B

Node / control	Event statement	Position / timing
CP-0 control	Inline egress policy prevents the unauthorized export from initiating (no Loss of Control).	Cause-side prevention, pre-SRE.
SRE	Application gains the capability to export a restricted dataset to an unauthorized destination.	—
CB-1 (CP-1)	Egress enforcement quarantines/blocks the transfer before bytes leave the authorized boundary.	VC-4, within Δt(SRE → data-state event).
Data-state event	Customer data becomes accessible outside its authorized audience/purpose + [DRE: C].	Effectively immediate once transmitted.
BRE₁	Unauthorized recipient obtains or can access the dataset.	Immediate.
BRE₂	Notification, customer and regulatory response processes are initiated.	Hours to days (CP-3/CP-4).
Consequence	Material or severe financial and strategic effect.	DC-C/DC-B by scope.

Detection after transmission cannot reverse disclosure. High-damage confidentiality paths therefore favour CP-0 prevention at the boundary, with CP-1 containment only where Loss of Control genuinely precedes disclosure.

9.4 Payment batch unavailable — VC-3 / DC-B

#6 or operational infra failure → SRE → (data-state event + [DRE: Av]) → BRE₁ → BRE₂ → BRE₃ ⇒ DC-B

Node / control	Event statement	Timing / effect
SRE	The payment-processing component loses control over instruction retrieval.	—
Data-state event	Payment instructions are unavailable for required processing + [DRE: Av].	Minutes.
CB / safe degradation (CP-1)	Processing is redirected to a validated alternate queue; non-essential functions disabled.	Must complete before settlement cutoff.
BRE₁	Payment release cycle is delayed.	VC-3.
BRE₂	Settlement cutoff is missed.	Tens of minutes to hours.
BRE₃	Contractual and liquidity obligations are not fulfilled.	Hours.
Consequence	Major financial, liquidity and customer damage.	DC-B.

Av is correct — data is gone/unreachable. If the data were present but encrypted or locked (e.g. ransomware), the annotation would be [DRE: Ac]. The circuit breaker creates safe degradation, preserving W_effective before the cutoff BRE.

9.5 Liquidity position — VC-3/VC-4 / DC-A

(feed defect or #1/#2) → SRE →[Δt] (data-state event + [DRE: I(inc)]) → BRE₁ → … → BRE₄ ⇒ DC-A

Item	Specification
Business service	Maintain the institution’s ability to fulfil due settlement obligations.
Business object	Current and forecast liquidity position.
SRE	The feed-processing service loses control over completeness and duplicate suppression and emits an unvalidated candidate update.
Data-state event	The candidate update becomes authoritative with omitted or duplicated obligations + [DRE: I(inc)].
Final consequence / class	Loss of ability to continue critical settlement operations / DC-A.
Node	Event statement	Δt	Manifested / reachable
SRE	Feed service loses control over completeness/duplicate suppression; emits candidate update.	Seconds/min	— / DC-A
CB-1 (CP-1)	Feed validation gateway quarantines the candidate; preserves last-known-good position.	VC-3/VC-4	Prevents authoritative data-state event if timely
Data-state event	Candidate becomes authoritative; liquidity position materially incorrect + [DRE: I(inc)].	min–cycle	DC-D / DC-A
BRE₁	Incorrect position is used for funding decisions.	Minutes	DC-C / DC-A
BRE₂	Required intraday liquidity is not obtained.	Hours	DC-B / DC-A
BRE₃	Major settlement obligations are not fulfilled.	Hours	DC-B / DC-A
BRE₄	Emergency measures fail to restore viable operation.	Hours/days	DC-A / DC-A
Consequence	Capital/liquidity erosion threatens continued viability.	—	DC-A

Only functions, data, interfaces and systems necessary to this path receive DC-A derived criticality. Historical reporting copies and presentation formatting do not inherit DC-A unless they participate in a separate credible path.

9.6 Same BRE from incorrect and manipulated data

Path	Chain	Control emphasis
Incorrect-data path	Mapping defect → SRE → data-state event [I(inc)]: beneficiary identifier is wrong → BRE: payment routed to wrong account.	Validation, source quality, reconciliation, error correction.
Manipulated-data path	#4/#1 → SRE → data-state event [I(man)]: beneficiary identifier is substituted → same BRE.	Authorization, provenance, state-transition control, circuit breaker, evidence.

The same BRE can arise from different integrity qualifiers. Controls, evidence, accountability, actor relevance and risk appetite differ, so the paths SHALL remain separate — even though both resolve to the canonical [DRE: I].

9.7 Circuit breaker creating a more severe secondary path

Element	Primary protected path	Secondary control-induced path
Trigger	Suspicious change in one high-value payment.	Low-confidence anomaly applied to entire batch.
Control action	Hold the affected transaction.	Suspend all outgoing payments.
Prevented result	Potential DC-B fraud loss.	Primary path blocked.
New BRE chain	None beyond customer validation delay.	Batch suspended → settlement cutoff missed → systemic obligations fail.
Max reachable	DC-D/DC-C secondary path.	DC-A secondary path.
Required redesign	Narrow scope, tiered thresholds, safe degradation, time-bounded release/escalation.	Avoid broad fail-closed action without alternate processing.

10. Implementation guidance, control testing and quality checks

10.1 Recommended workshop sequence

1. State the intended business outcome in one sentence.
2. Select one business function and one business object.
3. Assess C, I, Av and Ac separately.
4. Define the final consequences and approved damage-class thresholds.
5. Write the last BRE before valuation and trace the BRE chain backward.
6. Derive the data-state event, the SRE, the cause (cyber cluster or non-cyber operational) and the authoritative-state point.
7. Place Δt and velocity classes on every material transition; compute W_effective where a control is proposed.
8. Identify the latest preventive point and candidate control positions (CP-0…CP-4).
9. For VC-3/VC-4, calculate or test control timing.
10. Model successful activation, false positive, control failure and reset paths.
11. Compare maximum credible reachable classes before and after the control.
12. Document evidence, assumptions, ownership and residual risk.

10.2 Circuit-breaker testing

Test	Minimum evidence
Trigger quality	Representative positive and negative cases; false-positive and false-negative analysis.
Activation latency	Measured p50, p95 and worst-case time from signal to effective action.
Pre-activation exposure	Maximum number/value of objects that can commit before the breaker acts.
Scope test	Proof that the smallest intended scope is applied under normal and degraded conditions.
Fail-open test	Documented behaviour and residual path when the control is unavailable but processing continues.
Fail-closed test	Documented business-event path and recovery when processing is blocked.
Safe-degradation test	Proof that essential processing continues while the protected transition remains controlled.
Reset / override test	Authorization, dual control, evidence and timeout behaviour.
Third-party test	Contractual evidence, telemetry and joint exercise where the control is outsourced.

10.3 Quality checks

Check	Question
Entry-path conformance	Is the scenario correctly typed cyber-originating (cluster cause) or non-cyber operational (named cause, no artificial cluster)?
Node/annotation	Are SRE, data-state event and BRE nodes distinct, with DRE present only as a + [DRE: …] annotation?
SRE boundary	Does the SRE describe loss of control over capability, with the data-state event describing the resulting impairment?
CIIA completeness	Have all four dimensions been assessed or explicitly justified as not relevant?
Integrity qualifier	Where used, do I(inc)/I(man) remain droppable qualifiers on canonical I?
BRE completeness	Are intermediate business events preserved until terminal valuation is possible?
Damage threshold	Is the damage class based on an approved, scenario-relevant threshold on the final consequence?
Manifested vs reachable	Are intermediate states described by manifested and maximum-reachable class, not by a class of their own?
Path-specific inheritance	Is derived criticality limited to elements participating in the path?
Authoritative state	Is it clear when the business object becomes operationally effective?
Transition timing	Does every material edge have Δt (propagation), with W_effective computed where a control is proposed?
Control side & location	Is every control marked CP-0 (cause) or CP-1–CP-4 (consequence) and attached to a node/transition?
Timing feasibility	Is W_effective > 0 for the selected control?
Circuit-breaker scope	Is the action narrow enough to avoid unnecessary secondary damage?
Secondary path	Are activation, false positive, failure, override and recovery paths modelled?
Residual risk	Is any unpreventable high-damage path explicitly accepted or redesigned?

10.4 Maturity path

Stage	Characteristics
1 – Inventory	Business services, processes, functions and objects identified.
2 – CIIA profile	C, I, Av, Ac assessed with requirements and tolerances.
3 – Event chain	Cause → SRE → data-state event → BRE chains and final consequences modelled.
4 – Damage and time	Damage classes, Δt and transition velocity documented; manifested/reachable separated.
5 – Control positions	CP-0 to CP-4 assigned and intervention deadlines defined with W_effective.
6 – Circuit breakers	VC-3/VC-4 controls designed with fail modes and secondary paths.
7 – Assured operation	Latency, volume, fail behaviour, reset and external dependencies continuously tested.

Appendix A. Compact notation (TLCTC v2.1-conformant)

Notation	Meaning
#1…#10	Cause-side cluster step (cyber-originating). For non-cyber scenarios the cause box is a named operational cause.
SRE	Central node: Loss of Control over capability/behaviour. The pivot.
data-state event	Timed consequence node where the adverse data state arises/becomes authoritative.
+ [DRE: C / I / Av / Ac]	DRE annotation on the data-state event (I MAY be qualified I(inc)/I(man)).
→[Δt=value]	Transition with propagation interval (single arrow, per v2.1). Not automatically an intervention window.
[CP-1 CB: HOLD scope, W_eff>0]	Consequence-side circuit breaker action, scope and effective-window condition.
⇒ Consequence / DC-x	Final valuation or viability effect and damage class.

Canonical form:

Cause → SRE →[Δt] [CP-1 CB] → (data-state event + [DRE: …]) →[Δt₀] BRE₁ →[Δt₁] … ⇒ Consequence / DC-x

Example (cyber):

#4 → SRE →[Δt=250ms] [CP-1 CB: HOLD txn, W_eff>0] → (beneficiary change authoritative + [DRE: I(man)])

Example (non-cyber projection):

Mapping defect → SRE → (rate incorrect + [DRE: I(inc)]) →[Δt] BRE₁: interest miscalculated ⇒ DC-C

Appendix B. Reusable templates

B.1 Function-object CIIA profile

Item	Specification
Business service
Business process
Business function
Business object
Authoritative-state point
C requirement / path
I(inc) requirement / path
I(man) requirement / path
Av requirement / path
Ac requirement / path
Entry path (cyber / non-cyber)
Cause
Maximum reachable / DC
Critical transition / VC
Control position(s)
Owner / evidence

B.2 Event-chain record

Seq.	Node type	Event statement	Δt / VC / W_eff	Control / CP
0	Cause
1	SRE
2	data-state event [DRE]
3	BRE₁
4	BRE₂
n	BREₙ
	Consequence / DC

B.3 Circuit-breaker design record

Item	Specification
Circuit-breaker identifier
Protected SRE → data-state event transition
Trigger signal
Decision logic
Action
Scope
T_detect / T_decide / T_actuate
Worst-case T_control / W_effective
Δt(SRE, data-state event)
Fail mode / safe-degradation mode
Reset authority / override conditions
Evidence preserved
Maximum pre-activation exposure
Secondary BRE paths
Max reachable class before / after
Test owner and frequency

B.4 Residual-risk decision record

Item	Specification
Scenario / path
Uncontrolled maximum reachable class
Critical transition / VC
Why W_effective ≤ 0
Alternative design considered
Residual reachable class
Risk owner / approval authority
Review date / trigger

Appendix C. VC/DC reference matrix

Driven by maximum credible reachable class.

Combination	Default design question	Typical response
VC-1 / DC-C–D	Can periodic control identify and correct the condition before material business use?	Manual detection, reconciliation and correction may be proportionate.
VC-1 / DC-A–B	Can latent accumulation cross a high-damage threshold before detection?	Stronger monitoring, independent reconciliation and accumulation limits.
VC-2 / DC-C–D	Can workflow escalation complete within hours or days?	Defined escalation, semi-automation and accountable intervention.
VC-2 / DC-A–B	Is response pre-authorized and tested against the shortest credible interval?	Automated alerting, prepared actions and time-bound authority.
VC-3 / DC-C–D	Can rapid semi-automated action limit scope or delay propagation?	Rate limits, holds, isolation or rapid approval.
VC-3 / DC-A–B	Can any manual chain reliably yield W_effective > 0 before the next event?	Automated circuit breaker or demonstrably equivalent design.
VC-4 / DC-C–D	Does the path justify an inline control without disproportionate secondary effects?	Pre-commit validation, transaction-level hold or quarantine.
VC-4 / DC-A–B	Can the adverse state become authoritative before any post-event response?	Inline/pre-commit enforcement (CP-1) or CP-0 prevention, tested fail mode, safe degradation and narrow scope.