Catalyst Calendar

Catalyst Calendar

A calendar of dates is a list; a catalyst calendar is a decision-pressure ranking. An event earns its place because it can move the estimate path, the narrative, the multiple, position size, the downside case, liquidity, or the odds of another event. Proximity alone ranks nothing: a high-materiality readout in eleven weeks outranks a routine print on Thursday, and the routine print belongs in a hygiene block.

Evidence labels, source tiers, staleness, the readiness posture and the intake limits: .agents/skills/research-conventions/SKILL.md, read before the first deliverable.

Step 1: Scope the universe

Settle four things, taking the mandate and horizon from memory per .agents/skills/research-conventions/references/intake.md and asking only about what it leaves open:

• The universe: tickers, a portfolio or watchlist file, a sector, or an index.
• The horizon: the next two weeks, a month, a quarter, or through the next reporting season.
• Whether macro releases and policy dates are in scope, or only issuer events.
• Whether the output goes to the desk or outside it, which decides the externally clean rule in step 7.

With nothing supplied, ask for one of those four concrete inputs and say what the default calendar will contain once it arrives (a rolling ninety days, issuer events plus the macro releases that bind the sector).

Done when the universe resolves to a named list of issuers, the horizon has dates, and the macro decision is recorded and the destination is recorded as desk or external.

Step 2: Gather events and classify by investment path

Pull live rather than recalling:

• Macro MCP: get_earnings_calendar(from_date, to_date) for every reporter in the window, and get_economic_calendar(from_date, to_date) for releases and policy dates.
• get_company_overview for the issuer's reporting history and consensus context.
• WebSearch and WebFetch for the events no calendar feed carries: regulatory dockets, trial readouts, conference agendas, lockup schedules, contract expiries.

Company, regulator and exchange sources override an aggregator. When two sources disagree on a date, keep both, mark the row's confidence at the lower level, and write the disagreement as a conflict-register row per .agents/skills/research-conventions/references/evidence.md.

Event groups

Earnings and financial: quarterly results with session (pre-market, post-close), annual meeting, investor or capital-markets day, guidance updates, debt maturities and refinancings, dividend and buyback authorisations.

Corporate: product launches, regulatory decisions and their preceding milestones, contract renewals and expirations, M&A milestones (shareholder vote, regulatory clearance, close), management transitions, litigation dates.

Industry: conferences and which issuers present, trade shows, comment periods and rulings, recurring industry data (monthly sales, traffic, channel checks).

Macro: policy meetings, labour, inflation and growth releases, central bank decisions elsewhere, scheduled geopolitical dates.

Index and passive flow: index additions, deletions, rebalances and reconstitutions; lockup expiries; secondaries and block trades; convertible issuance and conversion; buyback blackout windows; float changes. Each carries the fields that make it assessable: expected flow in shares and in days of average daily volume, the holder base behind the supply, and the float change in percentage points. This group is mechanical supply and demand, so it is kept apart from anything fundamental in the write-up.

Classify by the path, not the headline

The classification decides what the row must contain to be useful, so it happens as the event is captured. A merger date needs the spread, the implied probability and the break-price arithmetic; a spin needs a parts-based value and a forced-selling estimate; an activist date needs the vote arithmetic; a litigation date needs merits, timing, damages and the settlement path; a flow event needs flow against average daily volume. Per-class core questions, required outputs and the must-extract list from the primary document: .agents/skills/catalyst-calendar/references/event-lenses.md, read when a captured event falls outside the earnings and macro classes you already handle, and again when a P1 row needs the action block of step 5 filled.

Timing fields

Every row carries a date type and a date confidence, kept separate because a rumoured hard date and a company-guided window fail differently.

A window renders as its span everywhere it appears, including a calendar export, and the export carries only rows whose date type is hard. Presenting "second half" as one Tuesday manufactures a date the issuer never gave.

An undated row keeps the event: undated thesis-critical events go to a review table with what would date them (a statutory clock, a filing, a conference agenda), not to the cutting-room floor.

Source metadata per row: source name, retrieval date, the publication date of the date itself when it differs, and a last-checked timestamp.

Done when every captured event carries a category, a class, a date type, a date confidence and its source metadata, and every undated thesis-critical event sits in the review table.

Step 3: Score materiality and actionability

Two independent one-to-five scores, combined by judgement rather than multiplied:

• Materiality: how much the event can move the estimate path, the narrative, the multiple, the downside case, position size, liquidity, or the probability of a later event. A 5 changes the thesis; a 1 changes nothing we track.
• Actionability: how much we can do about it. A 5 has prep time, a tradable expression and the inputs a decision needs; a 1 is a fact we learn afterwards.

Priority is P1, P2 or P3, written with the sentence that justifies it. A high-materiality, low-actionability event is still P1 when its outcome resets the model.

Escalators. Any one of these promotes an event above its base score, and the row names which fired:

1. It lands within a week and the prep is not done.
2. Date confidence is low while materiality is high.
3. It collides with another portfolio-critical event.
4. Expected volatility is high or the name trades thinly.
5. The market setup is one-sided (crowded positioning, a stretched multiple, consensus clustered).
6. The asymmetry is not reflected in consensus.
7. It can trigger follow-on catalysts.
8. Missing data is blocking a clean risk decision.

Clustering. Flag every date carrying events for two or more correlated positions, and flag the week where portfolio-level event risk concentrates. A cluster is its own catalyst.

Done when every row carries both scores, a priority with its one-line justification, the escalators that fired, and a clustering flag where a date is shared.

Step 4: Build the calendar

Canonical fields per event, all of them in the workbook, the readable subset in the markdown view:

event_id (stable across refreshes), issuer and ticker, category and subcategory, event name, one-line description, date, date type, date confidence, session and time zone, source, retrieval date, date publication date, last checked, materiality, actionability, priority, escalators fired, expected outcome, what to watch for variance, prep required, prep owner, prep due date, follow-up date, decision implication, post-event action.

Markdown view:

Routine dates that nothing hangs on group into a hygiene block underneath, listed but unranked.

Done when every row shows its date type and confidence beside the date, every window row shows a span, and every P1 and P2 row names the decision it supports.