Home / Changelog

Changelog

The dated, inspectable
history of the grade.

Every Veriqa report carries the engine version and the schema version it was graded under. This page is the public, dated history of those changes — so an audit on a brief shipped six months ago can be reproduced against the rules that fired, not against whatever ships today.

How the grading works Methodology integrity
Latest release · pinned

What every report shipped today is graded under.

If a report's footer cites these two versions, the rules that fired are the ones described below. Any earlier version is preserved in the timeline — never silently superseded.

Current versions · 2026-06-08

  • Rules engine — v0.5.0 · deterministic, feature-driven, claim-discipline gate enforced in api/app/analysis.py
  • Report JSON Schema — v1.0.0 · data/report_schema.json · the output contract shared by the API, the SPA, and the static demo
  • Platform — single-domain, SPA at /app, API at /api, marketing built by web/build.mjs
  • Status — live in production · reports issued today cite these exact versions in their footer

Engine and schema versions on a Veriqa report are the version of the rules that fired and the version of the output contract that was emitted, respectively. A change to either is logged on this page with a date, a one-line summary, and a bulleted note of what moved.

01 · Methodology version pinning

The verdict is pinned to the rules that produced it.

A Veriqa verdict is a function of two things: the input, and the rules. If the rules move, the verdict is not retroactively rewritten — the report is preserved, and a re-check against today's rules is a separate, dated artifact. This is what lets a brief stay reproducible after the engine evolves.

Every report cites the engine and schema it was graded under. Open any Veriqa report and the footer states the rules-engine version, the JSON Schema version, and the date the verdict was issued. Those three values are what tie the grade to a specific row on this page.

Reports are immutable post-reviewer-approval. Once the software-enforced reviewer gate logs an approval, the artifact is frozen — its scores, its evidence table, its verdict, and the version stamps that produced them. A later engine version cannot rewrite an approved report; it can only produce a new one.

The audit trail ties the verdict to those exact versions. Re-checking a brief six months later means running it again against today's engine and comparing the two reports side by side — same input, different rules, dated outputs. The original verdict is still defensible against the rules it was graded under, which is the point.

The full method behind the grade lives on science.html; the integrity statement on how versions, approvals and logs hang together lives on trust.html.

What every report carries

  • Engine version — the rules that fired
  • Schema version — the output contract emitted
  • Issue date — when the verdict was logged
  • Reviewer approval — logged against that exact version
  • Re-check — produces a new, dated report; does not overwrite
02 · Releases

The timeline, oldest to newest.

