How to Connect Commits and Work Sessions to a Project Deliverable

A commit is evidence of a code change. It is not a complete account of the work around it.

The missing context may include investigation, prompts, agent output, review, testing, rework, or an abandoned approach. If you begin with a commit and work backward, it is easy to pull unrelated activity into its story. A stronger review begins with the thing you were trying to deliver.

1. Define the review boundary first

Write down four items before opening session records or Git history:

• Deliverable: the specific result you intended to produce.
• Project: the codebase or client engagement it belongs to.
• Task: the issue, request, or work item being addressed.
• Review period: the time window you are examining.

Keep the deliverable narrow. “Improve the application” is too broad. “Add validation to the payment form” gives you something testable against the record.

This boundary prevents a common error: finding a commit that looks relevant, then assuming every nearby session was part of that work. A session on the same day may belong to another task, an exploratory branch, or general maintenance.

2. Build a session-to-task list before looking for proof of outcome

Gather the computer-based and AI-assisted sessions that fall within the review period. For each one, note the available project context, task reference, short description, and anything that makes the connection uncertain.

Do not force every session into the chain. Use three simple labels:

• Directly connected: the session clearly concerns the task or deliverable.
• Possibly connected: the timing or project fits, but the record does not establish the relationship.
• Not connected or unknown: there is not enough context, or the session belongs elsewhere.

LogAgent tracks AI-agent sessions, including time, tokens, cost, commits, and short titles from local session logs. That can give you a starting record, but it does not remove the need to interpret the work in context.

For example, imagine you are reviewing a deliverable called “Add validation to the payment form” for task PAY-142. You find three sessions:

1. A session titled “payment form validation” in the relevant project.
2. A session about updating a dependency in the same repository.
3. A session with no useful title after a long break.

The first is a direct candidate. The dependency update may be related only if the task record or resulting change supports that connection. The third should remain unknown unless you can establish more context. Unknown is a valid review result, not a gap to fill with confidence.

3. Connect commits to the defined deliverable, carefully

Now inspect commits associated with the relevant sessions and project. Ask a narrower question than “Did this work produce a commit?” Ask: “What does this commit show about this task and deliverable?”

A useful commit-to-deliverable connection has at least one clear basis: a task identifier, a commit message that describes the requested change, a changed area of code that matches the deliverable, or review context that ties the change to the work item. The more direct the basis, the less explanation you need to add.

LogAgent can link AI sessions to commits, tasks, projects, and invoice lines. Use those links as a chain to inspect, not a shortcut to a conclusion.

In the example, a commit named PAY-142 validate payment form fields is strong evidence that a change was made for the task. It supports a direct chain from the relevant session to the task and deliverable. But it does not automatically prove that every minute before the commit was necessary, successful, or part of that deliverable.

Treat these situations separately:

• A commit directly supports the deliverable.
• A commit is related to the project but not clearly to the task.
• A session produced a change that was later reverted.
• A session was exploratory and produced no commit.
• A session may have contributed through review or testing, but the record cannot establish that connection.

This distinction is the difference between a review record and a polished story assembled after the fact.

4. Keep the chain readable and preserve its limits

Your final review can fit in a short structure:

Deliverable: Add validation to the payment form
Task: PAY-142
Direct sessions: One AI-assisted implementation session with matching project and task context
Commit evidence: PAY-142 validate payment form fields
Outcome: Commit matches the requested change
Open questions: A separate dependency-update session may be related, but the available record does not establish it

That last line matters. It prevents uncertain activity from becoming an unsupported claim about work performed.

Use this checklist before sharing the record in a status update, report, or billing discussion:

• Is the deliverable specific enough to review?
• Does each included session have a stated connection to the project or task?
• Does each commit support the deliverable, rather than merely occurring nearby?
• Have you marked inferred links as inferred?
• Have you separated unfinished, reverted, and outcome-unknown sessions?
• Can another person follow the chain without needing your memory of the day?

LogAgent uses explainable rules and heuristics and routes disputed segments to review. That is useful when a segment needs attention, but your final judgment should still state what the record shows, what it suggests, and what remains unresolved.

A well-formed chain does not claim that a commit proves all work was valuable or billable. It gives you a more honest basis for discussing how a defined deliverable moved from work sessions to a recorded change.