Codebase Time Machine replays a target's Git history, as deep as you choose, to show which files rest on one or two key engineers, how strong that evidence is, and what to ask management before you sign. It sees code contributors only: who wrote and changed the code, not who understands it today.
A read-only token scoped to the repository you want analysed. We never ask for write or admin rights, and you can revoke the token at any time.
The repository is cloned into a temporary directory created for that scan. You choose the depth, up to the complete history, and the report states what share of it was analysed.
A PDF for the investment committee and an Excel workbook for the deal team.
The working copy is deleted when the scan ends, and the deletion is logged. A forcibly terminated scan is the exception; we check by hand after one.
CTM adds one question to technical diligence: where the critical code knowledge sits, and whether whole subsystems depend on one or two people who may have no contractual reason to stay past close.
If the one person who understands a core subsystem leaves the day after you sign, what breaks, how long until anyone else can safely touch it, and what does that do to your model?
If only one engineer can safely change a subsystem, the value you are paying for depends on someone who can resign the week after close.
A single bottleneck engineer can delay a migration, carve-out or roadmap after the price is already set.
Raised and confirmed before signing, a concentration can shape a retention package or an earn-out condition instead of becoming a post-close surprise.
We measure what share of each file's changed lines (added and removed, across its whole history) one contributor wrote. That line share is the evidence. A tier is then derived from the line share and the file's commit count against fixed thresholds, not a subjective judgment.
Illustrative data, not a real repository. Each tile is a subsystem, shown with the tier and line share of its most concentrated file. In a report, tiers are assigned per file; subsystems get their own concentration measures.
High-confidence: 10+ commits on a file, with one contributor writing over 70% of its changed lines (held at Watch when a single commit accounts for most of that contributor's lines). Strong evidence of concentration; confirm with management who maintains it today.
Watch: 5+ commits and over 55% line share. Concentration is visible but the history is shorter; ask who maintains it today.
Distributed: no single contributor reaches the Watch threshold.
A file with fewer than 5 commits gets no tier, however concentrated it is: so few commits describe a few changes, not a pattern of who holds the knowledge.
What was found, how strong the evidence is, and the highest-priority finding up front.
Which contributors hold the history of which files, and how concentrated it is: evidence, then interpretation, then a recommendation that applies only if management confirms the dependency.
Files ranked by concentration, with line share, commit count and tier. The full list stays in the workbook.
The same measurement at subsystem level, so you see where in the system history is concentrated, and in whom.
How each top file's share of commits has changed over time, not just a snapshot. The report labels this separately from line share, the measure behind the tiers.
Which questions the scan answers itself, and which only management can answer.
How much of the repository's history was analysed, what Git history cannot establish, and the exact tool version and settings that produced the report.
Evidence first, then why it could matter, then what to ask, then what to do. Git history shows who wrote the code. Only management can say who maintains it today, so the report keeps the two apart.
Which files and subsystems one contributor holds, the commits behind that line share, and how strong the evidence is.
Codebase Time Machine drops into the process you already run. It runs during confirmatory diligence, informs the terms you negotiate, and gives the integration team a starting list on day one.
Turn "the team seems strong" into a line in the IC memo.
Know whose knowledge to confirm before you sign.
Add a key-person section built on commit evidence.
What CTM adds to a deal file: an evidence-backed picture of where code knowledge is concentrated, with its confidence and its limits stated.
| The question | What CTM gives you |
|---|---|
| Where is code history concentrated? | Per file: the line share one contributor holds, the commits behind it, and a confidence tier. Per subsystem: how concentrated it is |
| How has that changed over time? | Risk evolution for each top file |
| What should we ask management? | Buyer questions, split into those the scan answers and those only management can answer |
| What can't it see? | People who never committed code, and who maintains the code today. The report says so. |
The automatic deletion is recorded. A forcibly terminated scan can leave a temporary copy behind without recording it, so after one we check by hand and delete what we find. CTM is a tool we run for you, not a cloud service you sign up to: there is no customer account and no database holding your repository.
How a scan works. Your repository is cloned over HTTPS onto the machine running the analysis, into a temporary directory created for that one scan. It is read there and nowhere else. When the scan ends, whether it succeeds or fails, that directory is deleted, along with the temporary directory used to assemble the report. What survives is the report we hand you, and a deletion log (unless the scan was forcibly terminated; see below).
What leaves that machine. The authenticated request to your repository host to fetch the code; a metadata request to that host's API; the finished report, which we deliver to you; and, if you ask for it, the deletion record. Nothing else, unless you have agreed in writing to the optional AI narrative, which is off by default.
The optional AI narrative is off. With it off, no part of your repository, no commit message and no contributor identity reaches any AI service. Every number and every finding in the report is computed deterministically from your repository's files, its Git history and repository metadata on the machine that ran the scan. If we ever propose enabling it, we will ask you first and in writing.
Identities are pseudonymised by default. Unless you ask in writing for named reports, contributor names and email addresses are replaced with pseudonyms such as "Contributor A". Names that appear inside file paths, commit messages or code-owner team handles are not scrubbed. (Pseudonymised, not anonymised: this reduces exposure, it does not take the data outside GDPR.)
Every report records what produced it. Each report carries its own provenance: the exact version of CTM, whether that version had local modifications, the analysis settings, the timestamp, and whether AI was used.
Deletion is evidenced. Each automatic removal of temporary data is recorded: which scan, which class of data, whether it succeeded, and when. We can send you that record. It deliberately contains no file names, no paths and no contributor identities, so the evidence of deletion never becomes a place your information comes to rest. A forcibly terminated scan leaves no automatic record; see below.
Credentials. You give us a read-only token scoped to the repository you want analysed, which you can revoke at any time. It is sent to your repository host as an HTTP authorisation header and is never written into the clone's configuration, a command line, a log, or any report.
Supported hosts. github.com, gitlab.com and bitbucket.org. GitHub Enterprise Server and self-managed GitLab are not supported today.
We would rather tell you this than have you find it out:
No encryption at rest. Your code is protected while it exists by the short lifetime of the copy and by the machine's own access controls, not by application-level encryption.
No certification. No SOC 2, no ISO 27001, no GDPR certification, and no independent penetration test.
Access to the tool is protected by an operator passphrase, not individual accounts or single sign-on.
A forcibly terminated scan can leave a temporary copy behind without recording that it did. We check by hand after any forcibly terminated scan.
Working with European customers. We can sign a data processing agreement under Art. 28 GDPR. Ask us for the Security & Trust Pack: it covers the data flow, retention and deletion, access control, incident response, AI egress, subprocessors, and a GDPR readiness checklist that states the open gaps as plainly as the controls.
I built Codebase Time Machine because who holds the knowledge of a codebase matters to a deal, and much of that knowledge is written into the company's Git history, where it can be measured.
I run every engagement myself, and I'll walk you through exactly what I read, and what I never touch, before you grant any access. No support rotation, no black box.
The full repository is cloned for one scan: its source files and its Git history (authors, dates, file paths, commit messages and the content of each change), plus basic metadata from your repository host. CTM counts and attributes lines, and scans file contents and changes for exposed secrets and licence files. Source code can contain personal data, and we treat it that way. Not runtime data, and not anyone who never committed code. Git shows who wrote and changed the code; who maintains it today is a question for management, and the report says so.
No. Access is read-only, through a token scoped to the repository, and you can revoke it at any time.
Your repository is copied for a single scan and the copy is deleted when the scan ends, with the deletion recorded (a forcibly terminated scan is the exception; we check by hand after one). The optional AI narrative is off by default, so nothing goes to any AI service. Delivered reports pseudonymise contributor identities by default, and each report states the exact tooling and settings that produced it. We hold no certification and do not encrypt at rest. Our full Security & Trust Pack says so, along with everything else we do and do not do.
Tiers come from fixed thresholds on line share and commit count. For example, 10+ commits on a file with one contributor writing over 70% of its changed lines is High-confidence, unless a single commit accounts for most of those lines. It's not a subjective score, and it measures concentration of history, not who maintains the code today.
Every engagement is quoted individually, before you grant any access, so you know exactly where you stand up front. Book a call or email us and we'll turn a quote around quickly.
The analysis runs in minutes to a few hours, depending on repository size and depth. Depth is your call, from the most recent commits up to the repository's complete history, and the report states the exact share of the history it analysed.
Nothing, by default. Every number and finding is computed deterministically from your repository's files, its Git history and repository metadata. An optional AI narrative exists; we enable it only if you agree in writing first.
Questions before you hand over repo access? Email directly at hello@codebasetimemachine.com and you'll hear back from the person who built this, not a support rotation.
AI off by default, contributor identities pseudonymised, read-only access. You receive the PDF and workbook. You never install anything, and the tool never leaves our hands.
Book a call →