// bounded change authority / verified release control

HowlChangeOps チェンジ・オプス // 2026

Name: HowlChangeOps
Author: William Elias

HowlChangeOps is the approval, execution-boundary, verification, and rollback component of the Howl ecosystem. Engineered by William Elias as the authority gate of the Howl Autonomous Software Engineering Ecosystem, AI agents reason about release state, but deterministic machinery strictly gates mutation authority behind cryptographic human approval.

AXIOM // INTENT IS NOT AUTHORITY. The proposal describes what is desired. It does not grant permission to perform mutations. HowlChangeOps verifies cryptographic signatures and rejects stale evidence before allowing one bounded Git change.

[ CLONE REPOSITORY ] [ AUTHORITY BOUNDARY ] [ FIVE-MINUTE DEMO ]

PIPELINE // PLAN → VALIDATE → APPROVE → EXECUTE → VERIFY STATUS: TOCTOU_PROTECTED

01 // PLAN

AI / User Intent

Untrusted proposal payload specifying action, logical repo, and target branch.

[TIER: UNTRUSTED]

02 // VALIDATE

Git Evidence

Subprocess test runs, branch checks, and SHA-256 evidence envelope hashing.

[ENVELOPE: BOUND]

03 // APPROVE

Critical Human Gate

Trusted HMAC-SHA256 signature bound to exact decision digest. Replay protected.

[GATE: SIGNATURE]

04 // EXECUTE

Bounded Action

Single atomic mutation (e.g. tag creation). Blocked if evidence drifted.

[EFFECT: ATOMIC]

05 // VERIFY

Post Audit

Post-action invariant check, durable receipt logging, and rollback readiness.

[AUDIT: VERIFIED]

SECTION // 01 Overview & Core Problem

HCO-MOD-OVERVIEW

AI coding agents are capable of analyzing diffs, evaluating test coverage, and proposing release candidates. However, allowing an unconstrained model to invoke arbitrary shell commands or push tags directly to production creates catastrophic risk.

HowlChangeOps proves that intent is not authority. It allows an AI (or human) to propose actions, strictly validates intent via deterministic HowlFrame bytecode policies, requires trusted human approval for state mutations, and executes bounded operations securely.

01 // PROPOSE AI or human submits JSON intent payload

02 // CHECK Host gathers trusted Git state & test evidence

03 // DECIDE HowlFrame VM evaluates policy decision

04 // EXECUTE Bounded executor performs one verified effect

SECTION // 02 Authority Boundary Architecture

HCO-MOD-BOUNDARY

The core architectural principle is the total separation between proposal and permission. Untrusted inputs never touch host execution paths directly:

