How auto-capture decides what's worth logging

Auto-capture is one of those features that's easy to get wrong in two opposite directions. Log too little, and it feels broken — wins slip through and the whole point of automation disappears. Log too much, and the suggested-wins inbox turns into another feed to ignore, which is worse than not having the feature at all. Here's a look at the heuristics that keep LogPact's auto-capture somewhere in the middle: useful enough to trust, quiet enough to actually check.

The problem with "just log everything"

The naive version of auto-capture is simple: watch GitHub, Jira, and Slack, and turn every merged PR, closed ticket, and shipped announcement into a suggested win. It sounds thorough. In practice, it's noisy in a very specific way — most of the activity in those tools isn't a win, it's maintenance. A one-line typo fix and a six-month platform migration both show up as "merged PR" if you're not looking any deeper than the event type.

If the inbox can't tell those apart, the person using it ends up doing the filtering by hand, which defeats the purpose. So the detection layer has to do more than watch for events — it has to score them.

What the signal actually looks for

Every connected source contributes a few signals that feed into whether something surfaces as a suggested win at all, and if so, how it gets described.

Scope and effort. A merged PR that touches three files and closes in an hour reads differently than one that spans dozens of files across several weeks. LogPact weighs commit count, file breadth, and time-in-review as a rough proxy for scope — not perfect, but a meaningful filter against routine housekeeping.

Ownership language. Tickets and PRs where the connected account is the primary author or assignee score differently than ones where they're a reviewer, a mentioned collaborator, or one of a dozen people on a thread. Auto-capture is trying to find your wins, not a transcript of everything you were nearby.

Outcome markers. A closed ticket isn't automatically a win — a ticket closed as "won't fix," reopened twice, or rolled back within a week is a weaker signal than one that shipped clean and stayed shipped. Where the source system has that status information, it factors in.

Routine-task filtering. Some activity is structurally unlikely to be a win regardless of scope: dependency bumps, formatting-only commits, auto-generated changelog entries, recurring standup threads. These get filtered out early rather than scored low, since they'd otherwise crowd out real signal just by volume.

None of these signals is decisive on its own. A small PR can be a real win — fixing a production incident might be five lines and enormous impact — which is exactly why this is a scoring model and not a set of hard rules. The goal isn't to be right every time. It's to get the ratio of signal to noise low enough that reviewing the inbox takes ten seconds a day instead of ten minutes.

Why the inbox exists at all

However good the heuristics get, they're still guesses. That's the reason auto-capture never writes directly to your timeline — every detected win lands in a suggested-wins inbox first, where you approve, edit, or dismiss it. Nothing gets logged silently on your behalf.

This isn't just a trust decision, though it is that too. It's also how the detection model gets better for the specific way you work. A dismiss on a low-scope PR you didn't think was worth logging is signal in the other direction — it tells the model that your bar for "worth surfacing" sits a little higher than the default. Over time, the suggestions should get closer to what you'd have logged yourself, if you'd had the time to sit down and write it every week.

The trade-off, made honestly

There's a version of this system that's more sophisticated — one that reads full commit diffs, ranks PRs against your entire team's activity, and writes richer auto-generated descriptions from the ticket content itself. We've deliberately started simpler than that. Heuristics you can reason about and override are more trustworthy than a black box that's occasionally more impressive and occasionally more wrong, and the inbox review step matters more than the detection model being clever. A system that's transparent about being imperfect, and easy to correct, beats one that's quietly confident and wrong more often than it looks.

The result isn't a perfect detector. It's a first pass that gets most of the obvious noise out of your way, and a five-second review step for everything else — which, compared to remembering it all yourself in March, is still the whole point.