This glossary defines every recurring term in Signal, Power Digital's internal business-intelligence web app. Each entry states what the term means, where it appears in Signal, what system the number or concept originates from, and any caveats. Definitions are verified against the Signal codebase (staging @ 98df0c4, verified 2026-07-07) and the Signal module documentation pages. When two Signal views show slightly different values for the same term, the per-term caveats explain why.
Revenue & finance terms
These are the money metrics used across Signal (Power Digital's internal BI web app). Revenue and gross-profit figures originate in Vena, finance's planning system of record; Signal reads Vena data and never writes it.
MRR (Monthly Recurring Revenue)
Definition: monthly contracted recurring revenue. Signal uses MRR in two distinct senses: (1) company/client MRR — gross monthly revenue from active retainer contracts (e.g. the Summary view's MRR tile, the Churn Risk table's "Current MRR" column); (2) per-employee MRR ("book value") — the total monthly revenue of every client the employee is assigned to, counted once per client at FULL client value (not the employee's share), averaged over the selected months. Per-employee MRR is the primary KPI for Account Director, Sr Account Director, and Account Manager roles.
Where it appears: Summary (/summary) KPI tile, Employees (/employees), Staffing (/staffing), Capacity Planning (/capacity, /company-capacity), KPI Targets (/kpi-targets, as a target), Churn Risk (/predictions/churn), Portfolio Review (/predictions/portfolio), ETCR (/etcr).
Source/basis: Vena contract revenue; per-employee book value additionally uses Nova/Signal team assignments to know which clients an employee touches.
Caveats: an Account Manager's MRR is much larger than their attributed revenue (RPE) because MRR counts whole client relationships. VABO clients are excluded from per-employee MRR rollups on the Employees view.
RPE (Revenue Per Employee)
Definition: an individual employee's allocated share of client gross profit per month — each client's revenue is split across its team using allocation percentages (blueprint slices merged per client × department, revenue_split_overrides applied, consulting-role weighting for Consulting accounts), plus the employee's monthly-averaged VABO allocation, divided by the number of selected months. Primary KPI for Strategist and Sr Strategist roles. On org-level views (e.g. Summary, AI Solutions), "Avg RPE" means (revenue + VABO) ÷ employee count.
Where it appears: Summary (/summary), Employees (/employees), Staffing (/staffing), Capacity Planning (Role Capacity /capacity, Company Capacity /company-capacity), KPI Targets (as a target), AI Solutions (/solutions), Hiring Pipeline (/hiring).
Source/basis: Vena gross profit × Nova/Signal staffing assignments. Computed by the shared helper computeEmployeeRpe (src/utils/employeeRevenue.ts), used by Employees, Summary, and the Staffing simulator so views cannot drift.
Caveats: VABO is included in an individual's RPE actual but excluded from the RPE Trend chart on Company Capacity, so trend values are not directly comparable to individual actuals. RPE vs MRR: RPE answers "how much revenue is credited to this person"; MRR answers "how much business does this person touch."
MGP / Gross Profit
Definition: gross profit. MGP (Monthly Gross Profit) is the client-level monthly gross profit figure from Vena finance actuals, shown per client on client-health views. On the Divisional P&Ls view, Gross Profit = Revenue − COGS, computed on in-contract revenue (excluding shared-services revenue and VABO).
Where it appears: Churn Risk (/predictions/churn, MGP column), Portfolio Review (/predictions/portfolio), Summary (/summary, Gross Profit tile), Divisional P&Ls (/divisional-pl), Corrections (/corrections, as a flaggable field), Client Profitability (/profitability).
Source/basis: Vena finance actuals (Vena writes, Signal reads only).
Caveats: MGP can be $0 for new contracts before Finance posts actuals. Churn Risk shows two money columns by design: MGP/MRR/VABO from Vena vs a "Revenue" column from Nova contract data — they can legitimately diverge. VABO is excluded from Gross Profit and margin calculations on Divisional P&Ls.
VABO
Definition: performance-based revenue tracked by Finance in Vena, outside the standard retainer contract ("out-of-contract revenue uplift"). The canonical expansion of the acronym is not spelled out in the Signal codebase and is unconfirmed; treat it simply as performance-based revenue.
Where it appears: Summary (/summary, VABO tile), Churn Risk ("Last Month VABO" column), Portfolio Review, Divisional P&Ls (own row), Employees (VABO Allocations table in the employee drawer; vabo client tag), AI Solutions (per-employee breakdown).
Source/basis: Vena finance actuals, tracked per VASO arrangement. VABO credit attribution to employees is manual: VABO leads are assigned in Manage Leads; clients with no VABO leads are unattributed.
Caveats: VABO division attribution is finance-assigned, not client-division — a CPG client's VABO can sit in Shared Services. VABO is included in individual RPE but excluded from: Gross Profit/margins, the RPE Trend chart, In-Contract Revenue, and Employees-view revenue/MRR/seat rollups. Current-calendar-month VABO is substituted from a separate latest-VABO field because the Vena contracts table lags for the in-flight month.
Retention (retention rate)
Definition: the percentage of clients (or client revenue) retained over the period — Signal's client-retention KPI, computed by the server-side KPI engine and compared against role-based retention targets (typically 90–95%). Client-facing roles carry a retention benchmark alongside their RPE or MRR target.
Where it appears: Summary (/summary, Retention Rate tile and per-division badges), Employees (/employees, per person), KPI Targets (/kpi-targets, as a target), AI Solutions baseline/current cards.
Source/basis: actuals computed in server/vena-kpi-engine.ts from Vena contract data plus Nova client churn dates; targets parsed from the People-team KPI Google Sheet into signal_roles.retention_target.
Caveats: a missing retention target defaults to 90% in DataContext.tsx (code constant as of Jul 2026). Do not confuse retention rate with the "Division Forecast" view (route /predictions/retention), which shows human-declared renewal outcomes from the CSM renewal tracker sheet, not a computed retention rate.
Model scores & client-health terms
These terms come from the AI/ML team's weekly model pipeline, which runs outside the Signal repo. Signal displays the scores as-is and never recomputes them.
Churn score
Definition: a 0–1 score per active client estimating churn risk, produced weekly by the AI/ML team's churn model. Decomposed into three sub-scores: Client Profile Risk, Sentiment Risk, and Performance Risk. Risk bands (code constants as of Jul 2026): Critical ≥ 0.6, High 0.5–0.6, Medium 0.3–0.5, Low < 0.3.
Where it appears: Churn Risk (/predictions/churn, the ranked table), Portfolio Review (/predictions/portfolio, churn-risk column), Pulse Summary (risk category), AI Solutions (client-health baseline).
Source/basis: the AI/ML churn model (weekly pipeline; model outputs CHURN_SCORE and sub-scores), consuming contract timelines, invoice behavior, Gong call sentiment, Client Pulse submissions, performance pacing, and Salesforce pipeline activity.
Caveats: Signal passes scores through — no user or view can change them. New scores appear only when the weekly model run lands; API responses are additionally cached 15 minutes. A "priority client" on Churn Risk = churn score ≥ 0.5 AND top-25 by (score × monthly GP).
Expansion score (readiness score)
Definition: a 0–1 score per active client estimating readiness for a service-expansion conversation, produced weekly by the data-science pipeline, with Blueprints/Performance/Sentiment sub-scores and a model-owned "Is Ready" boolean.
Where it appears: Service Expansion (/predictions/se, ranking table + weekly history chart), Portfolio Review (expansion-readiness column, "SE-ready" briefing picks at readiness ≥ 0.7), Pulse Summary (SE pipeline status), AI Solutions (SE readiness baseline).
Source/basis: weekly ML readiness model, built from contract history, revenue performance, Gong/CSM sentiment, invoice health, and past deal behavior.
Caveats: the Service Expansion table displays the latest weekly historical snapshot per client (the primary model table can lag), while Portfolio Review uses the raw primary-model score — small cross-screen discrepancies are by design. A dismissed client auto-resurfaces when its score moves ≥ 0.15 from the dismissed score (default).
ETCR (Expansion-to-Churn Ratio)
Definition: closed service-expansion MRR divided by confirmed churned MRR. Company goal: 60% — for every dollar of confirmed MRR lost, at least 60 cents won back through expansion. Closed expansion MRR = retainer MRR + project revenue ÷ 6 (the ÷6 converts one-time project revenue to a monthly-recurring equivalent; frontend convention as of Jul 2026). Companion forecasts: ETCR Floor = SE Closed MRR ÷ Forecasted Churn MRR (worst case); ETCR Ceiling = Forecasted Expansion MRR ÷ Forecasted Churn MRR (best case).
Where it appears: ETCR (Beta) view (/etcr), shown per Account Director, Group Director, and Division, colored against the 60% goal.
Source/basis: Salesforce SE deal data and churn records assembled by the data pipeline; ETCR is the primary outcome metric of Power Digital's Service Expansion initiative.
Caveats: "Expansion-to-Churn Ratio" as the acronym expansion is consistent with the math but is not spelled out in the Signal codebase. A 0% ETCR (e.g. no churn recorded) is deliberately uncolored — red flagging applies only to non-zero ETCR below 60%.
Priority tiers (P1 / P2 / P3)
Definition: a pre-computed per-client priority tier from the data-science pipeline. UI labels: P1 — "Act now", P2 — "Plan this week", P3 — "Healthy / Monitor".
Where it appears: Portfolio Review (/predictions/portfolio) — priority chip, per-tier summary cards (count + MGP), grouping, and the "Your week" briefing strip (top-3 P1 clients by churn risk × retainer value).
Source/basis: the modeled feature set's PRIORITY_TIER field (data-science pipeline); Signal only displays it via fetchPriorityTierMap() in server/vena-kpi-engine.ts.
Caveats: the trigger rules live upstream with the data team and can change without an app deploy; the app repo does not define them. A client missing a tier silently defaults to P3 in the UI.
Pulse & planning terms
Signal contains two entirely separate "Pulse" workflows plus a quarterly planning record. Disambiguating them correctly is essential.
Pulse — Client Pulse vs Employee Pulse (disambiguation)
Client Pulse: a weekly client check-in that Account Directors and Group Directors record in Signal for each client they own — client sentiment, pacing to goal, goals established, and the client's own business performance. Entered on Submit Pulse Data (/pulse/submit, Team Lead+), self-audited on My Submissions (/pulse/my-submissions, Team Lead+), aggregated on Pulse Summary (/predictions/pulse-summary, Admin+), and consumed on Portfolio Review (Pulse Submitted flag, sentiment/pacing columns, Pulse History tab). Stored in Signal's own Supabase tables pulse_weekly_submissions and pulse_qbp_submissions. Client Pulse replaced the old Pulse Google Sheet.
Employee Pulse: a weekly employee check-in that Power Digital delivery employees submit in the Nova platform — personal sentiment, bandwidth, and hours spent per client. Signal only reads it: the Employee Pulse view (/pulse-coverage, Admin+) shows submission compliance and rolling 4-week sentiment/bandwidth trends; per-client Pulse hours also appear on the Employees view and feed Client Profitability. The Employee Pulse week runs Tuesday through Monday (deadline Monday evening).
Caveats: the two share a name but have different subjects (clients vs employees), different data entry systems (Signal vs Nova), different audiences, and different tables. "Pulse Summary" is Client Pulse only — quarterly QBP submissions are not shown there, and weekly Employee Pulse data never appears in the Client Pulse section.
QBP (Quarterly Business Plan)
Definition: a quarterly business plan record per client, submitted by Account Directors in Signal's Client Pulse section — quarter (format YYYY-Qn), QBP date, narrative URL, and presentation URL.
Where it appears: Submit Pulse Data (/pulse/submit, entry), My Submissions (/pulse/my-submissions, Quarterly tab), Portfolio Review (QBP Submitted flag and link columns; quarter derived from the selected week).
Source/basis: Signal's own records — the pulse_qbp_submissions Supabase table, written by users in Signal.
Caveats: QBP dates may be entered up to one year ahead (forward-looking QBP change, Jul 2026). QBP rows are NOT included in Pulse Summary (weekly pulses only). Voided QBP rows are soft-deleted and remain visible in My Submissions.
People & portfolio terms
These terms describe how Signal models clients, teams, and organizational structure. Client and org records originate in Nova (Power Digital's client/org platform); team-assignment overrides are Signal's own records.
Seats
Definition: a seat is one unique (employee, role) assignment on a client account. The "Total Seats" metric counts unique (employee, role) seats on accounts with Vena financial activity in the selected month(s).
Where it appears: Summary (/summary, Total Seats tile and Group-By breakdown), Employees (seat/client counts per person), AI Solutions (Seats baseline card).
Source/basis: Nova platform assignment history (CLIENT_ACCOUNT_ASSIGNMENT_HISTORY), joined to Vena revenue; overridden by Signal's own team_assignments records where a client's team is managed in Signal's Manage Leads.
Caveats: one person can hold multiple seats (different roles or different clients). Seats require financial activity in the month — an assignment on a dormant account does not count. VABO accounts are excluded from seat rollups on the Employees view.
Active book
Definition: the set of currently active (non-churned) clients. Client-health views show only the active book: churned/inactive clients are filtered out server-side before data reaches the browser (fetchActiveBook in server/activeBook.ts).
Where it appears: Portfolio Review (/predictions/portfolio — including the "Active Book MGP" summary card), Churn Risk, Service Expansion, POC Management.
Source/basis: Nova client records and churn dates, resolved server-side.
Caveats: because filtering is server-side, a recently churned client disappears from these views entirely rather than appearing greyed out; historical analysis of churned clients happens elsewhere (e.g. Division Forecast, ETCR churn rows).
Book / portfolio
Definition: the collection of clients a person is responsible for. An employee's "book" (or "book of business" / "portfolio") is every client they are assigned to; its "book value" is the MRR sense of total monthly client value counted once per client. "The book" company-wide means all active clients.
Where it appears: Portfolio Review (whole-book review screen), Employees ("who is carrying how much revenue"), Staffing ("whose book gets too heavy"), Capacity Planning ("how full is each book vs target").
Source/basis: Nova/Signal team assignments (who owns which client) × Vena revenue (what each client is worth).
Caveats: "book value" ≠ attributed revenue: book value counts full client revenue once per client (MRR KPI), while attributed revenue splits each client across its team (RPE KPI).
Division
Definition: Power Digital's client-vertical organizational units. The eight P&L divisions as of Jul 2026: B2B, Core, Consumer Services, CPG, Fashion, Lifestyle, plus Healthcare and Shared Services (both labeled "nuanced" on the P&L). Both clients and employees carry a division; several views slice or gate data by it.
Where it appears: Summary (division filter/breakdown), Divisional P&Ls (/divisional-pl, one P&L per division), Division Forecast (/predictions/retention), Revenue Overlap (/revenue-overlap, cross-division revenue), ETCR (division rollup), Growth Access (/growth/access, division-scoped data grants), Corrections (division as a flaggable field).
Source/basis: Nova employee/client records (novaDivision on employees); for Divisional P&Ls the division list and "nuanced" labels are code constants. On Division Forecast, division comes from the CSM renewal-tracker sheet and is NOT reconciled against Signal's assignments.
Caveats: VABO division attribution is finance-assigned and can differ from the client's own division. The Growth division picker derives its vocabulary from the Growth People dataset and can be empty until that dataset is warmed.
Access & platform terms
Signal's access control combines a five-tier role ladder with an orthogonal Growth grant system. Roles live in Signal's own app_users Supabase table; Growth grants live in growth_access_grants and growth_access_capabilities. Full detail is on the Signal Access Model page; these entries give bot-answerable definitions.
Member (base tier)
Definition: any signed-in Signal user with no elevated flag and no Growth capability — formally, isMember = not Team Lead, not Admin, not Gandalf, not Sauron, no Growth division grant, no Radar capability, no Growth-manage capability.
Where it appears: everywhere as the default audience — Members see exactly two destinations, Summary (/summary) and Employees (/employees, own row only, "Your Record"). Global Search and the Iris drawer are hidden for Members; MemberAllowedRoute redirects them away from all other views.
Source/basis: absence of flags in Signal's app_users table and Growth tables; every user is auto-provisioned into app_users (all flags false) on first sign-in.
Caveats: sign-in itself is limited to three email domains (powerdigitalmarketinginc.com, external.powerdigitalmarketinginc.com, cardinaldigitalmarketing.com) via Google OAuth.
Team Lead
Definition: the first elevated tier. Unlocks Manage Leads (/leads), Client Pulse submission (/pulse/submit, /pulse/my-submissions), and Revenue Overlap (/revenue-overlap) via TeamLeadRoute, plus everything open to non-Members (Staffing, ETCR, and the Client Health prediction views).
Source/basis: app_users.is_team_lead in Signal's Supabase. Auto-granted at first sign-in to anyone who is an Executive Sponsor (Account Director) or Group Director on any active client in Nova; also implied by Admin, Gandalf, or Sauron.
Caveats: provisioning never downgrades an existing Team Lead. The intended Team Lead audience is Account Directors and Group Directors.
Admin
Definition: the second elevated tier. Unlocks (via AdminRoute, which also admits Gandalf): Corrections (/corrections), Role Capacity (/capacity), Company Capacity (/company-capacity), KPI Targets (/kpi-targets), Client Profitability (/profitability), Employee Pulse (/pulse-coverage), Pulse Summary (/predictions/pulse-summary), Insights (/insights, hidden nav), and the Iris AI chat drawer.
Source/basis: app_users.is_admin in Signal's Supabase, managed by Gandalf-tier users on the General Access screen (/users).
Caveats: the Iris drawer's enable check is the isAdmin flag specifically, so a Gandalf-only user whose is_admin is false does not get the drawer even though Gandalf passes every AdminRoute gate.
Gandalf
Definition: the executive/leadership tier above Admin. Unlocks (via GandalfRoute): Divisional P&Ls (/divisional-pl), AI Solutions (/solutions), General Access user management (/users), Hiring Pipeline (/hiring), JD Sheet Sync (/jd-sync), Assignment History (/audit-log), and the Garden external link. Gandalf also passes every Admin route gate.
Source/basis: app_users.is_gandalf in Signal's Supabase, plus a hardcoded code allowlist (GANDALF_ALLOWLIST in AuthContext.tsx, currently one person: makenna@) that bypasses the database.
Caveats: Gandalf is deliberately NOT auto-granted Growth Access management — Growth is a separate permission system. Payroll/personnel-expense endpoints require a further hardcoded email allowlist (PAYROLL_AUTHORIZED_EMAILS) independent of Gandalf.
Sauron
Definition: the hardcoded super-admin tier. Sauron users get every flag forced true regardless of database state (Team Lead, Admin, Gandalf), always hold Growth-manage capability, and are the only users who can open the Analytics usage dashboard (/analytics, via SauronRoute).
Source/basis: a hardcoded email list (SUPER_ADMIN_EMAILS, mirrored in src/context/AuthContext.tsx and server/index.ts) — as of Jul 2026: john@, jaime.diaz@, laura.bejarano@, lily.loyer@ (all powerdigitalmarketinginc.com).
Caveats: being Sauron does not by itself grant Growth data visibility — a super-admin needs a division grant like anyone else; only Growth management is automatic.
Growth grants (Growth access)
Definition: an access system orthogonal to the five tiers, controlling the sensitive Growth section: the People tab (/growth/people, salary/payroll/compensation data) and the Performance Radar tab (/growth/performance-radar). Two Supabase tables define it: growth_access_grants (WHICH divisions/departments a person may see; a NULL-division row = all divisions; revocations are soft-deletes) and growth_access_capabilities (three per-user booleans: can_view_people, can_view_radar, can_manage_access).
Where it appears: Growth tabs, the Growth Access management screen (/growth/access), and the sidebar (Growth section appears only if the user holds a viewing capability).
Source/basis: Signal's own records, managed on /growth/access by delegated Growth managers or Sauron super-admins; resolved at sign-in via GET /api/growth/my-access. On top of grants, each Growth tab requires a shared unlock password (validated server-side against the GROWTH_UNLOCK_KEY environment variable; held in browser memory only; re-locks after ~5 minutes backgrounded).
Caveats: before July 2026 Growth access was a hardcoded email allowlist in code; the migration seeded the 8 previously-allowlisted emails as all-division grants. A user with a division grant but no capabilities row shows People visibility by default (backward compatibility); Radar is strictly opt-in. Capabilities gate tab visibility; the division scope is what actually filters data server-side.
Iris (disambiguation: external tool vs Signal drawer)
Iris, the external tool: Power Digital's standalone AI platform at iris.novapower.io, used for questions specific to client data and performance and for enriching client-facing deliverables. Signal hands off to it explicitly: the Churn Risk "Iris Draft" tab and the Service Expansion growth-roadmap draft both generate Claude-written narratives intended to be copied into Iris.
Iris, the Signal drawer: an AI analyst chat drawer inside Signal (Cmd/Ctrl+I, or the "iris" button in the top header). Enabled for the Admin flag only (IrisContext.tsx checks isAdmin); hidden for Members. It answers questions about the data currently on the user's screen: the context sent to Claude is a client-side snapshot of the current period's employees, accounts, and computed KPIs. It does NOT query databases. Backed by Anthropic Claude (Opus, with silent Sonnet fallback on overload); every generation is logged to llm_generation_logs.
Caveats: the two share a name and a brand but are different products: the drawer sees only Signal's on-screen data snapshot; the external tool has its own client-data sources. For client-performance questions beyond what a Signal screen shows, the standard guidance is to ask Iris at iris.novapower.io.
