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.

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

Request private alpha

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 sourceAgent

    Declares the acceptance-critical facts.

  2. 02 · Evidence sourceRepository + trusted CI

    Supplies state and execution evidence.

  3. 03 · AdjudicatorET Verify

    Tests the bounded declarations against that evidence.

  4. 04 · Consequence authorityHuman + 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 a required piece of acceptance evidence is missing, stale, or unbound.

BLOCKED

Trusted evidence positively contradicts a required declaration.

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.

The current public description is conceptual. There is no public self-serve Action or installation path yet.

  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.

Exact integration material is provided during private-alpha onboarding.

Private external alpha

Bring a real acceptance boundary.

The alpha is for teams using coding agents in GitHub pull-request workflows and willing to examine where agent claims, trusted evidence, and human approval should meet.

A strong fit looks like

  • Coding-agent pull requests are already part of the workflow
  • Required test and build checks run under organization control
  • The team wants a bounded gate, not a general code oracle
  • Practitioners can give direct feedback on findings and limits
Founder-assisted private-alpha access.

Email Abram with your team, GitHub workflow, coding agents in use, and what you want to evaluate.

Request private alpha