Under the Hood: How a FIRE Score Gets Made

In short: Fit is your ICP compiled and kept fresh, and it can never top-tier an account on its own. Intent is named, timestamped motion, not a black-box surge. Recency is a learnable decay, so scores fall on silence. Engagement is reveal with match confidence attached, consent-first. The four combine into account- and contact-level scores, and every action writes a decision trace, which is what makes the score debuggable, ownable, and measurable by holdout.

Last time I made the argument that your ICP is a starting line, not a strategy, and that the question deciding your CAC is the one a static list can't answer: who's actually in motion this week, and how do you know?

The honest follow-up question I got, mostly from ops people, was some version of: fine, but how? Scoring systems have overpromised for fifteen years. So this post is the mechanics: what each dimension is actually computed from, where the fragile parts are, and what makes the loop trustworthy enough to hand to an agent.

Fit: your ICP doc, compiled

Fit is the least glamorous dimension and the one most teams already half-have. The work is turning the ICP from prose into scored attributes: industry and sub-vertical, employee band, funding stage, detected stack, data maturity signals. Nothing here is exotic. The difference is that Fit gets computed continuously against fresh firmographic and technographic data rather than frozen at list-build time.

Two design choices matter. First, Fit is deliberately slow-moving; a company's fundamentals shouldn't jitter week to week, and a scoring system that lets them jitter trains your team to ignore it. Second, Fit alone can never push an account into the top tier. A perfect-fit company with no motion is a nurture candidate, not a priority. Encoding that rule is what stops the score from degenerating back into the static list you started with.

Intent: motion, from sources you can name

