Deze case beschrijft geen systeem van één klant. Ze combineert terugkerende vereisten uit acht afgeronde records met indicatorovereenstemming, higher-timeframecontext, lower-timeframetriggers, risicogebaseerde sizing en positiebeheer. Namen, markten, waarden, links en eigen regels zijn uitgesloten.
Het doel is tonen hoe “handel wanneer meerdere timeframes overeenkomen” een architectuur wordt die een trader kan controleren en een developer kan testen.
Hoe een tradingbrief software wordt
Het werk gaat van een duidelijke vraag naar toestandslogica, risicocontrole, herhaalbare tests en gedocumenteerde oplevering.
- 01BriefScheid hogere context, setup, lagere trigger, exits en risicotoestemming.
- 02StatemapDefinieer waarden, bars, geldigheid, verval, conflicten en eenmaal-per-event.
- 03RisicolaagBereken size, verifieer bescherming en cap reeks- en accountexposure.
- 04BewijsSpeel gelabelde scenario’s af en vergelijk logs vóór brede historische tests.
- 05OpleveringDocumenteer inputs, aannames, blokkeringen, herstel en acceptatiechecks.
De vraag
De terugkerende brief bevatte een hogere contextvoorwaarde, een of meer indicatorbevestigingen en een sneller timeframe voor entry, plus stop- en targetbeheer, optionele risk sizing en controle op herhaalde posities.
Dat klinkt volledig, maar is nog niet testbaar. “Overeenstemming” kan simultane voorwaarden, een onthouden setup of het laatste signaal van elk timeframe betekenen. “Gesloten candle” kan enkel de trigger of alle lagen betreffen.
De vragen
We scheiden eerst marktbetekenis van interfaceopties. Elke voorwaarde krijgt bron, timeframe, bar, geldige toestand, verval en reset. De groep krijgt AND/OR-logica, voorrang en het event dat een trade mag evalueren.
Daarna komen beschermingsafstand, volumenormalisatie, gecombineerde exposure, tegengestelde signalen en de veiligheidslaag die een geldige setup mag vetoën.
- Zijn hogere voorwaarden filters, setups of rechtstreekse signalen?
- Moeten bevestigingen tegelijk gelden of mogen eerdere states gewapend blijven?
- Welke candles zijn finaal en welk event maakt een beslissing?
- Wat annuleert een setup vóór de lagere trigger komt?
- Wat gebeurt wanneer het signaal geldig is maar risico weigert?
De architectuur
De samengestelde oplossing gebruikt aparte modules. Context leest gekozen hogere bars, setup bewaart overeenkomst en verval, trigger evalueert het lagere timeframe eenmaal per event en risico bepaalt toestemming en exposure.
Positiebeheer start pas na een bevestigd brokerresultaat. Het bewaakt stop, target, break-even of trailing zonder het historische entriesignaal te wijzigen. Logs bewaren zowel positieve states als blokkeringen.
De validatie
Validatie begint met gelabelde scenario’s, niet met een lange equitycurve: geldige overeenkomst, vervallen setup, intrabarsignaal dat verdwijnt, ontbrekende hogere historiek, dubbel lager event, risicoblokkering en een geweigerde of gewijzigde order.
Pas wanneer dit gedrag bij de specificatie past, wordt een brede historische test zinvol. De eerste maatstaf is gedragsequivalentie: code en beschrijving beslissen hetzelfde uit dezelfde snapshot.
De les
De belangrijkste verbetering was geen extra indicator maar de scheiding van verantwoordelijkheden. Context, timing, risico en beheer konden onafhankelijk worden gewijzigd en fouten waren sneller te lokaliseren.
De case toont alleen terugkerende engineeringervaring. Ze reconstrueert geen klantstrategie en is geen bewijs van toekomstige tradingprestaties.
Vragen die je misschien hebt
Is dit een POLARIS-productbeschrijving?
Nee. Het is een educatieve samengestelde case uit terugkerende, geanonimiseerde developmentvragen.
Waarom staan indicatoren en thresholds er niet in?
Ze horen bij verschillende private projecten en zijn niet nodig om de engineeringles uit te leggen.
Wat was de eerste acceptatiemaatstaf?
Gedragsequivalentie: specificatie en EA geven dezelfde toestand en actie uit dezelfde getimestampte data.