Each entry is a dated change to the rules engine, the JSON Schema, the platform, the documented methodology, or the security posture. Categories are visible on every entry — they are not interactive filters, they are the label set we maintain.

  1. Methodology Schema 2025-11-04 schema v0.1.0

    Initial JSON Schema — output contract drafted

    The first draft of data/report_schema.json — a strict shape for the readiness report so the API, SPA and the static demo share one contract instead of three.

    • Top-level fields fixed: subject, context, verdict, vlabel, exec, tracks, scores, ev, missing, next, engine.
    • Verdict vocabulary fixed at the wire level: go / monitor / nogo (rendered as Proceed / Monitor / Require further diligence in the UI).
    • Scores constrained to integers 0-100 across the three axes — maturity, urgency, hype.
    • Evidence rows fixed as [claim, source_id, confidence] with confidence in 0-1.
    • Drift gate stood up: TS types in packages/shared are generated from the schema and CI fails if they diverge.
  2. Rules engine 2025-12-12 engine v0.2.0

    Claim-discipline gate — first cut

    The baseline rule is written into the engine, not just the marketing site. An advantage claim without a classical baseline is flagged in code, and the verdict is gated accordingly.

    • Added ADVANTAGE_RE / BASELINE_RE regexes in analysis.py to detect the central advantage claim and whether a comparator is present.
    • Introduced the needs-baseline flag on the report and on individual evidence rows.
    • Verdict downgrade: a go verdict is invalidated to monitor while any core advantage claim is needs-baseline. Enforced in the analyzer return path.
    • Maturity score capped at 55 when needs-baseline fires — the discipline cap, written down in code rather than in copy.
  3. Methodology 2026-01-21 method note

    Evidence confidence — definition pinned

    A written definition for the 0-1 confidence value on every evidence row, so the number means the same thing across the engine, the SPA and a printed report.

    • Confidence is defined as how strongly the cited source supports that specific sub-claim — not a probability of the underlying claim being true.
    • Degrades with the source (undated whitepapers and press releases score lower than peer-reviewed work with a method section), not with the optimism of the framing.
    • Uncitable factual claims are marked unverified and cannot raise the verdict — absence of evidence is recorded as absence.
    • Definition published on science.html § Evidence & confidence.
  4. Platform Methodology 2026-02-09 platform

    Reviewer gate — software-enforced

    Every customer-facing report is held in draft until an internal reviewer approves it; the gate is enforced in software, not by goodwill. The marketing site banner makes the gate visible to readers of the public demo.

    • Backend: a report cannot be released around the reviewer gate — the workflow is enforced on the API side.
    • SPA: the verdict surface holds the report in draft until an approval is logged against the exact engine + schema version that produced it.
    • Marketing site: "Advisor review required" banner added in web/js/main.js on every demo report so the gate is visible on public surfaces too.
    • Explicitly not claimed: we do not represent that an outside expert reviews every report yet. The current gate is internal.
  5. Rules engine 2026-02-24 engine v0.3.0

    PQC analyzer — separate vertical, same discipline

    A dedicated PQC analyzer in api/app/pqc.py: cryptographic inventories are graded against the finalised NIST standards, then prioritised by exposure and data shelf life — not by vendor enthusiasm.

    • Mapping fixed to FIPS 203 (ML-KEM, key establishment), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, signatures).
    • Asset model added: system, role, current, target, status, phase, rationale, optional shelf_life_years and deadline.
    • Phase buckets — P1 (next 12 months), P2 (12-36 months), P3 (36+ months) — prioritised by shelf life and harvest-now exposure.
    • Schema extended with the optional pqc_plan block and an agent discriminator (readiness / pqc) — see schema v0.4.0 below.
  6. Schema 2026-02-26 schema v0.4.0

    Schema additions for the PQC plan

    The output contract grows to carry a PQC plan when an asset inventory is in scope, without disturbing the existing readiness-report shape.

    • Added optional agent field with enum readiness | pqc (defaults to readiness) — routes UI rendering.
    • Added optional pqc_plan object with assets[] and phases{P1,P2,P3}.
    • Constrained enums: asset role ∈ {key_exchange, signature, encryption, hash, other}; status ∈ {ok, needs-migration, broken}; phase ∈ {P1, P2, P3, none}.
    • Backwards compatible — existing readiness reports validate unchanged.
  7. Rules engine 2026-03-18 engine v0.4.0

    Feature-driven rewrite of the analyzer — same-number bug fixed

    Internal task #53. The earlier analyzer leaned too hard on keyword presence, which produced near-identical scores for very different inputs — the so-called "same-number bug". Rewritten as a feature-driven function of evidence density, hedge/superlative balance, named-entity hits, dated specifics and the baseline gate.

    • Each score is now a deterministic function of counted text features, not a flat keyword toggle.
    • New feature lexicons: HYPE, SPECULATION, EVIDENCE, HEDGE, URGENCY — each with stated weights in analysis.py.
    • Named-entity and known-org detection: a benchmark with a named institution attached carries weight a bare keyword does not.
    • Quantitative-claim and dated-year detection: superlatives without numbers push hype up; specifics with dates push maturity up.
    • Distinct inputs now produce distinct, defensible scores. The evidence table reflects what was actually detected in the material — not a fixed template.
    • Discipline cap preserved: needs-baseline still caps maturity and still blocks a Proceed verdict in code.
  8. Schema 2026-04-09 schema v1.0.0

    Schema v1.0 — output contract frozen

    The schema is promoted to v1.0 after a quarter of use in production. Every field is documented, the verdict vocabulary is locked, and the CI drift check between schema and generated TS types is required to pass on every merge.

    • All required top-level fields enumerated; descriptions added to every property.
    • Verdict vocabulary locked at the wire level (go / monitor / nogo) — the public-facing labels (Proceed / Monitor / Require further diligence) are rendered in the UI from those values.
    • Evidence-row tuple [claim, source_id, confidence] formally constrained: minItems/maxItems=3, confidence in 0-1.
    • Claim-discipline rules attached at the schema root in a non-validating claim_discipline block — documented, not silently enforced by validation alone.
    • Forward changes will be additive minor versions unless explicitly noted; any breaking change is a new major version and a separate entry on this page.
  9. Security Platform 2026-05-15 platform

    HTTP security headers + self-XSS sink escape

    Hardening pass across the static site and the SPA shell: HTTP security headers added at the edge, and a self-XSS sink in the demo's report-render path escaped at the boundary.

    • Added Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security and Permissions-Policy at the edge for the marketing site and the SPA.
    • Escaped a self-XSS sink in the demo report renderer — user-supplied subject and material strings are now HTML-escaped before insertion.
    • CORS posture re-checked: production ALLOWED_ORIGINS is an explicit allowlist, dev default remains permissive.
    • No change to the rules engine or the schema.
  10. Platform 2026-06-08 engine v0.5.0 · schema v1.0.0

    Information-architecture fix — dedicated pages, no front-page anchors

    Today's deploy. The marketing site is restructured so each major topic — Science & Methodology, Insights, FAQ, Company, Changelog, Trust — has a dedicated, deep-linkable page rather than a front-page anchor. Engine and schema versions stamped on reports issued today are the ones at the top of this page.

    • Front-page anchors retired in favour of dedicated pages; deep links into specific sections are stable.
    • This Changelog page added — the dated, inspectable history that was previously only readable in the git log.
    • Reviewer-gate language audited across surfaces: the gate is software-enforced; we do not represent that an outside expert reviews every report.
    • Engine v0.5.0 is a maintenance bump — no scoring-rule changes since v0.4.0, only logging and the version-stamp wiring that backs this page.
