Architectural Properties of Computational Configurations Satisfying the WP-006 Duration Requirements
Kestävyyskykyinen reunaälysolmu: WP-006:n kestävyysvaatimusten täyttävien laskentakokoonpanojen arkkitehtuuriominaisuudet
This Technical Note specifies the architectural properties that a computational node must exhibit to satisfy the four duration components — power endurance (D1), data endurance (D2), identity endurance (D3), and audit endurance (D4) — defined in WP-006 §07.
A configuration satisfying all four components across a common duration envelope is defined here as a Duration-Capable Edge Intelligence Node (DCEIN). This note identifies the structural properties required of each layer, maps them to a reference implementation architecture, and establishes the relationship between the node's decision engine and the M(t) model of WP-006 §04.
The reference implementation is a two-unit architecture: a computationally capable edge node (Pi 5 class hardware) carrying sensor integration, local inference, and the KRI/LR decision engine; and a physically separated trust anchor (Pi 2 class hardware) providing post-quantum cryptographic attestation and decision audit logging. This separation is a structural requirement, not an implementation preference.
Tässä teknisessä muistiossa määritellään arkkitehtuuriominaisuudet, jotka laskentasolmun tulee täyttää neljän WP-006 §07:ssä määritellyn kestävyyskomponentin osalta: virtakestävyys (D1), datakestävyys (D2), identiteettikestävyys (D3) ja auditointikestävyys (D4).
Konfiguraatiota, joka täyttää kaikki neljä komponenttia yhteisellä kestävyysikkunalla, kutsutaan tässä kestävyyskykyiseksi reunaälysolmuksi (DCEIN). Muistio määrittää kunkin kerroksen rakenteelliset vaatimukset, kuvaa ne viiteimplementaatioarkkitehtuuriin ja rakentaa yhteyden solmun päätösmoottoriin ja WP-006 §04:n M(t)-malliin.
Viiteimplementaatio on kaksiosainen arkkitehtuuri: laskennallisesti tehokas reunasolmu (Pi 5 -luokan laitteisto) sensorien integraatiota, paikallista inferenssiä ja KRI/LR-päätösmoottoria varten; sekä fyysisesti erillinen luottoankkuri (Pi 2 -luokan laitteisto) post-kvanttikryptografista attestaatiota ja päätöslokia varten.
WP-006 §08 establishes that the specification of technologies, protocols, and implementations satisfying the four duration components (D1–D4) is outside the scope of a structural working paper. That specification is the purpose of this Technical Note.
This note answers one question: What must a computational configuration look like — structurally and architecturally — to maintain decision capacity across the worst-case compound stress envelope defined for Finnish operating environments in WP-005?
The answer is not a product recommendation, a procurement specification, or a deployment guide. It is an architectural vocabulary: a set of structural requirements that any configuration must satisfy, expressed with sufficient precision to support engineering evaluation and to ground falsifiable claims about implementation adequacy.
A Duration-Capable Edge Intelligence Node (DCEIN) is a computational configuration that satisfies all four duration components (D1–D4) of WP-006 §07 across a common duration envelope determined by the compound stress profile of its operating environment.
The DCEIN concept is defined by the conjunction of all four components, not by any one of them in isolation. A configuration that addresses power endurance alone is energy-capable but not duration-capable. A configuration that addresses D1–D3 but not audit endurance may retain operational function but loses the institutional weight required for its outputs to be acted upon. The four-component conjunction is the minimum viable definition.
WP-006 establishes that decision capacity M(t) degrades under two interacting stressors — structural drift d(t) and authority concentration r(t) — and that M(t) must remain above M_crit for decision outputs to retain causal relevance. The DCEIN architecture is the operational response to this constraint: it specifies a configuration whose structural properties bound d(t) from below and r(t) from above across the duration envelope.
Each of the four duration components addresses a specific pathway through which M(t) can fall below M_crit:
| Component | M(t) pathway addressed | Failure without it | WP-006 failure mode |
|---|---|---|---|
| D1 Power endurance |
Prevents d(t) spike from power loss terminating the computational layer entirely. | M(t) → 0 on grid failure; all decision capacity ceases. | FM-1 (Hidden Dependency Accumulation): power dependency invisible until failure. |
| D2 Data endurance |
Prevents d(t) increase from data source loss degrading sensor-informed inference. | Decision outputs become ungrounded; M(t) drops as outputs lose empirical basis. | FM-1 (data dependency hidden); FM-4 (Memory Rigidity: historical data substitutes for current state). |
| D3 Identity endurance |
Prevents r(t) effective increase from loss of trust infrastructure removing verifiable decision authority. | Outputs cannot be attributed to an authorised decision source; institutional weight lost. | FM-5 (Institutional Displacement): system outputs unactionable without identity verification. |
| D4 Audit endurance |
Maintains the auditability condition required for M(t) to remain in authoritative rather than advisory mode. | Decision outputs cannot be certified as produced within verified decision windows; M(t) advisory. | FM-5 (outputs retained formally but causally severed from institutional accountability). |
The M_crit threshold in WP-006 is not calibrated for specific systems in this note — calibration requires domain measurement. What this note specifies is the structural architecture whose properties maintain the preconditions for M(t) ≥ M_crit to be achievable across the duration envelope.
A DCEIN is not a single device. The four duration components impose architectural separation requirements that cannot be satisfied by a single-unit configuration. Specifically, D3 (identity endurance) and D4 (audit endurance) require that the trust anchor responsible for attestation and audit logging be physically separate from the compute unit responsible for sensor integration and inference. Combining these functions in a single unit creates the structural failure mode identified in WP-006 as FM-3 (Synchronised Behaviour Amplification) and undermines the independence condition required for decision auditability.
A DCEIN comprises two physically distinct units: an Edge Compute Unit (ECU) and a Trust Anchor Unit (TAU). The TAU provides D3 and D4 services to the ECU. Neither unit alone constitutes a DCEIN.
The structural rationale for physical separation is not efficiency but epistemic integrity. An audit log produced by the same unit that generated the decision it audits does not satisfy the independence condition required for the log to serve as an external check on decision validity. The TAU operates on the principle that it sees only decision hashes and attestation requests — not the sensor data or inference outputs from which decisions are derived. This limits its exposure surface and maintains its function as an independent verifier even under conditions where the ECU is partially compromised.
┌────────────────────────────────────────────────┐
│ TRUST ANCHOR UNIT (TAU) │
│ ─ Physical separation from ECU required ─ │
│ │
│ TrustCore Server │
│ · Nonce generation (per-attestation) │
│ · PQC signature verification (Dilithium3) │
│ · Device enrollment (first-seen / provisioned)│
│ · Decision hash audit log (immutable local) │
│ · Deferred reconciliation endpoint │
│ │
│ Duration profile: D3, D4 │
│ Compute class: low (ARM Cortex-A7 sufficient) │
│ Network: local segment only (no WAN required) │
└──────────────────┬─────────────────────────────┘
│
│ Local network (attestation channel)
│ Isolated from WAN; degraded operation
│ acceptable if local segment intact
│
┌──────────────────▼─────────────────────────────┐
│ EDGE COMPUTE UNIT (ECU) │
│ ─ Primary decision engine ─ │
│ │
│ Sensor Layer │
│ · Environmental sensors (gas, radiation, │
│ visual, atmospheric) │
│ · Normalised 0.0–1.0 output interface │
│ · Mock fallback on sensor hardware loss │
│ │
│ TrustCore v1.0 C Kernel │
│ · tc_calculate_kri(R, S, E) │
│ · tc_calculate_dissonance(R, S, E) │
│ · Deterministic; platform-agnostic │
│ │
│ KRI / LR Decision Engine │
│ · Sensor → state mapping (R, S, E) │
│ · KRI: composite risk index │
│ · LR-D: constructive / dissonant regime flag │
│ · Decision output → decision hash → TAU │
│ │
│ TrustCore Client │
│ · PQC key generation (Dilithium3) │
│ · Nonce request → TAU │
│ · Signed attestation payload → TAU /verify │
│ · TPM 2.0 PCR binding (optional, enhancing) │
│ │
│ Duration profile: D1, D2 (primary) │
│ D3, D4 (via TAU) │
│ Compute class: mid (ARM Cortex-A76 or equiv.) │
└────────────────────────────────────────────────┘
The two-unit architecture maps the duration components to hardware in a way that optimises for the distinct failure modes of each function. The TAU requires low compute and high integrity — old, simple hardware running a narrow, well-audited function is architecturally preferable to new, capable hardware with a larger attack surface. The ECU requires sufficient compute for sensor integration, C-kernel execution, and optional inference — constrained hardware that cannot sustain real-time inference under load is not duration-capable for environments requiring continuous situational assessment.
WP-006 §07 defines power endurance as the duration of operational power availability without external supply, with the requirement that local energy independence extend across the Black Period envelope as defined in WP-001.
For a DCEIN, the power endurance requirement applies jointly to both units. A configuration in which the ECU has independent power but the TAU does not is not D1-compliant: the TAU's loss under power disruption takes the attestation channel offline, compromising D3. A configuration in which the TAU has independent power but the ECU does not is also not compliant: the decision engine ceases regardless of the trust infrastructure's availability.
D1-SR1: Local primary supply. Both units must be capable of operating from local power sources (battery, UPS, local generation) independent of grid connectivity for the full duration of the Black Period envelope applicable to the deployment environment.
D1-SR2: Independent supply paths. ECU and TAU power supplies should not share a single point of failure. A single UPS serving both units provides shared failure exposure; physically separated supply paths provide independent endurance.
D1-SR3: Low idle draw. ARM-class edge hardware at the Pi 5 compute tier draws 3–5W under sensor polling and inference loads; the Pi 2 trust tier draws under 2W at attestation idle. This power profile is compatible with small UPS and portable generation configurations for Black Period durations of 24–72 hours without grid dependency.
D1-SR4: Graceful degradation on supply reduction. Under reduced power availability, the ECU should prioritise the TrustCore C-kernel and KRI/LR engine over UI and dashboard processes. The decision function is the continuity-critical component; display functions are not.
The Black Period envelope for Finnish compound stress environments is calibrated in WP-005. Configurations deployed in environments with different compound stress profiles must recalibrate the D1 duration requirement accordingly. D1 cannot be assessed in isolation from the operating environment's expected disruption duration.
WP-006 §07 defines data endurance as the duration of decision-relevant data availability without network access, requiring locally held sensor data, cached state, and offline inference capability. The failure condition is connectivity loss or infrastructure failure that severs the node from remote data sources.
Data endurance is the dimension most directly tied to the sensor architecture. A DCEIN is not a node that receives data from external sources and processes it — it is a node that produces data from locally attached physical sensors and infers from that data locally. The distinction is structural: a node dependent on external data sources for its decision inputs has D2 endurance only as long as those sources remain accessible, which is precisely the condition that fails under compound stress.
D2-SR1: Physical sensor attachment. The ECU must carry at minimum one class of locally attached physical environmental sensor capable of producing decision-relevant signal without network connectivity. The reference sensor suite includes gas detection (MQ-9 class, ADC-attached), visual stream (local IP camera or direct-attached), and atmospheric indicators. The specific sensors are not mandated — the structural requirement is local physical attachment, not sensor type.
D2-SR2: Normalised sensor interface. All physical sensors must present a normalised 0.0–1.0 output to the KRI/LR engine. This interface abstraction enables mock fallback — if a hardware sensor fails, the system continues operating on the fallback signal generator without engine-layer modification. Mock fallback is not a workaround; it is a D2 compliance mechanism that prevents sensor hardware failure from propagating to decision engine failure.
D2-SR3: Local state cache. The ECU must maintain a rolling cache of sensor state sufficient to continue inference during brief sensor dropout or hardware reset cycles. The cache duration is environment-dependent but must exceed the longest expected sensor restart window.
D2-SR4: Offline inference. The KRI/LR decision engine must be capable of producing valid outputs with zero WAN connectivity. External API calls, cloud model endpoints, and remote inference services are not D2-compliant data sources. The TrustCore v1.0 C-kernel satisfies this requirement by design: it is a deterministic, locally compiled, platform-agnostic computation with no network dependencies.
The mock fallback mechanism deserves particular attention. Under the D2 architecture, a sensor hardware failure should produce a degraded but valid decision output rather than a system halt. The fallback generator produces signals in the normal operating range, ensuring the decision engine continues to produce auditable outputs. These outputs must be flagged as sensor-degraded in the decision record — this is a D4 audit requirement — but the decision function continues. This is the computational analogue of WP-003's advisory mode: functioning at reduced capacity rather than halting.
WP-006 §07 defines identity endurance as the duration of verifiable decision authority without central attestation infrastructure, requiring a local trust anchor with deferred attestation reconciliation. The failure condition is trust infrastructure unavailability — the inability to verify that a decision was produced by an authorised node.
Identity endurance is the component most frequently overlooked in edge computing architectures. A node that can produce decision outputs but cannot prove it is an authorised source of those outputs — under conditions where central identity infrastructure is unavailable — produces outputs that no downstream actor can act upon without independent verification. This is computational ITT as defined in WP-006 §06: the system retains the formal structure of a decision system while having lost its causal relevance.
D3-SR1: Local trust anchor. Identity verification must not depend on WAN-accessible PKI, cloud-hosted identity services, or central attestation infrastructure. The TAU serves as the local trust anchor: a physically separate device that can verify the ECU's identity using only locally available information (enrolled keys, nonce challenge-response, TPM PCR state if available).
D3-SR2: Post-quantum key infrastructure. The ECU must generate and hold a post-quantum cryptographic key pair (Dilithium3 minimum) stored in a local key directory not accessible to the inference and sensor layers. Key generation occurs at first initialisation. The TAU holds the corresponding enrolled public key. This key pair is the root of the ECU's identity claim and must survive power cycling.
D3-SR3: Challenge-response attestation protocol. Each attestation cycle consists of: (1) ECU requests nonce from TAU; (2) ECU signs a payload containing the nonce, device ID, and current decision hash using its Dilithium3 private key; (3) TAU verifies the signature against the enrolled public key and records the attestation result. This cycle must complete over local network without WAN dependency. The TAU's nonce endpoint and verify endpoint are the minimum TAU service surface.
D3-SR4: TPM 2.0 binding (enhancing, not required). Where TPM 2.0 hardware is available on either unit, PCR values should be included in the attestation payload, binding the identity claim to the hardware state at attestation time. TPM availability is not required for D3 compliance — Dilithium3 software keys satisfy the structural requirement — but TPM binding strengthens the attestation against software-level compromise.
D3-SR5: Deferred reconciliation. When the TAU is temporarily unavailable (TAU power loss, local network disruption), the ECU must continue producing decision outputs and must log the attestation gap in the audit record. On TAU restoration, the ECU must submit the gap-period decision hashes for retroactive verification. Outputs produced during an attestation gap are valid for local operational use but must be flagged as pending attestation in the audit record until reconciliation completes.
The first-seen enrollment model — in which the TAU automatically enrolls any ECU presenting a valid key on first connection — is appropriate for demonstration and development environments. Production deployments require a provisioned enrollment model in which TAU enrollment is performed as an explicit, recorded step during system commissioning. The distinction matters for the audit record: a first-seen enrollment does not establish the provenance of the enrolled key.
WP-006 §07 defines audit endurance as the duration of decision auditability without external verification systems, requiring a local immutable decision log with post-event reconciliation protocol. The failure condition is logging infrastructure loss or synchronisation failure that severs the connection between decision outputs and their verifiable record.
Audit endurance is the component that determines whether a decision output carries institutional weight under stress conditions. A decision that cannot be audited — cannot be shown to have been produced by a verified node, at a verified time, from verified inputs — is, from an institutional accountability perspective, indistinguishable from an unverified assertion. WP-006 identifies this as the point at which computational ITT onset occurs: the system retains functional output capability while losing the auditability condition required for those outputs to remain causally relevant.
D4-SR1: Decision hash generation. Every decision output produced by the KRI/LR engine must have a corresponding decision hash: a deterministic SHA-256 hash over the decision payload (input state, output values, timestamp, device ID, KRI values, LR status). The TrustCore v1.0 C-kernel produces this hash as part of its standard output via the tc_calculate_kri pathway. The hash is the audit anchor for the decision.
D4-SR2: Local immutable log. Decision hashes must be written to a local append-only log on the TAU. The log must survive TAU power cycling and must not be modifiable by the ECU. The TAU's physical separation from the ECU is the structural mechanism that provides log independence — if the ECU is compromised, the TAU's log remains unaffected provided the TAU itself is intact.
D4-SR3: Attestation-bound log entries. Each attestation event (TAU nonce challenge-response cycle) must produce a log entry that binds: the ECU device ID, the attestation timestamp, the attestation result (PASS / FAIL / GAP), the decision hash submitted, and the TPM PCR values if available. This binding creates a chain: physical hardware state → signed identity claim → decision output → audit record.
D4-SR4: Sensor degradation flag. Decision records produced while any sensor is operating on mock fallback (D2-SR2) must be flagged as sensor-degraded in the log entry. The flag does not invalidate the decision — it contextualises it. An auditor reviewing the log must be able to distinguish decisions produced from full physical sensor data from decisions produced under sensor degradation conditions.
D4-SR5: Post-event reconciliation protocol. On restoration of TAU connectivity after an attestation gap (D3-SR5), the ECU must submit gap-period decision hashes to the TAU for retroactive log entry. The reconciliation must record the gap interval, the number of decisions produced during the gap, and the reconciliation timestamp. Decisions reconciled retroactively carry lower institutional weight than decisions attested in real-time — the audit record must preserve this distinction.
The local immutable log on the TAU is not a replacement for enterprise audit infrastructure. Under normal operating conditions, TAU log contents should be synchronised to external audit systems. The D4 requirement is that auditability is maintained across the disruption window — that the log remains valid and recoverable even if synchronisation has been interrupted for the full duration of the Black Period envelope. Post-event synchronisation restores the full audit chain without retroactive invalidation of decisions made during the disruption window.
WP-006 establishes M(t) as the formal model of decision capacity. The DCEIN's decision engine is the operational implementation of M(t) at the node level. This section specifies the structural relationship between the KRI/LR engine and the M(t) model.
The KRI (Key Resilience Index) and LR-D (Lex Resiliens Decision) engine maps physical sensor readings to a decision capacity assessment. The mapping is three-stage: sensors produce raw environmental signals; the TrustCore v1.0 C-kernel performs deterministic KRI computation from normalised inputs; the LR policy layer applies regime logic to determine authoritative vs. advisory mode.
Physical sensors → Normalised values (0.0–1.0):
voc_ppb → S component (stress: VOC gas concentration)
geiger_cpm → S component (stress: radiation count rate)
lidar_obstacles → E component (exposure: obstacle density)
State derivation (KRI engine, Python policy layer):
S = min(1.0, voc/500 + geiger/100) ← stress index
E = min(1.0, 0.2 × obstacles) ← exposure index
R = max(0.0, 1.0 − 0.5(S + E)) ← resilience index
TrustCore v1.0 C-kernel (deterministic):
kri = tc_calculate_kri(R, S, E) → composite risk index
dis = tc_calculate_dissonance(R, S, E)
→ {constructive: bool, delta_R, delta_S, delta_E}
LR regime logic (Python policy layer):
if kri > threshold or not constructive:
status = ALERT | WATCH
else:
status = OK
Output: {score, status, kri, R, S, E, constructive, decision_hash}
The mapping from sensor readings to the M(t) model is structural, not direct. The KRI/LR engine does not compute M(t) — it provides the empirical inputs from which drift d(t) and concentration r(t) can be estimated by an analyst or higher-order monitoring system. High KRI (high S, high E, low R) is evidence of elevated d(t). A system operating in ALERT status without external communication is exhibiting the computational ITT precondition identified in WP-006 §06.
The TrustCore v1.0 C-kernel provides deterministic, platform-agnostic computation of KRI and dissonance. Its determinism is a D4 property: given identical inputs, it produces identical outputs, which means that the decision hash computed from its output is reproducible and auditable. A non-deterministic inference model — one that produces varying outputs on identical inputs due to stochastic sampling or floating-point non-determinism across platforms — cannot satisfy D4-SR1 as stated, because the decision hash is not stable across audit replay. Determinism of the core inference component is a structural audit endurance requirement, not a preference.
The dissonance indicator (constructive / non-constructive) provides a stability signal that maps to WP-006 FM-3 (Synchronised Behaviour Amplification). A non-constructive state indicates that the deltas between R, S, and E are moving in directions that amplify instability rather than absorb it. This signal should trigger conservative decision posture — increased logging frequency, reduced decision confidence weighting — rather than system halt.
A DCEIN configuration is duration-capable only relative to a specified duration envelope. The envelope is not a fixed number — it is determined by the compound stress profile of the operating environment. WP-005 specifies the compound stress configuration applicable to Finnish operating environments. This section identifies how the duration envelope translates into configuration requirements.
The duration envelope has five parameters, each of which must be covered by the corresponding D-component:
| Envelope parameter | Component | Minimum coverage requirement | WP-005 calibration basis |
|---|---|---|---|
| Grid disconnection duration | D1 | Local energy supply sustains both ECU and TAU across the 95th percentile Black Period length for the deployment region. | WP-001 Black Period envelope; WP-005 Finnish compound stress configuration. |
| WAN connectivity disruption duration | D2 | Local sensor data and offline inference remain valid for all decisions produced during the connectivity gap. No decision requires WAN data to be valid. | WP-005 §infrastructure: connectivity disruption window estimates. |
| Central identity infrastructure unavailability | D3 | Local trust anchor (TAU) provides attestation independently of any WAN-reachable identity service for the full gap duration. Deferred reconciliation window must cover the full disruption envelope. | WP-005 §digital: trust infrastructure availability profile. |
| External audit system unavailability | D4 | TAU local log capacity must be sufficient to store all decision records produced during the full disruption envelope without overflow or truncation. | Derived from decision frequency × log entry size × envelope duration. |
| Local network segment integrity | D3+D4 | ECU–TAU communication must remain functional on a local network segment independent of WAN routing. If local segment fails, deferred reconciliation (D3-SR5, D4-SR5) must activate and cover the gap. | WP-005 §network: local segment resilience assumptions. |
A configuration that satisfies all four D-components but only for a shorter duration than the worst-case compound stress envelope is not duration-capable for that environment. Duration adequacy is not a binary property — it is a coverage relationship between the configuration's endurance parameters and the environment's stress profile. This is the computational expression of WP-001's core distinction: power does not equal persistence.
A DCEIN is duration-capable for environment E if and only if its D1–D4 endurance parameters collectively exceed the compound stress duration envelope of E across all five envelope parameters simultaneously.
Define the DCEIN as a formal architectural category with specified structural requirements for each of D1–D4.
Map each duration component to the M(t) degradation pathways it addresses.
Specify the two-unit (ECU + TAU) architecture as a structural requirement derived from D3 independence conditions.
Define the KRI/LR decision engine's relationship to the M(t) model.
Specify determinism of the inference core as an audit endurance requirement.
Establish the duration envelope concept and its five parameters.
Ground the falsification conditions for DCEIN architectural claims.
Certify any specific hardware configuration as D1–D4 compliant — compliance assessment requires empirical measurement against the deployment environment's stress profile.
Specify sensor calibration parameters, KRI threshold values, or LR policy weights — these are domain-specific and require operational parameter estimation.
Replace security evaluation, electromagnetic compatibility assessment, or physical installation risk analysis.
Determine the duration envelope for any specific environment — envelope calibration requires WP-005-compatible compound stress analysis for the deployment region.
Specify procurement, vendor, or product recommendations — the structural requirements are technology-neutral.
The Aether One dual-Pi platform (Pi 5 ECU + Pi 2 TAU) is the reference implementation from which this note's architectural vocabulary is derived. It satisfies the two-unit separation requirement, the PQC attestation requirement (Dilithium3), the TrustCore v1.0 C-kernel determinism requirement, and the local sensor interface requirement. It does not, as currently specified, address D1 (power endurance) — this requires external UPS or local generation provisioning not included in the software architecture. The platform is a D2–D4 architecture; D1 completion requires physical power infrastructure decisions outside this note's scope.
The reference implementation is published as an open working draft and constitutes one conforming instantiation of the DCEIN specification. Other hardware platforms satisfying the structural requirements are equally valid DCEIN implementations.
The architectural claims of this note should be considered falsified if any of the following conditions is demonstrated through empirical evidence:
| Condition | Claim falsified |
|---|---|
| FC-1 Single-unit configurations (ECU and TAU functions combined) demonstrate sustained D3 audit independence under conditions where the combined unit is partially compromised, without exhibiting the correlated failure mode identified in §03. |
The two-unit physical separation requirement as a structural necessity for D3 compliance. |
| FC-2 Non-deterministic inference cores (stochastic sampling, floating-point non-determinism) are shown to produce stable, reproducible decision hashes across audit replay without additional determinism guarantees, satisfying D4-SR1 as stated. |
The determinism requirement for the inference core as a D4 structural condition. |
| FC-3 Documented compound stress events show that nodes relying on WAN-reachable identity services maintain verifiable decision authority throughout stress events of WP-005 duration, without local trust anchor fallback. |
The local trust anchor (TAU) requirement as a necessary D3 architectural element. |
| FC-4 The mock sensor fallback mechanism (D2-SR2) is shown to introduce systematic bias in KRI/LR outputs that renders those outputs non-conservative relative to full-sensor outputs — i.e., the fallback consistently underestimates risk relative to physical sensor readings under stress conditions. |
The mock fallback as a valid D2 compliance mechanism, requiring replacement with a sensor-specific safe-state value. |
| FC-5 The five-parameter duration envelope framework fails to capture compound stress scenarios documented in WP-005 in which a DCEIN configuration satisfies all five parameters individually but fails to maintain decision capacity due to an interaction between parameter gaps not addressed by the envelope model. |
The completeness of the five-parameter duration envelope as a coverage specification for DCEIN adequacy. |
Domain D-5 · Continuity Computing · TN-002 v1.0 · ACI · March 2026
A Duration-Capable Edge Intelligence Node is not a device. It is an architecture.
Duration capability is a property of the conjunction of D1–D4, not of any component in isolation.