What the runtime layer adds — and which discipline it belongs to¶
A recurring classification objection in public discussion of the Charter's runtime model (August 2026) runs: the runtime gate is "classical control engineering, not governance" — policies and authority boundaries are defined upstream in the engineering and certification lifecycle, the runtime component simply implements and enforces them, and the vocabulary around it ("runtime governance", "authority", "admissibility") is terminology in search of a mechanism. Its sharpest form is a question: what problem is the runtime layer intended to solve that is not already addressed by established control engineering and certified configuration management? (Alexander Strüver's article of 1 August 2026, his reply of 2 August, and his article of 7 August state this position most explicitly.)
This note answers the question once, so replies can cite one argument instead of re-deriving it.
What the Charter accepts in the classification¶
The component is engineered enforcement, and the Charter's own texts never claim otherwise. The gate decides under current policy and authority, not what policy should exist (When Should Runtime AI Governance Interrupt?); "a deterministic authorization gate can prove that declared rules were applied; it cannot by itself establish that those rules are lawful, fair, or legitimate" (Charter Commitments, consequential-action baseline); a compliant gate does not establish legitimacy; and perfect enforcement establishes deterministic execution of predefined constraints — bounded unattended operation, not autonomy. None of that is contested.
What is contested is the problem class. "Control engineering plus configuration management" names two disciplines, and the gate's job belongs to neither.
The discipline map¶
| Layer | Question it answers | State it consults | Anchor |
|---|---|---|---|
| Governance (institutional) | What may be required; who is accountable; who remedies | Law, policy, society | The Govern function of the NIST AI RMF; the EU AI Act; the five separated roles |
| Certification & configuration management | Is the running system the approved system and policy version? | Design baselines, versions | Type approval and conformity assessment (precedents below) |
| Runtime assurance / control engineering | Is this proposed transition within the specified safety properties — typically physical stability — and is a fallback needed? | Plant state, safety envelope | The Simplex/runtime-assurance pattern — assured monitors plus fallback (Fenn, Nicholson, Pai & Wilkinson 2023, who note the reasoning may extend to properties such as security) |
| Runtime authorization & policy enforcement — the gate | May this actor take this exact action, now? | Current mandate, delegation and revocation state, cumulative counters, nonces, plus the frozen proposal | Decision/enforcement separation in XACML 3.0 (2013); NIST SP 800-207 tenets 3, 4 and 6; RFC 9396; NCCoE agent identity & authorization — open questions |
| Accountability infrastructure | What happened; who answers; can it be contested and remedied? | Sealed action records, custody, review routes | EU AI Act Arts. 14, 72, 73; split custody; the five roles again |
Control engineering regulates a plant against physics. Authorization regulates an actor against a mandate. Certification proves the evaluator is the approved one. The table is the Charter's analytical map, not a taxonomy the cited standards define — the anchors show that each row's question already belongs to an established discipline, and the rows interlock rather than isolate (NIST's Govern function, for instance, is explicitly infused across the whole lifecycle). The objection as first stated named rows two and three; in the subsequent public exchange its author himself placed the current-authority check in row four, as "classical identity, access control, and authorization engineering." The Charter's distinctive work is row five. One rule is worth importing from the runtime-assurance tradition rather than disputing: there, the wrapper must be assured to a higher level than the complex function it constrains — for the Charter, the authorization service should carry at least the assurance of the acting path it gates.
Authority boundaries versus authority state¶
Authority boundaries are defined upstream: mandate schemas, policy rules and ceilings are versioned, approved and certified. On this the objection is right, and the Charter says the same thing.
Authority state moves on a different clock. Which mandates exist right now, whether a delegation has expired, whether Wednesday's revocation has landed, how much of a cumulative ceiling is already consumed, whether this ruling's nonce has been spent — these facts change through institutional acts at transaction cadence, not at release cadence. A certified baseline alone therefore cannot establish that this exact payment, filing or disclosure is authorized now: the execution-time decision needs sufficiently fresh authority evidence bound to the exact action. How that evidence travels is secondary — signed configuration, credentials, revocation lists, or a live query are all established transports for it (certificate revocation lists and OAuth token introspection, RFC 7662 exist for exactly this state). The distinction is semantic and temporal — approved rules versus current facts, release cadence versus transaction cadence — not a claim about storage technology.
Security engineering treats use-time authority as its own discipline precisely because a certification-time snapshot alone cannot supply it. NIST SP 800-207 defines zero trust around "accurate, least privilege per-request access decisions" and rejects treating a subject authenticated once as valid for every later request (tenets 3, 4 and 6 — with freshness explicitly risk-based: trust evaluated "sometime recently" and continually re-evaluated, not necessarily at every transaction boundary). RFC 9396 exists because type-level OAuth scopes cannot express "this transfer of this amount to this creditor". And for AI agents specifically, the NCCoE draft concept paper (February 2026) poses "What are the mechanisms for an agent to prove its authority to perform a specific action?", delegation for "on behalf of" scenarios, and non-repudiation binding back to human authorization as open questions — evidence of active, unresolved implementation work in an existing discipline, not proof that the discipline lacks applicable mechanisms; equally, "already addressed" is not the standards body's position either.
So the component's discipline name is per-action authorization and policy enforcement — security engineering, not plant control — and the Charter's name for it is the per-action authorization and evidence gate. Certification governs the gate itself: its evaluator, its versioned rules, its fail-closed behaviour. What the gate consults is current institutional state whose freshness a certification-time baseline alone cannot vouch for. The Charter's contribution in this row is accordingly not a new mechanism: it is the mandate and authority-state semantics for agent actions, the record sealed before effect, and the coupling of that established authorization machinery to the institutional arrangement in row five.
Where the public discussion converged — and where it did not. Presented with this distinction, the objection's author agreed (2026-08-03) that "the runtime must verify the current authorization state before executing the action," classifying that function as "classical identity, access control, and authorization engineering" — row four, under its security-engineering name — and later (2026-08-07) described such mechanisms as "engineering mechanisms implementing governance requirements." The convergence is therefore on the need for a separate current-authority check and on its discipline. It is not full convergence: he holds the disagreement to be "more than terminology … a question of architectural precision," maintains a strict governance–engineering scope boundary, and confines joint work to the requirement–feasibility interface — while the Charter uses governance for the institutional arrangement spanning requirements, enforcement conditions, evidence and accountability. The full exchange is mirrored in the runtime article's discussion record.
The capability boundary, stated as the Charter's own rule¶
The objection's strongest line — no amount of governance terminology, middleware or audit infrastructure can make a missing computational capability exist — is a rule the Charter already encodes rather than resists. Missing or ambiguous authority fails closed. A screening model's output can raise a concern but never authorize. "Not assessed" never waives a baseline duty, and evidence theatre is a named risk, not a compliance strategy. Stated once, generally: where no available architecture can produce the evidence a consequence requires, that consequence is not available for that scope — the gap routes to engineering or research, never to more process. The runtime layer does not manufacture capability; it prevents a missing basis from being papered over at the moment of effect.
Precedent: requirements that become engineered, auditable controls¶
The objection's home domain — type-approved vehicles — already runs requirements-setting and engineered enforcement as a coupled loop with feedback:
- UN Regulation No 155 (cybersecurity and cybersecurity management systems; entry into force 22 January 2021) makes vehicle type approval conditional on an audited management system: the CSMS certificate of compliance is valid for at most three years, the approval authority may verify continued conformity at any time and withdraw the certificate, and the manufacturer's duties include managing supplier-related risks, implementing cybersecurity measures in the design, detecting and responding to attacks, and logging data to support detection.
- UN Regulation No 156 (software updates and software update management systems; entry into force 22 January 2021) governs post-approval change: type-approval-relevant software carries a dedicated identifier (RXSWIN), every initial and updated software version must be uniquely identifiable including integrity validation data, and the RXSWIN state before and after an update must remain accessible — versioned post-approval change under governance, with the regulation determining when an update stays within the approved type and when it instead triggers an approval extension or a new approval.
- FDA, Predetermined Change Control Plans (Federal Register notice, 4 December 2024; current FDA guidance page) brings the same pattern to AI directly: a marketing submission for an AI-enabled device software function may include the planned modifications, the methodology to develop, validate and implement them, and an impact assessment — reviewed once, so that pre-specified modifications can be implemented "without necessitating additional marketing submissions".
These regimes show that requirements-setting stays institutional while becoming operative and auditable through engineered controls, and that certification frameworks already anticipate versioned post-approval change — R156 even requires per-update records and an auditable software-identification register. What none of the reviewed regimes combines is transaction-specific authorization of an actor against changing mandate state together with an affected-person record, challenge route and remedy for individual actions. That combination is what the Charter specifies — as a proposal, not an operating scheme.
Terms, held precisely¶
- Where the Charter says "runtime governance", it names the arrangement — an action-level enforcement point wired to upstream rulemaking and downstream custody, independent review and remedy — not the component. The component alone is enforcement; calling it governance without the institutions would deserve the objection.
- No novelty claim attaches to decision/enforcement separation itself: it has a dated antecedent in the 2013 XACML 3.0 architecture. The Charter's additions around those primitives are the mandate and authority-state semantics, the record sealed before effect, and the separated institutional roles.
- The published articles mirror the live LinkedIn texts, with clearly marked repository-only notes recording any divergence; whether to carry a one-sentence definition of "runtime governance" into the live articles is a separate maintainer decision, not made here.
Sources¶
Discussion — Alexander Strüver, The Real AI Safety Problem Is Not Runtime. It Is Certification. (1 August 2026) and reply of 2 August 2026; AI Governance Is Confusing Governance With Engineering (7 August 2026). Robert Schaub's comments in both threads are mirrored in the runtime article's discussion record.
Standards and regulation — NIST SP 800-207, Zero Trust Architecture (2020), definition and §2.1 tenets. RFC 9396, OAuth 2.0 Rich Authorization Requests (2023). OASIS XACML 3.0 (2013). NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization, draft concept paper (February 2026). UN Regulation No 155 and UN Regulation No 156 (EU Official Journal L 82, 9 March 2021; texts fetched and checked 2026-08-08). Federal Register notice of FDA's final PCCP guidance (4 December 2024). Fenn, Nicholson, Pai & Wilkinson, Architecting Safer Autonomous Aviation Systems (SSS 2023) for the runtime-assurance pattern. NIST AI RMF Core for the Govern function.