A photograph is not the whole story
A good food photograph cannot establish kitchen quality. A profit chart alone likewise cannot establish software version, costs or execution. We build an evidence table: claim, supplied artifact, limitation and next question. The conclusion may be insufficient information, which is more useful than unsupported confidence. We are not searching for a magical robot name or inferring certain future profitability from an image. Conclusions must be limited to what the available evidence actually supports.
Claim • evidence • limitation • question
Three defensible statuses
Label items claimed, checked or unknown. A seller describing out-of-sample validation but providing only a screenshot has not established the selection method. A ninety-out-of-one-hundred score cannot replace limitations. Missing evidence alone is not proof of fraud; it restricts conclusions. Keep the distinction between the seller said this and we checked this artifact. Every status should point to identified evidence or a specific missing piece, rather than a general impression of trustworthiness.
Claimed / checked / unknown
A reviewable evidence pack
Request exact build, configuration, symbol and broker, data period, cost assumptions and complete report. Sample size, drawdown path and error logs matter. Ask how settings were selected and when data was held aside. Evidence need not all be public; remove sensitive information and use a private channel. A one-page summary starts a conversation but cannot replace full records. If the reported build differs from the delivered build, that discrepancy must be resolved explicitly.
Build + data + settings + costs Complete report + journal
Usage rights and security
Possessing source code does not establish ownership or resale permission. Clarify licensing, installation and account restrictions, and support terms. Reviewing an EA does not require a master account password, wallet recovery phrase or withdrawal key. Do not test unknown software on a live account; use an isolated environment. A large following or professional website cannot substitute for usage rights and technical evidence. Share only information actually needed for the specific review.
Source ≠ ownership or resale rights No passwords or recovery phrases
Two packs, different limitations
Pack one has a profit screenshot and settings, but unknown version and costs. The conclusion is insufficient evidence, not certain profit or proven fraud. Pack two adds a full report, build, settings, separate evaluation and demo logs. It enables more meaningful review without guaranteeing future outcomes. File count alone cannot establish quality; the evidence must address the actual claim. For both packs, state the next question and identify which decision remains unsupported.
Sparse evidence: limited conclusions Fuller evidence: better review, not certainty
Write criteria before payment
Before purchasing, define required information and conditions that would postpone the decision. Resolve unknown builds, unclear costs and ambiguous usage rights. Payment methods alone are not technical evidence. Even a responsive seller cannot eliminate market uncertainty. Separate service scope, deliverables and support from the return a customer hopes to achieve. Do not rewrite purchasing criteria because an advertisement is exciting. Establish evidence first and decide within its limitations.
Criteria before payment Defined service ≠ guaranteed returns
Foundation capstone
Write ten evidence rows for an imaginary EA or one you own. Include claim, artifact, status and next question. Retain one unknown and specify evidence that would resolve it. A good review acknowledges its limitations. These seven lessons aimed to improve questions and testing. The first paid workshop turns that approach into a behavior specification and acceptance tests before coding. Completing the evidence worksheet is more useful than collecting attractive profit screenshots without their assumptions.
10 evidence rows One unknown + a resolution plan