Intent watches for change: hiring patterns (three demand gen roles posted in a month means something a single posting doesn't), funding events, tech migrations and certifications, content and community activity, competitive displacement signals. Each signal type carries its own weight and its own reliability profile.

The design principle here is attributability. Every intent point that moves a score must trace back to a named, timestamped signal: "careers page added 3 growth roles on July 2," not "surge detected." That sounds like a compliance nicety. It isn't. It's what makes the score debuggable when it's wrong, and it's the raw material for the personalization that comes later: an email can reference a hiring pattern; it cannot credibly reference a black-box surge.

Recency: the decay function nobody ships

Recency is less a dimension than a discipline applied to the other three: every signal has a half-life. A pricing-page visit is scorching for a week, warm for a month, and near-worthless at a quarter. A funding round stays relevant longer; a conference badge scan, barely days.

Decay rates differ by signal type, and, crucially, they're learnable. If your closed-won deals consistently show intent signals within 45 days of first touch, the system should tighten half-lives toward that window. Most stacks fail here in a specific, familiar way: scores only accumulate. An account that engaged heavily in Q1 and vanished still tops the list in Q3, and your SDRs work a graveyard. If you take one diagnostic from this post: check whether anything in your stack ever makes a score go down on silence alone.

Engagement: reveal, with the caveats attached

Engagement measures contact with you: site visits, ad views, sequence opens, community presence. The hard part is that most of it starts anonymous, which is where website and ad reveal come in: resolving anonymous traffic to accounts, and where identity allows, to contacts, so the director reading your pricing page twice this week is visible instead of hypothetical.

I said this in Part 1 and it bears repeating with more precision, because ops people have been burned by reveal vendors. Resolution is probabilistic. Account-level resolution (IP intelligence, firmographic matching) is meaningfully more reliable than contact-level, and the system treats them differently: match confidence is a first-class attribute that travels with every resolved signal and discounts its contribution to the score. A 90%-confidence resolution and a 55%-confidence one are not the same evidence, and a system that launders them into the same "engaged!" flag is manufacturing false precision.

And it runs consent-first: the Consent Capital argument from Part 1 applies with full force. Engagement you're entitled to observe is defensible under GDPR, under scrutiny, under your own brand's standards. Reveal that can't survive a privacy review isn't intelligence; it's liability with a dashboard.

This part isn't hypothetical, for what it's worth. It's the same machinery running in production at ReversingLabs, where visitor intelligence resolves in real time into BigQuery and writes back to Salesforce contacts, so their growth team acts on live engagement rather than last month's export.

Composition: two scores, not one

The four dimensions combine into a weighted composite, but at two resolutions, and the distinction is the whole point.

The account-level score answers which companies this week. It aggregates fit and intent across the org and rolls contact engagement upward. The contact-level score answers which people inside them, because the VP who attended your webinar and the VP who's never heard of you need different messages, different channels, and different spend, even though they share a firmographic profile.

Weights start from a sensible prior, but they're not sacred. Which brings us to the part that separates a scoring feature from a learning system.

Decision traces: the loop's memory

Every time the score triggers an action, whether an account jumps the queue, a sequence fires, or spend concentrates, the system writes a decision trace: which signals, at what confidence, produced what score, which triggered what action, which produced what outcome. A durable, queryable record.

Traces do two jobs. The first is trust. When your CFO points at the top of the queue and asks "why this account?", the answer is a record you can open, not "the model said so." When the score is wrong, and every score is sometimes wrong, the trace shows you which signal misled it, which is the difference between tuning a system and superstitiously rebuilding it.

The second job is learning. Traces are the training data for the loop itself. Closed-won deals reveal which signal patterns actually preceded revenue; closed-lost and gone-quiet accounts reveal which patterns were noise. Those outcomes retrain the composite's weights and the decay rates, on your market, from your results. The ownership argument from Part 1 lands here in its most literal form: the learning is a table in your warehouse, not a line in a vendor's changelog.

One more thing traces make possible, and it's the claim most scoring vendors can't back: incrementality. "The system learns" is exactly the shape of promise that attribution and MMM tools spent a decade breaking trust with. The check is a holdout, and because every action is traced, you know precisely which accounts the loop touched and which it didn't. Hold out a slice of the queue, run the loop against the rest, compare pipeline. Lift becomes something you measure, not something you assert. A scoring system that can't tell you which accounts it touched can't run that test; a traced one can't avoid it.

Why agents make all of this non-optional

A human SDR compensates for a mediocre score with judgment: they eyeball the account, sense something's off, skip it. An agent doesn't. It executes the queue at machine speed, judgment not included. That inverts the requirements: for agentic GTM, the score's transparency matters as much as its accuracy. An agent acting on "score 8.4 because hiring signal (July 2, high confidence) plus resolved pricing visit (July 9, 87% match)" can write outreach that references reality. An agent acting on "surge score: high" writes confident fiction.

The same traces that let your CFO audit the queue are what let an agent act on it safely, and what let you audit the agent afterward. One substrate, humans and agents reading from it and writing back to it. That's the architecture behind the phrase "always-on intelligence": not a smarter list, but a system where every action makes the next decision slightly better, and every decision can explain itself.

Next in the series: Part 3: Activation That Uses the Evidence. How contextual segmentation and messaging get generated from the trace evidence itself, so the email a contact receives is built from the same signals that made them a priority.

FAQ

How is a FIRE Score actually calculated? It combines four dimensions into a weighted composite: Fit (ICP match), Intent (named, timestamped signals of motion), Recency (a decay function so older signals count for less), and Engagement (contact with you, resolved from anonymous traffic with a match-confidence score attached). It is computed at both the account and contact level.

What is a decision trace? A decision trace is a durable, queryable record of which signals, at what confidence, produced a score, what action it triggered, and what outcome followed. Traces make the score debuggable when it is wrong, and they are the training data that retrains the weights on your own results.

How do you measure whether a scoring system actually works? With a holdout. Because every action is traced, you know exactly which accounts the loop touched and which it did not, so you can hold out a slice of the queue, run the loop against the rest, and compare pipeline. Lift becomes something you measure, not something you assert.

Series: Always-On Intelligence · Part 1 · Part 2 · Part 3