Skip to content
#software testing Open access

The External-Maintenance Problem in Digital Systems

Oct 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

This document specifies SHOP-D (Self-Regenerating Hybrid Organizational Process — Digital), a digital architecture designed to probe the HDO criterion — the three conditions for an interior defined in the companion paper History-Dependent Ontology (HDO): self-production, historical self-registration, and their operational unity. It is a design specification, not a claim of achievement. Nothing described here has been built or tested, apart from a small illustrative computation in Appendix A. CENTRAL PROBLEMA digital process whose continued existence depends on externally maintained infrastructure — an operating system, a scheduler, a secure element, a hardware maintenance process — does not obviously satisfy HDO condition 1, because its continued existence as that process does not depend on its own self-production. This is the external-maintenance problem. The architecture is designed to make it experimentally tractable, not to solve it by fiat. For SHOP-D as specified, the closure test returns "falsified" by construction: the identity region is fixed externally and the secure element's TTL requirement follows from that specification. The empirical question is therefore whether a redesign can be built in which the secure element's role is regenerated by the system's own operation. Where the dependency graph is not known in advance, progressive removal of external supports can also uncover couplings that the declared classification hides. WHAT THE DOCUMENT SPECIFIES- A formal notion of external-maintenance load (E_ext), distinguishing maintenance from resource supply.- A dependency graph classifying each component as constitutive, supporting, observational, or resource, with the secure element left explicitly under investigation.- A continuity monitor with hardware binding (TRNG, monotonic counter, constitutive refresh signal, secure-element enforcement) that addresses the specified software-level attack surfaces; verification of the refresh signal against cloning remains open.- An internally structured viability valuation (ν), historically integrated but not shown to be endogenous.- A tiered inference structure (L1–L7) separating engineering dependency, organizational closure, and ontological interpretation.- Discrimination protocols (T2-H matched-present, self-registration ablation, buffered decoupling) with explicit estimands and pre-registered decision rules.- Closure tests (constitutive dependency, closure, substrate closure) with explicit falsification conditions.- Behavior under power loss, cold boot, and external reconfiguration, and safety considerations for any implementation (containment, moral status under uncertainty). WHAT THE DOCUMENT DOES NOT CLAIM- That the architecture satisfies the HDO criterion, or that any digital system currently does.- That satisfaction is achievable in a digital substrate — only that this architecture is designed to probe whether it is.- That satisfaction of the HDO criterion would be sufficient for consciousness. The abductive gap between criterion satisfaction and experience remains open.- That cryptographic or hardware security properties entail organizational closure. SUPPLEMENTARY MATERIALAppendix A contains a toy computation of the external-maintenance load and the closure test, with sensitivity analyses over numerical parameters, structural variants (redundancy, at-least-k requirements, intermittent regulators), and randomly generated dependency structures. The Python script (shop_d_closure_toy.py) reproduces Tables A1–A5 (default run, plus the --sens, --checks, and --struct options). The toy model illustrates the procedure; it is not evidence about any physical or digital system.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54
#computer vision Review Mar 2008

Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum

The results show that the embedded industry has been able to apply agile methods in its development processes and that the appreciation of the agile methods and their individual practices appears to increase once adopted and applied in practice.

O. Salo, P. Abrahamsson · 238 citations · ⚡9
#computer vision Open access Jul 2017

What happens when software developers are (un)happy

Consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts are found.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 236 citations · ⚡13
#computer vision Open access Oct 2004

Mobile-D: an agile approach for mobile application development

The Mobile-D approach is briefly outlined here and the experiences gained from four case studies are discussed, which helped develop an agile development approach for mobile application development.

P. Abrahamsson, Antti Hanhineva, H. Hulkko et al. · 225 citations · ⚡18

Related blog posts

MIT News · Artificial Intelligence Oct 2, 2026

Documenting the tech worker movement

Writing as a participant and researcher, PhD student JS Tan SM ’22 has co-authored a new book about the rise of tech worker protests and the employer backlash that followed.

GPT-Lab Sep 23, 2026

Requirements Don’t Live in Isolation: What We’re Exploring with Req-Space

Requirements in large systems rarely exist in isolation. Their meaning depends on the wider project context - other requirements, policies, decisions, tests, and implementation details. That becomes especially important when AI is used for review, because spotting a possible conflict or gap is only the beginning. ReqSpace explores how AI, visualisation, and connected project context can help reviewers understand those findings, trace the relationships behind them, and focus on the questions that…

GPT-Lab Sep 17, 2026

Beyond Prompt Engineering: The Role of Tacit Knowledge in Software Engineering

AI is making software generation faster, but speed does not remove the need for expertise. As more work is delegated to AI, tacit knowledge may become one of the most important human advantages in software engineering. The post Beyond Prompt Engineering: The Role of Tacit Knowledge in Software Engineering appeared first on GPT-Lab.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.