Guidelines for Selecting and Implementing Financial Time Series Feature Engineering Solutions

Source: Notion | Last edited: 2025-06-04 | ID: 2082d2dc-3ef...

---

Core Principles

1. Maintainability and Currency

• Use only well‐maintained, off‐the‐shelf packages that have been actively maintained over the last six months and are not going out of fashion.
• Prefer community‐vetted libraries over custom implementations whenever possible.

1. Simplicity (Occam’s Razor)

• If two solutions deliver equivalent functionality, choose the simpler one.
• Avoid unnecessary layers of abstraction or complexity.

1. Replaceability (Liskov Substitution)

• Any component you select should be replaceable by another implementation of the same abstraction without breaking correctness.
• Design interfaces so that swapping one library or module for another does not require major rewrites.

1. No Hard-Coded Constants

• All numeric parameters (thresholds, epsilons, etc.) must be configurable or derived at runtime (e.g., via machine epsilon, rolling statistics, or other data‐driven methods).
• For division‐by‐zero scenarios, use a community‐vetted “safe_divide” routine or compute any regularizer dynamically—never embed a literal constant in code.

Top-Priority Requirements

• Feature engineering must focus on financial time series forecasting for directional trading.
• Solutions must maximize:
  1. Gradient Informativeness
  2. Surrogate Fidelity
  3. Extrapolative Reliability If a candidate solution fails to meet these requirements, move down the hierarchy.

Hierarchy of Solutions (Highest to Lowest Rung)

1. Turnkey/Off-the-Shelf (SOTA Pre-Packaged)

• Only consider packages that:
  • Are widely adopted in the community.
  • Have had commits, releases, or active issue‐tracking activity within the last six months.
  • Show evidence of ongoing support and maintenance.

1. Out-of-the-Box (SOTA Defaults)

• Use default configurations of well‐known libraries when they satisfy core requirements without modification.

1. Plug-and-Play Components (SOTA Modules)

• Integrate individual modules (e.g., a feature‐extraction library) that can be composed into a pipeline.

1. Template/Framework (SOTA Skeletons)

• Leverage boilerplate or skeleton projects that provide a starting point, customizing only as needed.

1. Configurable/Semi-Custom (Adaptive SOTA Frameworks)

• Use frameworks that allow parameterization or light customization at runtime.

1. Custom/Bespoke (Research-Grade SOTA)

• Only if none of the above options meet requirements, develop a fully custom implementation following best practices.