Intelligence
Jobs
The runner that keeps saved models, reports and feeds current without anyone asking.
Who it is for
Analysts, general manager, anyone who saved a model.
How this is handled today
Keeping work current is somebody's Sunday. Reports get re-run by hand, models get re-fit when a person remembers, and the whole arrangement depends on one analyst being available.
The failure mode is silent. A board that quietly serves last week's numbers as though they were this week's is worse than a board that is visibly down, because people act on it.
What changes
Saved work plus a trigger, and the useful trigger is usually arrival rather than a clock. Nobody wants a board recomputed at three in the morning. They want it recomputed when Saturday's charting lands.
Every run keeps a receipt of what it read and what it wrote, and a job that cannot reach a source fails loudly and marks the surface stale with the reason attached instead of publishing half an answer.
What you do here
- Recompute a saved model whenever the data behind it lands
- Run a report on a schedule and publish it to the surface that needs it
- Hold a run for approval before anything it produces goes live
- Show what ran, what it produced, what it cost and what failed
What it reads
- Everything the role permits
What a job actually is
A job is a saved piece of work plus a trigger. The work is something a person already built on another surface: a scoring model from the Model Lab, a report, a feed ingest. The trigger is either a clock or an event, and in practice the event is the useful one. Nobody wants a board recomputed at 3am on a Tuesday. They want it recomputed the moment Saturday's charting lands.
That distinction matters because a program's week is not evenly paced. Data arrives in a burst after games, then trickles. Jobs that fire on arrival keep a Sunday morning board honest without anyone remembering to press anything.
The four triggers
The default. A job runs when a feed it depends on delivers new rows. A fit model recomputes when the week's production lands, not on a guess about when that might be.
For work that is genuinely time-based: a Monday personnel report, a nightly recruiting sync.
When a person edits the thing underneath. Re-weighting a saved model reruns every board that model drives.
Someone presses run. Useful when a coach wants a board current before a meeting that starts in ten minutes.
Every run keeps its receipt
A run records what triggered it, what it read, how long it took, what it wrote and who owns it. That is the same owner, state, evidence and approval record the rest of the store carries, applied to machine work rather than human work.
The practical version: when a figure on a board looks wrong, you can open the run that produced it and see the inputs. A number whose lineage you cannot reconstruct is a number nobody should act on.
Failure is a state, not a silence
A job that cannot reach a source does not publish a partial answer. It fails loudly, holds the previous result, and marks the surface as stale with the reason attached. A board that quietly served last week's numbers as though they were this week's would be worse than a board that admits it is behind.
Runs that produce figures a role is not cleared to see never reach that role. Scoping is applied at the store, so a job cannot leak a cap figure into a position coach's report by accident.
Approval gates
Some output should not go live because a clock said so. A job can be set to hold: it runs, produces its result, and waits for a named person to approve before anything publishes. The approval is recorded with what the approver saw at the time, which is the only version of an audit trail that is worth keeping.