Changelog

​

QWED Math Engine — fail-closed on mode ambiguity, eigenvalue cardinality, and IRR convergence

Three core-verifier fixes tighten the math engine’s fail-closed contract. verify_statistics(statistic="mode"), verify_matrix_operation(operation="eigenvalues"), and verify_irr() no longer produce VERIFIED when the underlying claim is ambiguous, under-specified, or numerically unproven. Callers see BLOCKED or CORRECTION_NEEDED with structured diagnostics instead of a best-effort answer.

​

What changed

• verify_statistics(statistic="mode") requires a unique mode. When two or more values tie for the maximum frequency, the engine returns BLOCKED with an ambiguous_modes list instead of heuristically picking one. Only a unique mode can produce VERIFIED.
• verify_matrix_operation(operation="eigenvalues") requires cardinality match. The claimed eigenvalue list length must equal the calculated count (counting algebraic multiplicity). Mismatched lengths return CORRECTION_NEEDED with calculated_count/claimed_count. Previously the value comparison used zip, which silently truncated to the shorter list.
• verify_irr() requires proof of Newton-Raphson convergence. BLOCKED is now returned when cash flows have more than one sign change (multi-root ambiguity per Descartes’ rule), zero sign changes (no real IRR), all-zero cash flows (IRR undefined), the Newton derivative stalls at zero, or the method fails to converge within 100 iterations. Successful results include converged: true and iterations_used.

​

Before and after

# Before — heuristically picked one of the tied values and could return VERIFIED
client.verify_statistics(statistic="mode", data=[1, 1, 2, 2, 3], expected=1)
# status: "VERIFIED"

# After — BLOCKED with the full list of tied values
client.verify_statistics(statistic="mode", data=[1, 1, 2, 2, 3], expected=1)
# status: "BLOCKED"
# ambiguous_modes: [1, 2]

# Before — zip truncated the comparison to length 1 and returned VERIFIED
client.verify_matrix_operation(operation="eigenvalues", matrix=[[2, 0], [0, 3]], expected=[2])
# status: "VERIFIED"

# After — CORRECTION_NEEDED with explicit cardinality diagnostics
client.verify_matrix_operation(operation="eigenvalues", matrix=[[2, 0], [0, 3]], expected=[2])
# status: "CORRECTION_NEEDED"
# calculated_count: 2, claimed_count: 1
# calculated_eigenvalues: [2.0, 3.0]

# Before — Newton-Raphson returned a best-effort iterate that could be VERIFIED
client.verify_irr(cash_flows=[-100, 230, -132], expected=0.10)
# status: "VERIFIED"

# After — BLOCKED because two sign changes admit multiple real IRRs
client.verify_irr(cash_flows=[-100, 230, -132], expected=0.10)
# status: "BLOCKED"
# sign_changes: 2

​

What this means for you

​

QWED-Finance — v2.1.0 released

qwed-finance v2.1.0 is now the current release. This is a version-sync release: the Python package, npm wrapper, GitHub Action, and quickstart workflow reference are all realigned so QWED Finance Guard reports a single consistent version across PyPI, npm, and SARIF output in GitHub Advanced Security.

​

What changed

