ForgeQuant: Anatomy of a Multi-Gate Signal Protocol

The Failure Mode

The standard approach to equity screening is weighted-sum scoring: assign a weight to each factor, multiply, sum, rank. The problem is structural. A stock with exceptional momentum but deteriorating fundamentals can still rank near the top because one dimension compensates for another. The output looks decisive. The underlying setup is fragile.

Analyst consensus compounds this. The signal basis is often opaque - a rating arrives without its reasoning. When the thesis breaks, there is no audit trail to determine which assumption failed or when it became invalid.

ForgeQuant was designed as an architectural response to both problems. The constraint protocol treats each evaluation dimension as an independent gate rather than a weighted contributor. A ticker must survive every gate independently. No single strong factor can carry a weak setup past the threshold.

Design Doctrine

Three principles govern the protocol architecture. They were established during the initial research phase and have not been relaxed since.

The protocol was validated using the same adversarial research methodology applied to all critical Greyforge builds - structured opposition, deliberate stress-testing, and a formal GO/NO-GO gate before committing to the architecture.

The Six Gates

ForgeQuant evaluates a universe of 600+ symbols daily. Each ticker passes through six independent evaluation gates. The order below reflects the logical pipeline, though gates are computed in parallel and evaluated independently.

Composite Scoring Pipeline

After each gate produces its independent score, the composite pipeline determines the final signal classification. The algorithm operates in two phases: gate qualification, then weighted aggregation of survivors.

for each ticker in universe:
  gate_scores = {}
  for gate in [trend, momentum, volatility, flow, persistence, valuation]:
    gate_scores[gate] = evaluate(ticker, gate)

  # Phase 1: Gate qualification
  # Every gate must independently clear its minimum threshold.
  # A single gate failure disqualifies the ticker entirely.
  if any(score < gate.min_threshold for gate, score in gate_scores):
    classify(ticker, BELOW_THRESHOLD)
    continue

  # Phase 2: Weighted composite of surviving gates
  composite = sum(gate_scores[g] * weight[g] for g in gates) / sum(weights)

  # Phase 3: Classification bands
  if composite >= STRONG_BUY_THRESHOLD and valuation_gate.cleared:
    classify(ticker, STRONG_BUY)
  elif composite >= BUY_THRESHOLD:
    classify(ticker, BUY)
  elif composite >= WATCH_THRESHOLD:
    classify(ticker, WATCH)

  # Phase 4: Risk framing
  stop_loss    = compute_stop(ticker.atr, ticker.volatility_profile)
  trailing_exit = compute_trail(ticker.atr, composite_strength)

The critical detail is Phase 1. In a traditional weighted-sum system, Phase 1 does not exist - every score contributes regardless of quality. The gate qualification step is what makes the protocol structurally different. Weighted aggregation only runs on tickers that already passed every independent check.

Walkthrough: A Ticker Through All Six Gates

Consider how a hypothetical ticker moves through the pipeline.

Now consider a second ticker with identical momentum and volatility scores, but trading above the valuation hurdle rate. In a weighted-sum system, the strong technical scores would compensate and the ticker might still rank highly. In ForgeQuant, the valuation gate failure terminates evaluation. The ticker is classified Below Threshold regardless of how strong the other five gates looked.

This is the architectural consequence of gate independence: the protocol is structurally incapable of endorsing a setup where any single dimension is deficient.

Signal Classifications and Risk Framing

Every signal classified Buy or above includes two exit levels computed from the ticker's own volatility profile:

The Daily Brief: A Deliberate Constraint

ForgeQuant produces one brief per trading day. This is an architectural decision, not a limitation. The protocol targets swing and position timeframes - holding periods of days to weeks. The daily cadence enforces several properties:

• Signal quality is bounded by the gate constraints, not inflated by frequency. More scans per day would not produce more qualifying setups - just more Below Threshold classifications.
• A single daily decision point reduces reactive, emotional trading. The protocol does not reward compulsive checking.
• Alert fatigue is structurally eliminated. The brief contains only what survived all six gates. On quiet market days, the brief may contain nothing - and that is a valid output.

Each signal in the brief carries its ticker, composite score, signal classification, per-gate breakdown (regime, flow health, persistence state), stop and trailing exit levels, and a plain-language summary of the reasoning. The summary is generated deterministically from the gate outputs - it is not an LLM interpretation.

What the Protocol Catches

The gate architecture is designed to reject categories of setups that routinely survive traditional screens:

None of these rejections require discretionary judgment. They are consequences of the gate architecture - each gate exists specifically to prevent its corresponding failure mode.

Relationship to ForgeCast

ForgeCast is the full trading platform under active development - portfolio management, position tracking, multi-strategy tools, and real-time analysis in a unified interface.

ForgeQuant is the constraint protocol that powers ForgeCast's daily scanner. It was extracted and made available as a standalone signal brief while the broader platform matures. Architecturally, ForgeQuant is a subsystem - the signal-generation layer of a larger system. When ForgeCast ships, the protocol integrates directly as a core component.

What Comes Next

The protocol is stable and in daily production. The next phase of work is focused on expanding the evaluation universe and refining the persistence and flow dimensions with additional data sources. The gate architecture is designed to be extensible - adding a seventh or eighth gate does not require restructuring the pipeline, only defining the new gate's threshold and failure mode.

Backtesting methodology remains under active research. The policy is to publish no performance claims that cannot be independently audited. Fabricated ROI numbers, cherry-picked windows, and hidden execution assumptions are excluded by design. If a number cannot be reproduced from stated inputs, it does not appear in any ForgeQuant output.