RFC-0011: Authority Binding Sub-Spec Revision

RFC: RFC-0011
Status: Placeholder
Version: 0.0.1
Created: 2026-03-15
Updated: 2026-03-15
Author: Ken Tannenbaum, AEGIS Initiative
Repository: aegis-governance
Target milestone: TBD
Supersedes: Authority Binding sub-spec (revision — see Motivation)
Superseded by: None

Summary

The existing Authority Binding sub-spec defines how authority is captured at proposal time and re-validated at commit. It does not enumerate the conditions under which proposal-time authorization may not imply commit-time admissibility, does not name the resulting failure outcomes, does not define the minimum authority claim set required for an admissibility proof, and does not address behavioral declaration fields that a runtime should assert at registration time. This RFC revises the Authority Binding sub-spec to specify those missing normative definitions.

Status Note

This is a placeholder RFC. Content is pending the normative source audit (target: before 2026-03-22 IEEE outline). The RFC number is reserved to maintain index continuity with the README and roadmap.

Motivation

Two gap findings from the normative source audit (2026-03-15) are assigned to this RFC, along with one unresolved drift instance:

gap-005 — Minimum authority claim set for admissibility proofs. The Authority Binding sub-spec does not define the minimum set of authority claims required for a commit decision to be considered admissible. This is an open research question — Elora Taurus’s 06_ROADMAP_AND_RESEARCH_QUESTIONS.md identifies it explicitly as unresolved. AEGIS must either answer it or explicitly defer it in the IEEE paper Limitations section.

gap-006 — Behavioral declaration at registration. A runtime should declare its own reasoning profile, behavior mode, and behavior profile ID at registration time as part of the authority binding record. The Elora Tape schema defines four behavioral declaration fields: runtime_mode, reasoning_profile, behavior_mode, behavior_profile_id. AEGIS has no equivalent in the Authority Binding sub-spec or Constraint Envelope. This is a prerequisite for cryptographic agent registration (RFC-0010 dependency; Discussion #75).

Authority drift failure modes (unresolved drift instance). The Authority Binding sub-spec does not enumerate the conditions under which proposal-time authorization may not imply commit-time admissibility, nor the named failure outcomes. Four invalidation conditions must be specified: revocation, delegation change, authority epoch drift, and policy state transition. Three failure outcomes must be named: authority_not_admissible, authority_drift, authority_not_captured (or AEGIS equivalents — see Open Questions). These are currently absent from the corpus.

The motivating threat model for this RFC: in extension-heavy ecosystems (skills, plugins, MCP-style integrations), runtime identity can drift after approval unless explicitly bound to a verifiable artifact at registration time. Administrative registration alone is insufficient — governance decisions must be tied to a verifiable runtime identity, not just a label. (Reference: Nathan Freestone, Elora Taurus, Discussion #75, 2026-03-15.)

Guide-Level Explanation

Pending. To be drafted after normative source audit.

Reference-Level Explanation

Pending. To be drafted after normative source audit.

Anticipated sections:

Drawbacks

Pending.

Alternatives Considered

On “Authority Drift” as AEGIS terminology: Elora Taurus uses “authority drift” as a named term in its terminology glossary (2026-03-09) to describe mismatch or evolution between captured authority context at proposal time and commit time. AEGIS has the concept but not the term. This RFC must decide whether to adopt the term directly or define an AEGIS equivalent. Adopting Elora’s term aligns the two systems and simplifies cross-referencing in the IEEE paper; defining an AEGIS equivalent preserves terminological independence. Decision deferred to drafting.

Compatibility

This RFC revises the existing Authority Binding sub-spec. Sections not addressed here remain in force. Breaking changes, if any, will be enumerated in the Reference-Level Explanation once drafted. The behavioral declaration fields introduced here interact with the Constraint Envelope sub-spec — that interaction must be reviewed for consistency during the normative source audit.

Implementation Notes

Pending.

Reference implementations to consult during drafting:

Open Questions

Success Criteria

References

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative — AEGIS Operations LLC