Direct answerSeparate claims by scope. Product proof says a defined capability worked under defined conditions. Release readiness says the packaged product survives the installation, update, compatibility, lifecycle, security and support conditions expected of real users. Never let one claim silently stand in for the other.

Why AI product claims blur together

AI systems make it unusually easy to demonstrate something impressive before the surrounding product is mature. A model can reason correctly, a tool can execute and an end-to-end test can succeed while packaging, recovery, permissions or installation remain unfinished.

The mistake is not having an early proof. The mistake is marketing the proof as a broader readiness claim than the evidence supports.

Four useful claim levels

Capability proof: one defined capability worked.

Integration proof: multiple components completed a defined end-to-end workflow.

Production candidate: a frozen implementation has passed an agreed engineering gate and is stable enough for controlled production-oriented evaluation.

Public release readiness: the product has passed the broader gates needed for distribution to intended users.

These levels can overlap, but they should not be collapsed.

A public release needs more than a green core

Depending on the product, release gates may include:

  • clean installation on representative machines;
  • first-run behaviour;
  • upgrade and rollback;
  • restart and reconnect;
  • permission prompts and denial paths;
  • packaging and signing;
  • uninstall or cleanup;
  • fresh-profile behaviour;
  • hardware and OS compatibility;
  • documentation and known limitations.

These are product concerns, not merely model concerns.

Historical proof can stay valid without becoming current release proof

Evidence does not become worthless because it is old. A retained end-to-end test can still prove that an architecture worked under the recorded conditions.

But a historical test should not be described as a fresh release gate. Dependencies, packaging, operating systems and product code may have changed.

Use status words with explicit meaning

Terms such as prototype, alpha, beta, production candidate and release should be attached to documented gates rather than used as decoration.

A useful status line answers three questions:

  1. what exactly is being labelled;
  2. which evidence earned the label;
  3. which important gates are still open.

Example: current ARKTOR boundaries

ARKTOR Controller V0.3 is an accepted frozen Production Candidate at 96/96 Rust tests PASS, with additional held-out, recovery and full-stack evidence.

ARKTOR Android 0.8.7 / versionCode 22 is a physically validated Product Workbench / advanced prototype on a Huawei P30 Pro. It is not presented as a general public release.

ARKTOR Go / Link retains historical end-to-end proof, while the fresh clean-Windows one-click release gate remains NEEDS VERIFY. Stable authenticated Sovereign Internet command/result E2E remains open.

The rule: retain the strongest proof you have, but attach it to the exact scope it actually proves.

A practical release-claim checklist

  • Is this claim about a component, workflow or distributable product?
  • Was the tested build frozen?
  • Were the tests performed on the same version being described?
  • Is the evidence physical, simulated or historical?
  • Have installation and lifecycle paths been tested?
  • Are open release gates visible?
  • Could a reasonable reader interpret the wording more broadly than the evidence?

The useful principle

Good engineering communication does not weaken a product by exposing open gates. It makes the claims durable because each statement can be traced back to evidence with the same scope.