How the FAR algorithm produces its outputs
This page describes how the FAR algorithm produces the outputs published on this Service. It is intended as research transparency, not as instructional material or investment guidance.
Inputs
Price action, volume and volatility, macro context, cross-market signals, session context.
Bias scoring
Inputs combine into a directional bias score and a confidence percentage.
Direction call + levels
BULL, BEAR, or FLAT with REF, TP1–TP3, and STOP computed at emit time.
Outcome resolver
When the window closes, the resolver logs HIT or MISS to the public track record.
Overview
FAR is an experimental algorithmic model that produces directional reads on the gold market. Each run produces:
- A direction call (BULL, BEAR, or FLAT)
- A confidence percentage
- A computed reference price
- Computed levels representing potential price targets and invalidation points
The algorithm publishes one directional call per trading day. Past calls accumulate into a track record that displays hits and misses with no curation.
What the algorithm looks at
The algorithm ingests several categories of inputs at each run:
- Price action data: gold futures price history across multiple timeframes
- Volume and volatility signals: relative volume and recent range characteristics
- Macro context: recent and upcoming high-impact economic events (rate decisions, inflation prints, employment reports) and their general expected directional influence
- Cross-market context: correlated assets used as confirmation or divergence signals
- Session context: which major trading session is active
The algorithm does not look at user account information, user trading history, social sentiment, news headlines, or anything outside its defined input set. It has no awareness of who is reading the Service.
How it produces a direction call
The algorithm combines its inputs into a directional bias score. The bias score reflects how strongly the inputs collectively favor an upward, downward, or neutral move over a defined window.
A direction call is published when the bias score crosses defined thresholds:
- BULL: bias score favors upward move
- BEAR: bias score favors downward move
- FLAT: bias score is inside a neutral band
The confidence percentage reflects the algorithm’s internal estimate of edge based on input alignment. Outputs only become a tradeable thesis at confidence ≥ 70; below that the engine watches or waits. Higher confidence does not guarantee accuracy.
What the levels represent
For each direction call, the algorithm computes:
- REF: the reference price at the time of the output, anchoring all other levels
- TP1, TP2, TP3: computed price levels representing potential targets in the direction of the call
- STOP: a computed price level representing the algorithm’s invalidation threshold
These levels are computational predictions, not trade instructions. They represent points in price the algorithm has identified as relevant to its directional thesis. They are not personalized to any user, are not adjusted for any user’s risk tolerance or capital, and are not recommendations to enter or exit any position.
Internal conviction classification
Each output also receives an internal conviction tag:
- CONFIRMED: multiple inputs aligned, high internal conviction
- PARTIAL: partial alignment, mixed signals
- NO-EDGE: insufficient signal alignment
This tag describes the algorithm's internal state, not a recommendation to the reader.
How outcomes are determined
A resolved output's outcome (HIT or MISS) is determined by the algorithm's outcome resolver after the output's resolution window has closed.
Two resolvers run depending on the call type:
BULL or BEAR with TP/stop levels (the default): the resolver tracks price action inside the window and the first level hit decides the outcome.
- HIT if TP1 or further is reached before stop is hit
- MISS if stop is hit before any TP, or if neither is hit before the window closes
FLAT or directional calls without TP/stop: the resolver measures gold’s net move from the reference price to the close of the window.
- BULL is HIT if the net move over the window is upward
- BEAR is HIT if the net move over the window is downward
- FLAT is HIT if the net move stays inside a defined band
Resolution windows and band thresholds are defined per output type by the resolver.
Outputs are added to the public track record only after their outcome is determined. Pending outputs (those with unresolved windows) are not added to the resolved track record.
Market closures. When an output’s as-of date is a non-trading day (US federal holiday, exchange closure, or weekend edge), the resolver bridges the resolution window to the next available trading close instead of leaving the output pending indefinitely. The first observed instance was the Jun 19, 2026 Juneteenth Friday: twelve WAIT_CONFIRMATION outputs on Jun 19–21 could not resolve against a same-week close and were bridged to the Jun 22 (Mon) close after the resolver fix landed on Jul 1, 2026. Rows resolved this way are scored under the same HIT/MISS rules as any other resolved row; they carry no distinct marker. The June 2026 recap was published before the fix landed and freezes the pre-bridge hit rate (48%); the live archive at /track-record/2026-06 reflects the post-bridge number (47%). Both are correct at their respective points in time; the archive updates as outcomes land and the recap does not.
Chart markers. On the /track-record chart each resolved output that falls inside the visible bar window is drawn as a small circle at the bar of its emit time. A green circle above the candle marks a HIT. A red circle below the candle marks a MISS. A larger gold circle with a star marks a PREMIUM HIT (a high-confidence directional call that resolved as a HIT). The currently selected output is drawn slightly larger so it stands out in the timeline.
Hit rate calculation
The published hit rate is calculated across all resolved outputs in the record, including misses. There is no curation, no removal of underperforming outputs, and no cherry-picking. Outputs that have not yet resolved are excluded from the calculation.
Before May 5, 2026, the algorithm published multiple intraday refinements per trading day rather than a single daily call. For metric purposes (hit rate, streaks, magnitudes, breakdowns) those refinements are collapsed to one canonical row per trading day. That row is the algorithm's final published refinement of the day. A single daily call counts as one output regardless of how many refinements it went through. The journal continues to show every refinement individually as raw research material. From May 5, 2026 onward the algorithm publishes one row per trading day directly, so no collapse is needed.
The track record reflects the algorithm's actual published outputs over the period shown. Past performance is not indicative of future performance.
Known limitations
The algorithm has substantial limitations that readers should understand:
- It may be wrong on any given output, including high-confidence outputs
- It may experience extended periods of underperformance
- It is sensitive to regime shifts in market conditions
- It does not account for unscheduled news, geopolitical events, or other shocks
- It does not adjust for any individual user's situation, risk tolerance, capital, or objectives
- Hit rates measured over small samples are not statistically meaningful
- Past algorithm performance does not predict future performance
What the algorithm is not
The algorithm is not:
- A recommendation system
- A trading service or signal service
- A licensed advisory product
- A backtested system with audited historical results
- A fund or investment vehicle
It is an experimental research model whose outputs are published for educational and transparency purposes.
Operator's role
The operator builds and maintains the algorithm and publishes its outputs as research data. The operator is not a licensed investment adviser. The operator does not provide personalized advice and does not give trade-by-trade guidance on user inquiries about specific positions.
Changes to this methodology
The algorithm is in active development. Methodology, inputs, thresholds, and resolution rules may change. Material changes will be reflected in this document with the updated last-updated date at the top.
Questions
For questions about the methodology: support@faractionradar.com.
For privacy and data requests: privacy@faractionradar.com.