• qwed-finance Python package is now v2.1.0 on PyPI (qwed_finance.__version__ == "2.1.0").
• @qwed-ai/finance npm package version bumped to 2.1.0 to match.
• GitHub Action auto-syncs its reported version from the installed package — the QWED Finance Guard name in workflow logs and the version field on SARIF uploads to the GitHub Security tab now both read 2.1.0 instead of a hardcoded v2.0.
• Quickstart qwed-verify.yml workflow is re-pinned from the stale v1.1.4 SHA to the v2.1.0 SHA (QWED-AI/qwed-finance@19ce969f21d1fc2019da4d89fff23bc108e15a98 # v2.1.0).

​

What this means for you

pip install --upgrade qwed-finance

- name: Verify banking calculations
  uses: QWED-AI/qwed-finance@v2.1.0

​

QWED-UCP — v0.3.0 released

qwed-ucp v0.3.0 is now the current release. This version ships the typed TrustStatus enum on every verification result, alongside the fail-closed middleware and internal-error handling delivered over the v0.2.x series.

​

What changed

• qwed-ucp Python package is now v0.3.0 on PyPI.
• Express middleware qwed-ucp-middleware package version bumped to match.
• TrustStatus enum is confirmed as available from v0.3.0 onward — see Trust status for the full state table and usage.
• GitHub Action should now be pinned to QWED-AI/qwed-ucp@v0.3.0.

​

What this means for you

pip install --upgrade qwed-ucp

- name: Audit Commerce Transactions
  uses: QWED-AI/qwed-ucp@v0.3.0

​

QWED-UCP — Express middleware fails closed on internal verification errors

When a guard raised an unexpected exception, the Express middleware previously logged the error and called next() — letting an unverified checkout through to the downstream handler. That defeated the trust boundary. The catch block now short-circuits with HTTP 500, X-QWED-Verified: false, and code: "INTERNAL_VERIFICATION_ERROR" so an internal crash can no longer be mistaken for a passing verification.

​

What changed

• Express middleware catch block is now fail-closed. On any exception raised during verifyCheckoutLocally(), the middleware returns:
  {
    "error": "QWED-UCP Verification Failed",
    "message": "Internal verification error: verification could not be completed",
    "code": "INTERNAL_VERIFICATION_ERROR"
  }
  
  The underlying exception is logged server-side via console.error but is not included in the response body — raw stack traces, file paths, and internal messages stay out of client-visible output.
• X-QWED-Verified: false is set on the 500 response so upstream policy layers can treat it the same as a 422 failure.
• npm package fix. qwed-ucp-middleware.js is now included in the published files array. Previous versions installed via npm were missing the entrypoint that index.js required at runtime.

​

What this means for you

​

QWED-UCP — typed TrustStatus enum on every verification result

Verification results previously exposed a single verified: bool that collapsed “proof disproved,” “proof could not be established,” “input outside supported semantics,” and “verifier engine crashed” into the same False bucket. Every result dataclass now also carries a typed status: TrustStatus field so downstream policy code can make trust-aware decisions without parsing error strings.

​

What changed

• New TrustStatus enum exported from qwed_ucp with seven states: VERIFIED, FAILED, UNVERIFIABLE, UNSUPPORTED, PARTIAL, ENGINE_ERROR, and QUARANTINED (reserved).
• status field on every result — GuardResult, UCPVerificationResult, and each per-guard result type (MoneyGuardResult, StateGuardResult, SchemaGuardResult, LineItemsGuardResult, DiscountGuardResult, CurrencyGuardResult, RefundGuardResult, TipGuardResult, FeeGuardResult, AttestationResult).
• UCPVerifier.verify_checkout() now surfaces ENGINE_ERROR when any guard raises an exception, instead of silently collapsing to verified=False.
• verified: bool is preserved as a backward-compatible derived field: result.verified is True only when result.status == TrustStatus.VERIFIED. Existing constructors that pass verified=True/verified=False continue to produce the corresponding VERIFIED/FAILED status.

​

What this means for you

​

QWED-UCP — middleware fails closed on empty and non-JSON request bodies

The FastAPI and Express middleware previously forwarded requests with an empty body, malformed JSON, or a non-object JSON payload to the downstream handler without running any guards. On a /checkout-sessions route that defeated the trust boundary — an attacker could send {}’s worth of nothing and skip verification. Both middlewares now reject those requests with HTTP 422, X-QWED-Verified: false, and code: "UNPARSEABLE_REQUEST" before the handler runs.

​

What changed

• FastAPI: returns a distinct message per case:
  • Empty body → "Empty request body: cannot verify empty payload"
  • Malformed or non-UTF-8 body → "Malformed request body: expected JSON"
  • Top-level non-object JSON → "Invalid request body: expected JSON object"
• Express: all three cases return "Empty or non-JSON request body: cannot verify unparseable payload".
• Non-protected methods and paths (for example, GET /health or a POST to a route outside verify_paths) still pass through untouched.

​

What this means for you

​

QWED-A2A — persistent signing key and JWKS discovery endpoint

A2ACryptoService no longer generates an ephemeral ECDSA P-256 key per process. The signing key is now loaded from the QWED_A2A_SIGNING_KEY_PEM environment variable (or the pem_key constructor argument) so attestation JWTs issued before a restart remain verifiable afterwards. A new /.well-known/jwks.json endpoint publishes the current public key for external consumers.

​

What changed

• Persistent signing key — A2ACryptoService reads an unencrypted PKCS#8 P-256 PEM from QWED_A2A_SIGNING_KEY_PEM on first use. The derived key_id is a SHA-256 fingerprint of the public key, so it stays stable as long as the PEM does.
• Fail-closed on missing key — sign_verdict, verify_attestation, get_public_key_jwk, and A2AVerificationInterceptor.intercept() all raise RuntimeError when the PEM is missing, malformed, or uses a curve other than SECP256R1. The FastAPI gateway surfaces this as HTTP 503 Signing key unavailable.
• JWKS endpoint — A new wellknown_router exposes GET /.well-known/jwks.json for downstream services and auditors to fetch the current public key without an out-of-band exchange.
• get_public_key_jwk() — Returns the current public key as a JWK (kty, crv, x, y, kid, use, alg).

​

Breaking changes

openssl ecparam -name prime256v1 -genkey -noout \
  | openssl pkcs8 -topk8 -nocrypt \
  > qwed_a2a_signing_key.pem

​

What this means for you

​

QWED-Tax — structured 3-layer diagnostics for TDS, ITC, and GST-RCM

QWED-Tax adopts the same 3-layer DiagnosticResult contract introduced in QWED-Verification v5.2.0 — as an independent model, no cross-package dependency. The first three guards (TDS, Input Tax Credit, GST reverse-charge) now expose a structured diagnostic in addition to their existing dict response.

​

What’s new

• Tri-state status — Every diagnostic resolves to VERIFIED, UNVERIFIABLE, or BLOCKED. No HEURISTIC or AMBIGUOUS middle ground.
• Three disclosure layers — A short agent-safe summary (no statute IDs or detection logic), a structured developer evidence block (constraint ID, statute, jurisdiction, audit trace, deduction, net payable), and an optional proof reference.
• Proof reference is the authority bit — A deterministic sha256 hash of the audit trace, present only when a result is VERIFIED. Absent on UNVERIFIABLE and BLOCKED.
• First migrations — TDSGuard, InputCreditGuard, and GSTGuard (reverse-charge) each expose the new diagnostic format alongside their existing return shape.

​

Compatibility

​

What this means for you

​

QWED-Tax — exact paise comparison, edge-case input rejection, and strict payload schemas

Three input-strictness fixes ship together. CryptoTaxGuard.verify_flat_tax_rate now compares quantized paise values exactly instead of within a 0.1 tolerance, ValuationGuard and RemittanceGuard reject the edge-case numeric inputs that previously slipped through, and every QWED-Tax Pydantic input model now forbids unexpected fields.

​

What changed

• CryptoTaxGuard.verify_flat_tax_rate — The Decimal("0.1") tolerance was removed. Both the computed expected_tax and the caller’s claimed_tax are now quantized to two decimal places using ROUND_HALF_UP and compared with an exact ==. A 1-paise (0.01) deviation correctly returns verified=False.
• ValuationGuard.verify_conversion — Added explicit range checks: discount must be in [0, 1), and cap, next_round_price, and investment must all be strictly positive. DivisionByZero is now caught alongside InvalidOperation so a degenerate cap = 0 or discount = 1 no longer crashes — it fails closed with a structured {"verified": False, "error": "..."} response. The previous behavior allowed a discount > 1 to produce a negative share count.
• RemittanceGuard.verify_lrs_limit — After numeric parsing, amount_usd and financial_year_usage are now checked for negativity. Negative inputs return {"verified": False, "error": "BLOCKED: ..."} instead of being summed into the limit check, where a negative usage could mask a transaction that exceeds the $250,000 LRS cap.
• Input models — Address, WorkArrangement, WorkerClassificationParams, ContractorPayment, TaxEntry, DeductionEntry, PayrollEntry, and VerificationResult are now configured with model_config = ConfigDict(extra="forbid"). Any payload with an unexpected key raises a Pydantic ValidationError at the boundary. QWEDTaxMiddleware already surfaces this as status: "BLOCKED" with risk: "INVALID_PAYLOAD".

​

Breaking changes

from decimal import Decimal, ROUND_HALF_UP

claimed = (vda_income * Decimal("0.30")).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

​

What this means for you

​

Audit reference

​

QWED-Tax — middleware never returns full “verified” and ReciprocityGuard no longer always-passes

Two fail-closed fixes ship together. The Gusto interceptor middleware no longer overstates a gross-to-net arithmetic pass as full tax verification, and ReciprocityGuard no longer returns verified=True for arrangements with no reciprocity agreement.

​

What changed

• QWEDTaxMiddleware.process_ai_payroll_request — The success response is now status: "ARITHMETIC_VERIFIED" with execution_permitted: false. The middleware only verifies gross-to-net math; classification, withholding legality, reciprocity, and filing checks are still required before execution. The response includes checks_run (what was verified) and checks_not_run (what is still required) so callers can decide what to run next.
• TaxPreFlight report — Every report now includes a checks_not_run list covering both unselected guards and known gaps (checks not yet implemented for the action). For example, action="hire" reports payroll_arithmetic, withholding_legality, reciprocity, and filing_obligations as known gaps.
• ReciprocityGuard — The Z3 solver was removed (the prior expression was tautologically satisfiable and ignored the same_state parameter). The guard is now a deterministic lookup against the reciprocity-pair table with explicit fail-closed paths: same state → verified, known pair → verified, no agreement → verified=False, unknown state → verified=False. A new verify_reciprocity(residence_state, work_state, same_state=None) method takes string inputs; determine_withholding_state(arrangement) is kept for backwards compatibility.

​

Breaking changes

​

What this means for you

​

Audit reference

​

QWED-Tax — fail-closed on ambiguous classification and unverified claims

Six more QWED-Tax guards now refuse to sign off when they can’t independently prove a result. Ambiguous worker classifications, unparseable trade dates, unknown set-off heads, and reverse-charge inputs the guard doesn’t recognize all return verified=False with a structured error instead of a quiet pass.

​

Bug fixes

• CapitalGainsGuard — Unparseable acquisition or disposal dates and unknown asset types now block instead of being coerced into a sentinel value that flowed through to verified=True. SLAB-rate verification can no longer succeed without an income bracket — slab rates can’t be proven from the claim alone.
• ClassificationGuard — Mixed employee/contractor signals now return verified=False with an “ambiguous classification” error. The guard only returns CONTRACTOR when no employee indicators are present.
• SpeculationGuard — Set-off verification now requires a known income source (intraday, f&o, futures, options, delivery, business, capital_gains). Unrecognized sources are blocked instead of silently treated as non-speculative.
• InterHeadAdjustmentGuard — Set-off eligibility now runs against an explicit allowlist of heads. Salary loss set-off is added to the prohibition matrix, and unknown heads are blocked rather than defaulting to allow.
• GSTGuard (RCM) — Unrecognized service or entity types in reverse-charge checks now surface as a verified=False error naming the unknown value, instead of being coerced to OTHER or INDIVIDUAL and potentially suppressing a statutory RCM obligation. The verifier also gained an optional claim parameter — when you pass a claimed_is_rcm value, the guard compares it to the computed result and only returns verified=True on an exact match. Calls without the claim get a computed_only=True flag so calculation and verification are no longer conflated.
• CryptoTaxGuard — Zero VDA income now verifies a claimed tax of zero, instead of returning verified=True regardless of claim. Negative VDA income (a loss) returns verified=False with a message directing the caller to use verify_set_off for loss treatment — the method does not internally invoke verify_set_off, so callers must handle the verified=False branch explicitly.

​

What this means for you

​

QWED-Tax — fail-closed on unknown tax rules

Tax guards no longer silently pass when they encounter a service, asset, jurisdiction, or payment type they don’t model. Six guards now return verified=False with a structured error instead of an unsafe default.

​

What changed

• TDSGuard — unrecognized payment categories no longer return “verified, zero deduction.” This closes a path where an agent could classify a payment into an unknown bucket and have it execute with no withholding. TaxPreFlight now blocks these payments.
• CapitalGainsGuard — unknown asset class or holding term fails closed instead of returning “no hard constraint.”
• NexusGuard — states not in the configured risk list now require manual review instead of being treated as low-risk.
• AddressGuard — unknown state codes fail closed with “manual review required” instead of “assumed valid.”
• Form1099Guard (US) — unmodeled payment types return filing_required=None with a manual-determination flag, instead of defaulting to “no filing required.”
• InputCreditGuard (GST) — verified=True remains the legal default (ITC is allowed unless specifically blocked), but unknown categories now carry an explicit unverified_category=True flag in the result and an audit_trace entry of category_match: "default_allow" so downstream consumers can distinguish known-eligible from default-allowed.

​

What this means for you

​

QWED-Infra — ecosystem policy framework adopted

qwed-infra now ships with the shared QWED governance baseline: QWED_RULES.md, contributor guidance, PR template, CodeRabbit config, and a boundary-check workflow that is consistent with the other QWED repositories.

​

QWED-MCP — boundary-check parity with QWED-Infra

The qwed-mcp boundary-check tool now catches the same import-alias, module-alias, wildcard-import, eval/exec alias, and shell=True patterns that qwed-infra does, and fails closed when the scan root is missing.

​

What this means for you

​

QWED Open Responses v0.3.0 — version sync and dependency fix

Aligns qwed-open-responses with the rest of the QWED package versions and patches a transitive qs CVE flagged by Dependabot.

​

v5.2.0 — Structured Verification Diagnostics

Introduces the unified 3-layer DiagnosticResult model — the diagnostic contract that all QWED verification engines will conform to. This is an additive release: no existing engine return types are changed. Engine conformance is tracked in blocked issues (#129, #130, #131, #133, #134, #162, #163, #164, #190, #205).

​

New: DiagnosticResult model

• Layer 1 — Agent-Safe: agent_message: str — agent/model-facing summary, no internals leaked
• Layer 2 — Developer: developer_fields: dict — structured evidence (constraint_id, advisory_checks, methods_used, evidence)
• Layer 3 — Proof: proof_ref: Optional[str] — sha256 hash of retained proof artifact; the authority bit

​

Key design

• Tri-state status — VERIFIED / UNVERIFIABLE / BLOCKED only. No HEURISTIC or AMBIGUOUS proliferation; richer distinctions live in developer_fields.constraint_id
• proof_ref is the authority bit — present = admissible for control flow, None = reject. No separate authoritative boolean needed (resolves #190 design debate)
• VERIFIED requires proof — structurally enforced in __post_init__; “VERIFIED without proof” is impossible to construct
• Frozen dataclasses — DiagnosticResult and AdvisoryCheck are frozen=True; post-construction mutation blocked
• Advisory checks never influence verdicts — AdvisoryCheck.advisory_only=True enforced via __post_init__
• compute_proof_ref() — deterministic sha256 hashing of JSON-serialized evidence
• from_legacy_dict() — migration helper for ad-hoc engine dicts (fail-closed states only; raises for legacy VERIFIED)

​

Version propagation

​

Tests

​

Compatibility

​

Included PRs

• #206 — feat(diagnostics): unified 3-layer DiagnosticResult model (#204)
• #207 — release: v5.2.0 version propagation