Reconstructing Change Requests and Change States in IT Projects

IT Projects & Technical Due Diligence

A change request is an organisational or technical request, not proof that a corresponding implementation was created or deployed. Reconstruction therefore separates the request, versioned code change, review or pull request, build artefact and release state, then connects those elements through identifiers, content and provenance.

1. Separate the change request from implementation

Intent and technical state are different evidence classes

A change request can exist without implementation, can be implemented differently from its wording, or can be superseded by later discussion. The examination records the request's content, identifier, version and status history where available.

Comments and ticket transitions provide context but do not automatically establish what was changed in source code. The implementation should be identified independently through versioned artefacts.

Where the request itself changed, the report should preserve the applicable wording for the technical state being examined.

2. Use Git history as a technical timeline

Version relationships and content are more important than one timestamp

Commit history can identify revisions and parent relationships, while diffs show the actual technical changes. Branch names, merge commits, tags and release references can help reconstruct the route by which a change entered a delivery line.

Git timestamps require interpretation. Rebase, cherry-pick or amended commits can alter committer metadata without changing the original intent of the code. The relevant time field should be documented rather than treated as a generic implementation date.

Full object IDs can provide stable references to the examined repository state. A commit still does not prove deployment unless the release or build chain connects to it.

3. Relate pull requests, reviews and CI/CD records

Review and build systems add context to the versioned change

Pull requests can connect discussion, approvals and merge actions to specific revisions. CI/CD systems can show which tests ran, which inputs were used and which build artefact was produced.

These systems may reference commits by hash, branch or tag. The strongest chain preserves a concrete revision through build and release rather than relying only on a human-readable branch name that may later move.

SLSA provenance concepts can help structure the relationship between build inputs, builder and output. Absence of formal provenance does not prove an artefact is wrong; it limits how confidently the artefact can be tied to a source state.

4. Reconstruct chronology without false precision

Several timestamps can describe different events

Ticket updates, commits, pull-request approvals, pipeline runs and deployments can occur close together without representing the same event. The reconstruction preserves the semantic meaning of each timestamp.

When systems have different clock sources or time zones, original values should remain visible and any normalisation should be documented.

A range or sequence can be more accurate than a single asserted implementation time when the available records cannot establish one exact point.

5. State technical limits of assignment

Temporal proximity is not sufficient evidence of content relationship

A commit made shortly after a ticket does not necessarily implement that ticket. The relation should be supported through ticket references, changed files, code semantics, tests, review discussion or other artefacts.

Likewise, a release occurring after a commit does not prove the commit was included unless branch, tag, build or artefact provenance supports the inclusion.

The technical reconstruction does not decide why a change was requested, whether a party was obligated to implement it or whether the timing has legal consequences.

6. Build a change matrix and defensible assignment chain

The chain should remain reviewable event by event

A practical matrix can record change-request ID, applicable requirement, candidate commits, merge or pull request, build identifier, tests, release artefact, deployment and confidence of the assignment.

Where the chain is interrupted, the matrix shows the missing link instead of assuming continuity. This is especially useful when artefacts were rebuilt locally, tags were moved or manual release steps occurred.

Confidence can differ by change. One request may be fully traceable from ticket to deployed artefact, while another remains supported only by contextual timing.

Depth: follow request, approval and realised state separately

A change request does not prove implementation

Tickets can be proposed, rejected, partially implemented, superseded or delivered in a different form. Repository, build, test and release evidence should be used to connect the request to the actual system state.

Scope changes can create several competing explanations for schedule and quality effects

Delay or rework may result from the change itself, dependencies, estimation error, technical debt or parallel project events. The review should avoid attributing later outcomes to a change merely because the dates are close.

Further reading

• Reconstructing the History of an IT Project
• Requirements, Actual State and Technical Acceptance
• Reconstructing Test, QA and Release Evidence
• Reconstructing Project Documentation and Decision History

IT Project Assessments & Project Reconstruction

Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.

Explore this assessment service