E.3 - Principle Taxonomy, Precedence and Agent Autonomy Profiles (ABL)

E.3:1 - Problem frame

Pattern E.2 supplies eleven immutable pillars, yet experience shows that a flat list of principles invites ambiguity: reviewers cannot decide which pillar overrules another and “dead‑letter” rules accumulate.

E.3:2 - Problem

When two pillars or derived principles pull in opposite directions, architectural decisions stall—or worse, drift toward the loudest voice. Without an explicit taxonomy and precedence cascade, participants lack an agreed basis for identifying the governing principle and explaining the decision.

E.3:3 - Forces

E.3:4 - Solution

E.3:4.1 - Principle Taxonomy

For this precedence classification, assign each principle exactly one class from { Gov, Arch, Epist, Prag, Did }.

Epistemological sub‑concerns (reasoning, falsifiability) reside inside Epist, avoiding category sprawl yet keeping semantics and trust in one bucket.

E.3:4.2 - Precedence Stack

Each precedence node is an exact applicable pillar, derived principle, guard or assurance requirement, or local policy. The table identifies its source level; it does not rank every sentence in one file above every sentence in another. In particular, level 1 is the Eleven Pillars, not the entire E.2 file.

Default class order. Identify the applicable rules and their source levels. Within the higher-rule boundaries, apply any explicit priority governing this pair. Only an otherwise unresolved conflict uses the default class order: Gov ≫ Arch ≫ Epist ≫ Prag ≫ Did

Unresolved conflict. These relations form a partial order. Two incompatible applicable rules may remain tied or incomparable after the source-level, explicit-priority and class comparisons. Return that exact pair, the shared action and applicability conditions, and hold the dependent action. Unrelated actions remain governed by their own applicable rules. Acyclicity does not guarantee a winner.

To resolve the hold, refer the pair to the authority empowered to amend the affected rules or their priority under their governing change process. That authority may adopt a priority or amend a rule’s scope. Record the rationale, affected scope, Pillar Impact Analysis and edge effects under E.9; an exception also retains its required expiry. The DRR records the decision and does not itself authorize the change. Apply the resolution only after the necessary authorization, retaining higher-rule constraints and the graph rule below.

Graph Rule — The precedence graph MUST be acyclic; any new edge that would form a cycle is rejected.

Governance principle vs Pragmatic principle clash: e.g. Core release schedule (Gov) outranks performance‑tuning (Prag).

E.3:5 - Conformance Checklist

E.3:6 - Illustrative Conflict Resolution

Same-kind wording. First recover the intended kind under A.1. For an already identified U.System, compare the plain name System with its technical expression U.System; both name the same kind. P-1 supports a precise, economical expression, while P-2 expressly gives human comprehension priority over theoretical or tooling purity. Use the familiar wording where it preserves the required meaning and make the technical designation recoverable where needed. The default Arch-over-Did order does not reverse that explicit P-2 priority. U.System is a proper subtype of U.Holon: replacing a non-System Holon with System would change the subject’s extension before any legitimate wording comparison.

Two Gov rules with no priority. Suppose two rules at the same source level apply to publishing report R to audience A at noon: rule G1 requires that action and G2 forbids it. Both are Gov and neither has priority over the other. Return G1/G2, R, A and the noon window as the unresolved conflict; hold publication. Merely listing the class and an acyclic graph does not settle it. The rule-governing authority can authorize an applicable priority or scope amendment with the §4.2 rationale. A proposed G1-over-G2 edge that completes an existing G2-to-G1 path is rejected; the hold remains until a permitted resolution exists. An authorized amendment outside this action’s scope leaves this conflict unresolved.

BLP and a guard. If an applicable E.5 guard excludes a proposed implementation dependency, BLP-6 already gives that guard priority over BLP. Compare those particular rules in their current scope, not the E.2 and E.5 files as whole nodes. B.3 enters the policy ordering for an assurance requirement actually consumed by the use.

