Developer Profile — Lo-fi Wireframe STEP 3 · NARRATIVE-FIRST PASS

Net-new design. First visual pass built from 01-Objectives + 02-Data-Relevance only — full feedback/transcripts and detailed annotation tagging come at Step 4. Two conventions for non-real content: greyed, dotted-underlined numbers are sample data showing layout only; [red brackets] mark data that is undecided or not yet captured (each traces to the Open decisions list). Nothing fabricated.

Data readiness (from 02)

DATA-READY served by current marts — measured

SECONDARY feasible, flagged caveat (e.g. Work-Area overlap)

BLOCKED needs new pipeline work — design only, no data

1,840 sample data, layout only · […] undecided / uncaptured

Markers

FLAG open question → bottom box

G1…G4 traces to a gap in the data inventory

TM our design call (rationale in tooltip)

Review annotations — internal only, not product UI

✦ manager takeaway what the manager should leave with

data-basis lines explain every number’s source

Built for the engineering manager SINGLE PRIMARY USER

The reader arrives here by drilling into one developer from the team view — "could I… slice that same data?" (the CEO, Jun 1). So every panel is voiced as a manager assessing a developer, not the developer self-reviewing. The question the whole page answers, in the CEO’s words: "how engaged is this developer, and where have they been investing their time?" — and engagement means quality of engagement, not raw hours ("not so much busy in terms of hours, but how engaged is the team"). Losing a prior enterprise prospect on "very, very underwhelming" metrics dashboards is the cautionary anchor: this page has to show value clearly, at a glance.

Token cost control is the company’s top priority, so where two signals compete for space the human/AI & spend read wins the tie. Example content uses a real-feeling developer ("Sam Okafor") on the atlas team so the page reads like the product.

Narrative spine — the reading orderWHY THIS ORDER

The page is laid out so the manager gets the answer before the evidence. Read top to bottom it is a single sentence: this developer is engaged (or not), here’s their rhythm, here’s where the effort went, here’s the quality of that effort, and — once we can — here’s when in the day they work. Charts only appear after the question they answer.

The verdict — engagement at a glance. The one-glance answer: is this developer engaged, and trending up or down against their own baseline and the team median? Nothing below earns its place if this doesn’t land first. DATA-READY
The rhythm — activity over time. The GitHub-style heatmap: consistent presence, recent ramp or fade. The native shape of day-grain activity. DATA-READY
Where the effort went — work investment. Which projects/repos this developer’s time landed in. Answers objective 2 directly. DATA-READY
The quality of that effort — engagement, not hours. Human vs AI-assisted retained code, does their AI output survive review, is work moving. This is what makes "engaged" mean more than "present" — and carries the token-cost story. DATA-READY
When in the day they work — times-of-day grid. The rhythm detail. Placed last because it is not data-ready: the panel is designed, the data is flagged. BLOCKED · G1+G2

1 · Engagement at a glance

Is this developer engaged, and which way are they trending?

DATA-READY

✦ Manager takeawayIn five seconds: I know whether Sam is engaged, and whether that’s up or down versus how Sam usually works and versus the team.

Identity

Sam Okafor

Software Engineer · atlas team · profile scoped to [selected Work Area]

Role/team labels confirmed at Step 4 — flagged as an open identity question in 01. The Work-Area scope label matters: this profile is always "Sam, within the Work Area the manager is allowed to see", never tenant-wide by default.

Basis: dim_subject (SCD-versioned), resolved through the Work-Area scope the manager arrived from. G—

Engagement vs baseline

Active

active days this period: 18 / 21

vs Sam’s own 3-mo baseline: ▲ +12%
vs team median: ▲ +6%

✦ TakeawayEngaged and slightly above their normal — not a flight risk this period.

Basis: active-day count & active_minutes_sum from fact_session_day, rolled to the period; baseline = same metric over prior 3 mo; team median from the team view the manager drilled from. Measured.

AI engagement TM

14 / 18

days with AI activity this period

