IT Projects & Technical Due Diligence
A project history is not reconstructed from one timeline field. Tickets, Git commits, emails, meeting records, CI/CD logs and deployment artefacts record different events and use different time semantics. A technical reconstruction therefore classifies each source, preserves original references and timestamps, normalises time only for comparison, and distinguishes documented sequence from causality and responsibility.
Short answer
The reconstruction begins with a concrete question and a source matrix. For every source, the analysis records what the timestamp technically represents and what the source can and cannot establish. Ticket creation, Git author date, Git committer date, email Date headers and SMTP Received fields are not interchangeable.
A reliable chronology grows stronger when distinguishable sources correlate through ticket IDs, commit IDs, Message-IDs, build identifiers or matching content. Temporal proximity alone is not enough to prove that one event caused another or that a contractual obligation was fulfilled.
1. Define the reconstruction question and source basis
The chronology should answer a bounded technical question
Before collecting dates, the examination defines what is being reconstructed: implementation of a feature, correction of a defect, release of a build, change of an architecture decision or another technical event. The relevant period and systems follow from that question.
A source matrix can classify ticket systems, repositories, build logs, deployment records, emails, meeting minutes and exported documents. For each source, the matrix records original identifiers, available history, acquisition form and known limitations.
Current database fields or screenshots can omit earlier states. Where audit histories, exports or original files are available, they should be distinguished from current snapshots.
2. Place ticket and repository events in time
Ticket timestamps and Git timestamps describe different technical events
A ticket can contain creation, status transitions, comments, assignments and later edits. An 'updated' field does not establish when the described code change was implemented, and ticket creation only establishes when the item entered the system.
Git provides versioned repository events. Commit history can establish object relationships and recorded metadata, but a commit can contain distinct Author Date and Committer Date values. Rebase, cherry-pick or other history operations can therefore create time relationships that differ from the original authoring time.
Content inspection remains separate from time metadata. Commands such as git show and git diff can connect a commit identifier to the actual versioned change. A commit by itself does not establish productive deployment or actual working time.
3. Evaluate email and time information
Message dates, transport traces and time zones require context
RFC 5322 describes fields including Date and Message-ID. The Date field records the origin date represented in the message header; it is not automatically the same as the recipient's receipt time. A Message-ID can support message correlation but does not on its own prove authenticity or receipt.
SMTP Received fields described in RFC 5321 can record transport stages. Preserved full headers can therefore provide additional time and routing information that a screenshot or printed message may not retain.
Sources can use UTC, local time or different UTC offsets. The examination preserves each original value and may derive a normalised comparison time under documented rules. Normalisation helps comparison but does not alter the original source.
4. Correlate meeting records and technical sources
Different source types have different evidentiary roles
Meeting minutes document human-recorded statements, decisions and observations. Their date, document creation time, later edits and approval status can differ. These properties are distinct from an automatically created repository event.
A stronger reconstruction can arise when a ticket ID appears in a commit message, a release record names the same revision and a CI/CD record documents a build from that state. The relationship is supported by several technical links rather than by time proximity alone.
Apparent multiplicity should be examined carefully. A build system may copy a ticket title into a release note, so several records can originate from one source rather than represent independent confirmation.
5. Handle contradictions, gaps and causal limits
Do not manufacture a precise chronology from incomplete material
Deleted tickets, partial repository histories, missing email headers and documents created after the event can create unresolved gaps. Conflicting timestamps should be shown and explained where possible instead of being silently reconciled.
A chronology can support the order in which documented events appear. It does not prove that earlier event A caused later event B. A causal statement requires a technical mechanism, relevant system state and consideration of alternative explanations.
Where assignments remain uncertain, the report can distinguish confirmed, plausible and unresolved relationships. This is more informative than presenting one unsupported timeline as definitive.
6. Document and assess the technical project history
Every event should remain traceable to its source
A structured event record can include sequence number, source system, original reference such as ticket ID, commit ID or Message-ID, original timestamp, UTC offset, normalised comparison time, supported event description, related sources and a technical limitation.
Exported files or archives can additionally be identified by cryptographic hash values. The hash documents which file was examined later; it does not establish the truth of every statement contained in the file.
The technical report can state that an implementation is first supported by a particular commit and later linked to a build. It does not automatically determine whether a party breached a contract, caused a delay or bears legal responsibility.
Is the project chronology technically traceable?
- Is the concrete reconstruction question and relevant period defined?
- Are the available sources classified in a source matrix?
- Is the technical meaning of every relevant timestamp documented?
- Are Git Author Date, Committer Date and commit content distinguished?
- Are original time values preserved and time-zone normalisation documented?
- Are events correlated through identifiers, content or technical relationships rather than timing alone?
- Are missing or contradictory sources explicitly treated as limitations?
- Are chronology, technical causality and legal responsibility kept separate?
Constructed example
A disputed export function appears as a change request on 3 March. An email on 5 March contains the same ticket number. A Git commit on 8 March references that number and a CI/CD record on 9 March documents a build from the corresponding repository state.
The reconstruction records each source separately, preserves its time semantics and then documents the technical relationships among ticket, email, commit and build. It can support a traceable event sequence; whether the feature was contractually due at an earlier date remains a separate question.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Technical primary source Git documentation: git-log, used for the representation and examination of commit histories. Open source.
- Technical primary source Git documentation: pretty-formats, including Author Date and Committer Date representations. Open source.
- Technical primary source Git documentation: git-show and git-diff, used to examine concrete versioned changes. Open source.
- Technical primary source Git documentation: git-diff, retained separately from the German reference article for examination of versioned differences. Open source.
- Technical primary source Git documentation: git-rev-list, used for commit-set and repository-history analysis. Open source.
- Technical primary source RFC 5322, Internet Message Format, used for email header fields including Date and Message-ID. Open source.
- Technical primary source RFC 5321, Simple Mail Transfer Protocol, used for SMTP trace information and Received fields. Open source.
- Technical primary source RFC 3339, Date and Time on the Internet, used for standardised timestamps and UTC offsets. Open source.
- Author technical literature Mathias Ellmann: Von Code zu Lösungen im Software Engineering mit Java, providing technical background on requirements, version control, development processes, decisions and defect analysis. Open source.
- Author methodological framing Source matrix, separation of time semantics and cross-source correlation are used as methodological building blocks for project reconstruction.
Further reading
- Requirements, Actual State and Technical Acceptance
- Reconstructing Change Requests and Change States
- Reconstructing Test, QA and Release Evidence
- Reconstructing Project Documentation and Decision History
Critical review and methodological limitation
A project chronology can organise sources and establish technically supported sequences, but it should not turn every timestamp into a factual start or completion date. The semantics of the originating system determine what the value means.
Alternative explanations remain essential when sources coincide. Tickets, emails, commits and deployments can reflect the same project activity without establishing causal or contractual relationships.
- Source semantics: each system records different events and may retain only part of its history.
- Time semantics: original values, time zones and Author/Committer distinctions must remain visible.
- Causality: chronological order and technical cause are separate analytical steps.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Project Assessments & Project Reconstruction
Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.
Explore this assessment service