What a release on this page is, and is not. A release here is a dated change to one of five things — the rules engine, the JSON Schema, the platform, the documented methodology, or the security posture. It is not a marketing announcement, and not every internal commit gets an entry. If a change moves what a report says, what it carries, or how it is gated, it is here.
03 · Subscribe & download

The feed, and the schema, on request.

We do not run an email list or a capture form for the changelog. The two ways to track changes are: read this page on a cadence that suits you, or request the schema and its history directly.

RSS. Insights are published with an RSS feed at /insights/feed.xml. Changelog entries are not currently fanned out to a separate feed — they live on this page, dated, and the page itself is the source of truth.

Schema, on request. The current JSON Schema and the previous N versions are available on request — email hello@quantum-nexus.dev and we will send the relevant files and, if it is useful, a diff between the versions you care about.

Why on request, and not a download link. The schema is the output contract for a live product; we would rather hand it over with a note on which engine version it pairs with than publish a file that drifts from the running system. If that ever changes, it will be a dated entry on this page.

On request, by email

  • Current JSON Schema — v1.0.0
  • Previous versions — back through v0.1.0
  • Diff — between any two versions, on request
  • Engine pairing — which engine version emits that schema
  • Contact — hello@quantum-nexus.dev
04 · How to read this page

Match the report footer to a dated row.

If you are re-checking a brief weeks or months after it was issued, the two numbers in the footer — engine version and schema version — are how you find the rules that produced the verdict you have in hand.

  1. Read the engine and schema versions on the report

    Every Veriqa report carries the engine version and the schema version in its footer alongside the issue date. Those three values are the report's coordinates on this page.

  2. Find the matching entries above

    Scan the timeline for the engine version and the schema version cited. The rules that fired on your report are the ones described in those two entries — earlier history is context, not what produced your verdict.

  3. Compare against today, if you need to

    The latest release card at the top of this page is what a new report on the same input would be graded under today. A re-check produces a new, dated report — it does not overwrite the original. Both are defensible against the rules they were graded under.

  4. If anything does not match, ask

    If a version on a report is not represented on this page, that is a bug and we want to know. Email hello@quantum-nexus.dev with the report's engine + schema versions and we will reconcile it.

Public verdict vocabulary is Proceed / Monitor / Require further diligence. The scoring engine is a transparent rule-based heuristic over text features — it is not a sentiment score and not a statistically validated model. The reviewer gate is software-enforced; we do not represent that an independent outside expert reviews every report. See trust.html § methodology integrity and science.html for the full method.

Want the method behind the version numbers?

Every entry on this page changes something the method makes a specific claim about. The method itself — the baseline gate, the three scores, the evidence table, the reviewer gate — is written up in full on the science page.

Read the methodology Request the schema