Verified against ChatGPT · 2026-08-11
Run a compensation review that surfaces pay compression before it becomes a retention problem
Analyzes a team's pay data against tenure and level to flag compression and inequity risks in a clear table, so the review produces decisions instead of just a spreadsheet everyone nods at.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are running a compensation review for one team, looking specifically for pay compression (newer hires paid close to or above longer-tenured people at the same level) and any pattern that would look like inequity if scrutinized. TEAM PAY DATA 12 engineers at levels L3-L5 with current base, hire date, and last increase date for each. LEVELING FRAMEWORK IN USE L3 = 0-2 years scope, L4 = owns a subsystem, L5 = owns cross-team technical direction. BUDGET AVAILABLE FOR ADJUSTMENTS $45,000 total across the team for this cycle. KNOWN CONTEXT PER PERSON (performance, market moves, tenure) Two L4s hired in the last 6 months came in at market rate which is now higher than three L4s hired 3 years ago with strong performance ratings since. STEP 1 — BUILD THE COMPARISON TABLE Group people by level (not by title alone, if title and level can diverge) and list current pay, tenure at company, tenure at level, and last increase date, in one table sorted by level then by tenure descending. STEP 2 — FLAG COMPRESSION AND ANOMALIES For each level group, flag any case where a shorter-tenured person is paid within 5% of or above a longer-tenured person at the same level with equal or stronger performance context, and separately flag anyone more than two standard deviations of that level's pay range below the group's median with no performance or context reason given. Do not speculate about causes not in the data (do not guess at gender or other protected-characteristic patterns from names or any other proxy) — flag the pay pattern itself and note explicitly that any deeper equity analysis needs the company's formal pay-equity process, not this review. STEP 3 — PRIORITIZE WITHIN BUDGET Rank the flagged cases by retention risk (recent tenure with strong performance and no increase is higher risk than a compression case involving someone with a documented performance issue), and show how far the stated adjustment budget goes against that ranked list — state plainly if the budget doesn't cover every flagged case and which ones would be deferred. OUTPUT FORMAT 1. The full comparison table. 2. Flagged compression cases and flagged below-median anomalies, each with the specific numbers that triggered the flag. 3. A ranked adjustment list showing what the given budget covers and what it doesn't. 4. One line stating that any suspected systemic equity issue beyond individual compression cases should go through the company's formal pay-equity audit process rather than being resolved ad hoc here.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The explicit instruction not to speculate about protected-characteristic patterns from names or proxies is the single most important constraint in this prompt, because a model asked to "look for inequity" in a pay table has enough surface pattern-matching capability to produce guesses that look analytically confident but are actually unfounded inference from names or other proxies — output like that is worse than no analysis at all, since it can manufacture a false equity concern or, just as dangerously, miss a real one while appearing to have covered it; routing anything beyond individual compression flags to the company's formal pay-equity process keeps the tool doing what it can actually do reliably (arithmetic and pattern flagging on the data given) rather than what it can't (causal inference about protected characteristics from insufficient data). The two-part flagging rule — compression by tenure comparison and below-median anomaly by standard deviation — gives GPT-5.1 a concrete, checkable rule to apply consistently across every row rather than an open-ended "look for problems" instruction, which tends to produce inconsistent flagging where the model catches obvious cases and misses subtler ones depending on where they fall in the list; a numeric threshold applied uniformly removes that inconsistency. Ranking flagged cases by retention risk rather than presenting them in table order matters because a compensation review's actual output needs to be a decision under a real budget constraint, not just a list of interesting patterns — without an explicit ranking instruction, the model would present flags neutrally and leave the prioritization work, which is the actual hard part of the task, to the reader instead of doing it as part of the deliverable.
What you get back
L4 group: Priya (hired 3.2 years ago, $118,000, strong performance, no increase in 14 months) sits within 3% of Jordan (hired 5 months ago, $121,000, market-rate new hire) — flagged as compression. Anomaly: no below-median flags in this group. Ranked adjustment: Priya is highest retention risk (strong performer, stale pay, direct compression exposure) — a $9,000 adjustment brings her to $127,000, clearing compression and using about 20% of the $45,000 budget. Two lower-priority flagged cases would need to be deferred to next cycle at current budget.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
