Microcap Engine Methodology

Micro/nano-cap trading is unusually sensitive to data quality, timing and simulation assumptions. A delayed trade can change a candle. A split can distort a historical comparison. A ticker can represent a different security years later. A revised filing can introduce information that did not exist when a historical trade occurred.

A trading decision should be evaluated using the information, market state and rules that could actually have existed at that moment.

Microcap Engine is designed around three priorities: speed, reliability and consistency between historical research and live use.

Built for fast decision-making

Speed in Microcap Engine is not limited to how quickly a scanner can detect a signal. A trader can define in advance which information should appear when a scanner signal is triggered. Instead of finding a ticker and then opening multiple tools, websites and data sources, the relevant market, company, technical and risk context can already be waiting in the workspace.

The objective is to shorten signal → context → decision without reducing the amount or quality of information available to make that decision.

Internally, low latency is designed to come from the architecture itself. Live market state and scanner evaluation are separated from slower persistence and downstream processing so that database writes do not have to sit in the critical path between a market event and a scanner decision.

Just as importantly, speed is not achieved by creating a separate, simplified version of market truth for the live scanner. Historical and realtime processing are designed to converge on the same canonical data semantics; only the timing of when a strategy evaluates that state differs.

Reliability starts before the data reaches the user

Microcap Engine does not assume that a dataset is correct simply because it is commercially available or commonly used.

For roughly 1.5 years, the data inputs and market-structure edge cases relevant to the platform have been investigated in detail: timestamps, trade conditions, extended-hours activity, delayed reports, corporate actions, security identity, historical fundamentals, trading sessions and other cases capable of changing a scanner or backtest result.

The purpose is not to make historical charts look cleaner. It is to understand what a datapoint represents, when it became knowable and whether it can safely participate in a trading calculation.

For example, visually extreme micro/nano-cap moves are not automatically classified as bad data. Genuine extended-hours volatility can be extreme. Historical evidence, timing and market semantics determine whether an event belongs in analytical data rather than an arbitrary percentage or visual-outlier rule.

Data integrity is also part of signal eligibility. A feed gap, incomplete required state or unresolved integrity problem should not quietly become a normal trading signal. The system is designed to distinguish healthy state from degraded or recovering state and to prevent incomplete data from being presented as equivalent to complete data.

Every research feature needs a defined meaning

A historical column existing in a database does not automatically make it a valid backtesting feature.

Every strategy-facing feature is intended to have an explicit definition covering its semantics, timeframe, information-availability rule, adjustment policy, missing-value behavior, historical coverage and both historical and live calculation paths.

For validated research, a feature should not be eligible merely because it can be calculated retrospectively. It needs a defined availability timestamp and evidence that the historical and live implementations represent the same concept. This prevents a subtle form of backtest leakage: using a historical value simply because it exists today even though the live strategy could not have observed that same value at the original decision time.

Point-in-time, not hindsight

Every input used by a validated historical strategy should have been available at the time of the decision.

That applies not only to OHLCV, but also to the historical stock universe, shares outstanding, float, fundamentals, news, earnings, corporate actions and other information that changes over time. Historical values therefore need availability and revision semantics rather than destructive replacement with the latest known value.

Ticker symbols are not permanent identities either. Mergers, re-listings, ticker changes and symbol reuse mean that historical security identity must be preserved independently of the ticker text.

Intraday prices remain as-traded, while cross-day comparisons and positions affected by splits require explicit corporate-action handling rather than silently rewriting history.

One market history across the product

Microcap Engine is designed around a canonical analytical market historyrather than separate interpretations for charts, indicators, scanners and backtests.

Raw market events are evaluated according to explicit timing and eligibility rules and transformed into a common 1-minute analytical foundation. Higher timeframes and downstream metrics derive from that foundation rather than independently rebuilding their own interpretation.

This matters because apparently small differences in raw-trade handling can propagate through price → volume → VWAP → indicators → scanner conditions → backtest signals.

Historical and realtime aggregation are therefore designed to share one canonical implementation rather than simply trying to produce similar-looking outputs.

The detailed reasoning behind individual market-data decisions is documented separately in Microcap Engine Research, where specific cases can be examined without turning this page into implementation documentation.

The same strategy should mean the same thing live and historically

The scanner and backtester should not quietly implement different interpretations of the same strategy.

A strategy is therefore designed as a versioned definition evaluated through shared strategy semantics. The backtest identifies candidate moments historically, but the final strategy decision is verified through the same conceptual kernel used by the scanner.

