2026-10-07T00:11:45Z https://api.figshare.com/v2/oai

oai:figshare.com:article/34032459 2026-09-30T13:08:04Z category_28864 category_28828 category_28831 category_28834 category_28855 category_28852 category_28846 category_28843 item_type_12 month_year_09_2026

BEFORE AUTONOMY: Earning the Right to Act Volodymyr Kotegov (24861739) Artificial intelligence not elsewhere classified Artificial life and complex adaptive systems Autonomous agents and multiagent systems Evolutionary computation Satisfiability and optimisation Planning and decision making Modelling and simulation Knowledge representation and reasoning AI Safety & Governance AI autonomy autonomous systems design systems engineering in practice AI Assurance AI Governance Policies <p dir="ltr">This book argues for a simple engineering principle: a system should not receive more freedom to act than we have the independent ability to verify, constrain, and stop. Five ideas carry the argument. 1. Safety Must Be Designed Before Capability Growth Boundaries, stop mechanisms, verification criteria, and rules for expanding authority must exist before the system receives the corresponding freedom. “We’ll patch it later” does not work when the consequences may be irreversible. 2. A Claim Is Not Evidence Neither a developer’s statement (“we checked everything”) nor the system’s own statement (“I am safe”) constitutes engineering evidence. Trust must rest on checks that can be independently repeated, challenged, and traced to evidence. 3. Freedom Grows in Steps, Alongside Verifiability Autonomy is not a switch. It is a set of distinct authorities that can be granted, limited, or withdrawn. Each increase in authority requires its own evidentiary basis. As independent action becomes more consequential, verification must grow with it. If verification falls, granted freedom must fall with it. 4. No Self-Authorization—and No Safety Only from the Outside The system must not decide for itself when the evidence is sufficient to receive more authority. But safety cannot consist only of an external fence around an otherwise unrestricted capability. Control must also be built into the architecture and preserved as capabilities change. The goal is not to keep a system below some fixed level of intelligence. It is to ensure that control properties do not disappear as capability increases. 5. Unknowns Must Remain Visible The absence of an observed failure does not prove the absence of failure. An unassessed item is not a pass. Every safety claim has boundaries: configuration, conditions, scope, evidence, and validity period. What remains unknown must remain visible—and must not silently turn into authorization. In short: capability is not authority, authority is not operation, and a successful test is not a permanent guarantee.</p> 2026-09-30T13:08:04Z Text Preprint 10.6084/m9.figshare.34032459.v1 https://figshare.com/articles/preprint/BEFORE_AUTONOMY_Earning_the_Right_to_Act/34032459 CC BY 4.0