Missing input is not an evaluated false condition

Real input does not make every displayed result real

The historical conversation distinguishes a screen reading source prices from fixed demonstration results. The user later requested virtual calculations that continue from incoming observations instead of a fixed demo. I did not present that transition as current investment performance; I read the functions that derive decisions and the values returned when required observations are missing.

When I first wrote this article and its synthetic module, I ran neither the original app nor a market connection. Earlier quote reception, virtual fills and test results were read as historical records. The subsequent pure-engine repair and synthetic reproduction are recorded separately below. The program’s orders and ledgers are virtual calculations, not outcomes in an actual account. The question is what the software had evidence to evaluate, rather than which strategy performs best.

Hold a strategy before inventing its required inputs

The selected entry function immediately returns HOLD with dataSupported false for particular strategy families, including a reason naming the missing observation class. A snapshot price does not imply the presence of finer-grained execution observations or validated event material. This branch makes the available integration scope explicit in code rather than filling the gap with invented signals.

In the current source that support scope is established by strategy-specific branches. Adding a few fields to an input object does not automatically enable an unsupported strategy. A new connection would need its data meaning, timing and consumer path checked together. This content task added no such connection and changed no strategy.

The same hold can mean observed false or still unknown

Normal rules retain met and available separately. That can distinguish a comparison that was performed and returned false from a comparison that could not be performed because an input was absent. Both may lead to HOLD, but the next useful operation differs: wait for a condition or connect the missing material.

The decision record retains its reason, rule evidence, source observation time and decision time. In particular, dataSupported false preserves the prior last-evaluated timestamp. I read this as a choice not to count an unsupported attempt on the same clock as a supported evaluation. It is a static source finding, not a new measurement of waiting time or reproduction of the original runtime.

Keep optional observations outside the required population

Some recent observations may not yet have accumulated. The original function excludes specifically named auxiliary rules from its required-condition calculation. The full rule count is consequently different from the required population. Explaining a fulfilled count requires also reading the policy that permits an auxiliary rule's initial state.

The independent example expresses this through a required field rather than a special identifier. An unavailable optional observation does not block prepared required inputs, while remaining visible in its own list. This neither judges the original policy incorrect nor clones it. It makes the intent explicit for another program with potentially different rule identities and requirements.

One waiting label cannot explain the next step

The selected rule-row component labels met conditions fulfilled and the others waiting. Its surrounding adapter separately reads dataSupported and distinguishes unsupported data, market state and risk-limit reasons. A short row label must therefore be read alongside the page's broader status explanation. I changed no original screen and performed no rendered-display inspection here.

The new summary returns missing inputs, evaluated but unmet conditions, or all required conditions met. Missing input has headline priority while already known false conditions remain recorded. Explaining that distinction gives a user a useful next question: is the feature broken, or does its input still need to be prepared? It does not hide every unavailable observation behind a generic waiting state.

Keep the simulation’s evidence separate from the shared example

For the first publication, I reviewed the existing material-state module, but it concerns content confirmation and preview or publication readiness. This question requires a separate availability and true-or-false result for each rule, so I wrote a small new module. An unavailable condition must be unknown; an available one must be boolean. Contradictory input is rejected, and a matched summary still executes no action.

The first publication ran twenty-two independent synthetic tests in the source directory and after ZIP extraction, saving five example records. That count was not borrowed from historical native tests or successful quote reception, and it is separate from the subsequent native repair below. The shared module organizes data and decision states; the summary module itself is not a modified native engine.

{
  "state": "inputs_missing",
  "required_total": 1,
  "available_required": 0,
  "met_required": 0,
  "missing_required": [
    "observation"
  ],
  "unmet_required": [],
  "missing_optional": [],
  "evaluation_ready": false,
  "all_required_conditions_met": false,
  "executes_action": false,
  "authenticates_evidence": false
}

A later repair found the missing value becoming zero upstream

Separate availability and condition fields were not sufficient by themselves. If an earlier interpreter turns an absent value into zero, the rule downstream believes an observation exists. In a later local development task, synthetic snapshots reproduced this in the actual pure engine: a required long-term average set to null still produced an available and met rule, followed by one virtual purchase.

A missing percentage exposed another consequence. With a synthetic current price of 100 and a change of 2, the existing calculation can derive a percentage when the supplied percentage is absent. Instead, null became zero first, hiding that derivation and evaluating the increase rule as a known zero. The same interpretation defect enabled an unsupported entry in one case and prevented a supported calculation in another.

This was a memory-only execution of selected original functions with synthetic inputs, not a trade based on newly fetched market data. I added it as a follow-up to the earlier state explanation. Naming a field available does not establish the observation; the interpreter that produces that flag must be checked as well.

Preserve a real zero without inventing one for missing data

The first follow-up repaired the interpreter inside the engine to accept only finite numbers or nonempty numeric strings. Null, missing values, blank text, booleans, arrays and objects remain null. An actual numeric zero or the string zero remains zero. Both sides matter: absence must not manufacture a zero, and an observed zero must not disappear merely because it is falsy. At this stage the tests supplied inputs directly to the engine.