Local product policy and a pillar. A product preference cannot override an applicable pillar merely because a local policy says it wins. A disclosed local tie-break can settle only a preference left open by the applicable higher rules. Classify the compared principles; a compound policy such as BLP need not receive one class for all its provisions.

BLP-policy precedence (high → low, for applicable rules). Law & Regulation → E.5 Guard-Rails → B.3 assurance requirements consumed by the use → E.3 governance decisions → E/E-LOG policies (editioned) → BLP derived policy (E.2 §6) → Product Policies → Implementation Tactics. This scope-specific ordering implements the stated BLP safeguards; it does not place a derived policy above a pillar or create unconditional file-to-file edges.

Notes.

• BLP is a constitutional policy (see E.2 / “BLP”), but does not supersede E.5 Guard‑Rails nor B.3 assurance floors; it governs an activated scale comparison; a non-dominant result leaves any generality tie-break to a separately declared local policy.
• Wherever NQD/E/E‑LOG promotes illumination telemetry to dominance (via an explicit CAL policy; policy‑id recorded in SCR), BLP adopts that lens rather than overriding it (see E.2 BLP‑6).
• Any exception to policy MUST include a DRR with rationale and expiry.
• BLP Override (Waiver). A waiver is needed only when an applicable declared generality policy would otherwise decide the use and its exception rule is invoked. Name that policy, the rationale, responsible review System and direct responsibility basis, expiry/review, and the evidence required by the actual exception. Apply C.19.1’s waiver and debt conditions. Ordinary bounded specialization is not an override. Add an AutonomyProfileId and GateDecision authority only when an independently applicable agentic profile governs the action. Set-returning parity. Activated scale comparisons preserve parity and admissible operations under A.18; use G.5/G.9 where their selector/parity contracts apply. Independently applicable stronger profiles retain those requirements. Mixed-scale scalarization without an admissible operation remains prohibited.

BLP — Bitter-Lesson Hooks into Precedence

1. Comparison and tie-breaking. Under E.2 BLP-2, compare usable responses over the declared range and receiving conditions, with uncertainty and applicable α/δ tolerances. Slope dominance alone supplies no usable-performance preference. On non-dominance, a generality preference must be a separately declared local policy allowed by higher rules.
2. Procedure and search. Select a positive procedure or general search under the task/control requirements and applicable policy. A mandated safety procedure keeps its force. BLP adds no universal prohibition-first rule or waiver for a fixed procedure.
3. Publication. A BLP precedence result retains the actual policy/edition and comparison basis. A performed full audit publishes its material resource and assurance accounts under E.2 BLP-1d and G.11. A bounded use with no scale claim creates no audit package.

ABL — Autonomy‑Budget & Oversight Profiles (GateProfile) This section defines an extensible family of autonomy oversight profiles for agentic tool use: each profile specifies (i) a budget envelope, (ii) a Freedom‑of‑Action (FoA) descriptor, and (iii) the required publication of a gate decision authorizing execution under that envelope. The familiar labels L0…L4 are treated here as profile identifiers (not a fixed managerial ladder): projects MAY introduce additional profiles or sub‑profiles by minting new profile ids, provided they publish the same fields (budgets, FoA, decision roles, telemetry requirements) and keep profile changes explicit and auditable.

Normative requirements by profile.

