AI GovernanceAGSOverview

Alignment Governance Stack

The Alignment Governance Stack is the implementation-facing branch of this work: a local-first set of governance components for delegated AI actions.

Current release: AGS v1.14.0, Risk-Scaled Assurance and Independent Validation. The external AGS repository contains implemented TypeScript packages, examples, documentation, evals, a CLI, and a local-first Continuity Console. Some areas, including runtime governance profile selection, are documented design work rather than completed runtime selection. This page does not claim production readiness or certification status.

Relationship to Alignment Theory

Alignment Theory studies coherent agency under constraint. AGS operationalizes one application: how delegated agency remains continuous with human authority from proposal through execution, evidence, and memory.

Support/substitution explains why automation can preserve output while eroding human participation. Constraints, authority, and continuity explain how delegation can remain accountable. HAPI names the human and institutional conditions to preserve; AGS supplies implementation-facing governance primitives.

Why Agentic AI Changes The Governance Problem

Agentic AI can move beyond text generation into delegated action. It can call tools, execute workflows, update records, send messages, publish drafts, or act through organization-approved systems.

That changes the governance question. The question is no longer limited to whether a model produced acceptable text. A governed system must also ask why an action was proposed, who had authority, what boundary applied, whether the actual runtime action matched the permitted action, and what proof remains afterward.

Delegated Agency

Delegated agency means a system acts under human or organizational authority. The delegation may be narrow, temporary, internal, reversible, and low risk. It may also become external, sensitive, irreversible, or consequential.

AGS treats delegated action as something that needs a path from authority to consequence. The stack asks whether delegation remains under policy, proposal review, execution gating, runtime permit checks, evidence, memory, and human audit.

Agentic AI is treated here as delegated operational agency, not as a moral person. Human or organizational responsibility remains upstream. Authority should have inspectable scope, conditions, expiration, and a revocation path.

The Governed Action Path

The operator-facing spine below follows delegated action from human agency through evidence and operator review. Proposal formation, deliberation, authorization, execution checks, and learning have distinct responsibilities. Handoff Integrity applies across the entire path.

Ten-node trajectory-governance spine

The September 2026 canonical handoff describes the following operator-facing architecture. These are ten positions in a governed trajectory, grouped by responsibility. They are not ten equivalent enforcement modules or a claim that every position is a separately implemented package.

Human-authority plane

  1. Human AgencyHuman understanding, judgment, refusal, responsibility, and direction.
  2. Governance SubstratePolicies, context, roles, and explicit authority boundaries.

Deliberative plane

  1. Context AdmissionThe place for deciding what context is admissible for reasoning.
  2. Agent ReasoningForms proposals under delegated scope; reasoning is not itself a governance control.
  3. PGDLPre-Gate Deliberation Layer: scrutinizes and matures proposals; does not approve or execute.

Enforcement plane

  1. AAGAgent Action Gate: the consequential authorization boundary.
  2. Runtime BindingChecks that actual execution matches a valid permit.

Evidence and maturation plane

  1. ReceiptsTamper-evident evidence of the governance path; evidence is not approval.
  2. Governance MemoryAnalyzes receipt history and recommends improvements for human review.

Operator surface

  1. Continuity ConsoleRead-only operator and evidence surface; not an enforcement layer.

Context Admission evaluates supplied context and provenance for a receiving use. Handoff Integrity and the continuity tests apply across stages. The implementation evidence and limitations remain in the component and status sections below. The Continuity Console is the operator surface, not the theory or an additional approval authority.

Handoff Integrity and continuity

Handoff Integrity is cross-cutting: source lineage, validated context, authority scope, transformation history, expiration conditions, and proof should survive every transfer between agents or stages.

Semantic continuity
Did meaning remain intact through the handoff? Preserve the source, context, uncertainty, and transformation history so inherited interpretation is not mistaken for original fact.
Runtime continuity
Did the authorized branch remain the executed branch? Preserve authorization from permit through the actual tool, target, environment, scope, and execution.

A plausible proposal can inherit distorted context. A valid approval can also be followed by a substituted runtime action. The two tests address different failures.

Pre-Gate Deliberation Layer (PGDL)

PGDL challenges and matures a proposed trajectory before authorization. It can analyze objections, seek revision, escalate, reject, or forward a proposal. It does not grant permission or execute the action.

Agent Action Gate (AAG)

AAG is the consequential authorization boundary. It evaluates the proposal against authority, policy, and applicable requirements before execution. A satisfied assurance result cannot authorize an action by itself or repair missing legitimate approval. AAG does not execute actions.

Runtime Binding

Runtime Binding verifies that the authorized action remains the action being executed. It checks the permit and the actual tool, target, environment, scope, and applicable approval conditions. Authorization must remain valid until the final mutation-capable boundary: the last point before an operation can change external state.

