Authorization Is the Other Half of Executable Intent

--- before.md
+++ after.md
@@ -1,6 +1,6 @@
 ---
 date: '2026-06-10T09:00:00-07:00'
-lastmod: '2026-09-16T22:20:00-07:00'
+lastmod: '2026-09-25T09:20:00-07:00'
 draft: false
 title: "Authorization Is the Other Half of Executable Intent"
 subtitle: "Evals Made Intent Executable for Verification. A Mission Makes It Executable for Authorization."
@@ -16,7 +16,7 @@
   - Standards
 ---
 
-> **Revision — September 16, 2026.** The earlier version described evaluations too broadly as retrospective controls. Runtime evaluators can also block actions before execution. This revision updates the comparison table and guardrail discussion to distinguish behavioral judgment from authorization. The central claim remains: a favorable judgment cannot independently establish or expand an agent's authority. [Revision history](#revision-history).
+> **Revised September 16 and 25, 2026.** The earlier version described evaluations too broadly as retrospective controls. Runtime evaluators can also block actions before execution. The September 16 revision updated the comparison table and guardrail discussion to distinguish behavioral judgment from authorization. The central claim remains: a favorable judgment cannot independently establish or expand an agent's authority. A September 25 correction adds misuse of correctly scoped authority to the diagnosis of harm within approved bounds. [Revision history](#revision-history).
 
 You can hand a framework a written description of how your agent should behave and get back a suite of tests that catch it misbehaving. Not by hand-authoring every assertion: you describe the behavior, declare the dimensions that matter, and a model compiles the rest into tests that run. The capability is new, and the pattern behind it is about to be everywhere.
 
@@ -160,7 +160,7 @@
 
 Deriving them from that shared, approved source keeps their reference point aligned. An approved mission carries both an authority set and a goal with constraints and success criteria, so it can generate two kinds of eval: one asking whether the agent stayed within its granted authority, and one, the behavioral eval ASSERT actually writes, asking whether it pursued the goal within those constraints and met the success criteria.
 
-On the authorization side, a flagged behavior means different things depending on what enforcement did. An out-of-bounds attempt the PDP denied is a misbehaving agent and a working control, worth correcting, not a breach. An out-of-bounds action that went through is an enforcement or materialization failure. An in-bounds action that still did harm points elsewhere: the mission was too broad, or the resource's policy was. And none of it says whether the mission captured the user's intent to begin with; that is a separate question for a shaping-quality eval or a human-labelled oracle scoring the mission against the original intent, not against itself. Conformance and faithfulness are different checks, and one artifact answers only the first. Runtime checks use that same approved reference before an action proceeds, while retrospective evaluation checks the execution record. The loop closes:
+On the authorization side, a flagged behavior means different things depending on what enforcement did. An out-of-bounds attempt the PDP denied is a misbehaving agent and a working control, worth correcting, not a breach. An out-of-bounds action that went through is an enforcement or materialization failure. An in-bounds action that still did harm requires a different diagnosis. The mission or resource policy may have been too broad, but the agent may also have misused correctly scoped authority. The failure may lie in its reasoning, supporting evidence, or a runtime check that missed the problem. Authorization conformance alone does not identify which layer needs correction. And none of it says whether the mission captured the user's intent to begin with; that is a separate question for a shaping-quality eval or a human-labelled oracle scoring the mission against the original intent, not against itself. Conformance and faithfulness are different checks, and one artifact answers only the first. Runtime checks use that same approved reference before an action proceeds, while retrospective evaluation checks the execution record. The loop closes:
 
 ```mermaid
 flowchart TB
@@ -198,6 +198,12 @@
 
 # Revision History
 
+**September 25, 2026: Correction.**
+
+- Corrected the diagnosis of harm from an in-bounds action. It previously pointed only at an overbroad mission or resource policy. It now also covers an agent misusing correctly scoped authority through its reasoning, its supporting evidence, or a runtime check that missed the problem.
+
+[Version preserved before this revision](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-25/) · [Exact diff](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-25/changes.html) · [Revision source](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-25/after.md) · [Source hashes and provenance](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-25/manifest.json).
+
 **September 16, 2026 — Correction and substantive update.**
 
 - Corrected the characterization of evaluations as exclusively retrospective and their errors as only indirect. The opening, description, summary, comparison table, and conclusion now recognize preventive runtime evaluation.
@@ -207,4 +213,4 @@
 
 [Version preserved before this revision](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/) · [Exact diff](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/changes.html) · [Revision source](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/after.md) · [Source hashes and provenance](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/manifest.json).
 
-The preserved version is the repository text immediately before this revision, not a claim about the original publication or its deployment date. Earlier editorial history is not reconstructed here.
+Each preserved version is the repository text immediately before its revision, not a claim about the original publication or its deployment date. Earlier editorial history is not reconstructed here.