RCLM Signals: Pattern Reference and Calculation Logic

RCLM Signals turn captured AI sessions into investigation leads. A signal is not a verdict by itself; it is a pattern with enough evidence to justify opening the underlying sessions, files, teams, or projects. Signals are calculated from captured session metadata, tool calls, project attribution, team membership, policy snapshots, and similarity scores. The backend evaluates each pattern over a trailing 7-day period, writes a score for evaluated patterns, and only creates an open signal when that pattern crosses its threshold.

​

How to read a signal

Each pattern has four useful parts: Most signals link to a session list. The right workflow is: open the signal, inspect examples, decide whether this is a habit issue, project artifact issue, team process issue, or org policy issue.

​

Pattern summary

​

P1 — Restart churn

Meaning: A developer repeatedly starts new sessions on the same project shortly after the previous session ended. This usually means work is being restarted instead of handed off cleanly. How it is calculated: RCLM orders sessions by start time for each user and project. It compares each session’s ended_at to the next session’s started_at.

• Gaps under 10 seconds are treated as automatic restarts, such as compaction, crash recovery, or tool relaunch.
• Gaps from 10 seconds up to 30 minutes are treated as deliberate restart pairs.
• The signal fires when one project reaches 3 deliberate restart pairs in the weekly period.

Example: A developer works on billing-api, ends a session, and starts another billing-api session 8 minutes later. That happens four times in the week. P1 fires because the project crossed the 3 deliberate-restart threshold. Admin action: Improve handoff behavior or project instructions. If the examples look like legitimate crash/relaunch behavior, fix tooling instead of coaching the user.

​

P2 — Groundhog files

Meaning: The same file is read again and again across sessions. This usually points to missing durable project context. How it is calculated: RCLM scans normalized tool calls for file reads. It includes native read tools and common shell reads such as sed, rg, nl, cat, head, and tail, then canonicalizes paths so absolute and relative forms map together. The signal fires when the same canonical file is read in at least 3 sessions for a project. Example: server/auth.py is opened in five separate sessions by three contributors. P2 fires for that project and includes the file path plus sample session ids. Admin action: Add durable project context: a CLAUDE.md note, project README section, or a file_brief workflow that explains why this file matters and when to touch it.

​

P3 — Exploration without landing

Meaning: A session spends heavily on reading, searching, or shell exploration but produces few or no edits. How it is calculated: RCLM counts exploration tool calls and edit tool calls per session.

• Exploration includes read/search tools plus shell search/read families such as rg, find, cat, and grep.
• Edits include edit/write/apply-patch style tools.
• A session must have at least 15 exploration calls to be evaluated.
• The signal fires when the exploration-to-edit ratio is at least 10:1.

Example: A user runs 48 reads/searches and makes 2 edits. The ratio is 24:1, so P3 fires and points to the worst session. Admin action: Tighten prompts and entry points. Ask users to name the file, symptom, failing command, or suspected module instead of starting from a broad goal.

​

P4 — Session idle gaps

Meaning: The assistant responded, then the next user prompt did not arrive until much later. This is a session-finding signal for waiting, review delays, interruptions, or abandoned work. How it is calculated: RCLM reads each session’s assistant-to-next-user gap list. A session qualifies when at least one gap is strictly greater than the configured threshold.

• The default threshold is 20 minutes.
• Enterprise admins can configure the threshold in org settings.
• P4 counts affected sessions, not teams.
• There is no minimum number of qualifying gaps; one long wait in a session is enough.

Example: The assistant finishes at 10:00. The user sends the next prompt at 10:27. With a 20-minute threshold, that session qualifies. If the same user has two qualifying sessions in the period, P4 reports two waiting sessions for that user. Admin action: Open the linked sessions. If the waits are caused by interruptions, suggest handoffs before stepping away. If they are normal review time, raise the threshold. If many users show the same pattern, define a team handoff convention.

​

P5 — Session bloat

Meaning: A session keeps going after it has already passed the user’s normal completion size, while context input continues growing. How it is calculated: RCLM builds a per-user baseline from previous sessions with turn-level input token data.

• It calculates the user’s p75 turn count.
• It calculates the user’s typical completion input-token level.
• A current session is flagged when its turn count is at least 1.5× the user’s p75, input grows monotonically, and the session continues after crossing the typical completion level.
• At least 3 baseline sessions are required.

Example: A user’s p75 session length is 20 turns. A current session runs 36 turns, keeps adding input tokens, and crosses the user’s typical completion token load at turn 18 but continues for many more turns. P5 fires. Admin action: Set a handoff policy for long sessions. The fix is usually to split the work or create a handoff before the context window becomes expensive and brittle.

​

P6 — Compression policy drift

Meaning: The organization expects supported compression mechanisms to enforce, but active sessions are still running with those mechanisms off or observe-only. How it is calculated: RCLM inspects the effective hook policy snapshot uploaded with sessions. A session is counted as drifted when:

• the snapshot says compression enforcement is required;
• a supported mechanism is enabled;
• that mechanism’s mode is not enforce.

