Read the evidence label, not the tone
If a page does not identify a tested version and test conditions, readers should not assume that every claim was verified hands-on. Older pages are being brought into this evidence model as they are reviewed.
Evidence classifications
| Label | Meaning | Minimum evidence |
|---|---|---|
| Hands-on verified | We performed the stated workflow. | Version, environment, date, steps, expected and observed result. |
| Documentation verified | A primary source supports the claim; no hands-on test is implied. | Source URL or document, edition/version, and check date. |
| Calculated estimate | A transparent formula derives the value. | Inputs, units, formula, assumptions, and source dates. |
| Editorial assessment | A judgement based on published criteria. | Rubric, evaluator, evidence used, and material conflicts disclosed. |
| Not verified | Evidence is absent, inaccessible, or contradictory. | The limitation remains visible; no positive inference is made. |
Reproducible software test record
A hands-on software claim should be accompanied by enough information for another evaluator to repeat it:
- Product name, version or build number, and test date.
- Licence or subscription tier and any enabled feature flags.
- Operating system, browser, runtime, PLC family, and relevant hardware.
- Project file, program listing, or exact configuration where sharing is permitted.
- Ordered steps, expected outcome, observed outcome, and pass/fail rule.
- Screenshots or logs that show the relevant state, not decorative images.
- Known limitations, failed attempts, and deviations from the published procedure.
Tutorial validation
A tutorial marked as tested should begin from a documented starting state and end with a verifiable result. Installation tutorials include the installer source, prerequisites, version, permissions, and an uninstall or recovery note where relevant. Programming tutorials include one complete program, defined inputs, expected scan behaviour, and at least one edge case.
Vendor user interfaces change. Screenshots are dated or versioned when a reader could otherwise follow an obsolete menu path.
Comparisons and scores
- The comparison declares its intended user and task before products are scored.
- Criteria, weights, pass rules, and test cases are published before the conclusion.
- Products are tested on comparable tiers and configurations, or the mismatch is disclosed.
- Editorial scores are not emitted as customer AggregateRating data.
- A commercial relationship does not change a test case, weight, or evidence requirement.
Prices, limits, and compatibility
Prices and free allowances are checked against the vendor's current public offer and recorded with currency, billing interval, tax treatment, region, tier, and check date. Supported instructions and dialect claims are verified against the exact version tested. A marketing total is not substituted for a counted inventory.
Safety and boundaries
A browser simulation or bench test cannot validate machine safety, electrical installation, stopping performance, network resilience, or regulatory compliance in the field. Examples are educational and require independent review before use on physical equipment.
Public simulator benchmark protocol
The PLC Simulator Benchmark 2026 protocol publishes the planned test cases and data schema. It currently publishes no rankings or test results; those will not be inferred from an incomplete run.