The feature and pattern layers turn normalized market state into evidence. They do not emit trades.
Feature Kernel
The feature kernel consumes MarketSnapshot and produces FeatureVector.
Core rules:
- feature computation is bounded by
ReferenceTime - feature definitions declare required capabilities
- missing or stale dependencies become explicit availability states
- features include provenance when useful
- schema version is surfaced downstream
Implemented Features
The current framework still includes the original price-window features:
price_return_pct_1mprice_velocity_pct_1m
price_velocity_pct_1m uses windowed sample selection and rejects gaps that exceed the configured tolerance.
The first Move Intelligence Core Pack adds legacy-compatible feature names used by the old pattern library:
price_velocity_pctprice_accelerationprice_range_pctvolume_zscoreoi_velocity_pctdeltasession_progress_pct
These features are still capability-aware. For example, oi_velocity_pct requires OpenInterestCapability; if OI is missing, the feature is unavailable rather than 0.0.
FeatureDefinition
A feature definition carries:
- feature id
- required capabilities
- safety flags
- schema version
- compute behavior
The registry is not decorative. The kernel reads required capabilities and checks the snapshot before computing.
FeatureVector
FeatureVector carries:
- feature values
- availability metadata
- provenance
- reference time
- cycle id
- schema version
The scoring layer later rejects mixed feature schema versions inside one hypothesis.
Pattern Engine
The pattern engine consumes FeatureVector and emits PatternHit[].
It owns:
- pattern availability
- evidence evaluation
- stage matching
- definition version
- definition hash
- hit id construction
It does not own long-term statistical updates. Scoring and research feedback are separate layers.
Pattern Availability
Pattern availability can be:
- eligible
- unavailable
- stale
- disabled
- retired
- cooling_down
This distinction matters. A retired pattern can still be used for historical comparison. A disabled pattern should not run live. A cooling-down pattern may be temporarily unavailable.
Evidence
Pattern evidence is structured:
- feature id
- operator
- threshold
- min and max range bounds
- observed value
- per-feature score contribution
- feature status
Operators are typed to avoid typo-driven behavior.
Stage Matching
The engine chooses the strongest qualifying stage instead of first-match-wins. This avoids making registry order a hidden scoring rule.
The current stage model supports two forms:
- legacy single-feature threshold stages for simple patterns
- multi-feature range stages for migrated Move Intelligence patterns
Move Intelligence stages are built from weighted feature ranges:
short_covering stage_1
oi_velocity_pct: (None, -0.1)
price_velocity_pct: (0.02, None)
volume_zscore: (0.4, None)
The range scorer preserves the old Atlantis doctrine:
More extreme is stronger. Never reject an intensity signal for being too strong.
So an OI velocity of -12.0 still matches an upper-bound rule such as (None, -1.0) and scores as stronger evidence.
Definition Hashes
PatternDefinition and PatternHit include definition hashes. If a definition changes without a version bump, the hash exposes the drift.
This is important for live-vs-replay comparisons and research reproducibility.
Current Patterns
The framework still includes the original contract-proving price_momentum_bullish pattern.
The first migrated Move Intelligence pack adds representative legacy patterns from:
/Users/home/dev/atlantis/process/move_intelligence/pattern_library.py
/Users/home/dev/atlantis/process/move_intelligence/pattern_detector.py
Migrated patterns:
short_coveringlong_unwindingrange_expansion_bullishrange_expansion_bearish
These definitions are not final coverage of the full old pattern library. They are the first large migrated subsystem boundary: OI, volume, price velocity, acceleration, delta, session progress, strict missing-data handling, highest-stage matching, and range-scored evidence.