Metrics · LGTM · L
Landing
What share of AI-assisted work actually ships?
Landing is the share of build-intent sessions whose work reached a merged or published outcome within the follow-up window. It connects the session record to the receipts — commits, pull requests, published documents — so effort and outcome stay in one number.
What it reads
- ●Session records (PSF) for the team and window, with their artifact links
- ●Repository state: which commits and pull requests merged, and when
- ●Published-document state, where sessions produce docs rather than code
How it’s computed
Take a team's sessions for a trailing window, keep the ones that set out to build something, and check whether their linked artifacts landed within fourteen days.
// window: trailing 30 days · scope: one team
const sessions = psf.load({ team, window })
.filter(s => s.intent === "build"); // exclude pure Q&A / exploration
const attempted = sessions.length;
const landed = sessions.filter(s =>
s.artifacts.some(a =>
a.kind === "commit" || a.kind === "pull-request"
? repo.merged(a.ref, { within: days(14) })
: docs.published(a.ref, { within: days(14) })
)
).length;
const landing = landed / attempted; // report with n and the trend
How to read it
- →A falling Landing with rising session volume is the classic churn signature: lots of starts, few finishes — look for review bottlenecks or unclear requirements upstream.
- →Landing differs by kind of work. Compare a team to its own history, and read it beside the trend, never as a lone number.
How it gets misused
- ✕Landing describes a team's flow. Computed per person it becomes an activity score, which the house rules prohibit.
- ✕Landing is a denominator game — excluding exploration sessions is the point, so agree on the intent classification before comparing anything.