EmpoweredText Labs

Coding-agent verification

Evidence before acceptance.

EmpoweredText Verify is a merge gate for coding-agent pull requests. It independently checks declared changed-file scope and required TEST and BUILD results before a human merges.

Verify checks the report. It does not certify the code. It establishes bounded acceptance facts—or makes the unresolved gap explicit.

View setup on GitHub

01 / THE PROBLEM

The claimant cannot also be the evidence.

A coding agent finishes a task and reports what changed and what passed. That report is operationally useful, but it remains the agent’s own account.

When a pull request reaches an acceptance boundary, the organization needs to compare those declarations with repository state and trusted execution tied to the exact state under review.

02 / DECLARATIONS

What the agent declares.

V1 stays deliberately narrow. The acceptance declaration names the facts that must be checked.

  1. 01

    Complete changed-file scope

    The exact set of paths the agent says the work changed.

  2. 02

    Required TEST results

    The required test outcome for the evaluated pull-request state.

  3. 03

    Required BUILD results

    The required build outcome for the evaluated pull-request state.

03 / EVIDENCE

What ET examines.

Repository state

The changed paths present in the pull request—not a prose summary of them.

Trusted execution

Required TEST and BUILD results produced by organization-controlled workflows.

Exact-state binding

Evidence must belong to the precise pull-request state ET evaluates. A result for an earlier state is not silently carried forward.

04 / AUTHORITY

The consequence stays human.

Verify adjudicates a defined relationship between claims and evidence. The organization still owns the acceptance policy and the final consequence.

  1. 01 · Claim source Coding agent

    Declares the acceptance-critical facts.

  2. 02 · Evidence source Repository / trusted CI

    Supplies state and execution evidence.

  3. 03 · Adjudicator ET Verify

    Tests the bounded declarations against that evidence.

  4. 04 · Consequence authority Human / organization

    Decides whether the work moves forward.

05 / FINDINGS

Three states. No synthetic confidence score.

Each state says something precise about the bounded declaration and the evidence available for it.

ACCEPTED

The required declarations are supported by trusted evidence bound to the evaluated state.

REVIEW REQUIRED

No positive contradiction is established, but required evidence is missing, stale, or unbound.

An evidence gap is not a positive failure.

BLOCKED

Trusted evidence positively contradicts a required declaration.

A contradiction does not establish dishonesty or global code failure.

Important: REVIEW REQUIRED is not a failed build. BLOCKED is not a judgment about an agent’s motives or the code as a whole.

06 / PORTABLE PROOF

One fictional repository. Three outcomes.

Every detail below is synthetic and public-safe. The repository, paths, hashes, and check names are fictional.

01Synthetic example

ACCEPTED

The required declarations are established for this exact pull-request state.

Agent claim
At 7f3c1a9, the complete changed-path set is src/parse.ts and tests/parse.test.ts. Required TEST and BUILD checks passed.
Independent evidence / state
Repository state at 7f3c1a9 contains exactly those two changed paths. Trusted checks required:test and required:build both completed successfully and are bound to 7f3c1a9.
Relationship
The declared path set matches repository state. Both required results are present, trusted, successful, and bound to the evaluated state.
ET finding
ACCEPTED
Human consequence
The bounded acceptance declarations are eligible for a human's merge decision.
Limit
This does not establish general correctness, test adequacy, security, or whether the pull request should merge.
02Synthetic example

REVIEW REQUIRED

No contradiction is established, but the evidence is not sufficient for acceptance.

Agent claim
At b81e204, the complete changed-path set is src/format.ts and tests/format.test.ts. Required TEST and BUILD checks passed.
Independent evidence / state
Repository state matches the declared paths. required:test is successful and bound to b81e204. The available required:build result belongs to the earlier state a20dd76.
Relationship
The BUILD evidence is stale for the evaluated state. Its absence is an evidence gap, not a positive build failure.
ET finding
REVIEW REQUIRED
Human consequence
A human reviews the gap or requests a BUILD result bound to b81e204 before deciding what happens next.
Limit
REVIEW REQUIRED does not mean the build failed, and it does not establish that the code is defective.
03Synthetic example

BLOCKED

Trusted repository state positively contradicts a required declaration.

Agent claim
At c49a6ef, the complete changed-path set is src/route.ts and tests/route.test.ts.
Independent evidence / state
Repository state at c49a6ef contains those paths plus scripts/release.mjs.
Relationship
The additional path is outside the declared complete set, so trusted state contradicts the scope declaration.
ET finding
BLOCKED
Human consequence
The acceptance gate remains stopped; a human returns the work or requests a corrected declaration and fresh evaluation.
Limit
BLOCKED does not establish agent dishonesty, malicious behavior, or general code failure.

07 / INDEPENDENCE

Why this is not AI checking AI.

Verify does not ask a second model whether the first model sounds credible. It compares a defined claim with repository state and trusted execution controlled by the organization.

The distinction is structural: the claim source is separate from the evidence source, ET’s adjudication is bounded, and human authority is retained.

08 / LIMITS

What Verify refuses to conclude.

Silence outside the evidence boundary is a feature, not a missing marketing claim.

  • General code correctness
  • Test adequacy or coverage sufficiency
  • Code security or dependency safety
  • Feature intent
  • Absence of malicious behavior
  • Global truth about the agent
  • Whether the work must ultimately merge

09 / GITHUB PR WORKFLOW

A conceptual acceptance path.

ET Verify is now available as a public GitHub Action alpha. The organization still defines and enforces the workflow and required checks.

  1. 01

    Coding agent commits an acceptance declaration
    Changed-path scope and required TEST / BUILD results are declared.

  2. 02

    Organization-controlled required workflow runs Verify
    ET evaluates repository state and trusted execution against the exact pull-request state.

  3. 03

    ET returns a bounded finding
    ACCEPTED, REVIEW REQUIRED, or BLOCKED—with the relationship and limit intact.

  4. 04

    Human merges or returns the work
    The consequence belongs to the organization, not the verifier.

Public GitHub Action alphaGitHub workflow coordinate
uses: empoweredtextlabs/et-verify@474a1d79599a714ccb2cac28a0b34c1444ad86c7

This is the Action coordinate. Setup also requires a GitHub workflow and your organization’s required-check configuration.

Repository-local and hosted smoke established Action invocation, exact-head evaluation, and output publication. They did not establish organization-ruleset authority or branch-protection sufficiency.

Public GitHub Action alpha

Public Action. Deliberately narrow claim.

The supported public alpha surface is the GitHub Action. There is no npm installation, and the CLI is not supported in this alpha.

View setup on GitHub

Hosted smoke established

  • Hosted Action invocation on GitHub.com
  • ACCEPTED returns success / exit 0
  • REVIEW REQUIRED and BLOCKED return failure / exit 1
  • An omitted configured check with a qualifying trusted failure remains BLOCKED
  • Exact-head evaluation and output publication

It did not establish

  • Organization-ruleset authority
  • Branch-protection sufficiency
  • Production readiness
  • General code correctness
  • Security assurance

Questions about setup: abram@empoweredtextlabs.com