Skip to content
#software testing Open access

TA-14 Admissible Computation Architecture: Governance Before Computational Commitment

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

Abstract

TA-14 Admissible Computation Architecture (TA-14 ACA) proposes a governance architecture before computational commitment. It addresses a distinction that becomes increasingly important as AI, search, agentic systems, autonomous infrastructure, and large-scale computational workloads expand: A system’s capability to perform computation does not, by itself, establish that a proposed computational path has sufficient standing to consume resources or create downstream consequence. TA-14 ACA introduces an explicit governance boundary between a computational proposal and committed computation. Before crossing that boundary, the proposed path may be evaluated for necessity, purpose, scope, evidence, authority, continuity, changed conditions, proportionality, resource bounds, and binding to the consequence that justified the request. The resulting determination may be: ALLOW · HOLD · DENY · ESCALATE The parent ACA architecture is expressed through the sequence: Request → Computational Proposal → Admissibility → Binding → Commit → Computation → Outcome The Version 1.1 parent specification formalizes architecture invariants, state-transition semantics, material-change revalidation, computational accounting boundaries, environmental attribution levels, adversarial stress tests, machine-readable records, and interoperability with the TA-14 Admissible Execution Architecture. The publication also establishes a falsifiable research proposition: Can governance before computational commitment prevent or constrain unnecessary computational work while preserving the legitimate outcome? Any resulting reductions in model calls, retrievals, retries, tool calls, agent branches, CPU/GPU use, network activity, storage activity, electricity, heat, cooling, water, emissions, cost, or infrastructure demand are treated as hypotheses requiring measurement rather than presumed benefits. A bounded pilot methodology compares a baseline computational architecture against an ACA-gated condition while measuring governance overhead, downstream work, task quality, latency, false admission, false rejection, resource consumption, and facility consequences where technically attributable. Negative, null, adverse, and unsupported results are admissible outcomes. Supplemental Continuing-Standing Research Note This record now also includes: TA-14 ACA Continuing Standing, Changed-Condition Revalidation & Adversarial Assurance — Version 2.0 This supplemental research note extends the ACA research program to a harder question: What happens when computation was legitimately admitted at T0, but one of the conditions supporting that standing changes before the next material computational commitment at T1? The note proposes that: ALLOW is not permanent authority. A valid T0 determination may become insufficient at T1 without making the original determination wrong. Revalidation is therefore treated as a prospective test of whether evidence, authority, context, scope, baseline identity, and resource standing remain sufficient for the next commitment. The supplemental note develops a dynamic continuing-standing sequence: PROPOSE → ADMIT → COMMIT → COMPUTE → OBSERVE → DETECT CANDIDATE CHANGE → ATTRIBUTE → MATERIALITY TEST → REVALIDATE → CONTINUE / HOLD / DENY / ESCALATE A critical distinction is preserved throughout: Detection is evidence production, not governance authority. A detector may observe, timestamp, bind, and attribute a candidate material change, but it does not itself decide whether computation remains admissible. ACA revalidation evaluates whether standing survives, and the execution/commit boundary enforces the resulting determination. The pilot must also test detector failure, including false positives, false negatives, stale detection, delayed detection, and attribution errors. The Version 2.0 note further strengthens the research program by introducing: explicit evidence classes separating assertion, participant-produced evidence, independently observable fixture evidence, independent reproduction, and operational/field evidence; a prohibition on treating participant-produced evidence as independent reproduction merely because it passes through governance; a candidate bounded standing lease containing fields such as actor, evidence-set hash, applicable baseline, scope, tools/endpoints, resource budget, expiry/revalidation conditions, lineage, revocation state, and determination; material-change categories covering authority, evidence, objective, scope, resources, dependencies, external reality, and baseline change; time-of-check/time-of-use (TOCTOU) testing; replay, branch escape, detector outage, evidence contradiction, race-condition, and governance-denial-of-service fixtures; explicit measurement of false HOLD, false CONTINUE, false admission, false rejection, gate latency, revalidation latency, computational overhead, shifted work, and outcome quality; preservation of null and adverse outcomes; independent reconstruction requirements; explicit claim-strength limits based on evidence strength. Non-Absorption and Baseline Integrity The supplemental note also formalizes an important examination principle: New knowledge may be incorporated prospectively, but never retroactively. Frozen baselines retain their original identity, date, and content. Later changes should identify what changed, why it changed, when it changed, and what external challenge, evidence, or test motivated the change where relevant. A later version may state that a feature was added after a challenge, but it may not represent that feature as having existed in an earlier frozen baseline if it did not. The original challenge remains preserved and citable. The governing rule is: Learning is allowed. Historical laundering is not. Substrate Neutrality ACA distinguishes the governance proposition from the substrate used to implement it. A computational-governance function may be implemented in software, hardware, middleware, policy engines, agent runtimes, gateways, accelerator control planes, or other substrates. Differences in stack, substrate, implementation layer, or technical category do not by themselves establish that governance propositions are incomparable. Implementation details such as latency, cryptographic binding, hardware enforcement, isolation, bypass resistance, and telemetry remain relevant to proving whether a particular implementation satisfies the governance proposition. Evidence and Independent Verification TA-14 ACA explicitly distinguishes: evidence originfromevidence admissibilityfromindependent reproductionfromoperational verification. TA-14 may independently adjudicate what submitted evidence is admissible to establish without claiming that the underlying event was independently reproduced. A recorded assertion does not become stronger evidence merely because it passed through governance. Claim strength must never exceed evidence strength. Pilot Test #2 The supplemental note defines a second falsifiable ACA pilot question: Can ACA detect and attribute a material change affecting previously admitted computation, require revalidation before the next material commitment, and enforce the resulting determination without silently broadening or repairing prior authority? The pilot is designed to falsify the proposition rather than showcase predetermined success. A credible outcome is therefore not simply: “ACA passed.” A credible result identifies which bounded fixtures were supported, which failed, which remained unestablished, what evidence class applied, and what was or was not independently reproduced. Computational and Resource Accounting Any computational-efficiency claim must account for ACA overhead and displaced work. The supplemental note expresses this as: Net computational benefit = Baseline total work − (ACA gate work + admitted downstream work + revalidation work + shifted/retry work) Facility-level claims involving electricity, cooling, water, emissions, or infrastructure demand should be made only where technically attributable. ACA does not claim that every computation requires continuous monitoring or continuous revalidation, that telemetry or hardware enforcement alone constitutes governance, that every changed condition is material, that participant evidence equals independent verification, or that ACA has already established data-center energy or water savings. Publication Status The Version 2.0 continuing-standing paper is a supplemental research note to the frozen ACA v1.1 parent specification. It does not silently amend ACA v1.1. It does not establish the continuing-standing mechanism as proven. It does not convert a research proposition into an institutional finding. Any future incorporation into the frozen ACA baseline should occur through explicit change control, versioning, revalidation, and publication. The strongest supportable continuing-standing statement remains: PROPOSITION — NOT YET ESTABLISHED For long-running or repeatedly invoked computational systems, ACA may be capable of treating previously admitted computation as condition-bound rather than permanently authorized, using attributable changed-condition evidence to trigger revalidation before further material computational commitment. The proposition remains subject to controlled testing, independent review of the evidence record, and preservation of adverse or null results. Central Research Questions What must be true before computation has sufficient standing to consume resources and create consequence? And, after legitimate admission: What must remain true before that computation is allowed to continue? GOVERN BEFORE COMPUTE.REVALIDATE BEFORE COMPUTE CONTINUES. NO ADMISSIBLE EVIDENCE. NO ADMISSIBLE EXECUTION.NO CONTINUING STANDING. NO CONTINUING COMPUTE.

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

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.

MIT News · Artificial Intelligence Aug 17, 2026

Q&A: Rethinking how innovation happens

In his latest book, Professor Eugene Fitzgerald examines the forces that turn breakthroughs into value — and why innovation resists simple formulas.

Microsoft Research Blog Aug 12, 2026

MindTopo reveals VLMs’ spatial reasoning abilities

A path, a fence, a knot. MindTopo sets a new benchmark for testing how AI understands topological relationships and highlights new opportunities to strengthen spatial reasoning and planning. The post MindTopo reveals VLMs’ spatial reasoning abilities appeared first on Microsoft Research.

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