# Systematic Strategy Engineering Translate a specification into deterministic testable software. Use this workbook alongside the course. Write your answers before opening the solutions. Practical work is self-reviewed; scored knowledge checks are in the Academy. ## 1. Specification ### State machines A strategy specification defines inputs, decision timing, eligibility, sizing and exits. Convert descriptive ideas into explicit conditions before coding. If two implementers can interpret a rule differently, the ambiguity belongs in the specification review. ### Signal timing Separate signal logic from execution policy. A desired exposure is not the same as an immediately executable order. The adapter must consider current positions, working orders and available account state. ### Sizing Configuration includes parameters and enabled behaviors. Validate ranges and combinations, and record the exact configuration with each experiment. Hidden defaults make it difficult to know what was actually tested. ### Exit lifecycle Define failure behavior for missing data, unavailable dependencies and uncertain state. A system needs a deliberate no-action or recovery path; an exception handler that returns an ordinary zero can disguise a failure as a valid signal. ### Worked example A strategy returns desired exposure of three units while two are already held. Sending a new three-unit buy would create five; the execution policy should reason about the target and current state. ### Independent exercise Write a target-to-order calculation for that case, including the possibility of one additional unit already working. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 2. Implementation ### Determinism Implementation should use small components with explicit interfaces. Data preparation, decision logic, risk calculation and execution adaptation can then be checked separately while preserving end-to-end behavior. ### Idempotent actions Event handling must be deterministic under recorded inputs. External calls, current clock reads and random values should be isolated or injected so replay can reproduce the decision path. ### Versioned configuration Persistence should capture the state needed for recovery, not merely the final chart output. Record decisions, identifiers and configuration references so a restart can distinguish completed work from uncertain work. ### Reproducible builds Concurrency can create duplicate or conflicting actions if two processes observe the same old state. Use appropriate serialization, identity and transaction boundaries for the environment. A local in-memory flag may not protect multiple workers. ### Worked example Two workers both see no order and each submits one. Each local check was true, but the combined system duplicates exposure because the decision and submission were not coordinated. ### Independent exercise Describe a design that prevents this race without assuming only one process will ever run. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 3. Verification ### Unit tests Verification should include unit calculations, state invariants and integrated event sequences. Tests that merely repeat the code's formula cannot establish independent correctness. Use hand-checked examples and adverse paths. ### Historical replay Compare a new implementation with a frozen baseline on identical inputs, then investigate every material difference. Expected changes should be explained; unexpected differences should not be dismissed because aggregate P&L improves. ### Cross-checks Test invalid and missing inputs, delayed responses and duplicate events. A system's ordinary behavior is only part of its correctness. Failure paths often determine whether state remains recoverable. ### Failure injection Separate software correctness from strategy effectiveness. A perfectly implemented losing rule is still losing; a profitable-looking backtest with implementation errors is not validated by its return. Both dimensions need evidence. ### Worked example A refactor changes trade timing by one bar but improves historical P&L. If timing was intended to remain unchanged, the improvement does not excuse the regression. ### Independent exercise Write acceptance criteria for a behavior-preserving refactor and a separate criterion for a deliberate strategy change. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 4. Strategy change management ### Separate research and execution configuration Separate research configuration from execution configuration. A notebook experiment should not activate account behavior merely by changing a shared default. Deployment or activation needs its own deliberate controlled path. ### Review a versioned change Review a proposed change against its problem, expected behavior and evidence. Include risk and rollback implications. A large collection of unrelated edits makes it harder to identify what caused an outcome. ### Maintain an experiment register An experiment register records hypotheses, variants, data periods and decisions. It prevents repeated rediscovery of rejected approaches and makes selection visible when presenting a successful candidate. ### Roll back a failed candidate without losing records Rollback should restore a known behavior version without deleting fills, account history or incident evidence. Recovery must reconcile existing state with the restored logic rather than pretending the intervening period never occurred. ### Worked example A candidate is rejected after introducing duplicate requests. Rolling back the code is useful, but deleting the execution log would remove the evidence needed to reconcile any actual fills. ### Independent exercise Write a rollback checklist that preserves records and verifies the resulting account state before new activity. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## Course project Build a demo strategy with unit, replay and failure-path tests. ### Self-review rubric - Concepts and reasoning: 25% - Calculations, data and evidence: 30% - Process and risk controls: 25% - Limitations and communication: 20% Record one correction and one next practice task. This rubric is not automatically graded. ## Worked solutions ### Exercise 1 With two held and no working quantity, one additional unit reaches the target. If one is already working, no further buy is needed unless its status changes. Reconcile authoritative state before issuing a new instruction. ### Exercise 2 Use a shared serialization or transactional claim keyed to the decision identity, with idempotent execution handling and recovery records. Verify state again where required and test multiple workers, not only a single-threaded path. ### Exercise 3 The refactor should match the frozen decisions and accounting on identical inputs except documented nonbehavioral differences. A strategy change requires a new specification, version and independent effectiveness evaluation rather than being hidden inside the refactor. ### Exercise 4 Identify the known version, stop conflicting actions, retain logs and configuration history, reconcile orders and positions, restore the approved behavior and verify it with the documented checks. Rollback is not a data reset. ## Further reading - https://docs.python.org/3/tutorial/ - https://scikit-learn.org/stable/common_pitfalls.html