Record AR-BRN-001…103 · Framework architecture
Entry is the part you chose.
Management is the part that decides.
A branch is a management population: one identifiable way of carrying a trade from fill to close. A single entry rule feeding four management populations is four strategies sharing a signal, and this page is about what that costs, what it buys, and how to keep the four separable in the record.
Why a strategy is rarely
one population.
The branch is the unit at which management decisions become measurable. Below it you are studying individual trades; above it you are studying an average that no single decision produced.
Ask a trader to describe their system and you will get an entry. Ask them what they did with the last twenty trades after the fill and you will usually get several answers: some were taken off at a target, some were scaled at the first checkpoint and trailed, a few were held whole because the move looked unusual, and one or two were taken outside the normal allowance because the week felt strong. That is not one strategy with noise in it. That is four populations, each with its own hit rate, its own dispersion and its own reason to fail — being averaged into a single expectancy number that belongs to none of them.
The averaging is the problem. Expectancy is linear, so a blended figure will always look like a weighted mix of its parts. Everything else is not. Drawdown depth is produced by sequences, and a population with a high hit rate and a thin right tail generates completely different sequences from one with a low hit rate and a fat one. Blend them and the resulting drawdown belongs to the mixture, not to any component — which means when the mixture deteriorates you cannot say which component did it.
Worse, the failure is usually silent for a long time. A tail-dependent population can run twenty trades below its own expectation without being distinguishable from bad luck, because twenty trades is nothing at that variance. Meanwhile the stable population continues to produce results, the blended curve keeps rising slowly, and the deterioration is discovered a quarter later than it needed to be. Separating the populations does not make anyone more profitable. It makes the diagnosis available earlier, which is a different and more defensible claim.
The averaging trap
Two populations, twenty trades each, blended into one line. The blend is positive. One of the two components is not, and the blended record does not contain the information needed to tell.
| Read | Trades | Mean R | Interpretation |
|---|---|---|---|
| Blended | 40 | +0.18 | “The system works.” |
| Population A | 28 | +0.41 | Carrying the whole result. |
| Population B | 12 | −0.36 | Invisible inside the blend. |
Arithmetic illustration only. No dataset is behind these three rows.
What a branch is not
A branch is not an instrument, a timeframe, a session or a setup grade. Those are attributes of a trade. A branch is the management contract the trade is placed under at the moment of entry — and it must be fixed at entry, not chosen later when the outcome starts to become visible.
Primitive branches carry risk.
Composites only carry information.
Four primitive populations are defined at entry and receive an allocation. Three composite views are arithmetic over those populations. Confusing the two is the most common structural error in this layer.
Primitive — AR.BRANCHES
A primitive branch is declared before the fill. It has an activation condition, a stop model, an exit model, a target profile and a weight in the allocation. It is the only object on this page that can consume capacity, and it is the only object that can be switched off.
Composite — AR.COMPOSITES
A composite is a lens. It sums outcomes that have already been produced by primitive branches and presents them as one series. It has no activation, no stop, no allocation and no ability to reject a trade. Removing a composite from the dashboard changes nothing about what the account is doing.
Composite masking
Because a composite is dominated by whichever primitive contributes the most trades, a deteriorating low-frequency population can be invisible in every composite view while being obvious in its own. Composites are for reading the system; primitives are for diagnosing it.
The bench: same engine,
four management contracts.
Select a population to load its record, redraw the network scene, and evaluate a configuration that differs from the others only in activation strictness and exit management. Nothing about the entry logic changes between selections.
Branch network
The scene is decorative. Node density stands for relative trade count and node spread for outcome dispersion; both are stated numerically in the panels below.
Modelled behaviour of the selected population
Interactive demonstration — not a historical backtestDistribution of modelled per-trade results in R for the selected population.
Simulated demonstration data
This visualization illustrates proposed product behaviour and does not represent historical, live, or guaranteed trading performance. The four populations are the same preview engine evaluated under four sets of management parameters; see the methodology block below for the exact overrides used.
A weight is a promise
about trade count.
Baseline weights describe how a week's opportunity is intended to be distributed across the four populations. They are a design target, not an outcome — the market decides how many of each actually activate.
Three readings of the same allocation: the baseline weight in percent, the resulting trade count in a sixteen-trade week, and each population's share of the risk actually deployed across that week. The third row is the one that surprises people — because Overflow carries a reduced per-trade risk here, its trade share and its risk share are not the same number.
The baseline splits the trend allocation three to one between the partial and no-partial populations, so the tail specialist is deliberately the smallest of the three core branches. That is not a judgement about its quality. It is a judgement about its variance: at roughly an eighth of the weekly count it can have a poor month without dominating the record, and it still receives enough trades over a year for the shape of its distribution to become visible.
Overflow sits outside the core three at a tenth of the count and, in this preview, at a reduced per-trade risk. Supplemental exposure that carries the same risk as core exposure is not supplemental — it is simply a higher concurrency limit with a story attached.
| Population | Weight | Trades / 16 | Rounding note |
|---|
Sixteen is the weekly throughput used by the example cycle architecture on the trade-flow page. At any other throughput the counts change; the weights do not.
Where rounding actually hurts
Eleven and a quarter percent of sixteen trades is 1.8 trades. Rounded to two, the no-partial population is over-weighted by eleven percent every week; rounded to one, it is under-weighted by forty-four percent and its annual sample halves. Neither is wrong, but the choice must be made once and recorded, because silently alternating between them makes the branch's measured expectancy a function of the rounding rule rather than of the market.
Which population is
actually paying for the week?
Contribution is weight multiplied by per-trade expectancy multiplied by the risk that population is permitted to carry. All three terms matter, and the branch with the best per-trade number is frequently not the branch producing the most account-level return.
Contribution in account-R per sixteen-trade week under the preview engine.
The mean of each population's worst ten percent of trades against the mean of its best ten percent. The left-hand markers are almost identical — the stop is the stop, and management does not change what being wrong costs. Only the right-hand markers separate, which is the entire case for having more than one management contract.
| Population | Net EV (R) | Capture | Tail index | Outcomes ≥ 2.5R | Dispersion (SD R) | Modelled DD | Trades / week |
|---|
Reading the tail index against the distribution
Tail participation is an index built from parameter shape, not a measurement of the realised distribution. It reads late trail activation as evidence of tail exposure — which is correct for the trend populations, and misleading for Normal, where late activation is used to switch trailing off rather than to extend a runner. Where the index and the outcome column disagree, the outcome column is the authority. This is exactly the kind of disagreement a decomposed record makes visible and a blended one hides.
Branches that share an entry
share a failure mode.
Four populations is not four independent bets. They are four exit policies applied to one signal generator, so anything that breaks the signal breaks all four at once.
Assumed correlation of weekly outcomes between the four primitive populations. These are design assumptions used by the preview, not measurements: they encode the structural claim that shared entry logic and shared activation conditions produce shared drawdowns.
The highest assumed figure sits between Trend Partial and Trend No-Partial, because those two populations share both an entry and an activation family — they differ only in whether the first checkpoint removes size. When directional authority is misclassified, they are wrong together, and the apparent diversification between them evaporates in exactly the week you were relying on it.
The lowest figure sits between Normal and Overflow, and even that is not low. Overflow is a permission, not a different edge: it fires on the same setups the core populations recognise, simply beyond the standard concurrency allowance. Treating it as an uncorrelated sleeve is a category error that shows up as a wider-than-expected worst week.
The practical consequence is that branch diversification is a management benefit, not a risk benefit. It improves attribution, it smooths the distribution of outcomes in ordinary conditions, and it does almost nothing for you in a regime break. Diversification that survives a regime break has to come from somewhere else — different edges, different instruments, different time horizons.
The variant layer sits on top,
and changes nothing about identity.
Five management overlays arranged on two axes. The branch decides what the trade is. The variant decides only how aggressively that decision is expressed.
Two axes are in play and they are easy to conflate. The time axis moves when things happen: when protection engages, when the first monetisation occurs, when the trail activates. The exposure axis moves how much size remains in the trade after each of those events, without changing their timing.
Keeping them separate matters because they fail differently. A time-aggressive setting fails by holding a decaying trade too long; an exposure-aggressive setting fails by carrying too much size through an ordinary retracement. They can produce a similar loss in a single trade and require completely different corrections.
No selection playbook is published
The mapping from measured conditions to a specific variant is calibration, and calibration is where a system is either sound or fitted to its own history. Publishing a fixed branch-by-variant playbook would present one set of thresholds as universal, invite it to be applied to instruments and horizons it was never derived on, and remove the step that actually matters — deriving the mapping on your own record and validating that it survives resequencing. The grid below therefore describes the direction of each combination and stops there.
| Branch ↓ / Variant → | Time-Cons. | Exp-Cons. | Standard | Exp-Agg. | Time-Agg. |
|---|
Directional description only. Cells state what a combination does to the branch's outcome shape, not when to select it.
Six ways a branch
architecture goes wrong.
Each of these has a cause, a signature in the data, and a repair that is usually structural rather than parametric. None of them is visible in a blended equity curve until it is expensive.
None of this is measurable
unless it is tagged at entry.
Branch attribution is a data problem before it is an analysis problem. A field that can be edited after the outcome is known is not evidence.
Branch EV = Σ(net outcome R) ÷ trades tagged to that branch
Trivial arithmetic, entirely dependent on the denominator being honest. If a trade is retagged after the fact — moved from Normal to Trend No-Partial because it ran, or out of Overflow because it lost — both numerator and denominator are corrupted, and the corruption is systematically in the flattering direction.
The single most common data failure
Retrospective branch assignment. It requires no dishonest intent — the trade genuinely did behave like a trend trade — and it makes every branch look better than it is while making the architecture untestable. A branch tag written after the close carries no information about the decision that was actually made.
Minimum viable record
Branch id, variant id, activation evidence, planned stop distance in price and in R, and a timestamp for each — all written before the position is live. Five fields, captured once, make every measurement on this page possible. Their absence makes all of them guesses.
How the branch preview works.
Stated in full so the figures above can be checked against the claim, rather than taken on trust.
Every population on this page is the same preview engine, evaluated four times with four sets of parameters. There is no per-branch model, no per-branch dataset and no per-branch tuning. The differences you see in Figures 1, 3, 4 and in the comparison table are produced entirely by the overrides listed opposite, applied to a single shared archetype — Pullback Continuation on a thirty-minute trigger with a four-hour authority timeframe.
Each population is evaluated standalone: the engine is asked what this management contract would do if it had the entire book, the whole concurrency allowance and all of the available signal. That is why the per-branch trade frequencies in the comparison table do not sum to the sixteen-trade week used in the allocation section. The sixteen-trade week is an architecture; the frequencies are four separate what-if evaluations, and mixing the two would be a category error.
Each branch's outcome series is generated by the same deterministic seeded routine used everywhere else on the site: no random number generator is called at page level, so the same selection always produces the same figure. The composite views are built by drawing from the primitive series in proportion to the baseline weights, shuffling deterministically, and walking the resulting sequence through an equity path — which is why a composite's drawdown is not the weighted average of its components' drawdowns, and should not be expected to be.
The correlation matrix in Figure 5 is different in kind from the rest. It is not derived from the engine at all; it is a set of stated design assumptions about how populations sharing an entry behave together. It is included because the assumption has to be visible to be argued with.
A model of relationships, not a measurement
This preview answers one question: if management is loosened in this direction, what else moves and which way. It reads no market data, no broker history and no trade journal, and it cannot tell you whether any of these populations is profitable in your market. Treat the ordering of the figures as the claim; treat the specific decimals as illustration.
Parameter overrides by population
| Parameter | Nrm | T·P | T·NP | Ovf |
|---|
All other parameters are held at the engine defaults for all four populations.
What this page
cannot tell you.
Listed because a research page that does not state its own boundaries is marketing.
Sample, not structure
The no-partial population receives roughly an eighth of the weekly count. At that rate a year produces a sample in which the shape of the right tail is still poorly estimated. Any conclusion about it from a single year is dominated by which moves happened to occur.
Weights are assumptions
The baseline split is a design choice presented for illustration. It is not derived from your instrument, your session, your cost structure or your holding horizon, and it should not be adopted without deriving it again on your own record.
Correlation is asserted
Figure 5 contains assumptions, not measurements. Real branch co-movement has to be estimated from tagged trades, will differ by regime, and will be highest exactly when it matters most.
One archetype
Every figure here uses a single strategy archetype. A breakout or mean-reversion framework will place its populations differently on the same plane, and some frameworks legitimately support only one branch.
Execution is idealised
The preview charges spread, slippage and commission against the working stop but does not model partial fills, rejected orders, or the behaviour of a trailing stop through a gap — all of which fall hardest on the populations that hold longest.
Calibration is not published
The activation thresholds, weighting rules and variant selection logic used by the MARS workbook family are part of that product and are described here structurally rather than numerically.
Where the branch layer
connects to everything else.
Trade flow and exposure
Branch weights are meaningless without slots to put the trades in. The trade-flow module converts concurrency, open-risk ceilings and correlation limits into how many of each population you can actually run.
Parameter laboratory
Every override on this page is a control on that bench. Change partial percentage or trail activation there and you are constructing a branch, whether or not you call it one.
Execution intelligence
Capture efficiency and giveback are the measurements that tell you whether a branch's exit policy is doing what it was designed to do, or quietly becoming a different branch.
MARS intelligence
Branch permission is rank five in the authority stack. Which populations are eligible is decided above signal quality and below the drawdown gate.
Development register
Branch attribution is the module we are building next.
Per-branch expectancy, contribution and correlation computed from an uploaded trade history — with the tagging discipline enforced at intake rather than assumed. Founding researchers see it first and decide what the diagnostic has to answer.
What is not promised
No launch date, no guaranteed invitation and no performance claim. Registration records interest and nothing more.