Evaluate default factory configs: should optional configs have sensible defaults?

[jlixfeld]

Problem

Currently, several optional configuration objects in TimeframeItemConfig default to None, which means certain features are disabled by default even though they have sensible default values defined in their schemas.

Example: target_config

The target_config field defaults to None, which means target_prices and target_count columns in the indicators dataframe are always null unless users explicitly configure it:

config = FactoryConfig(
    aggregation=AggregationConfig(target_timeframes=["1min"], asset_class="equities"),
    indicators=IndicatorsConfig(
        timeframe_configs=[
            TimeframeItemConfig(
                timeframes=["all"],
                swing_points=SwingPointsConfig(window=1, threshold=0.0)
                # target_config is None by default!
            )
        ]
    )
)

Result: target_prices column is always null, even though TargetConfig has well-defined defaults:

• upper_bound="higher_high"
• lower_bound="lower_low"
• merge_threshold_pct=0.0
• max_targets=None

IMPORTANT: Target Price calculation is extremely expensive, so it might be better to do some of these calculations on-demand. ie: if filtering signal_at_ll, then SwingPointConfigs are definitely(?) necessary but targets aren't necessary unless a signal is at lower low. This means we can make expensive calls on a far smaller number of symbols instead of expensive calls on the entire universe. ie: when starting up and calculating indicators, this takes a LOONG time if Target Prices are calculated as well.

Current Optional Configs in TimeframeItemConfig

From schemas.py:351-376:

class TimeframeItemConfig(BaseModel):
    swing_points: SwingPointsConfig | None = Field(default=None, ...)
    gap_detection: GapDetectionConfig | None = Field(default=None, ...)
    target_config: TargetConfig | None = Field(default=None, ...)

Questions to Evaluate

1. Should target_config default to TargetConfig() instead of None?

   • Pros: Target detection works out of the box, dataframe columns are always populated
   • Cons: Performance overhead for target detection when not needed
   • Trade-off: Is the performance cost significant enough to justify opt-in?

2. Should gap_detection default to GapDetectionConfig() instead of None?

   • Pros: Gap patterns detected automatically
   • Cons: Gap detection may not be relevant for all asset classes (most useful for equities)
   • Trade-off: Should this be asset-class dependent?

3. Should swing_points default to SwingPointsConfig() instead of None?

   • Current behavior: Actually appears to be required for market structure detection
   • Question: Is this truly optional or effectively required?

Design Philosophy Question

What's the guiding principle for defaults?

Option A: Opt-in features (current)

• Minimal performance overhead by default
• Users explicitly enable features they need
• More verbose configuration required

Option B: Sensible defaults

• Features work out of the box with good defaults
• Users can disable or customize as needed
• Simpler configuration for common use cases

Option C: Hybrid approach

• Core features like target_config enabled by default
• Asset-class specific features like gap_detection opt-in
• Performance-intensive features opt-in

Recommendation

Evaluate each optional config case-by-case:

Config	Current Default	Suggested Default	Rationale
target_config	None	TargetConfig()	Target detection is core to trading signals, performance cost is minimal, having null columns is confusing
gap_detection	None	Keep None	Asset-class specific (mainly equities), not universally applicable
swing_points	None	Review if actually optional	Appears to be required for market structure - is None even valid?

Action Items

• Review performance impact of default target_config on large datasets
• Test whether swing_points=None is actually a valid configuration
• Consider adding apply_defaults: bool flag to IndicatorsConfig for explicit control
• Document the design philosophy in CLAUDE.md once decided
• Update schemas based on evaluation

Related Files

• thestrat/schemas.py:310-376 - Config definitions
• thestrat/indicators.py:781-835 - Target population logic
• test_2d2u_dataframe.py - Example showing null target_prices