power-user days: 6 (prompts≥10 / tool-calls≥10 / agent-min≥30)

✦ TakeawaySam isn’t just present — they’re actually using the AI tooling, most days.

Basis: ai_active_day + power_user_day proxy per subject-day, fact_session_day. Measured. Token-cost tie-break: AI engagement sits in the headline by design. TM

2 · Activity over time

What’s the rhythm — consistent presence, or a recent ramp / fade?

DATA-READY · anchor

✦ Manager takeawayI can see at a glance whether Sam shows up steadily or in bursts, and whether the last few weeks are ramping up or trailing off.

Activity heatmap — last 6 months, one cell = one day

Range: 3mo · 6mo · 12mo | Cell metric: active minutes · commits — default active minutes: the engagement signal, not output volume TM

less more | outline = AI activity that day

Basis: one cell per UTC day, intensity = active_minutes_sum from fact_session_day sliced to this subject; AI-day outline = ai_active_day. Day grain is the native shape — measured. Reconciles: summed cells = Sam’s active minutes shown in §1 over the same window. Captured-but-unattributable activity is not here (lives in fact_session_unattributed_day) — expected, not a gap.

3 · Where the effort went

Which projects has this developer been investing time in?

DATA-READY · anchor

✦ Manager takeawayI know which projects Sam’s time actually went to this period — and can click into any of them.

By project (= repository) — share of active minutes

atlas / server

46%

atlas / portal

28%

atlas / clients

18%

atlas / docs

Each repo row links ↗ to the repo. (sample shares sum to 100%)

Basis: active_minutes_sum grouped by dim_repository for this one subject, fact_session_day. Measured. "Project = repository" is the design assumption — it’s the only fully-populated, non-overlapping grouping (02 §1.3). TM

By Work Area SECONDARY

Payments

52%

Platform

44%

Feasible from existing facts, but a Work Area is resolved at query time, and overlapping Work Areas can double-count the same minutes — so shares here need not sum to 100%. Surfaced as a labelled secondary view, not the default. FLAG

Basis: subject’s active_minutes_sum run through each Work Area’s repo/subject/branch predicate set (Inventory §5). Overlap caveat is shown, not hidden.

By work type (feature / maintenance / debt…) NOT AVAILABLE · G4

A "what kind of work" lens would sit here. [No data — deferred]

fact_cost_allocation currently allocates all minutes to unclassified, so this chart would be one slice today. Deferred, not faked. G4 FLAG

4 · Quality of engagement, not hours

Is the effort good effort — does it survive, is it moving, how AI-assisted is it?

DATA-READY

✦ Manager takeawayBeyond "is Sam here": their work is landing and surviving review, and I can see how much of it is AI-assisted — which is the cost story too.

Human vs AI-assisted retained code TM

Human 63%

AI 37%

of retained lines this period · sample split

✦ TakeawayI can see how AI-assisted Sam’s shipped work is — the human/AI mix, not a vanity AI count.

Basis: retained_human_sum / retained_ai_sum (line-level diff) from fact_commit/fact_file_retention joined to dim_subject. Measured — this is NOT a gap (02 correction to 01). Leads the quality block by token-cost tie-break. TM

Does the AI output survive?

81%

AI-generated lines retained vs abandoned

✦ TakeawaySam’s AI use is productive, not churn — most of it survives review.

Basis: retained vs abandoned_ai_sum per subject (contributionLineage, measured). Never imply "spend avoided" — that counterfactual is not computable (02 §2.2). Show only what’s knowable.

Is the work moving?

median cycle time: 2.4 days
completion rate: 88%
stale work items: 1

✦ Takeaway"Is work flowing" beats "hours logged" — Sam’s work is moving, with one item to nudge.

Basis: cycle_seconds, completion, stale count from fact_work_item (native branches + GitHub PRs, measured). Issue-tracker-linked items not covered yet. G—

