A Atlantis Core

Migration

Legacy Parity

How AtlantisV2 preserves legacy Atlantis behavior while replacing old structure with explicit core contracts.

# AtlantisV2 core pipeline
ReferenceTime
  -> MarketSnapshot
  -> FeatureVector
  -> PatternHit[]
  -> TradeHypothesis
  -> SignalIntent
  -> PermissionDecision
  -> PositionIntent
  -> OutcomeRecord

Legacy Atlantis is the behavioral reference, not the new module layout.

The rewrite should extract durable logic from:

/Users/home/dev/atlantis

and place it behind instrument-agnostic contracts.

Migration Principle

Extract behavior, not file structure.

When a legacy function mixes core domain logic with venue lookup, persistence, live process state, and dashboard shaping, split those concerns instead of moving the function wholesale.

Current Legacy Parity Fixture

The first parity fixture targets outcome labels from:

/Users/home/dev/atlantis/process/execution/lifecycle/outcome_record.py

It proves that AtlantisV2 preserves these legacy semantics:

  • winner is path-based target hit behavior
  • loser is path-based stop hit behavior
  • expired can still be economically profitable
  • scratch is not an economic outcome even if a return field is present
  • option_return_pct > 0 drives economic profitability when an economic outcome exists

Why Outcome Parity First

Outcome semantics are foundational for research.

If path labels and economic labels collapse into one field, then:

  • win rate becomes misleading
  • time-stop profitable trades are incorrectly penalized
  • pattern feedback learns from the wrong denominator
  • live and research drift

This was a known legacy lesson and is now encoded in tests.

Migration Workflow

Every extraction should follow this sequence:

  1. Locate the legacy source behavior.
  2. Classify what belongs to core, adapter, persistence, runtime, or presentation.
  3. Define the smallest new contract.
  4. Write a failing test or parity fixture.
  5. Implement the thin slice.
  6. Run verification.
  7. Update task logs and durable lessons.

Legacy Source Map

BehaviorLegacy starting pointNew home
Feature extractionprocess/move_intelligence/feature_engine.pyfeature kernel and capability definitions
Pattern definitionsprocess/move_intelligence/pattern_library.pypattern registry and definitions
Pattern detectionprocess/move_intelligence/pattern_detector.pypattern engine
Signal generationprocess/move_intelligence/signal_generator.pysignal intent engine
Permissionprocess/move_intelligence/trade_permission.pypermission engine
Lifecycleprocess/execution/lifecycle/position_lifecycle.pylifecycle engine and transitions
Outcomesprocess/move_intelligence/outcome_tracker.py and execution/lifecycle/outcome_record.pyoutcome records and research labels
Delta dataprocess/move_intelligence/delta_greeks_loader.pymarket data adapters and capability blocks

Expected Differences

Some differences are intentional:

  • Core uses typed enums instead of string bags.
  • Core uses capability blocks instead of hardcoded snapshot fields.
  • Core uses EventEnvelope instead of venue payload dictionaries.
  • Core records explicit availability instead of default numeric values.
  • Core separates SignalIntent from expression.
  • Core uses MarkRecord for observations and LifecycleTransition for state changes.

When a difference fixes a known legacy bug or coupling, document it in the parity test or migration notes.

Next Parity Targets

Good next slices:

  • one strict legacy pattern from pattern_library.py
  • permission status and reason parity for a narrow TPE scenario
  • feature parity for price velocity, VWAP distance, volume z-score, OI velocity, or realized volatility
  • signal identity and direction parity around legacy EntrySignal