Strategy Families vs Strategy Instances: How to Organise a Library of Algo Trading Strategies
Sooner or later every algo trader ends up with a folder. It starts with one strategy. Then there is a version with a different stop. Then one with a different entry time. Then a copy for SENSEX. A year in, the folder holds forty files with names like "straddle_v3_new_FINAL", and nobody, including the person who wrote them, can say which ones are running, why, or what would make them stop.
The problem is not a lack of tools. A spreadsheet is enough. The problem is that the folder mixes two different kinds of thing. Some entries are ideas about how a market behaves. Others are specific settings of those ideas. Treating both as "strategies" is what makes the pile impossible to manage.
One word, two jobs: why "strategy" causes the mess
Ask ten traders what their "short straddle strategy" is, and you will get ten answers at different levels. One means the idea: sell both sides at the money and collect decay. Another means a specific setup: NIFTY, entry at 09:20, stop at 30% of combined premium, exit at 15:15. A third means the whole running book: three lots live in a broker account right now.
All three are valid uses of the word. The trouble comes when they share one name in one folder. A change to the stop gets saved over the setup, and now the earlier result cannot be reproduced. A decision to "stop the straddle" is ambiguous, because it could mean the idea, the NIFTY version, or the three live lots. A review meeting spends an hour arguing because one person is talking about the idea and the other about the setting.
Software people solved a similar problem long ago by separating a class from its objects. You do not need the jargon. You need two words and a rule about when to use each.
Families and instances, defined
A strategy family is a reason to be in a trade. It is a short statement of what the position earns from, what it is exposed to, and what would show the reason is wrong. "Short at-the-money straddle on weekly expiry, earning time decay and re-pricing as spot stays near the strike, exposed to a large directional move" is a family.
A strategy instance is one concrete, fully specified version of a family. It has an index, an entry time, a stop rule, an exit time, a size, and a version number. "NIFTY, enter 09:20, stop at a 30% rise in combined premium, flat by 15:15, version 4" is an instance.
The rule is simple. Results belong to instances, because only an instance can be run and measured. Reasons belong to families, because only a family can be right or wrong about the market. Decisions about what to keep go on both levels, but they are different decisions. Closing an instance is housekeeping. Retiring a family means you no longer believe the reason.
What a family record contains
A family record is short on purpose. Five to eight lines are enough, and if you cannot write it in that space, the idea is probably not clear yet.
Name and one-sentence thesis. This says what the position is paid for. It should read like a claim about the market that could be wrong. "Collects decay while spot stays near the strike on expiry day" is a claim. "A good expiry strategy" is not.
Structure. The legs, in words. Short call and short put at the same strike, or at different strikes, with or without bought wings. Keep it general. The strike offsets belong to the instance.
Exposure. What can hurt it. A large directional move in either direction, a jump in implied volatility, a gap through a stop, thin liquidity at the exit. Writing the exposure down in plain words is the best defence against being surprised by it.
Regime notes. Where the idea is believed to work and where not, in terms you can check. India VIX band is a natural one. In a study of 163 NIFTY and SENSEX weekly expiry sessions between January 2025 and July 2026, the 09:20 ATM straddle premium averaged 0.38% of spot when VIX was under 12 and 0.83% when it was over 20, rising steadily across five bands. A family record can say plainly: the premium budget changes with VIX, so size and stop width must be stated as a function of the band, not as fixed numbers.
Kill conditions. The family-level reasons that would make you drop the whole idea. For example: a rule change that removes the contract, a change in costs that makes the edge disappear, or a structural break such as the exchange moving expiry days. These are not performance numbers. They are changes in the world.
If you want to see how strategy families are described in a published form for Indian index options, EliteAlgo's page on algo trading strategies sets out the kinds of positions a systematic desk builds. It is a useful point of comparison for your own family records, though you should write your own thesis and not borrow someone else's. A family you cannot explain in your own words is one you will not retire at the right time.
What an instance record contains, and how to name it
An instance record is long on purpose, because it must be enough to reproduce the result. If you cannot rerun the instance from its record alone, the record is incomplete.
Two habits make this work. First, never edit an instance after it has produced results. Change a parameter and you get a new version number, with the old one frozen. It feels fussy for a week and saves you months. A result can only be trusted if you know which settings made it.
Second, make the ID carry a little meaning without becoming a sentence. A short family code, an index letter, an entry time and a version is enough to tell at a glance what a file is. Avoid words like "final", "new" and "best". They stop being true the next day, and nobody can tell which "final" came last.
Counting your bets: why twelve instances may be three
Here is the most useful thing the split gives you. It tells you how many independent bets you hold.
Imagine a library of twelve live instances. On the surface that looks like diversification. Look at the family column and it changes. Suppose nine of the twelve are the same short-straddle family, entered at 09:20, 09:25 and 09:30, on NIFTY with three slightly different stop widths. Those nine are close to one bet. On a day when spot runs hard in one direction, all nine are hurt at once, and by about the same amount. The other three might be a strangle on SENSEX, a hedged version and a late-day entry. So the real count is perhaps three or four, not twelve.
The size rule follows. If you size each instance as though it were independent, your true exposure to the family is the sum of all the near-copies. Here is illustrative working. Suppose each of nine near-identical instances trades one lot, and each loses Rs 2,000 at its stop on a bad day. Taken one at a time, Rs 2,000 sounds small. Taken together, the family loses 9 x 2,000 = Rs 18,000 on the same day. If your daily limit was Rs 10,000, the library breaks it while every instance obeys its own rule.
So set limits at the family level as well as the instance level. A family cap says: all live instances of this family together may not risk more than X on one day. That one line is what stops a pile of small copies from turning into a single large position.
There is a second use of the count. When you look at past results, ask how many independent observations they contain. An instance and its near-copies share the same sessions and the same market moves, so they do not add evidence. Nine copies of one idea tested on the same 80 sessions is still 80 sessions of evidence, not 720. In the desk study cited here, there were 163 expiry sessions across both indexes, about 80 for each. That sets the ceiling on how much any family tested on that period can tell you, however many variants you generate.
Writing expected behaviour down before you go live
A library is only useful if it can tell you when something is wrong. That needs a written description of what normal looks like for each family, set before the live trading begins. Without it, every bad week is open to argument and every good week looks like skill.
Expected behaviour should be about the shape of outcomes, not only the average. The desk study gives a good example of the kind of baseline to record. For a short ATM straddle entered at 09:20 on expiry day, over 159 usable sessions, the median give-back from peak profit to the close was 42.8%. On 86 of 159 days (54%) the position gave back more than 30% of its peak, and on 78 days (49%) more than half. On 48 days (30%), a trade that had been in profit at some point finished at a loss.
These numbers are not a target. They are a description of how that structure has behaved in a stated sample. Once recorded, they give you something to compare live results against. If a live instance of that family never gives anything back, or if it gives back far more than the baseline on most days, then either the instance differs from the tested version or the market has changed. Both are worth knowing about. Neither would be visible if you only tracked the sum of profit and loss.
The same applies to premium behaviour through the day. The study found that the average ATM straddle premium dropped from 100% of its 09:16 level to about 88.6% by 11:16 and then moved sideways, in a band of roughly 88% to 93%, for the rest of the afternoon. The strike is fixed at the 09:20 level while spot keeps moving, so decay is offset by re-pricing. A family record for a short straddle can therefore say: do not expect a steady slide in the afternoon. If your afternoon exit logic assumes the slide, the record shows why it may disappoint.
Write three or four such lines per family. Keep each one checkable: a measure, a baseline, the sample it came from, and the size of deviation that triggers a look. Avoid vague lines like "should perform well in calm markets".
Status: a lifecycle every instance passes through
Most libraries fail because status is implied rather than recorded. Something is "kind of running", or "paused for now", or "I think we stopped that". A short fixed list of statuses removes the ambiguity.
The shadow stage is worth the effort. Running an instance on live data without sending orders shows you what the research number hides: how the live feed differs from the history, what the fills would have looked like, and how the rules behave on a day you did not test. Because expiry days come once a week per index, a shadow period of 20 sessions takes about five months on a single index. That is long, which is exactly why it is worth saying out loud and planning for.
Every status change gets a date and a one-line reason. The reason is the part people skip, and the part you will want in a year. "Moved to watch: three of last four sessions breached give-back baseline" tells you what you knew when you decided.
Retirement rules: decide before you are losing
Retirement is where a library earns its keep. It is also where emotions do the most damage. Nobody wants to retire an instance after a losing week, because it might be the week before it recovers. Nobody wants to keep one after a winning month, because it is a bad time to be unsentimental about it. The fix is to write the rules while you are calm.
Good retirement rules have four features. They are written before the instance goes live. They are numeric where possible. They separate instance-level triggers from family-level triggers. And they allow for noise.
The noise point deserves an illustration, because it catches many people. Suppose an instance wins 55% of its sessions. The chance of four losing sessions in a row is 0.45 to the power of four, which is about 4.1%. That looks rare. But with 20 instances in a library, the chance that at least one of them shows such a four-session losing run in a given window is 1 minus 0.959 to the power of 20, about 57%. These are illustrative figures, with independence assumed for simplicity, but the lesson holds: with enough instances, odd streaks are normal. A rule that retires "anything with four losers in a row" will retire healthy instances all the time.
Better rules look at more evidence. Some examples of the kinds of rule to write, with thresholds set by you:
- A drawdown limit for each instance, expressed in rupees at its normal size. Hitting it moves the instance to watch, not straight to retired.
- A comparison against the written expected behaviour. For example, the live give-back median sits above the baseline by a stated margin over a stated number of sessions.
- A minimum evidence window. No retirement decision on fewer than a set number of sessions, unless a hard limit is hit.
- A family-level review whenever more than a stated share of its instances are on watch at the same time. That pattern points at the family's thesis, not at the individual settings.
Note how the last rule uses the family level. If one instance struggles, the setting may be at fault. If most instances of a family struggle at once, the reason may be wrong, or the market may have shifted. The two cases need different responses. Retiring one setting is housekeeping. Re-examining the thesis is a research task, and it should be logged as one.
Keep retired entries. Move them to an archive with the reason code and the data they were tested on. A year later you will either want to check why you stopped, or someone will propose the same idea again. The archive turns a repeated mistake into a one-line answer.
Reason codes help
Use a short list of codes for retirement reasons, for example: thesis broken, costs too high, replaced by a better version, capacity or liquidity limit, rule or contract change, never reached live size. After a year of entries, the count of reasons tells you something about your process. If most retirements are "never reached live size", your research stage is passing too many ideas. If most are "thesis broken", your family writing is too optimistic.
Review rhythm: small, regular and boring
A library stays useful through a light routine, not through big clean-ups. Three cycles are enough.
Weekly, after the expiry sessions: update the status table for anything that changed, and record live results against the baseline for each live family. This takes minutes if the structure is in place.
Monthly: check family caps against what is actually running, review anything in watch, and look at costs. Costs deserve a regular look because they eat edge quietly. Brokerage, exchange charges and slippage all change, and an instance that cleared its test at one cost level may not clear it at another.
Quarterly: re-read every family record and ask whether the thesis still holds, whether any kill condition has been met, and whether the contract and rule environment has changed. The exchanges and the regulator publish updates that matter here, including contract specifications and expiry arrangements, so check current notices at nseindia.com rather than relying on memory. A reminder from recent years: the regulator's one-weekly-expiry-per-exchange rule ended Bank Nifty weekly expiries, which left NIFTY and SENSEX as the weekly index option contracts. Any family that assumed another weekly contract had to be rewritten. That is exactly the kind of event a family-level kill condition should name.
Keep the whole library in one place that you can read in ten minutes. A spreadsheet with one tab for families and one for instances is enough. If you find that you need a database, the likely cause is that you have too many near-copies, which brings the discussion back to the counting problem above.
Frequently Asked Questions
What is the difference between an algo strategy and a strategy variant?
A strategy, or family, is the idea and the reason the trade earns money, such as selling at-the-money options to collect decay. A variant, or instance, is one exact version with a specific index, times, stop and size. Results belong to instances, while the reasoning belongs to the family.
How many algo strategies should I run at once?
Count families, not files. Several near-identical versions of one idea behave like a single bet on a bad day. Start with the number of independent families you can monitor properly, and set a combined loss cap for each family as well as for each instance.
When should I stop using an algo strategy?
When a rule you wrote in advance says so. Good rules use rupee drawdown limits, a comparison with the expected behaviour you recorded, and a minimum number of sessions before judging. Avoid retiring on a short losing streak, since with many instances such streaks happen by chance.
What should I track for each algo strategy?
For each instance: ID, parent family, index, entry and exit times, strike rule, stop rule, size, costs assumed, data period tested, status with date and reason, and a change log. For each family: thesis, structure, exposure, regime notes and kill conditions.
Is it better to have one strategy or many?
It depends on what you can monitor and how independent they really are. Many near-copies add paperwork and concentrated risk without adding evidence. A few genuinely different families, each with clear caps and written expectations, are easier to manage than a large pile of tweaks.
How long should I paper trade a new algo strategy?
Long enough to see more than a handful of expiry sessions. With one weekly expiry per index, 20 sessions takes about five months on a single index. Set the number before you start, compare the result with your research figures, and write down what difference would make you change your mind.
Conclusion
A strategy library is two lists, not one. Families hold the reasons, with their exposures and kill conditions. Instances hold the settings, with their results, costs and status. Keeping them apart lets you count your real bets, cap risk at the right level, write down what normal looks like, and retire things by rule instead of by mood.
Start small. Take your current folder, sort every file under a family, freeze the versions that have produced results, and write a status and a reason next to each. You will probably find fewer independent ideas than you thought. That is not a failure. It is the first useful thing the library tells you.
Algo trading carries a real risk of loss, and expiry-day option selling can lose more than the premium collected. EliteAlgo is analytical software and not an investment adviser, and nothing in this article is investment advice. All worked examples, thresholds and records above are illustrative.
