OpenQAEvidence-based change acceptance for AI software delivery
Evidence-based change acceptance for AI software delivery· Nº 01Private beta · public beta planned for 2026 Q4

Scale AI coding agents without scaling review cost or release risk.

OpenQA turns every software change into an evidence-backed merge and release decision.

  • Understand the change:connect intent, requirements, the diff and repository context to establish what the change claims to complete.
  • Identify risk:find affected paths, out-of-scope edits, evidence gaps, and functional, security and compatibility risks.
  • Verify independently:orchestrate tests, code analysis, security scanners and real execution without trusting the authoring agent’s completion claim.
  • Produce a verdict:bind logs, traces, screenshots and tool results to the change, explaining whether it is ready to merge or release and what evidence is still missing.

Verify agent changes independently and show what supports the decision, what is missing, and which risks need human judgement.

Meet OpenQA Verifier Accept an agent PR Solutions

Change Acceptance Record

PR #482 · Order access control

Conditional pass

01

Understand

Intent · diff · impact

02

Verify

Tests · security · runtime

03

Decide

Merge · review · block

Direct evidence

  • Regression: fails before, passes after
  • Permission test suite: passed
  • SAST: no new high-severity findings

Residual risk

Cross-tenant isolation not verified

Next action

Allow merge; review before release

Evidence-based change acceptance· Nº 02

Keep the engineering stack. Turn its signals into a verdict.

Teams already have test frameworks, code scanners, CI and observability. What is missing is a change-level decision about whether the evidence is sufficient. OpenQA calls those tools; it does not replace them. The output is a Change Acceptance Record.

  1. OpenQA Verifier

    Runs locally or in CI. Give it an intent, commit or pull request; it plans verification, gathers direct evidence and produces readiness verdicts. Every step is visible and policy is protected.

    Meet the verifier

  2. Change graph

    Requirements, code calls, dependencies, business flows and prior outcomes in one queryable model. Every change starts with its intent, blast radius and prohibited scope.

    How changes are modelled

  3. Verification infrastructure

    Tests, code analysis, security scanners, browsers, devices and remote execution are evidence providers. OpenQA invokes them by risk and normalises the results into one Change Acceptance Record.

    See verification capabilities

  4. Verification skill registry

    First-party, open-source and third-party verification skills with source, permissions, versions and applicable risks. Install only what a change needs and encode organisation-specific acceptance rules.

    Browse skills
Why should this change be accepted· Nº 03

A decision needs more than a diff.

Acceptance evidence is scattered across requirements, code, tests, security tools and runtime systems. OpenQA binds it to one change and one policy version.

Change intent
The problem it claims to solve and the acceptance conditions it must meet.
Direct evidence
The checks that actually ran and the risks and paths they covered.
Residual risk
The conditions not yet verified and the decisions that still require a person.
  1. Intent and requirementsIssues, specifications and acceptance criteria define what the change was meant to accomplish.
  2. Code and dependenciesDiffs, functions, APIs, configuration and dependencies show what changed and where impact propagates.
  3. Tests and checksDirect build, test, coverage, static-analysis and security-scan output.
  4. Execution evidenceRequests, logs, traces, screenshots and environment facts show what actually happened.
  5. Policy and outcomesRepository rules, waivers, human decisions, regressions and rollbacks after release.
How acceptance runs· Nº 04

From a software change to an evidence-based decision.

OpenQA Verifier

Give it one change. Get a verdict and its trust basis.

One task, from understanding intent to merge and release readiness.

  1. Understand change

    Extract intent, diff, blast radius, permitted scope and acceptance criteria.

  2. Plan verification

    Select existing checks by risk and identify the evidence still required.

  3. Execute independently

    Call existing test, security and engineering tools and collect direct evidence.

  4. Issue verdicts

    State evidence sufficiency, merge and release readiness, and required human review.

Meet OpenQA Verifier Accept an agent PR
Case Management
Platform 01

智能用例管理平台

Turn requirements into cases, inside the review and maintenance flow your team already has.

MCP / Internal · Due 2026 Q4Unit & Integration Generation
API Testing
Platform 02

智能接口自动化平台

One place for API definitions, cases, mocks, environments and regression results.

MCP / Internal · Due 2026 Q4API & Contract Testing
QASkill Hub· Nº 05

Verification must execute. It must also be reviewable.

How ranking worksView all

Skills adapt existing engineering tools for OpenQA. Their source, permissions, version and scope must be explicit before their output can become trusted evidence.

  • Defects found
  • False positives
  • Test pass rate
  • Duration
  • Cost
    Independent agent PR acceptance· Nº 06

    Bring one real agent PR. Run an independent acceptance.

    Choose a repository and a change. OpenQA will determine whether it meets the conditions to merge. What ran, whether evidence is sufficient, and what is still missing remain visible.

    Accept an agent PR See the verification flow