• Budgets. Each profile MUST declare ceilings for time / compute / cost / risk and a FoA descriptor; units must be explicit under C.16, planned ceilings remain A.15.2 WorkPlan content, and run‑time consumption is tied to dated Work, aggregation, and provenance under A.15.1, B.1.6, and A.10. Budgets are hard gates at run‑time (A.21; C.Agent‑Tools‑CAL ATC‑3 for stopping or replanning when a ceiling is breached).
• Profile binding & change visibility. Every CallPlan MUST declare the active profile id. A profile change MUST retain its from/to profiles, policy editions, effective window and A.21 permission result in the DecisionLog. Recompute the decision when its subject, action, rule, checks, scope or window changes. Cite an E.18 GateCrossing only when an independently selected TFS, exact source/receiving positions and changed CtxState bindings establish that structural transition. Add an F.9 Bridge only for its independently obtaining relation between the two F.17 local senses.
• Assurance floors. Apply B.3 to the named assurance claim and receiving use. A required F floor uses C.2.3’s ordinal meaning; any R threshold, composition, or CL loss needs its justified quantity, scale, and model under B.3/C.2.2. No universal F/R weakest-link minimum is imposed by an autonomy-profile label, and F does not substitute for R. Any justified profile-specific tightening for broader FoA MUST be declared on the profile and pinned by policy-id; the actual protection and decision-authority conditions remain binding. Pre-deployment assurance deltas MUST be recorded for L2+.
• Exploration discipline. When a still-live C.19 pool constrains the CallPlan, cite its PoolPolicyResult. Include the exact EmitterPolicy and explore_share only when the plan uses that profile, including 0 when it explicitly plans no exploration. Apply the declared profile’s exception rule to a deviation; do not invent live-pool refs after the action is fixed and pool treatment is irrelevant.
• Provenance. L1+ MUST emit a CallGraph with Service/Method editions, any actually used EmitterPolicyRef, budget deltas, and observation hooks (C.Agent‑Tools‑CAL ATC‑5).
• BLP conformance. Apply E.2 BLP when selection makes a scale claim or invokes a declared generality policy, retaining its actual α/δ tolerances and conditional debt requirements. L2+ alone does not manufacture a scale claim. A profile that independently requires a fuller comparison or audit must state that trigger and basis; its other budget, oversight and assurance duties remain binding.
• Learning/Adaptation. L3–L4 MAY enable adaptation only under product permission, change authority, E.5 and privacy controls. L0–L2 retain their profile default off unless their authorized policy change documents mitigation. Remaining fixed needs no BLP waiver; changing an applicable product requirement follows that requirement’s exception rule.
• Human‑in‑the‑Loop (HITL). HITL obligations are expressed as gate decisions and pause/resume hooks, not an implicit “approval ladder”:
  • L0–L1: execution MAY start only after an explicit GateDecision authorizing the CallPlan is present in the declared window.
  • L2: sentinels MUST be able to pause execution; resumption requires a new GateDecision recorded in the DecisionLog.
  • L3: the profile MUST declare periodic review windows; continued execution across a review boundary requires an explicit GateDecision.
  • L4: continuous telemetry review; the default execution context is sandboxed. Leaving the sandbox requires an explicit A.21 GateDecision for that bounded action, with the applicable signers, budget, scope/window and stop conditions. Publish the decision and profile/policy change. When the case also satisfies E.18’s structural crossing conditions, cite its CrossingRef and required per-binding accounts. Unchanged local meanings need no invented F.9 Bridge.

Gate‑decision authority map (default signers; who may author GateDecisions).

• L0: EoR or appointed maintainer.
• L1: EoR and peer reviewer (two‑person rule).
• L2: Team Lead and Safety representative.
• L3: Product Owner and Safety and Legal/Privacy.
• L4: Gov‑CAL Board (multi‑disciplinary) with documented scope, time‑boxed trial budget, and rollback criteria.

Profile promotion / demotion triggers.

• Promote a profile when the active profile’s required performance and assurance evidence shows stability within its declared tolerances and budget adherence for ≥ N_policy runs. Promotion requires its A.21 GateDecision. If a scale claim supports promotion, cite the usable-response comparison under E.2 BLP-1c; slope evidence alone is insufficient. Keep every independently required profile check.
• Demote a profile when: (i) the profile’s declared risk or budget ceiling is breached, (ii) assurance drops below floors, (iii) policy changes, or (iv) a significant heuristic‑debt item expires without replacement. Demotion MUST be published as a profile-change and permission result with updated budgets and policies pinned. Any structural crossing is established separately under E.18.

