# I name what I built and what I adapted.

Why precise contribution labels make technical work more credible, reviewable, and useful.

- **Canonical URL:** https://vidhata.me/notes/i-name-what-i-built-and-what-i-adapted
- **Author:** Vidhatanand V. (Vid)
- **Role:** Fractional CTO and AI Systems Architect

**Published:** 04 Sep 2026 | **Reading time:** 8 minute read

## Why I hold this position

Source control makes it easy to show that code exists under an account. It does not prove that every line was written there, that every architectural decision was original, or that an adopted foundation remained unchanged. I do not think credibility requires pretending otherwise.

I use precise contribution language because software is usually assembled through several kinds of work. A team may evaluate an upstream project, integrate it with a new platform, extend one subsystem, migrate its data, wrap it behind a safer interface, or build a new product around it. Those are real contributions, but they are not interchangeable.

## Originality is not a binary property of a repository.

A repository can contain an original service, a standard component library, adapted upstream code, generated scaffolding, and a custom deployment layer at the same time. Calling the whole repository either original or copied loses the information a reviewer actually needs.

I prefer to identify the boundary. Which modules came from an external foundation? Which interfaces were changed? Which operational behaviour, data model, workflow, or deployment was added? Which parts remain dependent on upstream maintenance? The answer can be nuanced without being vague.

## I use contribution verbs that can be tested against evidence.

The labels I find useful are evaluated, integrated, extended, migrated, wrapped, adapted, and built originally. Each verb suggests a different evidence request. Evaluation should show criteria and findings. Integration should show the contracts and surrounding system. Extension should show the delta. Migration should show old and new paths, reconciliation, and rollback.

Built originally is the strongest claim, so it deserves the clearest support. Design records, commit history, implementation files, tests, and deployment evidence should point to the same boundary. I do not use that label merely because a repository is not formally marked as a fork.

## Integration can be difficult without becoming authorship.

Some of the hardest work happens around an adopted foundation. Making it fit a new domain may require permissions, data conversion, model serving, storage abstraction, review workflows, reliability controls, and a maintainable upgrade path. That work can be more consequential than writing a similar amount of isolated code from scratch.

Precise attribution does not diminish that value. It explains it. A founder or buyer can see why the integration matters, what knowledge the team owns, and where external dependency remains. Inflated authorship claims make that conversation harder because every later discovery becomes a trust problem.

## Precise attribution improves technical diligence.

Contribution labels expose licensing, security, and maintenance questions early. An adopted foundation needs an upstream update policy. A wrapped service needs a switching plan. A migrated system needs evidence that the old path no longer holds authoritative data. An original subsystem needs clear ownership and tests.

The same language improves portfolios. It lets me show breadth without turning repository presence into personal authorship. I can be proud of evaluating, integrating, extending, and operating technology well. The work becomes easier to trust because the claim is narrow enough to verify.

## What I take into the next build

- Describe the contribution boundary, not only the repository.
- Use verbs such as evaluated, integrated, extended, migrated, wrapped, adapted, and built originally.
- Match each contribution label with evidence that could disprove it.
- Treat precise attribution as a technical control, not modesty.

## Continue reading

[All Fractional CTO field notes](https://vidhata.me/notes)

## Work with Vid

Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).