Realtime scanning can operate in two different ways. Intrabar discoverycan react while current market state is changing. Candle-close mode is the mode intended to match ordinary candle-based historical backtesting.

The distinction is explicit because immediate realtime discovery and historical candle-close replay answer different questions. They should not be presented as identical when they are not.

A signal is not automatically an executable trade

Detecting that a strategy condition was satisfied does not prove that the trade could have been executed at the theoretical chart price.

Execution can depend on the bid/ask state, spread, available size, latency, liquidity, partial fills, non-fills, halts, SSR, trading costs and short availability.

Microcap Engine therefore separates signal generation → order intent → execution → account/portfolio result rather than turning every historical signal directly into a perfect fill.

Where the available historical evidence is insufficient—for example, broker-specific historical borrow availability—the correct state is unknown, not an invented assumption presented as fact.

Historical and current dilution risk from SEC filings

Micro/nano-cap trading also requires understanding the capital structure behind the chart.

Microcap Engine has built an AI-assisted SEC filing parser designed to support both current and historical dilution-risk reconstruction. The system works from original filing evidence and is designed to reconstruct financing state through time rather than reducing a filing to a headline or a single dilution flag.

Relevant areas include shares outstanding and authorized shares, registered securities, offerings, ATM programs, warrants and pre-funded warrants, convertible securities, equity lines, resale registrations, cash position and burn-related information, and other financing events relevant to potential dilution.

Historical facts are tied to the filings from which they were derived and to when the underlying disclosure became publicly available. This allows historical research to reconstruct what dilution information was knowable at a particular point in time rather than applying today’s capital structure retrospectively.

Unknown does not mean zero.

If a historical value or instrument cannot be established from sufficient filing evidence, uncertainty should remain visible instead of being converted into a fabricated numerical value.

Optimization cannot rewrite the baseline

Microcap Engine separates the user’s original strategy from what later analysis discovers about it.

Every strategy first produces a baseline result from the frozen user-defined entry and exit rules. Entry scoring, exit optimization and other analytical layers sit above that baseline. They cannot retroactively change the original trade set and then present the altered result as though that had always been the strategy.

Historical optimization is intended to use chronological out-of-sample or cross-fitted evaluation. A trade being evaluated should not also have trained the model responsible for evaluating it.

Validated research is designed around chronological validation, robustness testing and a clear separation between historical evidence and a model fitted for future use.

Reliability includes showing uncertainty

A trustworthy trading tool should not only report where a model worked. It should make the quality of the evidence visible.

A backtest result can therefore carry context such as historical coverage, sample size, execution assumptions, data-quality limitations and whether a result represents baseline, genuine out-of-sample evidence or a model fitted for prospective use.

The objective is to avoid false precision. Incomplete history, uncertain execution, insufficient sample size, stale or missing inputs, approximate execution and unavailable borrow evidence should weaken the conclusion rather than disappear from the report.

Reproducibility is part of the result

A backtest result is not just a return percentage or equity curve.

It depends on the exact strategy definition, data snapshot, feature semantics, execution assumptions, validation plan and other configuration used to generate it.

Microcap Engine therefore treats these inputs as versioned parts of the run. A reproducible run records enough state to identify how the result was produced rather than only storing its final statistics.

The design target is straightforward: identical frozen inputs and deterministic settings should be capable of producing the same result.

Institutional methodology without institutional complexity

Microcap Engine is not intended to be a general-purpose institutional quant platform. It is designed specifically for retail traders operating in micro/nano-cap stocks.

The internal methodology deliberately incorporates capabilities more commonly found in professional research systems: point-in-time datasets, immutable versions, shared live/historical semantics, execution-aware simulation, chronological out-of-sample validation, reproducible runs, robustness analysis and explicit data provenance.

The user should not need to understand or configure every internal parameter to benefit from that rigor. The design principle is complexity inside, clarity outside: detailed internal models, but sensible presets, explainable outputs and clear warnings at the product surface.

Microcap Engine is also being packaged and priced for retail access rather than institutional research budgets.

Evidence over certainty

Microcap Engine is still being built.

A methodology document is not proof that every dataset, historical period, model or advanced feature has already completed production validation.

Where coverage is incomplete, evidence is insufficient or a historical fact cannot be reconstructed reliably, the system should expose that limitation rather than manufacture precision.

Microcap Engine Research is where individual data decisions, validation experiments and market-structure edge cases can be examined in detail. This page defines the higher-level rules those implementations are expected to follow.

Methodology maintained by Jozef, creator of Microcap Engine.