Practical guide · 2026
A Repository Is Not a Product History
How to reconstruct the people, agreements, third-party components, data and AI tools behind a growing product before due diligence sets the deadline.
- Reading time
- 3 minutes
- Published through
- LinkedIn and Astana Hub
- Topic
- Systems and Implementation
- Series
- The system around the product
About this edition. This English site edition consolidates the published English and Russian versions into one reference article.
A repository can show who committed a line of code and when. It cannot tell you whether that person was a founder working before incorporation, an employee acting within an assigned role, a contractor under a development agreement or someone helping informally before contracts existed.
It may not show where a design came from, which dataset was used for early testing, whether an external component arrived under a licence or what an AI tool was asked to produce. The repository is important evidence. The history of the product is wider.
Reconstruct four links
A useful product history connects four things:
- Element. Code, design, content, data, model, integration, documentation or brand asset.
- Creator or source. Founder, employee, contractor, vendor, open-source project, customer or AI service.
- Basis of use. Employment terms, assignment, licence, contract, consent, public-domain status or another documented basis.
- Evidence. Repository history, signed document, invoice, delivery record, licence file, email, ticket or versioned decision.
A list of contributors without the relevant product element is incomplete. A folder of agreements without a link to what was delivered is equally hard to use.
Reconstruct by version, not by today's organisation chart
The current company structure can distort the past. The first prototype may predate the company. A contractor may later have become an employee. A module may have been replaced while parts of its data or design remained.
Build a simple timeline: prototype, first commercial version, major architecture change, new dataset, acquisition of an asset, introduction of a third-party model. For each stage, ask who contributed and under which relationship at that time.
This prevents a common shortcut: assuming that the company owns everything because the people involved now work there.
Use a set of traces
There may be no single perfect document. That does not make the history unknowable.
A repository record, invoice, statement of work, delivery email and access log may together establish a much stronger account than any one item alone. Record the evidence set and the uncertainty that remains.
Use unknown as a working status. It is not the same as a violation. It means the team knows where investigation, remediation or a new agreement may be required.
Prioritise the gaps that can affect the next event
Do not begin by trying to recover every historical file. Start with what could change the next material decision:
- the core code and model components;
- founder and contractor contributions;
- licences with commercial, attribution or distribution conditions;
- datasets used for training, testing or product operation;
- brand and customer-facing assets;
- components that cannot easily be replaced.
The first map should fit on one page. Its purpose is not historical perfection. It is to give the company a defensible account, a remediation queue and a mechanism that keeps the next contribution from becoming another archaeological problem.