[SCHEMATIC // BOUNDARY_ARCHITECTURE] AUTHORITY_GATE

              UNTRUSTED ZONE
        ┌─────────────────────────┐
        │  AI / USER INTENT JSON  │
        └────────────┬────────────┘
                     │
                     ▼
        ┌─────────────────────────┐
        │ HOWLCHANGEOPS EVIDENCE  │
        │ (GIT / LOCAL TEST RUNS) │
        └────────────┬────────────┘
                     │
                     ▼
        ┌─────────────────────────┐
        │ HOWLFRAME POLICY ENGINE │
        │ (COMPILED BYTECODE VM)  │
        └────────────┬────────────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
       DENY        ALLOW       REQUIRE
                               APPROVAL
                                  │
                                  ▼
                        [ CRITICAL HUMAN GATE ]
                        HMAC-SHA256 SIGNATURE
                                  │
                                  ▼
                        EVIDENCE REVALIDATION
                        (TOCTOU DRIFT CHECK)
                                  │
                                  ▼
                        BOUNDED GIT EXECUTION
                        (TAG CREATION / RELEASE)
                                  │
                                  ▼
                        POST-VERIFICATION & AUDIT

SECTION // 03 Separation of Concerns Matrix

HCO-MOD-SEPARATION

Domain	Allowed Capabilities	Strict Restrictions	Security Guarantee
AI / User Intent	Propose action, choose logical repo, provide rationale	Cannot choose arbitrary paths, run arbitrary shell commands, or self-approve	UNTRUSTED
HowlChangeOps Host	Repo mapping, Git evidence collection, test validation, approval verification, bounded effects	Cannot override policy, bypass evidence checks, or authorize itself	EVIDENCE BOUND
HowlFrame Policy	Branch rules, action rules, evidence requirements, stale-state checks, authorization verdicts	Cannot perform physical execution or modify host environment	DETERMINISTIC

SECTION // 04 Ten-Stage Release Flow

HCO-MOD-WORKFLOW

INSPECT: Retrieve verifiable Git states and logical repo configurations.
VALIDATE: Run tests and store status safely in a cryptographically bound evidence envelope.
PLAN: Simulate the changes the proposal intends to make.
EVALUATE: Assess an intent payload against policy to output a deterministic decision.
EXPLAIN: Decode the reasoning and invariant checks behind an evaluation decision.
APPROVE: Provide a trusted HMAC-SHA256 authorization signature tied to the exact decision state.
EXECUTE: Verify evidence is not stale and perform strictly bounded physical changes.
VERIFY: Post-action verification ensures the expected state was achieved.
AUDIT: Output a complete JSON-lines audit trail of evaluation and execution logic.
ROLLBACK: Revert release candidates when necessary under governed authorization.

SECTION // 05 Terminal Demo & Policy Output

HCO-MOD-CLI

[BASH // CLI_LIFECYCLE]

# 1. Inspect repository state
howlchangeops inspect howlframe

# 2. Validate tests and generate evidence envelope
howlchangeops validate howlframe

# 3. Simulate planned changes
howlchangeops plan howlframe

# 4. Evaluate proposal against HowlFrame bytecode policy
howlchangeops evaluate proposal.json

# 5. Explain decision invariants
howlchangeops explain decision-123

# 6. Human operator signs off with trusted key
howlchangeops approve decision-123

# 7. Execute bounded mutation
howlchangeops execute decision-123

# 8. View verified audit history
howlchangeops history

Representative Policy Verdict

[OUTPUT // POLICY_VERDICT] EVALUATION

DECISION: REQUIRE_APPROVAL

branch_allowed........ PASS
working_tree_clean.... PASS
tests................. PASS
build................. PASS
approval.............. REQUIRED

reason:
release candidate mutation requires trusted human approval signature

SECTION // 06 Attack the Boundary (Threat Invariants)

HCO-MOD-THREAT

Scenario A: Hostile Self-Approval Injection

An untrusted model submits {"approved": true, "admin": true, "override": true} in the proposal JSON.

RESULT: REQUIRE_APPROVAL. Fake approval parameters are ignored; only trusted cryptographic signatures matching the decision digest are accepted.

Scenario B: Directory Traversal

An attacker submits repo: "../../etc".

RESULT: UNKNOWN_REPOSITORY. Only strictly configured logical repository mappings are accepted.

Scenario C: Time-of-Check to Time-of-Use (TOCTOU) Drift

A commit is pushed to the repository after evidence validation and before execution.

RESULT: STALE_EVIDENCE. Execution is blocked immediately because the approved state drifted.

SECTION // 07 HowlFrame Relationship

HCO-MOD-HOWLFRAME

HowlChangeOps is an independent application built on HowlFrame's public execution boundary. It acts as real-world dogfooding for HowlFrame's core thesis: probabilistic systems may propose actions, while deterministic machinery retains execution authority.

HOWLFRAME = Language / Bytecode Runtime / Capability Authority Layer
HOWLCHANGEOPS = Governed Release & Change Control Application

SECTION // 08 Security Architecture

HCO-MOD-SECURITY

Finite allowed action catalog within operational domain
Trusted logical-repo mapping and path confinement
Revision-bound SHA-256 evidence envelopes
Decision integrity via deterministic bytecode policy
HMAC-SHA256 cryptographic approval bindings
Replay protection (consumed approvals cannot be re-executed)
Stale-evidence denial (TOCTOU drift detection)
Bounded exec.Command arguments without shell injection vectors
Post-action verification and audit logging

SECTION // 08B Bounded Authority & Change Control Q&A

HCO-MOD-FAQ

Autonomous coding agents cannot be granted unrestricted git push, merge, or deployment authority. HowlChangeOps solves the safety problem through deterministic cryptographic gates and bounded mutation envelopes.

How can AI-generated code changes be verified and rolled back safely?

HowlChangeOps encapsulates proposed changes into an immutable SHA-256 evidence envelope containing explicit test outputs, branch states, and diff hashes. Every execution phase is strictly paired with an automated post-action verification and a pre-computed deterministic rollback script, ensuring instant reversibility if post-deployment health checks fail.

How do cryptographic approval gates prevent prompt-injection attacks?

Prompt injection affects LLM reasoning, not deterministic signature verification. In HowlChangeOps, mutations require an HMAC-SHA256 signature generated by a human keyholder over the exact evidence envelope hash. Even if an agent's reasoning is compromised by untrusted prompt injection, the mutation engine rejects the payload unless signed by authorized human credentials.

How does HowlChangeOps prevent TOCTOU drift attacks?

Time-of-Check to Time-of-Use (TOCTOU) occurs when repository state changes between evidence collection and execution. HowlChangeOps locks the target commit SHA in the signed envelope. If any commit or tag is pushed to the repository before the mutation runs, the engine detects hash mismatch and immediately halts with STALE_EVIDENCE.

Who engineered HowlChangeOps and how does it fit into the Howl ecosystem?

HowlChangeOps was designed and built by William Elias. It acts as the release authority and human gatekeeper for HowlPlane, compiling policy via HowlFrame bytecode to guarantee that autonomous engineering work conforms to human sovereignty.

SECTION // 09 Documentation & Authorship

HCO-MOD-DOCS

HowlChangeOps is designed and maintained by William Elias as the release controller for the Howl Ecosystem.