Dependency Manifest Change in Public Code Repositories
Most technographic detection reads the outside of a company: script tags, DNS records, HTTP headers, public endpoints. That works for the handful of technologies that touch a browser and misses almost everything else, including the queues, databases, observability agents, identity and payment SDKs, data tooling and model providers that make up the bulk of an engineering budget. Public code repositories expose that layer directly. A dependency manifest is an explicit, versioned list of what a service depends on, a lock file records exactly which versions were resolved, and the commit history records who added each one and when. Additions reveal adoptions. Removals reveal reversals. A removal and an addition in the same commit reveals a migration with both sides named. Dockerfiles, terraform, helm charts and continuous integration workflows extend the same precision to infrastructure and services. Avina monitors the public repositories linked to a company, diffs manifest and lock files commit by commit, classifies each change as an addition, upgrade, pin, replacement or removal, measures how far it has spread across services and releases, and surfaces the accounts where a stack decision has just been made.
Why a Manifest Diff Is Better Than a Technographic Match
A dependency manifest is the closest thing to a declared architecture that a company publishes voluntarily, and it is far more precise than the inference methods most vendors rely on. It is a statement, not a probability. Conventional technographic detection fingerprints externally visible artefacts and assigns a confidence score, which means it is often stale, sometimes wrong and silent about scope. A manifest entry is unambiguous: the library is listed, at a stated version, in a named repository, added by a named engineer at a recorded time. Nothing else in account research is that exact. It covers the part of the stack nobody else can see. Message queues, databases and caches, observability and tracing agents, feature flag and experimentation clients, authentication and payment SDKs, data transformation and orchestration libraries, model and inference clients, internal platform tooling and build infrastructure leave no externally detectable trace. For these categories, which include most enterprise software spend, public manifests are the only dependable public evidence of adoption. Removals are the rarest and most useful event in the dataset. Every technographic provider will tell you what a company added; almost none will tell you what it deleted. A library removed from a manifest is a decision being unwound, a contract that may already be lapsing and a reference that has gone cold. When the same commit removes one client and adds another, the diff identifies the incumbent being displaced and the platform displacing it, with the date on which it happened. The change comes with an author and a timestamp. A commit tells you which engineer made the decision, whether a platform or architecture owner reviewed it, and precisely when. That supports outreach built on a specific decision by a specific person rather than on a vague observation about an account's stack. Scope separates experiments from standards. One dependency in one sample repository is somebody trying something on a Friday. The same dependency appearing across a dozen production services inside a quarter, reaching tagged releases, is a platform standard being rolled out with budget behind it. Counting affected repositories, services and releases makes that distinction quantitative rather than intuitive. In-flight evaluations are visible. When two competing libraries appear in the same manifest, or in parallel branches, or when one is added and then removed within weeks, an evaluation is happening in public. That is the only window in which the outcome is still open, and it closes quietly. Configuration leaks commercial context. Environment variable names, endpoint hostnames, region and tier settings, client initialisation options and feature toggles frequently indicate which product edition or plan tier a company is on. That distinguishes a free-tier user approaching a limit from an enterprise customer under contract, which changes the entire approach. Velocity after the change tells you whether a migration is live. A steady stream of commits touching the new library across services, with the old one being progressively deleted, is a migration in progress and therefore a project with resourcing, deadlines and gaps. A single commit that never spreads is not. And the surrounding files multiply the coverage, because dockerfiles, compose files, terraform, helm charts, kubernetes manifests and continuous integration workflows name hosted services, credentials and endpoints with the same commit-level precision as packages, which extends this signal from libraries to the services a company actually pays for.
How Does Avina Read and Interpret Repository Changes?
Avina, an AI-powered GTM platform, treats a company's public repositories as a continuously updated architecture document. Repositories are linked to companies. Avina associates public organisation accounts, and the personal repositories of identifiable employees where relevant, with the company they belong to, and tracks which repositories are active, which are archived and which represent production services rather than samples or forks. Manifests are parsed across ecosystems. Avina reads package.json, requirements.txt, pyproject.toml, Pipfile, go.mod, Cargo.toml, pom.xml, build.gradle, Gemfile, composer.json, project references, mix.exs, pubspec.yaml and mobile dependency files, along with the lock files that record resolved versions and transitive dependency trees. Every change is diffed and classified. Avina compares manifests commit by commit and labels each change as an addition, upgrade, downgrade, pin, replacement or removal, and where a removal and an addition occur together it records the direction of the replacement and names both platforms. Context is established before conclusions are drawn. Avina determines whether a change sits in production code, test code, examples, documentation or build tooling, how many repositories and services it affects, whether it reached a tagged release or remains on a branch, and the commit velocity that followed, which separates an experiment from a rollout. Authorship is captured. Avina records the committing engineer, their role and seniority where determinable, the reviewers on the pull request, and the title, description and linked issues, since a pull request description is often an explicit statement of why a platform was chosen or abandoned. Infrastructure and service definitions are read alongside packages. Avina parses dockerfiles and compose files, terraform, helm charts, kubernetes manifests, cloud templates and continuous integration workflows for named services, endpoints, regions and credential references, extending detection from libraries to hosted platforms. Commercial detail is extracted where it is exposed. Avina reads configuration and environment variable names, endpoint hosts, region settings and client options that indicate product tier, edition or plan, which distinguishes free-tier usage from a paid enterprise deployment. Evaluations are identified as a distinct state. Avina flags competing libraries coexisting in a manifest, appearing in parallel branches, or being added and removed within a short window, and treats those as an evaluation in progress rather than a settled decision. Corroboration is assembled from outside the repository. Avina cross-references job listings naming the library, platform or category and the volume of such requisitions, engineering blog posts, conference talks and public postmortems, employee profile skills and certifications, technographic detection of the corresponding hosted service, status page and incident history for the platform concerned, licence changes and relicensing events affecting the dependency, end-of-life and deprecation notices for a removed library, and funding, headcount and product activity explaining why the stack is changing. Suppression removes what does not represent a decision. Automated dependency bot upgrades and security patch bumps, transitive dependencies the company did not choose, forks and vendored third-party code, archived and abandoned repositories, template and scaffold repositories, documentation-only and example-only usage, and changes by external contributors rather than employees are all filtered out. Each account is enriched with the libraries added and removed, the classification and direction of each change, the repositories and services affected, release status and rollout velocity, the committing engineer and reviewers, any product tier indicated by configuration, evaluation state where competing libraries coexist, corroborating hiring and content evidence, and concurrent signals, then matched against your ICP filters.
What Happens When a Dependency Change Signal Fires?
Avina scores on direction, scope and whether a competitor is involved. A commit that removes a competing library and adds yours, or removes yours and adds a competitor's, scores at the top of the model, because a migration is under way and both sides are named. A competing library added across multiple production services and reaching tagged releases scores highly, because a platform standard is being set and the window to compete is closing. Two competing libraries coexisting in a manifest scores highly, because an evaluation is live and the outcome is still open. A library in your category added to a single production service scores as an entry point worth working, since initial adoptions are how standards start. A removal of a library in your category with nothing added in its place scores highly for a replacement conversation, because a capability has been dropped and the need usually has not. Configuration indicating a free or entry tier alongside growing usage across services scores as an expansion opportunity. Automated bot upgrades, transitive dependencies, vendored code, archived repositories, documentation-only usage and external contributor commits are suppressed. Timing is set by the commit history, which makes it unusually sharp. The days after an initial adoption are the highest-value window, because the engineer who made the choice is still working on it and the integration is unfinished. An evaluation with competing libraries present has a short and unannounced deadline, so speed matters more than polish. A rollout spreading across services is a live project with gaps in observability, security, testing and support that appear as the surface area grows. A removal is immediately actionable, because something was just taken out. A library's own licence change, price increase, deprecation notice or end-of-life announcement creates an externally imposed window across every account that depends on it, which can be worked as a cohort rather than one account at a time. And a tagged release containing the change marks the point at which the decision became production reality and therefore harder to reverse. Routing follows the commit. The engineer who authored the change owns the decision and is the most credible first contact, because the conversation can start from the specific commit. The reviewers on the pull request, particularly a platform or architecture owner, hold the standard-setting authority. The engineering manager or director over the affected services owns the rollout and its resourcing. The platform or infrastructure team owns anything that spreads across more than a few services. The chief technology officer or vice president of engineering owns the architectural direction where a company-wide migration is underway. The security team owns dependency risk, licence compliance and software bill of materials obligations where those are the angle. And the procurement or finance contact becomes relevant only once a free-tier deployment has grown into a paid one. Contacts are enriched with verified emails, phone numbers and LinkedIn profiles across the committing engineers, their management chain and platform and security leadership. Reps receive a Slack alert naming the company, the library added or removed, the repository and service, the commit author and date, the pull request context, the number of services affected, release status, any product tier indicated by configuration, the competing library where one is present, and the recommended angle. Salesforce and HubSpot records carry the commit reference, so outreach can cite the actual change rather than a general observation about the stack. Qualified accounts can be auto-enrolled into sequences built on the type of change: a migration message where a competitor has been removed in favour of your category, a defence message where your library has been removed, a bake-off message where competing libraries coexist, an expansion message where free-tier configuration meets growing usage, a scale message where a rollout is spreading across services and creating operational gaps, a cohort message where a dependency's own licence change or end-of-life forces action, and a standard Outreach or Salesloft sequence with the library, repository, commit date and engineer populated into the messaging.
Start Tracking Dependency Changes With Avina
A line added to package.json or deleted from go.mod is a stack decision with a timestamp and an author, and it precedes every announcement. Activate this signal in Avina's Signals Library to reach the engineer who made the call while the integration is still open. Every plan includes a 7-day free trial with no credit card required.