Anchor plans (signal-vs-signal benchmarks)
Most benchmarks compare a signal against a set of trade outcomes: you point a signal at a return dataset and the EDA charts ask whether the signal's value at entry lines up with how those trades performed. An anchor plan is the other case. Here the benchmark is not a trade outcome, it is another signal: a target market quantity you already track, like intraday realized volatility. You are asking whether your candidate signal predicts that quantity. When the benchmark is a signal, the two series live on their own timelines, and a fair comparison needs one agreed schedule for reading them. The anchor plan is that schedule. It fixes how and when comparison observations are sampled, and every EDA chart on the tab reads from the observation set it produces.
What an anchor plan is
When you set a signal's benchmark to another signal rather than a return dataset, the platform asks you to set an Anchor Plan: how and when to sample the comparison observations. A plan is a sample time and a cadence, for example "sample observations once per day at 9:35am." That schedule turns two continuously updating series into one aligned set of paired readings, and that set is what every EDA chart on the tab is built from.
The anchor signal is the target. In the intraday volatility workflow, it is a signal you save first ("Intraday Realized Volatility," a measure of how much the market actually moved during the session). Each predictor signal you build afterward, the overnight gap, the VIX level, the IV rank, prior-day realized vol, is then read against that anchor at the sampled times. One observation per day at 9:35am gives you one pair per day: the predictor's 9:35 value and the anchor's 9:35 value.
Anchor plan versus return-dataset benchmark
Both are benchmark contexts. The difference is what sits on the comparison axis and, from that, what question the EDA charts answer.
The return dataset already carries its own entries and their timing, so the observation set is the trades themselves and no anchor plan is needed. A signal has no entries, only a continuous line, so the anchor plan supplies the timing the return dataset would otherwise have given you.
Why sampling has to be pinned
Two signals rarely share a cadence. One might update every minute, another might be meaningful only once a day at the open. Compare them without an agreed schedule and you are reading values snapped at inconsistent times, which quietly changes the relationship you think you are measuring. The anchor plan removes that ambiguity by naming a single observation schedule that both series are read on.
Pinning the schedule also keeps a tab set consistent. Once you set the benchmark and the anchor plan on the first predictor tab, every other predictor tab inherits the benchmark context and the anchor plan automatically. All of them read on the same daily observation set, so their EDA charts are comparable to each other and, later, so the model that combines them trains on one coherent set of paired readings instead of a mix of schedules.
Setting an anchor
You set an anchor from the benchmark context selector on the Signal tab, the same place you would pick a return dataset. Choosing a saved signal as the benchmark instead of a return dataset is what prompts the platform for an Anchor Plan, and the plan is two settings: the sample time and the cadence, for example once per day at 9:35am. From there the tab behaves like any other benchmarked tab. The inheritance badge carries the same three states described in benchmark context and the inheritance badge: Project default when the context comes from the project, Overridden in this tab when you set it here, and Copied from [tab name] when you copied it from another tab. The anchor plan travels with the benchmark context, so a tab that inherits the context inherits the schedule too.
Reading an anchored chart
An anchored EDA chart reads the same way as a return-dataset chart, with the anchor signal's sampled value where a trade return would sit. Each point on the scatter is one sampled observation: your candidate signal on the x-axis, the anchor signal on the y-axis, both read at the anchor plan's sample time. A clean upward or downward slope means the candidate carries information about the target quantity at that time of day. The decile chart groups the sampled observations by candidate value and shows the average anchor value in each group, so a staircase confirms the direction.
The trap here is the anchor itself. When you benchmark against a return dataset, the y-axis is a settled trade outcome. When you benchmark against a signal, the y-axis is only as trustworthy as that signal's own estimate at the sampled time. Anchor to a signal that is itself noisy at 9:35am and a real relationship can wash out into a flat cloud, or noise in the anchor can dress itself up as a slope. Before you trust an anchored chart, confirm the anchor signal is a stable, meaningful reading at the sample time you chose, not a value that is still settling.
Aligning two signals
Two signals are aligned on the union spine with backward as-of fill before they are compared. The output spine is the sorted union of both series' timestamps, and each side carries its most recent value forward onto that spine (see the execution model). A faster and a slower signal are therefore compared at the union of their ticks, with any timestamp that precedes a series' first observation reading as null for that series, and null on either side making the paired reading null. The anchor plan sits on top of this: it selects which timestamps become comparison observations, so the alignment is deliberate instead of an artifact of whichever series happened to tick last. Choose a sample time where both the candidate and the anchor have a real, recent value, or the fill carries stale readings into the comparison.