How nima decides

nima makes four decisions without asking you: what kind of thing a signal is, where the signal belongs, how a beacon ranks, and when a beacon is ready for a person to look at. This page lists the rules behind each one, with the numbers.

Two of the decisions are judgment calls by a language model: labeling a signal, and choosing whether a signal joins a beacon or starts a new one. Ranking and readiness are arithmetic.

Signal classification and impact

nima labels each signal with one classification and an impact after an extraction pass that runs shortly after the signal arrives. Until that pass finishes the signal has neither.

Eight classification labels exist, but nima's extractor only ever assigns three of them: bug, feature_request and spec_drift. The other five exist so a signal can carry them and you can filter on them.

Impact is low, medium or high. The extractor also pulls out stakeholders and product areas from the text. Impact and stakeholders feed the beacon rank.

Noise dismissal and the topics nima always keeps

nima dismisses a signal its extractor judges to be noise, with the dismiss reason noise, except when the signal's topics mention money or legal exposure. A signal whose product areas or intent mention any of these words is kept as actionable even if the model called it noise:

pricing, price, discount, compliance, soc 2, soc2, gdpr, hipaa, contract, contracts, terms, legal, msa, dpa, loi, success fee.

The rule is a fixed keyword check, not a model instruction. In a Slack channel set to auto-skip, a noise signal is dismissed with reason auto_skip and hidden from every signal list, including the dismissed ones.

Extraction limits per signal

nima runs extraction on a signal at most 3 times, ever, and stops once the cumulative model cost for that signal reaches USD 0.25. Every reply in the signal's Slack thread runs extraction again on the same signal, so a busy thread uses up that budget. The next attempt after either cap moves the signal to failed, even if an earlier run already classified it; the classification stays on the signal. A single extraction job is also cut off after 60 seconds.

Signal origin: internal, external or customer

Every signal carries an origin of internal, external or customer, which says whose words it is. nima infers the origin from the integration that produced the signal. Most sources are resolved when the signal is read; Granola, Linear, ClickUp and HubSpot decide the origin when they create the signal, from the attendees, the request type, the custom field or the account.

HubSpot signal ingestion is rolling out; ask the nima team to turn it on for your workspace.

Attendees without an email address are ignored for Granola. If the person who connected the Granola key uses a free-mail address, every attendee at another domain counts as outside.

You can override the inferred origin on a single signal with PATCH /v1/signals/:id. That route needs a signed-in session (any member); API keys and MCP tokens get 403. There is no MCP tool or Slack action for it yet; ask the nima team if you only hold an API key. See Signals.

Placing a signal into a beacon

nima places each classified signal that is not already in a beacon (status ready) on its own, in a background pass that starts about 60 seconds after signals arrive. A pass handles at most 25 signals, oldest first, and schedules another pass when it filled up and placed something.

The pass has two steps for each signal.

1. Shortlist by similarity. Open beacons whose evidence is similar to the signal at cosine similarity 0.45 or higher become candidates, at most 6. Held, promoted and dismissed beacons are never candidates.
2. A model judge chooses. The judge answers join (one of the offered beacons), form (start a new beacon, titled as an imperative) or dismiss. Its instruction is: when unsure, form. A join that names a beacon that was not offered becomes form.

dismiss currently has no effect on the signal. nima turns it into form, so a signal the judge would drop still gets a beacon.

Signals that carry an incident fingerprint skip the judge. An error report with the same fingerprint and scope as an existing repair beacon joins that beacon, including a held beacon or a promoted one whose spec has not shipped yet. Otherwise it starts a new fix beacon.

A signal belongs to at most one beacon. Adding it to another beacon moves it, except that a signal behind a promoted beacon cannot be moved.

Beacon disposition: fix or decide

nima stamps every beacon it forms with a disposition. fix means the evidence describes something plainly broken with no product decision left. decide covers everything else and is the default when nima is unsure. Disposition is a label on the beacon, and it is what nima's optional auto-promotion looks at (see What nima does not do automatically).

Beacon rank formula

A beacon's rank is a whole number from 0 to 100, recomputed whenever its evidence changes. It is not recomputed on a schedule, so recency reflects the last time the beacon's evidence changed, not today.

The formula:

score = round(100 × (0.35·severity + 0.30·reach + 0.20·weight + 0.15·recency))

Producer weight by source

Producer weight says how much a source counts as evidence. A production error tracker outweighs a remark in Slack.

Worked example of a beacon rank

Four signals about one checkout failure, each with a single event: two Slack messages, one manual entry, one Sentry issue. One is high impact. Four distinct stakeholders in all, counting the people who reported each signal. The newest evidence is three days old.

severity = 1.0                          (one high-impact member)
reach    = 4 ÷ 6 = 0.667                (four distinct stakeholders)
weight   = (0.5 + 0.5 + 0.7 + 0.8) ÷ 4 = 0.625
recency  = 1 − 3 ÷ 30 = 0.900

score = round(100 × (0.35×1.0 + 0.30×0.667 + 0.20×0.625 + 0.15×0.900))
      = round(100 × (0.350 + 0.200 + 0.125 + 0.135))
      = 81

The same four signals as Slack messages at medium impact, naming two people, ten days old, score 51. Raising the highest-impact member from medium to high adds 14 points.

When a beacon becomes ready

A beacon moves from forming to ready by one of three paths, and which one applies depends on how the beacon was created.

An urgent incident is an open (not recovered) incident triage record with an error, severity critical, high or fatal, and outcome failed, terminal_failure, retry_exhausted, data_loss or unavailable.

For a person-grouped beacon, having 3 distinct signals marks the beacon as formed. That mark latches: removing evidence later does not un-form it. Three events on one signal count as one piece of evidence.

Held, promoted and dismissed beacons never change status when nima refreshes them, whatever their rank does.

The Grouping setting (Signals per beacon)

The Signals per beacon control under Grouping in the admin panel no longer affects anything. nima stores the value (beaconMinClusterSize, 2 or 3) but placement does not read it: the model judge and the rules above decide. Changing it does not change how signals group.

What nima does not do automatically

nima does not merge signals, merge beacons, start specs or dismiss beacons in a normal workspace. Three behaviors exist in the code but are off, and only the nima team can switch them on for the platform:

• Auto-promote. For a fix beacon, nima would start the spec itself, up to 3 per pass, under the workspace owner.
• Auto-dismiss. The judge's dismiss answer would park a non-ask on a beacon born held. Today dismiss becomes form.
• Daily and ship sweeps. A daily pass would hold suspected duplicate beacons and non-asks, and a shipped spec would hold the open beacons asking for what it delivered. Only a person could confirm a merge or dismissal.

In production, nima writes a spec only when a person promotes a beacon. See Anatomy of a spec.

Changing an outcome after nima decides

You can correct a decision, but only through signed-in session routes on the REST API. There is no MCP tool and no Slack action for any of these yet, and they need a signed-in session (any member); API keys and MCP tokens get 403. Ask the nima team if you only hold an API key.

• Signals. Edit classification, impact, stakeholders and origin with PATCH /v1/signals/:id, dismiss or restore a signal, and merge signals by hand.
• Beacons. Hold (a reason is required), dismiss, merge beacons, and add or remove member signals. Removing every member leaves an empty beacon instead of deleting it.

Impact and stakeholders are rank inputs, but editing them does not recompute the beacon on its own: the new values count the next time the beacon is refreshed, for example when a member is added or removed. A beacon stores its rank breakdown term by term, so you can see which term moved. Routes and scopes are on Signals and Beacons.