Deliberately left out of this pass: averageFocusBlock / contextSwitchRate — they sound like deep-engagement metrics but are proxies (derived, not measured), so they don’t headline the engagement story (02 §2 & G6). FLAG

5 · When in the day they work

When across the day/week is this developer most active?

BLOCKED · G1 + G2

Layout designed; data not yet available. The 7×24 grid (weekday × hour) is the target shape. The data to fill it does not exist yet — so the cells are drawn empty and flagged, never fabricated from day totals.

DATA BLOCKED
[hour-of-day grain] · G1 + G2

[Cells require an hour-grained activity fact (G1) and a per-subject timezone (G2)] — see Open decisions.

Why blocked, from 02 §1 Viz #2: the 30-second interval signal exists in Bronze/Silver, but every Gold fact collapses to UTC day, and source_timezone is fixed to UTC — so an honest local-time grid needs both a new hour fact (G1) and a per-developer timezone (G2). The only honest interim is a coarse UTC session-start-hour distribution from runtime_sessions.started_at (session-grain, still UTC) — usable only if explicitly badged a proxy. G1 G2 FLAG

Not in this first pass / deferred

AI-powered grouping into named work areas (the CEO’s "4–6 main things… group data that way") — aspirational, out of V2 scope per 01; needs auto-clustering that doesn’t exist (G3).
Work-type allocation (feature/maintenance/debt) — deferred until fact_cost_allocation classifies beyond unclassified (G4).
Supervised-vs-autonomous 4-way contribution split — the 2-way human/AI split (§4) serves the engagement story; the 4-way is collapsed in marts (G5).
Full feedback tagging + annotation system (FR/SB-style source pills, tooltips, coverage of every source ask) — arrives at Step 4 when the full transcript enters.

Coverage cross-check01 + 02 → where answered

Objective / viz (01, 02)	Where on the page	Status
Show engagement at a glance (obj 1)	§1 Engagement at a glance	Data-ready
Reveal where time/effort is invested (obj 2)	§3 Where the effort went	Data-ready (repo); Work-Area secondary
Behave as a drill-down (obj 3)	Audience head + Work-Area scope label + repo/PR links	Reflected in framing
Viz #1 — activity heatmap	§2	Data-ready · anchor
Viz #2 — times-of-day grid	§5	Blocked · G1+G2 (designed, flagged)
Viz #3 — work investment	§3	Data-ready (repo); G4 work-type deferred
Strengthener — human/AI retained split	§4	Data-ready (token-cost tie-break)
Strengthener — AI retention/abandonment	§4	Data-ready
Strengthener — work-item flow	§4	Data-ready (native + GitHub PRs)
Strengthener — trend vs baseline/team	§1	Data-ready

Open decisions — every red bracket traces hereFLAG

Hour-of-day data basis (Viz #2). Blocked on G1 (hour/interval-grained activity fact) + G2 (per-subject timezone). Decide: wait for the fact, or ship a UTC session-start-hour proxy badged as such. Until then §5 stays designed-but-empty. Drives [times-of-day cells].
Header / identity fields. Name, role, team labels listed as open in 01 — confirm against the full transcript / the Dev Lead sessions at Step 4. Drives [role/team].
Default scope of the profile. Which Work Area is selected when the manager lands here, and is it always the one they drilled from? Drives [selected Work Area] and the §3 Work-Area view.
"Project/area" meaning. Assumed = repository for V1 (only non-overlapping grouping). Confirm a manager reads it that way; Work-Area allocation kept as labelled secondary with the overlap caveat.
Period & baseline window. What is "this period" (calendar month? trailing 30d?) and the baseline length (assumed 3 mo). Needs a month of data before month-over-month reads cleanly.
Coaching / recommendation panel. Listed as an open question in 01; not placed in this pass. Decide whether the profile carries one (insight-feed serving is contracted-but-unavailable).
the Dev Lead sessions. 01 flags possible separate the Dev Lead ideation sessions; if transcripts exist, drop them in Sources/ for Step 4 — they may resolve the identity/coaching/layout open questions.