What is Ghost%?

The baseline

E is estimated effort in the selected scope and period, in reference hours, including allocated overflow. D is the developer’s day count in the selected mode. S = Share ÷ 100: at Share = 100%, S is 1. The default Ghost baseline is 3 reference hours per developer-day. This is a common basis for comparing output, not the length of the entire workday. If the interface lets you choose another baseline, substitute it for 3. Raw Ghost% uses S = 1.

In Spread mode, D counts dates with positive allocated effort, including eligible weekend dates. A day without commits can count if the model places effort there; a day with no allocated effort does not count, and a zero-effort commit alone adds no Spread day. These are modeled dates, not observed workdays.

FTE mode uses the developer’s activity span in the selected scope: from the first date carrying effort through the last commit date, including zero-effort commits. It intersects that span with the selected period and counts weekdays, including those with no commits or effort, plus weekend dates with positive effort. Team views can also clip this span to membership periods. Employee-calendar reports use a separate denominator: available minutes from the configured schedule, date overrides and absences, divided by 480 minutes per full-time day. They apply the same 3-hour norm and Share adjustment; they do not change the standard Spread/FTE day counts.

What Share adjusts

Share is a manually set allocation from 0% to 100%, default 100%. Treat 100% as a normal full-time development role, not eight hours of typing. The 3-hour baseline already leaves room for the ordinary non-coding part of that role. Lower Share for a reduced allocation to the development work being assessed, such as part-time work or additional responsibilities; do not subtract the ordinary non-coding part of the day again.

Effort includes understanding relevant code, designing the solution, implementation, self-testing, and necessary corrections. Share does not deduct these activities again. Separate reviews of other people’s work, mentoring, meetings, and work that leaves no trace in the analyzed code are not measured directly. A manager supplies the adjustment for the role’s context.

Share changes the adjusted Ghost% by division. It does not change estimated effort, the allocated timeline, raw Ghost%, day counts or cost. At Share = 0%, adjusted Ghost% is unavailable, not zero or infinity. An unresolved Share also makes it unavailable. This Coding Share is separate from the experimental AI-trace share shown elsewhere in the product.

Individual examples

At the default norm, E = 30 reference hours and D = 10 days gives 100% with Share = 100%: 30 ÷ (10 × 3 × 1) × 100. With the same E and D but Share = 50%, adjusted Ghost% is 200%; raw Ghost% remains 100%. At Share = 0%, adjusted Ghost% is unavailable and the 30 reference hours remain.

The selected mode matters: 6 reference hours placed on one date give 200% in Spread mode. If that date falls within a 20-weekday FTE span, FTE Ghost% is 10% at Share = 100%. The same code output is compared with different day counts; neither result reconstructs actual working time.

Team and repository totals

The overall Ghost% shown in dashboard and public repository summaries is an effort-weighted average of individual percentages: Σ(Eᵢ × Ghost%ᵢ) ÷ ΣEᵢ. Each person’s percentage already uses their own day count and Share. It is not total team effort divided by 3, nor a pooled person-day rate or a simple average of people. Read the selected scope and mode alongside the total.

Example: A has 30 reference hours across 10 days (100%) and B has 15 across 10 days (50%), both at Share = 100%. The effort-weighted overall result is (30 × 100 + 15 × 50) ÷ 45 = 83.33%. Dividing their combined 45 hours by 20 person-days and then by 3 would give 75%, a different statistic. Positive effort belonging to someone with unavailable adjusted Ghost% makes the adjusted overall result unavailable; zero-effort contributors add no weight.

Spreading effort over time

The timeline is a model of how estimated effort could be distributed, not an observation of when work happened. Normal allocation has a shared capacity of 5 reference hours per person per day across repositories and email aliases in one workspace. Commits authored on the same date are grouped and previous allocations consume that capacity.

The current allocation window contains 14 calendar dates: the commit date and the preceding 13 dates, potentially before the first commit or the selected reporting period. The commit date is eligible even on a weekend; earlier Saturdays and Sundays are skipped. Overflow is retained and included in the modeled timeline. This calculated overflow is not observed overtime. Reporting filters select the dates to which effort was allocated; changing the visible period does not move all of a commit’s effort into that period.

The 5-hour allocation capacity and the 3-hour Ghost baseline serve different purposes. Capacity places reference effort on the timeline; the baseline converts daily reference output into a relative productivity estimate. Neither number records a developer’s actual working day. Dates are interpreted in the projection’s time zone. Older workspaces and saved analyses may retain a previous distribution policy; these parameters describe the current policy.

How to read it

The displayed bands compare output with the selected reference baseline. Use sustained patterns and role context to interpret them:

• 120% and above — above the reference baseline.
• 100% to 120% — at or above the baseline.
• 80% to 100% — slightly below the baseline.
• Below 80% — well below the baseline.

What a result above 100% means

Above 100% means estimated code output exceeds the baseline for the selected day basis and Share. AI assistance can be one cause, alongside experience, tooling and the nature of the work. A high Ghost% alone does not prove AI use, code quality or business impact.

What Ghost% is not

This is a model-based estimate of individual code productivity, with uncertainty. It does not measure actual hours, diligence, ability, code quality, business impact or all work outside the analyzed changes. Use it to investigate sustained low contribution and recognize strong developers, with independent review and role context. It must not be the sole or primary basis for hiring, pay, promotion or dismissal, or an automated verdict on a person.

DevGhost uses Git history and changes. It needs no time tracking, screen capture or keystroke logging.