Designing an event-aware strategy: a checklist
what you'll learn · The six concrete steps for taking an event-aware idea from hypothesis to defensible-cost strategy on the alphakernel platform.
A working note that pulls the event-clock research into one recipe. Six steps from 'I have an event hypothesis' to 'I have a strategy whose cost I can defend.' The four prior notes are the why; this is the how.
Four prior notes circle the event-clock surface from different angles: why it exists, when a risk gate earns its cost, how to measure that with a 3-arm shape, and why narrow capture windows fail on diffuse signals. This note is the how-to: six steps from an event hypothesis to a strategy whose cost the operator can defend.
1. Name the event kind and the silver shape it lives in
alphakernel has three event kinds today: event_release (FOMC,
earnings, NFP), event_post (social-media + news), event_quote
(prediction markets). Every event-aware strategy starts with
which one — the silver schema, the vendor adapter, the
bitemporal contract differ across them. If your hypothesis is
“FOMC drift,” it’s event_release. “Musk effect” is event_post.
“Kalshi vs Polymarket arbitrage” is event_quote. Cross-kind
strategies are out of scope until each single-kind path is solid.
Operator check: ak data ingest-<vendor> lands silver under
base/source=<vendor>/event=<kind>/snapshot=*/. If the path
doesn’t exist, the adapter does; if the adapter doesn’t exist,
write it first (ADR-0028 — the cost tier of the adapter is part
of the decision, not a deferred concern).
2. State the hypothesis as a window + a direction
Two facts about your event:
- Window: the time-from-event range over which your hypothesis predicts non-baseline returns. “24 hours pre-FOMC,” “the 4-hour post-FOMC drift window,” “the 30-minute window after a tweet from an account with > 1M followers.”
- Direction: what should happen to whom, when. “Pre-FOMC, positions get hurt by vol — flatten.” “Post-FOMC, recent winners drift further — long them.” “Post-Musk-tweet, the cited stock rallies.” Be specific enough that a stranger can write the opposite.
The two together are the wrapper config. They’re also the spec the 3-arm A/B will measure against.
3. Decide whether you’re gating or capturing
Two shapes, two questions to ask the data:
- Gate (flat-inside): “Should the panel signal not trade
during this window?” — the
dont-pay-for-caution-you-cant-justifytest applies. The signal must have no event-specific edge to defend, and the cost must be tractable. - Capture (trade-inside): “Is there alpha in the window that
the panel signal isn’t already capturing through its regular
cadence?” — the
event-aware-needs-signal-concentrationtest applies. The signal must be concentrated in the window, not diffuse across the surrounding days.
The two shapes are inverses. Often the right answer is “do the A/B for both” — the third arm tells you which (if either) the data supports.
4. Write the wrapper
For the gate or capture shape, alphakernel ships canonical wrappers
under alphakernel/exec/strategies.py:
XsMomentumWithFomcBlackoutStrategy— gate, pre-event, flat-inside.XsMomentumPostFomcDriftStrategy— capture, post-event, trade-inside.
A new event kind needs a new wrapper class. The pattern is
straightforward: read event_table at init, project to the columns
your filter needs, look up the relevant event per tick, gate or
delegate to the inner panel signal. Both shipped wrappers use the
same cited_event_artifacts per-tick mutable so the ADR-0031
cooldown rule sees the citation.
5. Run the 3-arm A/B with the wrapper, its inverse, and the bare baseline
examples/fomc_blackout_compare.py is the template. Three arms
(baseline + your wrapper + its inverse), same panel signal under
the wrappers, same backtest harness. Multi-seed mode (--n-seeds N)
is the noise floor — anything within the stdev across seeds is
indistinguishable from luck. If your wrapper’s mean-Δ vs baseline
is smaller than the cross-seed stdev, you don’t have a result; you
have a possibility.
The synthetic data is the second variable. Run with
--fomc-drift-bps 0 (isotropic — no signal) and --fomc-drift-bps 50 (directional — there’s a signal). The 2×2 of (signal present,
signal absent) × (wrapper, inverse) is what the
the-baseline-arm-you-forgot
decision table reads.
6. Document what you measured — and what it didn’t tell you
The artifacts the platform expects:
- PR description quoting the result table verbatim (seed, days, drift bps, per-arm mean Sharpe + stdev, mean-Δ vs baseline). The table is your evidence; without it the PR is opinion.
- Research note in
/writing/if the finding generalises — “this wrapper shape doesn’t capture diffuse drift” is worth saving even when it’s a negative result. - Strategy citation (
cites: [research-note-slug]) so the audit trail points at the document that justifies the wrapper’s existence. Strategies withoutcitesregister only with an explicitintent="exerciser"orintent="experiment"(ADR-0015).
A strategy that ships without all three has weaker evidence than one that ships with all three. The platform doesn’t enforce that distinction — it just makes it visible to whoever reads the citation graph six months from now.
What this rules out
- Shipping the wrapper without the A/B. Operator’s prerogative in personal accounts; in any audited setting it’s structural ambiguity about why the wrapper exists.
- Shipping the A/B without the inverse. Two arms tell you whether the wrapper moves the number, not whether the data has anything for the wrapper to capture. The 3-arm shape is the cheapest way to know.
- Shipping a single-seed result as evidence. One seed is one draw from the strategy’s PnL distribution. Five seeds are five. The Sharpe stdev across seeds is usually larger than any wrapper’s mean-Δ; assume that until proven otherwise.
The platform’s job is to make all six steps cheap. The operator’s job is to do all six.