The Intelligence Feed

The intelligence feed is the part of a planning agent team that keeps the events ledger: a scout agent that gathers internal intelligence (go-lives, releases, outages, training pulls), external intelligence (weather, holidays, news, a client's announcements) and business asks, proposes each as an event with a type, a date, an effect window and a grade, and matches events to forecast misses when the daily clock runs. The page's claim is that most forecast misses in a service operation are explained by events the operation knew about and never wrote down, and that a ledger with effect windows turns that knowledge into something a forecaster can use, provided the match is written as association and not as cause. This page gives the event record, the scout's rules, the matching rule and the grade.

Why a ledger and not a calendar

Every planning function has a calendar of known events and most of it is in people's heads. A calendar entry has a date; an event record has a type, a window over which it is expected to affect demand or supply, a grade for how well it is known, and a link to the misses it has been matched to. The difference is what a forecaster can do with it. A regression with intervention terms needs a start, an end and a shape for each event; a holiday adjustment needs a window; a level-shift test needs a date. A calendar supplies none of that; a ledger supplies all of it, in the form Workforce Demand Signal Architecture describes as a signal schema and this series keeps as a file.

The event record

Field	Holds	Rule
ID	A permanent code	Never reused
Type	One of a closed list: go-live · release · outage · training pull · holiday · weather · client event · product change · marketing · business ask · other	A value outside the list is an error to raise
Source	Internal (which team or system) or external (which feed or announcement)	Named; "someone said" is not a source
Date	When it happened or will happen	Absolute dates only; relative dates resolved at intake
Effect window	Start and end of the period over which the event is expected to affect demand or supply, and which; open-ended is permitted with a review date	The window is a hypothesis about effect, not a record of the event's duration; an outage of two hours may have a window of two days
Expected effect	Direction and, where known, rough size, on which metrics and channels	Graded like any number; usually [E] or [A] at proposal
Grade	[A] proposed by the scout; [M] once a person confirms the event happened; the effect keeps its own grade	The event's existence and the event's effect are graded separately
Matched to	The forecast versions and misses this event has been matched against, with the match's rung	Always rung 1 from the scout; a causal claim is on the register row, not here
Confirmed by	The person who confirmed it, and when	Required before the forecaster may use it

The scout's rules

• Propose, never confirm. The scout writes [A]. A person moves the record to [M]. A confirmed event is one that happened; whether it did anything is a separate question.
• Every miss gets a search. On each daily run the scout reads the post-analyst's variance record and searches the ledger for events whose window covers the miss. It reports the matches, and it reports "no event in the ledger covers this miss" as a finding in its own right, because an unexplained miss is what opens a register row.
• Screen, do not explain. The scout may run a correlation screen between an event's window and a metric's movement and report the result as association. It may not write that the event explains the miss. That sentence belongs to the causal analyst, and it is written only after a test.
• Business asks are events. A request from a business leader for a change in service hours, a client's stated intention to move volume, a commercial commitment made in a renewal: each is an event with an effect window, and the ledger is where the forecaster learns of it before the forecast is wrong.
• External feeds are sources, not truth. A weather forecast is [A] until the day; a holiday calendar is [M] once confirmed against the operation's own closure schedule, because public holidays and service closures are not the same list.

Matching without claiming cause

The distinction the page turns on is the one the epidemiological literature stated for association and causation long before machine learning made it urgent: temporal precedence and co-occurrence are necessary for a causal claim and are nowhere near sufficient. A go-live on Monday and a handle-time rise on Monday are matched. A causal claim requires the diagram and the test that Hypothesis Testing with Agent Teams describes, and the register row is where the claim lives. The ledger's "matched to" field records the match and its rung so that a later reader can see that the match was association and can find the row where it became more.

The rule protects the forecaster from the commonest error in event-adjusted forecasting: adjusting for every event that co-occurred with a miss, which builds a forecast that explains the past perfectly and the future not at all. An event enters the forecast's assumption register only when a register row has graded its effect at least Inferred, and the register row cites the ledger.

Worked example

The series example. On Wednesday 4 March 2026 the scout finds no event whose window covers the third day's handle-time rise and proposes "phase 1 go-live, partner cohort," type go-live, source "migration plan, internal," date Monday 2 March, window open-ended from 2 March with a review date at phase 2, expected effect "handle time up, voice, size unknown" [A]. The planner confirms the event that afternoon; the record moves to [M] for existence, the effect stays [A]. The register row that asks whether the rise is structural or transitional cites the event.

On Thursday 9 April the scout reads Wednesday's variance record, a voice service-level miss with an 11 percent staffing shortfall, and finds the real-time team's event proposal "training pull, 8 to 9 April, voice, in-house cohort," confirmed by the planner on Wednesday afternoon. It matches the miss to the event at rung 1 and reports it. The forecaster, reading the match, excludes 8 and 9 April from the trend estimate for the next version and records the exclusion in the assumption register with the event's ID. No causal claim was made anywhere; a two-day supply-side break was kept out of a demand trend, which is all the ledger needed to do.

Later in April a public-holiday week arrives. The holiday is in the ledger at [M] with a window from the operation's own closure calendar; the forecaster's holiday adjustment reads it. The same week, an external weather feed proposes a storm day at [A]; the scout matches it to nothing until the day, and on the day the real-time issuer confirms a 30 percent volume drop on voice with the storm's window; the forecaster excludes the day. Forecasting practice treats these as regressors or as intervention terms; what the ledger supplies is the input those methods assume exists.

What would change this

The claim that most misses are explained by known-but-unwritten events is a practitioner observation, not a measured finding; a function that kept the ledger for a year and found most misses unmatched would weaken it and would argue for investment in the forecast model rather than in the ledger. The separation of event existence from event effect is a design rule that would only be dropped if a function found its planners unable to keep the two apart in practice. The ledger's type list is a starting point and should be revised from the operation's own history.

How this connects

The events ledger is one of the Living Ledgers; the scout is a roster role on The Agent Team Model; its daily match is step 3 of The Short-Term Forecasting Loop with an Agent Team; the real-time issuer's proposals from Real-Time Agents are its richest internal source; and the register row that turns a match into a graded claim is on The Question Register and Knowledge Base and Hypothesis Testing with Agent Teams. The signal plumbing the feed grows into is Workforce Demand Signal Architecture, and the human process that manages known events in advance is Event Management.

Maturity Model Position

A shared calendar of known events is Level 2 on the WFM Labs Maturity Model™. A typed ledger with effect windows, grades and matches, read by the forecaster, is Level 3, and the event-to-register-to-assumption path is the Level 4 discipline of a forecast whose every driver has a grade. The forecast's precision improves as the ledger fills; a Level 4 function's model card cites the ledger.

See Also

• AI Agent Teams for Workforce Management — the series hub
• Living Ledgers — the events ledger among the others
• The Short-Term Forecasting Loop with an Agent Team — the daily match
• Real-Time Agents — the issuer's event proposals
• Hypothesis Testing with Agent Teams — where a match becomes a graded claim
• Workforce Demand Signal Architecture — the signal schema and event-driven plumbing
• Event Management — managing known events in advance
• Reforecast and Rolling Forecast Methodology — trigger-based revision