# Glossary & Cheat Sheet > Plain-English definitions for every term Pulse uses. Designed to be opened in a side pane while working — reference, not a tutorial. The dashboard renders this same content as the in-app cheat sheet. If you remember nothing else, remember the four foundational principles: - **No silent disappearance.** Every commitment ends in `done`, `recommit`, or `retire` — explicitly, with attribution and reason. Nothing quietly evaporates. - **Radical transparency.** Every user's open commitments, reliability rollup, and nudge history are readable by every other user. Confidentiality scopes exist for the small set of cases that genuinely need them (Leads, Sessions); everything else is open. - **Artifact-grounded.** Pulse never grades personality. Signals come from real artifacts (mechanism prose, settlements, lead transitions, nudge response time), and managers read the artifacts to form judgments. - **AI-first authoring.** Prose-heavy fields (KR mechanism, AccountabilityArea definition, drives-graph restructuring) are authored through Claude Code conversation. The web dashboard handles reads, comments, and lightweight writes. --- ## Core vocabulary ### Super KR One of three top-level outcomes the firm measures itself against: **AUM** (Assets Under Management), **ROI** (Return on Investment), and **Brand Recognition**. Every other Key Result must trace a causal path to at least one Super KR. Adding or changing a Super KR is leadership-only and rare. ### Objective A team- or initiative-level goal for a given period (e.g. `2026-Q2`). Objectives group Key Results that share a theme. Objectives don't declare causal links themselves — that lives on their KRs. ### Key Result (KR) A measurable outcome under an Objective. Every KR must declare at least one **drives** link before it can be activated for a quarter. KRs have `start_value`, `current_value`, `target_value`, an `owner_id`, and a status (`draft` | `active` | `retired`). ### drives (link) A causal claim about how one node moves another. KRs declare `drives` links targeting Areas (typical), other KRs (sometimes), or Super KRs (allowed but discouraged — see *bypass*). Areas declare `drives` links targeting Super KRs (typical) or other Areas. Super KRs feed each other in named loops at the visualization layer. A drives link carries: - **target_type / target_id** — `area` | `kr` | `super_kr` and the id. - **polarity** — `+` if improving the source moves the target the same way; `-` if it moves the target the opposite way (e.g. reducing time-to-onboard helps AUM, so polarity is `-`). - **mechanism** — see below. - **strength** — qualitative: `weak` / `moderate` / `strong`. - **lag** — qualitative: `immediate` / `weeks` / `quarters`. - **history** — append-only log of validate/weaken/disprove events. ### mechanism The plain-English story for *how* a KR drives its target. Authored as `{ prose, coefficients? }`; v1 only writes prose. Coefficients can attach later as patterns mature, no migration required. If you can't write the prose paragraph, the KR isn't ready. > Example: *"Hitting 4 investor events per quarter generates ~12 qualified LP intros, of which ~2 typically convert to commitments within 6 months."* ### validate / weaken / disprove The three actions you can take on an existing `drives` link as evidence accumulates: - **validate** — the predicted feedback fired. Logged as positive evidence; mechanism stays. - **weaken** — predicted feedback didn't show up cleanly; downgrade the strength one tier; mechanism stays. - **disprove** — predicted feedback failed; the link is marked historical. The KR cannot stay `active` until a replacement drives link is declared. Disproven mechanisms are *evidence*, not blame — a person whose disproven mechanisms get followed by stronger replacements has a documented growth track. ### orphan KR A KR whose transitive drives don't reach any Super KR. Flagged automatically. Every orphan is one of: badly framed, a vanity metric, or revealing a missing link in the org's theory of change. ### bypass (KR-direct-to-Super-KR) A `drives` link that skips the Areas layer and points a KR straight at a Super KR. Allowed but discouraged — most bypasses reveal a missing Area in the strategic layer. The dashboard surfaces them as candidates for an Area-layer addition. ### two-layer causal model The systems-dynamics graph splits into two layers: - **Strategic layer** — Super KRs + AccountabilityAreas + the `drives` links between them. Founder-authored. Slow-moving (quarterly to yearly). The firm's standing theory of how the fund works. - **Operational layer** — KRs (and their `drives` links to Areas) + Projects + Tasks + Leads. Anyone authors. Fast-moving (weekly to quarterly). The day-to-day work hanging off the scaffolding. The causal-map dashboard toggles between **Strategic** (just the scaffolding) and **Full** (scaffolding + operational KRs). See [`okr-integration.md`](okr-integration.md#two-layers). --- ## Accountability vocabulary ### AccountabilityArea (often: Area) A persistent, indefinite area of responsibility — e.g. "Treasury operations," "LP communications cadence," "Research output quality." Distinct from Project (bounded) and Objective (periodic). Areas are the skeleton; projects and OKRs are temporary muscle. **Owned by a Role, never a User.** This is the load-bearing distinction — when the holder of a Role leaves, every Area attached to that Role instantly shows as unowned in the vacancy report. **Areas are also strategic-layer drivers.** Each Area declares its own `drives` links to Super KRs (or other Areas), with mechanism prose. Operational KRs typically attach to Areas (the KR's `drives` targets the Area), and the Area in turn drives a Super KR. Editing Areas and their drives is **founder-only**. See the *two-layer causal model* entry above. ### Role A named position on a Team (e.g. "Head of IR"). Roles persist; their **holder** changes (or is vacant). A User can hold multiple Roles. Roles carry: - `holder_user_id` — the current occupant; `null` means **vacant**. - `is_critical` — does losing this Role create a strategic gap? - `is_founder` — does the holder get **founder audit-read** across confidentiality scopes? See below. ### User A person. Comes from the nexus user record; Pulse references by `user_id` and doesn't own user data. ### vacancy A Role with no `holder_user_id`. The vacancy report lists open Roles ranked by exposed Super KRs — the prioritized hiring list, not by department politics. ### bus factor The number of critical Areas a single Role (or User) holds. Above a threshold = "if this person leaves, here is exactly what breaks." Surfaced as a structural flag in the bus-factor / overload report. ### Team A group of Roles, optionally nested into an org tree. Teams carry BU/FU context. --- ## Settling a commitment ### commitment A Task that came from a Session (it has an `originating_session_id`) — it carries the no-silent-disappearance rule. Ad-hoc Tasks become commitments too if they're tracked across a Session boundary, but session-originated ones are the canonical case. ### settle (the verb) Resolving a commitment to its final state. The technical operation in the API is `dispose`; in user-facing prose we say "settle." You settle your own commitments — peers cannot do it for you. Three settlement kinds: ### done You finished the work. Optionally include a closing note. ### recommit The work isn't done but is still relevant. Required: a new due date and a one-line *"what changed"* note (capacity hit, blocker, dependency). Pulse creates a new linked Task; the original is preserved with status `recommitted`. ### retire The work is no longer relevant. Required: a `retire_reason` (≥10 chars). Optionally link a successor — see below. ### settlement (the noun) The recorded outcome of a commitment: `done`, `recommitted`, or `retired`. The verb is "settle"; in API/data-model contexts you'll still see the field name `disposition` for historical reasons. Treat the two as synonyms. ### backed retire / unbacked retire A **backed** retire links a successor — `successor_task_id`, `successor_kr_id`, or `successor_lead_id` — when the work moved somewhere visible. An **unbacked** retire is one with no successor declared. Both are allowed; Pulse never algorithmically scores one as better than the other. Managers read the prose. A pattern of unbacked retires is a transparency signal under the radical-transparency default. ### chronic recommit A flag in the reliability rollup: a single commitment that has been recommitted N times. Above the threshold (default 3) it surfaces as a soft signal — usually a sign that the wrong owner, the wrong scope, or the wrong priority is at play. Not punitive; the goal is to surface the pattern. ### chronic retire A flag in the reliability rollup: a user retiring above-threshold counts or rate of commitments in a period. Same shape as chronic-recommit — soft signal, org-readable, no leaderboard. --- ## Sessions and meetings ### AllHandsSession (often: Session) A scheduled review meeting. Any cadence (quarterly, monthly), any scope (company, BU, FU). Multiple **kinds** of Session can coexist; each kind tracks its own carry-over. ### carry-over Commitments from a prior same-kind session that are **still open** at the next session's time. They become Phase 0 of the next session. Anything settled async since the prior session is in the recap, not the agenda. ### Phase 0 The non-skippable first agenda block of every session: dispose of every carry-over item. No carry-over leaves a session undisposed. ### prep view The auto-generated dashboard for an upcoming Session — Phase 0 carry-over, Super KR rollup, mechanism-disproven candidates, vacancy report scoped to the session, project status delta, discussion candidates. The CLI agent typically uses this to draft an agenda. ### recap The post-session summary: settlements made, KR movements, decisions, new commitments, vacancies that closed (or didn't). Generated by Pulse on session close, distributed to attendees. ### decision log The append-only record of decisions captured in sessions, scoped by BU/FU/Super KR for searchability. Preserves institutional memory across turnover. --- ## Communication ### comment An open-ended discussion attached to any commentable entity (Task, Lead, KR, Project, Area, Session). Cross-user — peers can comment on anyone's entity. One level of threading allowed. Comments inherit the parent entity's confidentiality scope. Authors can edit/delete their own; founder audit-readers can also delete (moderation). ### nudge A peer prompt to **settle** a specific commitment. Single-purpose ("please settle this"); rate-limited (1 per peer per task per 7 days); counted toward the reliability rollup. Distinct from a comment, which is open-ended discussion. ### thread A comment + its replies. Replies-of-replies are not allowed in v1. --- ## Reliability and capacity ### reliability rollup Per-user and per-role kept / recommit / retire-backed / retire-unbacked counts over a period. Org-readable, no leaderboard. Includes the chronic-recommit and chronic-retire flags, nudge response p50, and mechanism validation rate. ### activity heatmap GitHub-inspired daily heatmap on each user's profile page — completes, recommits, retires (backed/unbacked), nudges sent/received, lead transitions, mechanism work. Brightness scales with total activity; hover reveals the per-event-type breakdown. ### capacity signals A multi-axis flag from six artifact-grounded signals — areas owned, open commitments, active leads, settlement velocity trend, nudge response time, recommit rate trend. None self-reported. A user is **overload-flagged** when above the org's 90th percentile (or trend threshold) on N of the 6 axes (default N=3). Pulse never produces a composite "overload index" number. --- ## External work (BD pipeline) ### Lead A business-development opportunity progressing through a declared pipeline. Same no-silent-disappearance rule as commitments — every Lead must end in `converted`, `lost`, or `dormant` with a reason. Owned by a **Role**, not a User (so vacancies surface). ### Pipeline A named pipeline definition with ordered stages and conversion probabilities. Pipelines are configured rarely; Leads move through them constantly. Outliers' canonical pipeline is **LP fundraising** — 7 stages, 1% → 100%, defined in [`bd-pipeline.md`](bd-pipeline.md). Other pipelines (deal sourcing, partnerships) are anticipated. ### stage A named position in a pipeline (e.g. `04_soft_commit`). Each stage has a `conversion_probability` (used in forecasts) and a `stale_after_days` (triggers staleness nudges). ### stage transition A forward or backward move through a pipeline. Backward moves are valid signals ("LP cooled, dropped from 04 back to 02"). Reaching a 100%-probability stage does **not** auto-settle the Lead — only the Owner Role can flip status to a terminal state. ### status settlement (Lead-specific) The terminal state on a Lead: `converted`, `lost`, or `dormant`. Required `closed_reason`. A `dormant` Lead can be reopened (back to `active`) if the LP re-engages. ### expected_value Optional dollar amount on a Lead — typically the size of the AUM commitment. Used in the **pipeline forecast** rollup. ### pipeline forecast `expected_pipeline_aum = Σ(lead.expected_value × stage.conversion_probability)` over active leads, decomposable by Pipeline / BU / Stage / Owner Role. The headline number on the BD dashboard. --- ## Confidentiality ### confidentiality_scope A field on Lead, AllHandsSession, and (inherited) Tasks. Three values: - **`org`** — readable by every authenticated user. The default for everything. - **`role:`** — readable by holders of the named Role + the entity owner + founder audit-readers. - **`users:[, ...]`** — readable by the explicit list + the entity owner + founder audit-readers. There is no `team:` value — "my team's stuff is private from your team" is the opposite of what radical transparency wants. ### founder audit-reader A user holding any Role with `is_founder: true`. Can full-read every confidential entity in Pulse. The safety valve that prevents `confidentiality_scope` from quietly becoming opacity. ### public metadata For confidential entities, the always-visible information: that the entity exists, its scope, BU/FU, magnitude (e.g. Lead `expected_value`), stage if applicable, status. Non-readers see this with `redacted: true`; they never see the title, contents, owner identity, or notes. --- ## Taxonomy ### Business Unit (BU) The fund or entity an item belongs to — `OIAL`, `OSF LP`, `OSF GP`, `OIF LP`, `OIF GP`, `OBFIII`. Items can span many BUs. ### Functional Unit (FU) The functional area an item belongs to — `Investment & Deal Flow`, `Portfolio Management`, `Fundraising & IR`, `Finance & Accounting`, `Legal & Compliance`, `Fund Administration`, `Human Resources`, `Marketing & PR`, `Technology & Infrastructure`, `Frontier Research`. Items belong to exactly one FU. ### org_taxonomy The shared nexus storage key (`tool=null`, `key=org_taxonomy`) that holds the canonical BU and FU enums. `accounting` and `pulse` both read it. A rename in one place updates both tools. --- ## Foundational principles, restated ### no silent disappearance Every commitment ends explicitly. Every drives link gets validated, weakened, or disproven. Retire reasons are recorded. Nothing slips into a memory hole. ### radical transparency Default-on org-wide visibility. The opposite — private-by-default — is the slope to opacity, which is what kills accountability over time. ### artifact-grounded Signals come from artifacts the user actually produced: mechanism prose, retire reasons, settlements, lead progressions, nudge response time. Never from self-rated personality scales or peer trait surveys. ### AI-first authoring Prose-heavy fields are authored through Claude Code conversation, not web forms. The web dashboard handles everything that fits a single tap with visible context: comments, settlements, status flips, lightweight self-edits, Lead stage transitions. --- ## Quick API operations These are the API operation slugs you'll see in the CLI guide and error codes. The user-facing verbs are listed in parentheses. | API slug | What you say | Where it applies | |----------|--------------|------------------| | `dispose` | "settle" / "mark done" / "recommit" / "retire" | Tasks | | `transition` | "move stage" | Leads | | `validate` / `weaken` / `disprove` | (same) | drives links | | `nudge` | (same) | open commitments | | `comment` | (same) | every commentable entity | | `confidentiality_scope` | "scope" / "restrict" | Leads, Sessions |