What “unknown” should mean in a trading checklist

In a trading checklist, unknown should mean that a relevant question cannot be answered from the available evidence. It is not a failed check, a passed check, or permission to ignore the item. The useful response is to preserve the reason, keep the uncertainty visible, and apply the rule your process defined for missing information.

A four-state checklist separates passed, failed, unknown, and not applicable. That extra precision prevents a missing value from quietly becoming a favourable result.

Why yes or no is sometimes the wrong question

Suppose a newly listed stock has 80 completed daily bars. Your review includes price relative to the 200-day simple moving average (SMA), 20-day relative volume, and 14-day average true range (ATR).

The relative-volume and ATR calculations may have enough eligible history. The 200-day average does not. “Price is above the 200-day SMA” is neither true nor false because the required average cannot yet be calculated under the stated rule.

Forcing that item into a binary result creates one of two errors:

• Calling it failed claims the comparison was made and returned false.
• Calling it passed or dropping it from view makes the checklist look more complete than the evidence allows.

The correct state is unknown: insufficient eligible history. That label describes the evidence, not the stock and not the eventual trade outcome.

The four states need separate meanings

Write the state definitions before applying the checklist. Otherwise, the same missing value can be treated differently depending on how attractive the chart looks.

The difference between unknown and not applicable is scope. An unknown item belongs in the review but lacks usable evidence. A not-applicable item does not belong in this particular review at all.

Unknown needs a reason, not a blank cell

“No data” is often too vague to be useful. The reason should identify why the check cannot be evaluated and what would have to change before it could be evaluated.

Common reasons include:

• Insufficient history. The formula needs more eligible bars or sessions than exist.
• Unavailable source. A required provider or dataset did not return a usable observation.
• Stale evidence. A value exists, but it is older than the checklist permits.
• Invalid denominator. A ratio cannot be calculated because its defined baseline is zero or otherwise invalid.
• Conflicting evidence. Current sources disagree and the checklist has no approved resolution rule.
• Unverified event data. An earnings date or event time cannot be established from a suitable current source.
• Incomplete or ineligible input. The required bar has not finalized, belongs to the wrong session, or does not meet the rule’s coverage requirements.

These causes should not be collapsed into zero. Zero is a value. Unknown means the value or comparison is not trustworthy enough to state.

Technical platforms also encounter this distinction in ordinary calculations. TradingView’s Pine Script documentation, for example, shows that a 20-bar calculation returns na, or not available, on the first 19 bars because the required history does not yet exist. Replacing that absence with zero would change the meaning of the calculation.

A worked checklist with one unknown

The following example is hypothetical. It shows how to preserve evidence states; it is not a historical result, a trade recommendation, or a HeraldGoat product result.

A stock has 80 eligible completed daily sessions. At Friday’s close, a review applies four pre-defined items:

A transparent summary is:

Applicable checks: 3
Passed: 2
Failed: 0
Unknown: 1
Not applicable: 1

Do not rewrite this as “two of two passed.” That denominator silently removes the unknown applicable check. “Two of three applicable checks passed; one remains unknown” keeps the missing evidence visible, but even that is a factual summary rather than a score or success probability.

The unknown 200-day average does not cancel the correctly observed breakout. It also does not support it. What happens next depends on the rule defined before the review. One process may stop when a required item is unknown. Another may permit manual verification. A third may treat the 200-day comparison as optional context. The checklist should report the evidence state; the strategy should define the consequence.

Define the consequence separately from the state

Evidence and action are different layers. “Unknown” describes what can be established. It should not secretly encode “skip,” “continue,” or “safe.”

For every item, define these fields:

1. Question. What exact condition is being evaluated?
2. Evidence requirement. Which data, session, lookback, source status, freshness, and finality are required?
3. State rule. What produces passed, failed, unknown, or not applicable?
4. Unknown reason. Which reason should appear when evidence is unusable?
5. Process consequence. Is the item required, optional context, a caution, or a blocker under the written setup?
6. Recheck rule. Can later data resolve the state, and when should the item be evaluated again?

This separation matters. A required condition can be unknown without being failed, while the process can still choose to stop because the required evidence is missing. The stop comes from the process rule, not from pretending the comparison returned false.

Do not confuse unknown with pending

Timing creates another common ambiguity. At noon, a rule based on the finalized daily close has not reached its evaluation point. The closing value is not missing; it does not exist yet.

If the interface tracks work in progress, pending or not yet evaluated is a useful workflow label. Once the scheduled evaluation time arrives, an unavailable finalized close may become unknown. Calling an in-progress check failed makes the same mistake as treating a live bar as final.

For a checklist that stores only completed evaluations, include the evaluation timestamp and omit the item until its scheduled time. For a live checklist, show pending separately from the four completed evidence states.

Common ways unknown disappears

The denominator shrinks silently. A five-item review becomes “four of four passed” when the fifth item has no data. Report applicable, unknown, and not-applicable counts separately.

A missing value becomes zero. This can turn an undefined ratio into an apparently low reading or make an unavailable distance look exact. Zero must come from valid data and a valid calculation.

A provider error becomes a market fact. Failure to retrieve an earnings date is not evidence that no earnings event is near. The retrieval result and the market claim are different things.

Not applicable becomes a convenient escape. An item should be outside scope because of a rule defined before the chart was reviewed, not because its result is inconvenient.

The reason is discarded. “Unknown” without “insufficient history,” “stale quote,” or another explicit cause cannot be audited or rechecked efficiently.

Later data overwrites the original record. If a missing value becomes available, preserve what was known at the first evaluation and record the later resolution with its own time. Otherwise, a historical review can falsely appear to have used information that arrived later.

Where HeraldGoat fits

Checking one missing value manually is manageable. Repeating the same evidence review across a watchlist makes source status, freshness, finality, and explicit unknown reasons more important.

HeraldGoat is pre-launch. It is being built to place required conditions, blockers, cautions, unknowns, freshness, and finality in an inspectable context card, then leave the trading decision with the user. When a required or relevant fact cannot be verified, the intended behaviour is to show the unknown and its reason rather than invent a value or imply that nothing is wrong.

The four-state table in this guide is an editorial framework for designing a manual trading checklist. It is not a claim that HeraldGoat currently exposes a four-state checklist feature.

Continue building a clearer review process

• Understand what a 200-day moving average requires
• Use the breakout checklist without turning context into a verdict
• See why a passed checklist is not confirmation
• See why an unverified earnings date should remain unknown
• Browse all practical trading guides

If inspectable first-pass context would help you review a watchlist, you can join the launch waitlist. Joining does not imply immediate product access.

Sources

• TradingView Pine Script execution model: shows how a history-dependent calculation remains not available until the required number of bars exists and explains historical-buffer requirements.
• TradingView Pine Script type system: defines na as the special not-available value used when a usable result does not exist.

Method note: passed, failed, unknown, and not applicable are HeraldGoat’s editorial state definitions for this guide. The worked example is hypothetical, and the framework does not estimate outcome probability.

This guide is for educational information only. It is not investment advice, a recommendation, or a promise of trading results. Trading and investing involve risk, including the possible loss of capital.