Statement 001 Trinity Integrity
Published: 2026-08-08 · Covers: v0.5.56, v0.5.57, v0.5.58 · Status: Current
Three releases in three days. This statement covers all of them — including two defects that live testing found after the first one shipped, and one that our own catalogue check found in production.
A validation result should never look more complete than it actually is.
VerifiMind runs three independent AI seats over a concept — X for opportunity, Z for ethics, CS for security — and synthesises a verdict. The failure mode that matters is not a crash. It is a result that looks finished when one of the three seats did not really work. That produces a confident number nobody should trust, and it is worse than an error, because an error is visible.
These three releases exist to make that impossible.
If any Trinity stage returns anything other than real inference, that stage can no longer contribute a score, a confidence value, a verdict, or a derived count. You get an explicitly incomplete result marked for human review, with the failing stage named and its generated fields withheld. A trusted ethics veto still takes precedence.
Security. A time-of-check/time-of-use DNS-rebinding weakness in the template URL-fetch paths was closed: addresses are resolved once and only validated public addresses are dialled, while the original hostname is preserved for TLS certificate verification.
Terms v2.3 and Privacy Policy v2.4, rendered from a single canonical source so the browser page and the API response cannot drift apart. They state where data is actually stored, name the AI providers that process validation prompts, describe cross-border processing, and give a private email channel for access, correction and deletion requests. There is a Bahasa Malaysia section.
The day v0.5.56 shipped, testing against production surfaced two real defects. We report them here rather than quietly fixing them, because a release about not overstating completeness cannot open by overstating its own.
It could state "no major ethical or legal concerns" while simultaneously listing an ethical concern it had received. The underlying analysis was correct; the summary line was not.
Investigating it found something the original report could not have seen: the same fault existed on the security side too, where a high security score produced "no significant security risks identified" while a vulnerability was listed directly beneath it. The cause in both cases was the same — a numeric score threshold rendered as an absolute claim of absence.
When a hosted AI provider rate-limited us or returned a truncated response, the whole run failed with a generic error and an unhelpful hint — discarding two stages that had completed successfully alongside the one that failed.
Production logs identified both causes precisely: one token-rate rejection, and one truncation that our own v0.5.56 guard correctly refused to parse as a complete stage. The refusal was right. The way we reported it was not.
Neither defect caused an incorrect validation to be presented as correct.
- Deletion requests no longer fail silently. Storage failures now return a structured, non-enumerating, retryable HTTP 503. A failed operation is never reported as successful.
- Opt-in validation history is bounded — at most the 20 newest results, oldest evicted on every read and write, written atomically, with persistence reported truthfully.
- One source for legal text — duplicate policy copies removed.
- Terms v2.4 and Privacy Policy v2.5, English and Bahasa Malaysia, describing the retention contract in the same words the code enforces.
- A provider failure no longer destroys the whole validation. The affected stage degrades and is named — with its provider and model — while the stages that succeeded are preserved. The result is explicitly incomplete; it can never present as complete.
- Typed failure reporting — rate limit, truncation, timeout and authentication failures each carry an accurate retryable flag and a recovery hint specific to the actual failure, replacing a generic message that suggested changing a setting the caller had never used.
- The summary can no longer contradict its own analysis — fixed on the ethics surface and the security surface.
- Incomplete runs are never written to shared history.
- Provider logs are sanitized — failure events carry an exception type, never a response body, key, or provider account metadata.
- Model catalogue currency across all six BYOK providers: a retired-model gate and a 90-day verification ceiling. This fixed a live defect where our Cerebras default pointed at a decommissioned model and failed for anyone who selected it.
| Release | Internal review | Independent security review | Post-deploy smoke |
|---|---|---|---|
| v0.5.56 | 2 seats, multiple rounds | 2 runs — different model family and platform | 24 passed / 0 failed |
| v0.5.57 | 2 seats | 1 run — with a parent-commit differential | 25 passed / 0 failed |
| v0.5.58 | 2 seats | 1 run — fault injection incl. simultaneous all-stage failure | 31 passed / 0 failed |
Independent reviews were run on a different model family, on a different platform, from a clean checkout of the exact commit, with the reviewer required to prove its own checkout before its verdict was accepted.
The verification detail we think matters most (click to expand)
For v0.5.57, the independent reviewer ran the new regression tests against the previous commit and confirmed 16 of them fail there. That is the difference between a test suite that passes and a test suite that would have noticed. We reproduced that result independently, test by test.
Read the other way, those 16 failures are an itemised list of what was actually wrong before: history that was never capped, a crash on a malformed history file, storage exceptions escaping as generic errors, and a duplicate policy copy that could drift.
For v0.5.58, the independent reviewer injected typed failures — rate limit, truncation, authentication, and all three stages failing at once — and confirmed that even a total failure produces a withheld, explicitly incomplete result rather than a confident empty verdict. That all-stage case was the one our internal review had not tested.
During the post-deploy smoke for v0.5.58 — minutes after it went live — a real, unplanned provider failure occurred.
One stage failed. The other two returned genuine analysis. The run degraded the failed stage, named it, withheld its fields, and marked the result incomplete.
Under the previous release, that same event would have returned a bare error and discarded two stages of successful work.
We did not plan this test. It is the strongest evidence in this statement precisely because we did not.
- The coordination tools remain disabled. That incident is contained, not closed — see Standing disclosures. Statutory notification questions are with qualified counsel on a separate track.
- Model diversity. Our three-seat design assumes three independent perspectives. We found that two of the three seats were running the same model, which weakens that premise. We have measured a configuration of three seats across three providers and three model families, and are validating it before it ships. The rate-limit failure above is what exposed this.
- No legal certification. Nothing in these releases or this statement is a legal determination or a claim of regulatory compliance.
All 8 active tools remain free for every tier. The core is MIT licensed and you can self-host at any time.
Each release is bound to an exact commit and build, and each GitHub Release tag resolves to the deployed commit:
| Release | Merge commit | Deployed |
|---|---|---|
| v0.5.56 | 40a48924 |
2026-08-05 |
| v0.5.57 | 6faadef5 |
2026-08-06 |
| v0.5.58 | 3019f5c4 |
2026-08-07 |
Full technical detail: CHANGELOG.md · Live status: /health · Terms · Privacy
Corrections to this statement will be published as dated addenda below, never as silent edits.