The ParitLAB software catalogue includes released products and work that remains experimental. Calling everything “ready” would hide the difference between an idea, a testable build and a completed release process. We use Experiment, Testing, Stable and Archived as evidence levels rather than rankings.
Experiment: validating the problem and approach
An experiment may include a prototype, screenshots or partial code, but it should not promise a download or sale date. The goal is to state a hypothesis and decision criteria clearly enough to know whether the work should continue.
Testing: something exists, but evidence is incomplete
Testing indicates a build or system that can be checked in some conditions. Risk Co-Pilot MT5, for example, compiles and its shared calculations pass fixtures, but broker execution and forward testing remain pending. It is described as a demo hedging preview, not a live-account product. Compilation proves that code can be built; it does not prove market behaviour.
Stable: ready within the stated scope
Stable does not mean bug-free. It means the advertised scope has completed a release process and has a support path. Current product records place TADEE 1.2.7, KADEE 1.1.0, Suadmon Duaykan 1.0.0 and PZE 2.4 in this group. Their limits still differ: the first chanting release has no audio and only part of the library has Thai translations.
Archived: preserve evidence without encouraging new use
Work that has stopped or been replaced can still provide useful history. Archiving instead of immediate deletion preserves changelogs, lessons and old licence relationships while allowing the interface to point to a replacement.
Version and status answer different questions
A version identifies a build. A status describes its readiness. A newer preview number can carry less production evidence than an older stable release. Showing both values helps readers make the distinction.
Minimum evidence for a product page
- The problem and intended audience.
- What the current version demonstrably does.
- The environment or method used to test it.
- Observed results and remaining limits.
- Sale, download and trial availability.
- A date or changelog that shows whether information is current.
Why direct status language improves the product
Stating limits reduces mistaken expectations and improves feedback. Testers know what to examine, customers know what they receive, and developers know what evidence remains missing. Status is therefore part of risk communication rather than decoration on a product card.