Skip to content

v7.0.0 — Verification, Defined: One Proof-Bound Contract Across Every Engine

Marketplace
Marketplace

Choose a tag to compare

View all tags
@rahuldass19 rahuldass19 released this 08 Aug 15:18
· 62 commits to main since this release
v7.0.0
cb3e644
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

QWED v7.0.0

v7.0.0 completes META #216: every one of QWED's 13 verification engines now speaks the same contract — the unified 3-layer DiagnosticResult (status / agent_message / developer_fields / proof_ref). This is the release where QWED's definition of verification stops being a promise kept by discipline and becomes a guarantee enforced by construction, in every engine.

From fixing verification to defining it

Earlier releases asked: "Where is verification wrong?" — hunting fail-open bugs where an engine could say VERIFIED without a proof. That was necessary, but it treated verification as something to patch.

The architecture has since matured, and the question changed. It is no longer "how do we fix verification?" but "what IS verification, and how must it be done?" v7.0.0 is the answer, applied universally:

Verification is a deterministic proof, bound to evidence — or it is nothing.

With all 13 engines on one contract, that definition is no longer enforced engine-by-engine. It is structural. You cannot construct a VERIFIED result without a proof_ref, in any engine, by construction.

What verification means to us (and now, in code)

v7.0.0 codifies what does — and does not — count as verification:

  • Execution is not verification. Code that runs cleanly and returns a number proves only that it ran. Stats execution success is UNVERIFIABLE, never VERIFIED.
  • Agreement is not verification. Consensus and cross-engine votes are advisory; they never produce VERIFIED.
  • Confidence is not verification. A high heuristic/LLM/VLM score is carried as advisory_checks, never promoted to a status.
  • A proof is verification. VERIFIED requires a non-empty proof_ref — a deterministic hash binding the verdict to the exact evidence that justified it.
  • UNVERIFIABLE is an honest answer. "We could not prove this" is a first-class, fail-closed result — not a failure state.

If it can't be proven, it doesn't ship. That invariant is now enforced in all 13 engines, not just asserted.

What's new

All 13 engines conform to DiagnosticResult

Schema, SQL, Code, SecureCodeExecutor, and Stats join the previously-migrated Math, Logic, Symbolic, Fact, Image, Graph, Reasoning, and Consensus engines on the 3-layer contract. No engine returns an ad-hoc dict anymore.

Truth is separated from admission

POST /verify/code reports proven-unsafe code as VERIFIED-as-unsafe (is_valid = false, bound proof_ref) — a truth guarantee ("we checked it and it's unsafe") — while a separate admission = BLOCKED decision gates execution. Authority-only consumers can no longer admit unsafe code by reading status == "VERIFIED".

Fail-closed batch verification

Fact / image / SQL / code batches are authoritative only when every item is proven. Any refuted or blocked item fails the whole batch closed; batch proof_ref binds full claim digests plus the shared input (image/context).

Evidence is preserved, never fabricated

Stats retain the observed result, generated code, columns, and a deterministic dataset fingerprint on UNVERIFIABLE. Deferred capabilities (deterministic claim evaluation, schema validation) are tracked as #298 / #299 — filed, not faked.

⚠️ Breaking changes

  • POST /verify/code now returns HTTP 200 with status = "VERIFIED" for proven-unsafe code (previously status = "BLOCKED"). Admission is driven by the new admission field and developer_fields.is_valid. Consumers branching on status for safety gating must switch to admission / is_valid.
  • POST /verify/stats reports execution success as status = "UNVERIFIABLE" (previously VERIFIED), with the observed value at developer_fields.observed_result. Execution success alone is never presented as a proven claim.

Version propagation (6.0.0 → 7.0.0)

  • qwed (PyPI) · qwed_sdk (Python) · @qwed-ai/sdk (npm) · qwed (crates.io)
  • API version marker
  • Kubernetes deployment image: pinned to the published 6.0.0 until the release publishes the 7.0.0 image, then bumped (avoids ImagePullBackOff)

Included PRs (merged after v6.0.0)

  • #294 SchemaVerifier → DiagnosticResult (#255)
  • #295 SQLVerifier → DiagnosticResult (#253)
  • #296 CodeVerifier + SecureCodeExecutor → DiagnosticResult (#254)
  • #297 StatsVerifier → DiagnosticResult (#256) + fact/image batch

GitHub Action

The QWED Verification GitHub Action lives in [QWED-AI/qwed-verification-action](https://github.com/QWED-AI/qwed-verification-action). It wraps the qwedai/qwed-verification Docker image, is versioned independently, and is not published from this repository — no action release is part of v7.0.0.

The QWED Protocol: if it can't be verified, it doesn't ship.

Assets 3
Loading