A team P6 signal fires when at least 3 sessions in that team show drift. An org-level P6 signal fires when at least half of active teams are affected, or when org-only sessions meet the drift threshold. Example: The org requires read-cache enforcement, but five sessions in the Platform team report read_cache as observe. P6 fires for that team and shows the drifted mechanisms plus affected sessions. Admin action: Restore the org hook policy, ask affected users to start a new session so policy sync runs, then update stale hook installations if drift continues.

​

P7 — Project onboarding cost

Meaning: New contributors on a project spend materially more tokens than veteran contributors doing similar work. How it is calculated: RCLM groups sessions by project, contributor, and session category.

• A contributor’s first 5 sessions on a project are treated as onboarding sessions.
• Later sessions are treated as veteran baseline sessions.
• The comparison is category-matched, such as fix-to-fix or feature-to-feature.
• A category needs at least 5 veteran sessions before it can be evaluated.
• The signal fires when onboarding average tokens are at least 2× the veteran baseline.

Example: New contributors average 80k tokens on fix sessions for a project, while veterans average 32k tokens for comparable fix sessions. The ratio is 2.5×, so P7 fires. Admin action: Build a project context pack. Focus on setup, architecture map, common files, local test commands, and known pitfalls.

​

P8 — Cross-team duplicated work

Meaning: Two teams appear to be doing substantially similar work without reusing or finding the earlier result. How it is calculated: RCLM uses session similarity rows and supporting session metadata. A pair qualifies only when:

• the final similarity score is at least 0.86;
• either semantic similarity or file-overlap score is at least 0.50;
• both sessions belong to different teams;
• categories match when both sessions have a category.

The org-level signal fires when at least 2 qualifying duplicate pairs exist in the period. Example: Team A and Team B both modify the same payment retry flow in separate sessions. The sessions score 0.90 overall similarity with strong file overlap. A second similar pair appears later that week. P8 fires for the org. Admin action: Make prior work discoverable. Use shared project memory, better session search practices, or team conventions for recording completed investigations.

​

P9 — Context-weight burn

Meaning: A session carries far more cached context through each tool call than that user’s sessions normally do. How it is calculated: RCLM uses provider-reported cache-read tokens and tool-call counts.

• It calculates context weight as cache_read_tokens / tool_call_count.
• It compares current sessions to the member’s own baseline.
• At least 3 baseline sessions are required.
• The signal fires when the worst current session is at least 2× the user’s baseline context weight.
• Sessions without provider-reported cache usage are excluded.

Example: A user’s normal context weight is 4k cache-read tokens per tool call. One current session carries 11k per tool call. The ratio is 2.75×, so P9 fires. Admin action: Split heavy sessions, use handoff, or delegate broad exploration to a subagent so the main session stops carrying excess context.

​

P10 — Model-task mismatch

Meaning: A user is repeatedly using a more expensive model where comparable work is usually completed with a lighter model. How it is calculated: RCLM compares sessions within the same user, project, and session category. A mismatch candidate requires:

• at least 5 sessions on the expensive model for that user/project/category;
• at least 5 matched sessions on a lighter model;
• lighter-model median turns no more than 1.20× the expensive model’s median turns;
• lighter-model success rate within 10 percentage points of the expensive model’s success rate;
• lighter-model median tokens no more than 1.25× the expensive model’s median tokens.

The signal fires when at least one candidate exists for the user. Example: A user has 8 fix sessions on a premium model and 7 comparable fix sessions on a mid-tier model in the same project. The mid-tier model uses similar turns, has similar code-change success, and does not use materially more tokens. P10 fires and shows the expensive model, lighter model, and matching sessions. Admin action: Set model-selection guidance. This should not force a downgrade for every task; it identifies repeatable cases where a lighter model appears good enough.

​

Scope and escalation

Some signals start at member scope but can become project, team, or org issues when they repeat broadly.

​

Interpreting counts

Counts mean different things by pattern:

​

Practical admin workflow

​

Limits to keep in mind

• Signals depend on captured sessions. Missing ingestion means missing evidence.
• Session timestamps can show waiting, but not the reason for waiting.
• Provider-reported token/cache data is required for some patterns, especially P9.
• Similarity-based signals such as P8 are intentionally conservative to avoid false positives.
• Model guidance from P10 is comparative, not a guarantee that the lighter model is always safe for future work.

​

Automated alerts & notifications

Enterprise orgs can receive tiered email for signals and anomalies:

• Immediate P0 for acute AD-004 / AD-003 findings (with 4-hour throttle and severity escalation)
• Daily digest at 08:00 recipient-local time
• Weekly executive digest on Mondays at 08:00 local (signal counts, anomaly highlights, DLP protection rate)

Admins configure org routing (including a security inbox that always gets AD-004 Critical). Every member can set My alerts preferences. Email bodies follow a zero-exfiltration allowlist — no session titles, paths, or prompts. Configure from the Signals tab or Organization Settings. Full workflow: Signals Dashboard → Email alerts & notification cadence.