Sentryn Research / Concept guide 03
Runtime authority vs. autonomous control
Sentryn uses runtime authority as a conceptual term for responsibility over operational continuation or permission, while autonomous control concerns how a system actually performs its task.
Conceptual distinction
Responsibility for whether an operation should continue is not the same question as how a system executes it.
Monitoring, organisational authority and technical control can interact closely, but they are not interchangeable concepts. Keeping them distinct helps clarify responsibility and avoid overstating what a governance layer, monitoring system or controller actually does.
This distinction is conceptual. The page does not specify how authority is represented, evaluated, enforced or connected to a technical system.
Three perspectives
Different questions require different forms of evidence and responsibility.
Monitoring
Monitoring concerns what is observed or reported about an operation. Observation alone does not determine organisational authority or technical control.
Authority
Authority concerns responsibility, permission and legitimacy within an operating context. Its implementation depends on the relevant organisation, system and domain.
Control
Control concerns how a system executes behaviour. Control architecture remains a domain-specific engineering responsibility.
Why the distinction matters
Clear terminology supports clearer accountability.
Avoid category errors
A warning, permission, command and observed outcome should not be treated as the same thing merely because they occur in one operational workflow.
Preserve responsibility
Conceptual separation helps operators, engineers and assurance teams discuss who remains responsible for which part of an autonomous operation.
Respect domain boundaries
Airspace, robotics and maritime systems retain different control, safety and regulatory architectures even when similar governance questions arise.
Across domains
Authority is a governance question; control remains domain-specific.
Airspace
Governability questions in airspace operations.
Explore how oversight, accountability and operational responsibility can be discussed around increasingly autonomous airspace activity.
Explore Airspace ↗Robotics
Governability questions in ground robotics.
Explore how responsibility and operational oversight can remain understandable as robotic systems operate in shared environments.
Explore Robotics ↗Maritime
Governability questions in maritime autonomy.
Explore governance considerations around autonomous maritime operations without defining implementation-specific control or assurance mechanisms.
Explore Maritime ↗Public disclosure boundary
Concepts are public. Implementation details are not.
This page deliberately stays at the level of research questions and conceptual distinctions. Proprietary or patent-sensitive technical implementation details are intentionally not disclosed.
Public research basis
Research you can inspect.
These links point to public Zenodo research records. They provide background to the conceptual discussion on this page. A repository deposit or DOI does not by itself establish peer review, certification or product validation.
- A Science of Governability for Autonomous Systems: Toward a Foundational Discipline for Governable AutonomyDOI 10.5281/zenodo.20570246
- The Emergence of Governability as a Distinct Discipline for Autonomous Systems: Evidence from Industry, Research, Standards, and Regulation (2026)DOI 10.5281/zenodo.20599747
- Governability Metrics for Autonomous Systems: Toward the Measurement of Runtime GovernabilityDOI 10.5281/zenodo.20617057
- The Emergence of Governability Assurance for Autonomous SystemsDOI 10.5281/zenodo.20716828
- Governability Assurance for Autonomous Systems: Toward Verifiable Governability in Autonomous EcosystemsDOI 10.5281/zenodo.20722780
Sentryn Research / Scope
Sentryn Research
Public research programme on the governability of autonomous systems.
Explore the research programme ↗This page summarises public research themes at a conceptual level. Technical implementation details are intentionally outside its scope.
Start with the operating question.
For operators, system builders and research partners.