For protected actions in v1.14.0, assurance is re-evaluated at the consequence boundary. Expired evidence or changed conditions cannot be treated as continuing permission. Trusted hosts remain responsible for complete integration at that boundary.

Receipts

Receipts preserve evidence of proposals, governance decisions, runtime checks, and applicable assurance results. They do not create authority. Tamper-evident records help detect changes to supplied evidence; integrity is not authentication, and authorization is not proof of execution.

Governance Memory

Governance Memory analyzes receipt history and produces recommendations for human review. It can identify repeated revision patterns, hard-boundary blocks, missing authority, likely rubber-stamp approvals, runtime substitutions, invalid policy profiles, and other governance patterns.

The documentation is explicit about the boundary: Governance Memory does not silently mutate policy profiles, hard boundaries, authority maps, or participation policies. Every recommendation requires human review.

Internalization under authority

The theory-level maturation process is internalization. The safe Governance Memory loop is action, receipt, pattern detection, recommendation, human review, approved governance change, and improved future proposal.

Cultivated Alignment tests whether governed experience produces lasting improvement. The research asks whether governance-consistent behavior persists as external support is progressively reduced. Model/policy internalization has not been demonstrated here.

Better proposals may justify fewer unnecessary escalations when capacity, authority, and accountability mature. Receipt history alone does not grant permission to weaken controls or change policy.

Governance Profiles

Governance profiles are currently documented design work. The external AGS profile design document says static governance-module manifests exist in Continuity Console sample data, but runtime profile selection is not implemented.

The planned role is to select which governance modules apply to a workflow or action context without allowing modules to silently grant themselves authority. The fixed AGS roles remain PGDL, AAG, Runtime Binding, and receipt continuity.

Relationship To HAPI

HAPI names the agency-preservation problem in public and institutional terms. It asks whether people retain understanding, refusal, revision, authority, and accountability.

AGS is the implementation-facing companion. It gives delegated AI actions a governed path that can produce evidence for later review. HAPI names the human condition the system should preserve; AGS supplies technical primitives for testing and documenting action governance.

Relationship To The Original AAG Prototype

The existing public Agent Action Gate page documents the original AAG v0.3.0 prototype. That page should remain intact because it records a specific release and public implementation surface.

The AGS repository incorporates AAG as one stage inside a larger governed path. Later AGS work should not be described as part of the original v0.3.0 release unless release evidence supports that claim.

Current Status

AGS v1.14.0: Risk-Scaled Assurance and Independent Validation has been released. The project includes TypeScript packages, examples, documentation, evaluation tools, a developer CLI, Governance Memory, and the read-only Continuity Console. Project release milestones and individual package versions are distinct.

AGS is not an AI model, hosted service, legal compliance certification, identity provider, or replacement for human judgment. Supplied evidence and host integration determine what its checks can establish.

Risk-Scaled Assurance in v1.14.0

The required strength of assurance must scale with consequence.

Risk-Scaled Assurance supports AAG and Runtime Binding within the existing architecture. It does not add an eleventh position to the operator-facing spine. Assurance is evidence, not authority: a satisfied result cannot authorize an action by itself.

  • Risk-scaled validation requirements for host-designated protected actions.
  • Declared validator roles and independence groups.
  • Freshness and expiry checks for validation evidence.
  • Refusal-history preservation, including explicit resolutions.
  • Mandatory-human requirements where policy requires them.
  • Runtime re-evaluation at the consequence boundary.

AGS evaluates declared identity and independence metadata supplied by trusted hosts. It does not prove real-world validator independence. More validators can share the same dependencies; plurality must not be mistaken for independence. Hosts remain responsible for current identity and revocation information, policy coverage, complete history, and the final mutation boundary.

See the repository changelog and Risk-Scaled Assurance specification for implementation details and limitations.

Release status: The implementation described here is released as AGS v1.14.0. Older candidate-era copies of the assurance specification describe its pre-release status; that wording does not describe the released implementation.

Governance invariants

The project states these principles:

  • Capability does not create authority.
  • Persistence does not preserve authority.
  • Information transfer does not transfer authority.
  • Authorization is not proof of execution.
  • Integrity is not authentication.
  • Consensus does not create authority.
  • Approval does not establish truth.
  • Denial does not establish falsehood.
  • Governance should constrain consequence without constraining truth-seeking.
  • Authority may stop an action, but should not rewrite the epistemic record.
  • A valid refusal must remain visible to the trajectory.
  • The governor must also be governed.
  • High stakes require stronger assurance, not merely more validators.
  • Context must not outrun provenance.
  • Availability is not admissibility.
  • Assurance should be plural, but plurality must not be mistaken for independence.
  • Authorization must remain valid until the final mutation-capable boundary.
  • Preserve legitimate human agency across delegation.

For the origin and limits of stewardship, see Claim lineage, not control.

Technical Source Material