Candidate Scoring Blueprint: Behavioral Signals Across the Full Process

1. Problem & Mission

1.1 What Candidates Show You Before the Interview

Candidates reveal behavioral signals from the first moment they engage with a process. How carefully they write. How quickly they respond to outreach. Whether they confirm a calendar invite or let it expire. How deeply they explore a portal before an interview. Whether they send a follow-up after.

These are not soft impressions. They are observable, repeatable, measurable behaviors that I/O psychology research connects to on-the-job performance. Most hiring teams ignore them — not because they don't matter, but because there is no infrastructure to capture them.

1.2 The Infrastructure Problem

Without a structured scoring layer, evaluation compresses into a single interview. The behavioral context that accumulated across six, eight, or twelve process events is invisible. Recruiters rely on pattern recognition that is undocumented, inconsistent across reviewers, and impossible to audit.

The signals exist. They are already being generated at every stage of the process. The gap is not data — it is a system to capture, score, and surface them consistently.

1.3 Mission

Talent Intelligence exists to make behavioral signals observable, comparable, and auditable — without adding work for recruiters. Scores surface inside the tools recruiters already use. Decisions remain with humans. The system informs judgment; it does not replace it.

2. Construct Framework

2.1 Research Foundation

The four constructs are grounded in three bodies of I/O psychology research: Schmidt & Hunter (1998) on general cognitive ability and structured task performance as job performance predictors; Barrick & Mount (1991) on conscientiousness as the most consistent Big Five predictor across job types; and Kristof-Brown on person-environment fit signaled through motivation and communication behavior.

Constructs are not reverse-engineered from available signal categories. They represent theoretically grounded dimensions of on-the-job performance that candidate behavior during the hiring process can partially illuminate.

2.2 The Four Constructs

2.3 Design Principles

• Constructs are theoretically grounded first. Signal assignment follows from construct definition — not the other way around.
• Weights reflect research-supported predictive validity, not arbitrary balance.
• Scores are independent of recruiter decisions by design. The system surfaces intelligence; humans own the outcome.
• Null signals are excluded from scoring gracefully — weight redistributes to present constructs.

3. Signal Architecture

3.1 Signal Sources by Event Type

Signals are generated at each process event and stored in a signal layer that feeds the scoring engine. Raw observations (counts, durations, booleans, ratings) are normalized to a 0–1 scale before scoring.

3.2 Signal Normalization Rules

• Inverse normalization: Signals where lower raw values mean stronger performance (typo count, response delay, reschedule count) are inverted so 1.0 always means strong.
• Cap normalization: Continuous values (years experience, session duration, pages viewed) are capped at a defined maximum and scaled 0–1.
• Boolean signals: TRUE maps to 1.0, FALSE maps to 0.0.
• Null handling: Null signals are excluded from construct averages. Weight redistributes proportionally to present signals.

3.3 Excluded Signals

interviewer_impression_signal is intentionally excluded from construct scores. It feeds only the Decision Quality dashboard — keeping behavioral scores independent of human judgment inputs and preserving the separation between what candidates show and what interviewers concluded.

4. Scoring Engine

4.1 Architecture

The scoring engine runs in two layers. A Python layer (Google Colab notebook) handles data processing, signal computation, and construct scoring for the full candidate population and produces the score history used in the evolution timeline. A Google Sheets + Apps Script layer handles real-time scoring as new observations arrive and populates the output tables that feed Looker Studio and the Greenhouse widget.

4.2 Scoring Logic

Within each construct, score is the equal-weight mean of available signal values:

construct_score = mean(signal_values)  — nulls excluded, weights redistribute

Overall score is a weighted sum across constructs, null-safe:

overall_score = Σ(construct_score × weight) / Σ(weights of present constructs)

4.3 Recommendation Thresholds

Thresholds are configurable in the scoring_config tab via named ranges. No code change required.

4.4 Motivation Floor

Any candidate who has submitted an application receives a Motivation floor of 0.20. Self-selection is itself a motivation signal — a candidate who applied has demonstrated minimum intent. The floor prevents a null Motivation score from misrepresenting that fact.

4.5 Scoring Config (Google Sheets)

All scoring parameters are controlled from a single scoring_config tab:

• Construct weights — named ranges: capability_weight, conscientiousness_weight, motivation_weight, communication_weight
• Thresholds — named ranges: advance_threshold, review_threshold
• Signal mapping — named range: signal_mapping — maps each signal field to a construct with an active flag

View the live scoring notebook →

5. Greenhouse Widget

5.1 What It Is

The Greenhouse widget is the recruiter-facing surface of Talent Intelligence. It renders inline inside a candidate's Greenhouse profile — no separate tool, no context switching. It is fed by all agents across the full hiring process, not limited to any single stage.

5.2 What It Shows

• Four construct scores with visual bar indicators
• Overall score and department percentile
• Current stage with A[i]gent recommendation (Advance / Review / Pass)
• Top signals driving the current score
• Action buttons (Advance, Flag for Review, Pass) — human-in-the-loop
• Override log linking to Decision Quality dashboard

5.3 Candidate Navigation

The widget supports Next / Previous candidate navigation so recruiters can move through a cohort without leaving the panel. Department and requisition context carries across navigation.

5.4 Governance Note

Scores are labeled clearly as behavioral indicators. Every action taken in the widget is logged with candidate reference, event timestamp, action, and current score at time of decision. Overrides are captured and visible in the Decision Quality dashboard to support calibration over time.

Open the interactive widget demo →

6. Score Evolution Timeline

6.1 What It Shows

The score evolution timeline tracks cumulative construct scores at each process event — showing how behavioral signals accumulate across the hiring journey, not just at a single snapshot in time.

Each point represents an expanding window mean: the score at event N reflects all signals from event 1 through N. Scores stabilize and become more reliable as more evidence accumulates.

6.2 What It Enables

• See which stage produced the most signal movement for a given candidate
• Identify candidates whose scores improved or declined significantly mid-process
• Detect cohort patterns — e.g., portal engagement consistently predicting late-stage performance
• Audit score changes relative to specific events for governance and calibration

6.3 Technical Note

The score_history table is populated by buildScoreHistory() in Apps Script, which mirrors the cumulative scoring logic in the Colab notebook exactly. The Candidate Intelligence dashboard reads from this table to render the timeline.

7. Governance & Override Model

7.1 Scores Are Independent of Decisions

Talent Intelligence scores are computed from behavioral signals only — explicitly separated from recruiter decisions. A candidate can be advanced despite a low score, or passed despite a high one. The system does not enforce its recommendations.

7.2 Override Logging

Every action in the widget (Advance, Flag, Pass) is logged with candidate reference, timestamp, action taken, and the score at time of decision. Actions that diverge from the system recommendation are flagged as overrides and flow to the Decision Quality dashboard.

7.3 Autonomy Tiers

7.4 Bias Considerations

Signals are behavioral and process-based — not demographic. The system does not infer or store protected characteristics. Override patterns in the Decision Quality dashboard provide a structured mechanism for identifying and addressing systematic bias in human decisions over time.

8. Technical Stack

8.1 Components

8.2 Data Flow

ATS events → observations tab → Apps Script (onEdit) → signals tab → candidate_profile + score_history → Looker Studio dashboards + Greenhouse widget

Full-population run: signals.csv + observations.csv → Colab notebook → candidate_profile.csv + score_history.csv → Google Sheets → Looker Studio

8.3 Source of Truth

The metrics dictionary is the single source of truth for all signal definitions, formulas, and construct mapping. When scoring evolves, the dictionary is updated first — the scoring engine and Apps Script follow.

9. Metrics & Outputs

9.1 Candidate-Level Outputs

• Capability score (0–1)
• Conscientiousness score (0–1)
• Motivation score (0–1)
• Communication score (0–1)
• Overall weighted score (0–1)
• Recommendation (Advance / Review / Pass)
• Department percentile (0–100)
• Score history by event (for evolution timeline)

9.2 Dashboard Views

• Single-candidate view — Four construct scores with department percentile, score evolution timeline, stage indicator, top signals, action buttons
• Requisition view — All candidates for a role ranked by overall score with construct breakdowns
• Department view — Score distributions across the active pool, source channel comparisons, percentile bands

9.3 Feeds Into

• Decision Quality dashboard — Override logs, interviewer calibration, score-to-decision correlation
• Pipeline Health A[i]gent — Source channel quality signals, stage-level score distributions