Profile-change cases. A local budget revision from twenty to thirty minutes with unchanged meanings requires the authorized profile/policy change and its permission result; absent a selected TFS transition, it has no GateCrossing. If the profile label remains L2, the original twenty-minute permission still cannot authorize execution at minute twenty-five. Apply the authorized new ceiling, required checks and effective window before continuing; otherwise stop at the old ceiling. A case that changes a CtxState binding between two positions in an independently selected TFS also satisfies E.18’s crossing obligations. Leaving a sandbox with unchanged F.17 senses still needs the declared authorization and oversight, but supplies no semantic Bridge. Stop/resume, signer and budget duties remain applicable in each case under its profile.

E.3:7 - Conformance Checklist — E.3 ↔ BLP Interop

E.3:8 - Consequences

Positive — Makes priorities and unresolved conflicts inspectable before the dependent action.

Cost — A conflict outside the declared ordering needs an authorized governance decision. Holding that action can delay work, but avoids silently giving a new priority to whichever rule happens to be encountered first.

E.3:9 - Rationale

The chosen taxonomy mirrors FPF’s layered dependency: Governance rules how change occurs; Architecture shapes what can exist; Epistemology secures meaning and trust; Pragmatics and Didactics ensure usefulness and learnability. Explicit override edges and the default hierarchy determine a winner where the declared ordering suffices. Where it does not, the explicit hold preserves the boundary between applying a rule and acquiring authority to change it. The taxonomy supports that decision; it does not make every pair comparable.

E.3:10 - Relations

• Depends on: E.1, E.2
• Governs: All subsequent patterns and DRRs; Guard‑Rail patterns reference CC‑PT.

“A taxonomy sorts principles; precedence gives them order—together they convert debate into design.”

E.3:11 - SoTA-Echoing — resolve rule conflicts and bind oversight to the action

Practice question and choice. How can an agentic action use applicable governance rules and a budget profile without acquiring an undeclared priority or extra authority? The selected answer combines §4.2’s partial order and unresolved-action hold with §6’s editioned profile, concrete ceilings, checks and permission window. The serious simpler default uses one fixed conflict-combining rule and a stable table of profiles. That default is cheaper where every relevant rule fits its declared semantics and the table fully specifies the action; the added governance work is justified when obligations conflict or a profile’s actual conditions change.

Cedar’s authorization algorithm is a substantive comparator: an applicable forbid overrides permits, otherwise an applicable permit allows the request, and the default is denial. Adopt explicit request scope and a declared combination rule where that permission policy is intended. Reject treating it as a universal ordering of obligations: a requirement to publish and a prohibition of publication can remain normatively inconsistent even when access is denied. Cedar does not claim to repair that inconsistency. Its policy-error handling also does not replace A.21’s treatment of required check results. The source defines an authorization language, not FPF rule-change authority.

NIST AI RMF 1.0 §6, pp.33–34 supplies the candidate line for oversight: profiles depend on the particular use, requirements, risk tolerance and resources; they can distinguish current and target conditions. Adapt that contextual treatment to §6’s budgets, signers, checks and effective window. The source does not prescribe ABL’s L0–L4 labels, numeric defaults or FPF permission semantics. A project’s defaults still need a basis appropriate to its use; an ordinal-looking label alone supplies none. This is a comparison with the published 1.0 method, not a claim about an unreleased revision.

At the same action and input scope, the two cases expose the chosen trade-off:

The taxonomy groups principles for the declared fallback order; its five classes are not a claim that all governing duties reduce to permission predicates. Use the simpler default when its scope and maintained inputs suffice. Reopen only the affected priority or profile comparison when a new incompatible rule, changed permission condition, or equally adequate cheaper policy changes the action. BLP comparisons remain conditional on an actual scale claim or declared generality policy.

E.3:End