Building Feedback Gauge
From scattered feedback to a question worth investigating—with the evidence still attached.
- Next.js
- Jev / TypeSafe
- People Ops
The operating problem
Survey comments and performance notes arrive through different channels. A theme can look significant in a summary while the original context is hard to find. I built this prototype to explore how a People team could move from a signal back to the feedback that supports it.
What I built
Feedback Gauge connects a company overview, teams, engagement drivers and individual feedback records. The demo includes scoring paths and a visible distinction between model scoring and a heuristic fallback. The purpose is to make the evidence inspectable, rather than ask the reader to trust a number alone.
Walk through one example
- Open the fictional Harbor Labs overview.
- Explore the alignment driver and the related feedback.
- Read the original comment about decision ownership, alongside its context.
- Use that evidence to prepare a follow-up question for a manager. The prototype does not make an employment decision.
What this demonstrates
The result is a working, inspectable example of my approach: connect fragmented information, make the handoff clear and leave judgement with a person. It is a prototype using invented names, survey comments and review notes—not a claim of measured improvements at a real employer.
Under the hood
Technical architecture
The portfolio demo uses bundled fictional Harbor Labs data. It has no live HRIS connection or persistent employee database; scoring and streaming run in server routes.
Interface
Next.js · React · Motion
Renders team drivers, survey cycles and supporting feedback. Local React state updates the view as events arrive.
Scoring API
POST /api/pulse/score
Accepts feedback and context; sends four judgments together to TypeSafe: one theme Choice and three ordered Scores. The API key stays on the server.
Composition
TypeScript calculations
Normalizes scores by 3. Gauge weights engagement at 50%, inverse flight risk at 30%, and inverse performance concern at 20%. The separate concern score uses 45%, 35% and 20%. These are prototype design choices, not validated employment predictions.
Data and events
Bundled JSON · server-sent events
The initial dashboard loads a fixture. GET /api/pulse/stream replays up to 22 fictional signals; optional live scoring can replace a cached score. No new dataset is persisted.
Failure and fallback path
Without a TypeSafe key, single-comment scoring uses heuristic-v1. Streaming defaults to cached fixture scores. A replay is not evidence of a live Jev request; check the scoring source before interpreting a result.
One request, end to end
- Feedback and role/team context enter the scoring route.
- Jev returns typed theme and score judgments; code computes the composite.
- React presents the result and retains the original comment for inspection.
Why it is built this way
- Keep numerical composition in code so the weights can be inspected.
- Keep the demo fictional and distinguish model scoring, heuristics and fixture playback.
- Let people inspect evidence rather than treat a concern score as an employment decision.