Preparing for technical due diligence: evidence for code, models and rights provenance

When software companies prepare for technical due diligence or materials related to an initial public offering (IPO), they should ensure that their core products, development processes, external dependencies, and sources of rights are aligned. Detection reports can provide clues and records but do not replace the judgment by responsible parties during audits.

Build an evidence index around the core product

List core features, corresponding modules, code repositories, responsible individuals, and major dependencies by product and version. Differentiate between self-developed, open-source-introduced, commercial-purchased, commissioned development, and cooperative development, and associate each source with the relevant documents.

Code submission records can explain a part of the development process but do not alone prove full rights ownership. Contracts, employment development arrangements, outsourced deliveries, historical authorizations, and personnel changes also need to be verified to avoid drawing complete conclusions based solely on repository names or registration certificates.

Keep separate evidence for open-source and commercial components

For open-source components, maintain records of version numbers, licenses, modification methods, and combination strategies, as well as corresponding source code declarations. For commercial components, verify the authorization holder, validity period, intended use, distribution scope, and maintenance arrangements. When actual deliverables do not match the recorded information, first analyze the cause before supplementing or correcting the records.

Software Composition Analysis (SCA) can help identify components, similar code, and license clues. Code that is not recognized by tools cannot be directly attributed to being entirely self-developed, and a lack of issues found during scanning does not prove the absence of third-party rights disputes.

Define how the in-house development ratio is calculated

If using metrics like 'self-developed rate' or similar indicators, clearly state the statistical scope, denominator, handling methods for generated code and third-party code, duplicate code removal rules, and manual verification procedures. The proportion of lines of code does not equate to core technology contributions; a single percentage cannot explain an enterprise's technical originality.

For AI products, also document the base model, weight sources, fine-tuning processes, data origins, and application development work. Model similarity can serve as investigative clues; it cannot alone prove copying, infringement, or technical autonomy.

Make remediation records reviewable

Each issue should be linked to the material gaps, responsible parties, handling methods, completion dates, and verification results. Confirm updates after replacing dependencies, verify signed authorizations, and ensure contract coverage matches actual uses.

Enterprises should verify applicable requirements jointly with research and development, intellectual property, law enforcement and related intermediaries. The value of technical services is to improve the completeness and traceability of information and cannot be reviewed by a certain report or fixed service package.