An absent percentage can now reach the existing derivation using valid price and change inputs. If those inputs are also unavailable, the result remains unknown. With a required long-term average missing, the native entry rule has available:false and met:false, and its ratio evidence remains null. It holds the virtual entry for missing input instead of presenting the condition as satisfied.

I kept this input contract separate from the saved-ledger contract. Numeric text arriving as provider input may be interpreted explicitly, while saved calculation fields must already be JSON numbers under the earlier repair. Finiteness also does not establish every field’s business range. This task did not verify whether an explicitly supplied zero or negative value is meaningful for each average, volume or other provider field.

Twenty-two native tests and twenty-two example tests are different evidence

The follow-up development passed twenty-two tests: sixteen existing engine and storage regressions plus six quote-input tests. They cover wrong-type prices, missing long-term averages, percentage derivation, actual zero, compatibility with numeric provider text, input preservation and the shared helper’s effect on initial-capital parsing. The existing storage loader and ledger validator remained covered by the regression suite.

The task verified an isolated build, extracted before-and-after source archives and compared hashes for twelve files. Sixteen tests passed from the restored earlier source and twenty-two from the repaired source. It also preserved the bytes and modification times of twenty-nine protected files and the complete thirty-three-file project inventory. The build reused an existing separate dependency installation with the same lockfile; it was not a first-install test on a new computer. It replaced neither the running deployment nor real browser storage.

That editorial revision read the development records and current source without rerunning the native tests. The public rule-summary ZIP was separately downloaded, checked by bytes and hash, extracted and tested with twenty-two synthetic tests. The matching counts described different subjects: the actual engine’s input boundary and an independent summary function’s contract. They also precede the thirty native tests for the later market-input repair below.

The input had already changed before reaching the check

Rejecting a wrong type when it is passed directly into the engine leaves another question: does the real caller preserve that value until it reaches the engine? The next development task followed the market-payload normalizer, the calculation snapshot builder and the actual pure engine. The first two stages still contained numeric conversions that did not apply the engine’s type restriction.

A synthetic price of [100] became numeric 100 during payload normalization, while a price of true became 1. A true percentage, with no valid alternative change value, also became 1. Each counterexample traversed the actual original pure functions and engine and produced one in-memory virtual fill. By the time the engine saw the input it looked like a permitted number. A downstream check could not reconstruct the array or boolean that had existed earlier.

These were deliberately constructed inputs, not observations of current market trades or losses in an account. They nevertheless showed why a rejection test at one function did not establish protection along its caller path. An availability declaration needs a compatible interpretation contract before the declaration is constructed, while the original type is still available for inspection.

Connect one numeric interpreter at three stages

I moved the body of the already repaired engine interpreter into a shared utility rather than authoring another numeric policy. The engine, market-payload normalization and snapshot price filtering and conversion now use it. Applying the contract where the original type is visible avoids expecting a later consumer to guess which apparently valid numbers came from malformed input.

Interpreting a numeric value and admitting it as a trading price remain separate steps. Numeric zero and the string zero still parse to zero, while the calculation snapshot selects positive prices only. Preserving a declared zero change and excluding a zero trading price are compatible requirements. A finite-number interpreter does not determine every field’s business meaning.

The existing numeric-string contract also remains in place. It interprets nonempty strings and checks whether the resulting number is finite; it does not introduce a new grammar limited to decimal spelling. The task did not unify every server normalizer or establish complete economic ranges for averages, volumes and other fields. The separate saved-ledger requirement that accounting fields already be JSON numbers also remains unchanged.

Connected function tests are a different scope from screen verification

Eight new test groups connect the shared helper, actual payload normalizer, actual snapshot builder and engine with synthetic input. They compare wrong-type price rejection, unavailable versus declared-zero numeric fields and positive-price selection. A boolean percentage without valid alternative change evidence remains unavailable and produces no virtual fill. Valid numeric text still produces the expected single virtual fill while preserving frozen input, source time and collection time.

The twenty-two earlier tests plus eight new groups passed as thirty native tests. The development task also checked a separate build, extracted before-and-after source ZIPs and compared hashes for seventeen files in total. The restored earlier source passed twenty-two tests and the repaired source passed thirty; bytes and modification times of twenty-seven protected files were preserved. These are the immediately preceding development records, not native tests rerun during this writing task.

The tests extracted pure functions from the original hook files without mounting React. They did not query a live provider, use an account or broker, exercise browser storage or replace the running deployment. This revision separately rechecks the existing public summary ZIP’s twenty-two synthetic tests and the saved-record selector with DOM stubs. Its summary implementation is unchanged. An adapter from native available:false/met:false to Python met=None is still not implemented.

Other business software faces the same distinction

An order that cannot be checked because inventory data has not arrived needs a different next step from an order whose checked quantity fails a condition. Missing budget material also differs from a reviewed budget that was found insufficient. Rule names can change with the business while availability, condition results and authority to act remain separate responsibilities.

The first publication built an independent state summary. The first follow-up repaired interpretation inside the engine, and the next repaired the market-payload and snapshot stages before it. This revision connects that sequence to the current article. More precise status wording depends on following where its underlying observations change meaning. That path and its remaining limits can be explained without exposing real companies, accounts or source-price material.