Back to Analysis
2026-02-26·6 min read

How the 6-Factor Framework Becomes a Machine-Readable Signal

Six weighted factors. A dual-case scoring engine. One conviction number that collapses market noise into a directional read a machine can act on. Here's the architecture of the transformation.

How the 6-Factor Framework Becomes a Machine-Readable Signal

A human trader reading the InDecision Framework sees a bias, a conviction percentage, and a set of factor assessments. They interpret those outputs through experience, adjust for context they carry in their head, and make a decision. The framework handles the analysis. The human handles the judgment.

A machine reading the same framework needs something different. It needs structured, deterministic outputs with enough granularity to make conditional decisions without human interpretation in the loop. The same six factors, the same scoring logic, the same conviction thresholds — but the output format has to be different because the consumer is different.

This is the core design problem the Signal API solves.

From Weighted Factors to Dual Cases

The InDecision Framework doesn't produce a single score through a linear formula. It builds two independent cases — a bull case and a bear case — and scores each one separately. This is the mechanism most signal services skip, and it's the reason InDecision's conviction scores carry more information than a simple rating.

Each of the five weighted scorers evaluates the current market data and contributes points to both cases:

Daily Pattern (30 points max) runs 14 candlestick pattern detections across a 5-candle window. A hammer at support contributes to the bull case. An evening star at resistance contributes to the bear case. Ambiguous patterns contribute small amounts to both sides.

Volume (25 points max) measures volume anomalies and buyer/seller pressure. A rally on 2.3x average volume is strong bull evidence. A selloff on 4x average volume is strong bear evidence. A move on 0.4x average volume is weak evidence in either direction — which the API reflects by scoring that factor low for both cases.

Timeframe Alignment (20 points max) checks whether the 1-hour, 4-hour, daily, and weekly trends agree. Full alignment adds maximum points to the aligned case. Conflict between timeframes distributes points to both sides, reducing the spread — which is exactly how conviction drops in the real output.

Technical Confluence (15 points max) evaluates RSI(14), MACD(12,26,9), and Bollinger Bands(20,2). Divergence between these indicators splits points. Agreement concentrates them.

Market Timing (10 points max) accounts for session timing and day-of-week patterns. Crypto markets have measurable behavioral rhythms around funding rate resets (8-hour cycles), institutional session windows, and weekly structural patterns.

The bull case total and bear case total are computed independently. The winning case determines bias. The spread between them determines conviction strength.

The Spread Is the Signal

The most useful number in the API response isn't the conviction percentage — it's the spread.

A 74.3% BEARISH conviction with a spread of 48.6 (bear case 74.3, bull case 25.7) tells you the factors are heavily aligned in one direction. The opposing case is weak. This is a high-quality signal.

A 62% BULLISH conviction with a spread of 24 (bull case 62, bear case 38) tells you something different. The bull case won, but the bear case has real evidence behind it. Three factors might agree on bullish, but two are providing meaningful counterarguments. This is a lower-quality signal at a medium conviction level — tradeable with reduced size, not with full commitment.

The spread captures what a single conviction number cannot: the quality of the disagreement between the two cases. In the API response, both bull_case and bear_case scores are returned alongside conviction_pct and spread, so the consuming application can make its own quality assessment.

{
  "bias": "BULLISH",
  "conviction_pct": 62.0,
  "bull_case": 62.0,
  "bear_case": 38.0,
  "spread": 24.0,
  "factors": {
    "daily_pattern":       { "score": 18.0, "max": 30, "signal": "BULLISH" },
    "volume":              { "score": 15.5, "max": 25, "signal": "NEUTRAL" },
    "timeframe_alignment": { "score": 12.0, "max": 20, "signal": "BULLISH" },
    "technical":           { "score": 10.0, "max": 15, "signal": "BULLISH" },
    "market_timing":       { "score": 6.5,  "max": 10, "signal": "NEUTRAL" }
  }
}

In this example, volume and market timing are neutral — they're not contradicting the bullish read, but they're not confirming it either. A bot consuming this API might apply a rule: if spread is below 30 and two or more factors return NEUTRAL, reduce position size by 50%. That rule is possible because the factor-level data is exposed, not just the headline number.

Post-Scoring Adjustments

The raw factor scores aren't the final output. Two adjustment layers modify the dual-case totals before the API returns them.

Mean Reversion (up to +/-20 points): When RSI hits an extreme (above 70 or below 30) simultaneously with a Bollinger Band touch, the engine applies a counter-trend adjustment. This catches overextended moves where momentum scorers are still scoring in the trend direction but the statistical probability of a reversal has increased. The adjustment shifts points from the trending case to the counter-trend case.

Cascade Detection (up to +/-12 points): Bottom-up reversal signals propagating across timeframes — a bullish divergence appearing on the 5-minute that confirms on the 15-minute and echoes on the 1-hour — trigger a cascade adjustment. This layer detects the early stages of a trend reversal before the primary scorers fully register it.

These adjustments are reflected in the final bull_case and bear_case numbers. The API doesn't expose them as separate fields because the consuming application doesn't need to know about the internal scoring mechanics — it needs to know the final assessed conviction. The factor breakdown provides the transparency into what drove the score. The adjustments refine it.

Consuming the Signal Programmatically

The API returns everything a downstream system needs to make conditional decisions:

Threshold-based routing: if conviction_pct >= 70 and spread >= 40: execute_full_position(). This is the simplest consumption pattern — treat the API like a traffic light.

Factor-conditional logic: if factors.volume.signal == "BEARISH" and bias == "BULLISH": reduce_size(). The per-factor signals enable nuanced decision trees that go beyond the headline number.

State-change detection: Poll the API at regular intervals and trigger actions on transitions. A bias flip from BULLISH to BEARISH at high conviction is a different event than a gradual conviction decay. Both are detectable from sequential API responses.

Risk gating: When risk_context.gate is true, the engine is flagging a macro event that could invalidate the technical read. A consuming system can respect this gate by pausing execution or reducing exposure — the same discipline the InDecision Framework applies internally.

The output format is designed for machines that need to make decisions, not humans who need to be convinced. Every field is typed, every value is bounded, and every signal is deterministic given the same market data. The analysis is the same one that has produced 67% accuracy over 7+ years. The delivery mechanism is new. The engine is not.

Explore the Invictus Labs Ecosystem

Share:𝕏 / Twitter
// RELATED ANALYSIS

// FOLLOW THE SIGNAL

Follow the Signal

Stay ahead. Daily crypto intelligence, strategy breakdowns, and market analysis.

// GET THE SIGNALS

Get InDecision Framework Signals Weekly

Every week: market bias readings, conviction scores, and the factor breakdown behind each call.

Interests (optional)

No spam. Unsubscribe anytime.