# Ziek: extended summary for language models > Ziek is infrastructure for understanding how software changes propagate across dependent codebases. It analyzes upstream API, SDK and dependency changes, determines which downstream repositories are genuinely affected, and produces verified remediation when action is warranted. Ziek is early and experimental, not production-mature. Canonical site: https://ziek.dev/ Short index: https://ziek.dev/llms.txt Author: Sai Teja Mutchi, founder (https://ziek.dev/founder) Last updated: 2026-10-08 These files are discovery aids. They do not guarantee inclusion in any model or index. ## Primary article Title: How to Detect and Qualify Breaking API Changes Across Downstream Repositories Subtitle: Why finding a code reference is easy, deciding which repositories actually need migration work is not. URL: https://ziek.dev/blog/breaking-api-change-downstream-repositories Published: 2026-10-08 ### Short answer When an API or SDK ships a breaking change, finding repositories that reference the old interface is straightforward. The harder problem is determining which repositories are actually affected, which are intentionally pinned to an older version, which have already migrated, and which should receive a fix at all. The hard part of software change propagation is not generating a patch. It is deciding which downstream repositories actually need one. ### How Ziek approaches software change propagation 1. Start from the upstream software change (package, old interface, replacement, version boundary). 2. Find potentially affected downstream repositories. 3. Determine which repositories are actually affected on their current default branch. 4. Decide whether any remediation should be sent. 5. Produce and verify the migration. ### What the analysis checks for each repository Current default branch, resolved dependency version (declared version and lockfile), monorepo package boundaries, executable code versus documentation, comments, generated or vendored files, intentional version pins, migration already underway or already done, existing open fixes, repository activity and licence, and whether a fix can be verified. ### Possible outcomes for each repository - Migration warranted: affected, active, licensed, independently maintained, and the fix can be verified. - No action needed: intentionally pinned, already migrated, migration underway, documentation-only match, vendored or generated copy, existing compatibility path, or dormant. - Requires engineering review: affected, but the fix cannot be verified independently or the evidence cannot be fully resolved. ### What we observed - Inngest TypeScript SDK v3 to v4 census (read-only): 941 raw `new EventSchemas` code-search matches; 596 unique repositories; 545 independent non-fork; 210 active (pushed in the prior 90 days); 111 with the old interface in executable code on the current default branch; 105 intentionally pinned to v3; 4 already migrated; 2 actually affected (one dormant). The important result was not that more migration targets were found; it was that most were eliminated. - Downstream-impact benchmark (48 Inngest repositories, 30 held out): first frozen held-out run 28 of 30 correct; final 48 of 48 after documented fixes and label corrections. The first frozen result is the stronger generalization measure. No unnecessary remediation was recommended, 2 repositories were escalated to engineering review, and the benchmark contains no clean case where migration was warranted (36 of 48 are intentional v3 pins). - Opt-in major upgrades (bounded samples): firebase-admin 14, bullmq 6 and AI SDK 7 each failed a bar that was set before data collection. Clean cases where migration is warranted were much rarer than expected. - Changes consumers do not explicitly opt into: setuptools 82 (30 repositories inspected, 4 genuinely affected, 1 clear case for a fix), huggingface_hub 2.0, pandas 3.0, the MCP SDK package split, the OpenAI Assistants API sunset and GitHub runner retirements. None met the bar. These produced a higher density of genuine impact than ordinary major-version migrations, but not a large clean remediation population. - Ray: azure-mgmt-resource 25.0.0 moved deployment operations to the separate azure-mgmt-resource-deployments package (DeploymentsMgmtClient); 26.0.0 also removed the top-level ResourceManagementClient export. Pull request https://github.com/ray-project/ray/pull/66714 adds backward-compatible support; 36 tests passed on each of four SDK version combinations; no live Azure deployment and no full Ray CI run locally. Status on 2026-10-08: open, under review, no approving review. A Ray maintainer asked Azure-context contributors to review it. ### What we think this could become (hypotheses, not results) - Software providers could distribute not just documentation about a change, but structured downstream impact and verified remediation: an impact report, migration guidance, a task for a coding agent, a verified patch, a pull request, or an explicit "no action needed". - The recurring primitive is upstream software change, then downstream impact, then action, across SDKs, APIs, cloud services, libraries, models, security policies and dependency graphs. - Packaging the change, downstream impact, compatibility constraints and verification evidence together may make domain-specific review context easier to evaluate. Review time has not been measured. ### What remains unproven Finding every downstream repository is imperfect (GitHub search caps results at 1,000 per query); coverage is event-specific; the rules for when remediation is warranted are partly hand-designed; clean cases where migration is warranted are sparse; provider demand is unvalidated; there is no customer or pilot evidence; it is not shown that Ziek detects breakage before maintainers react. Next question: the lead time between the earliest technically detectable exposure and the first public maintainer reaction. ## Frequently asked questions Q: What is software change propagation? A: The process of determining how an upstream API, SDK, package or dependency change affects downstream codebases, and what action should be taken in each one. Q: How do you detect which repositories are affected by a breaking API change? A: Describe the change precisely, search for the old interface to find candidates, then check each candidate's current default branch: resolve the dependency version, separate executable code from documentation and comments, and check for intentional pins and migrations already underway. Q: Why isn't code search enough? A: It matches text, not executable use, and GitHub caps results at 1,000 per query. In the Inngest experiment 941 matches reduced to 2 affected repositories. Q: When should a migration automatically become a pull request? A: Only when the repository is affected on its current default branch and sending a fix is warranted: active, licensed, independently maintained, not already migrating, not intentionally pinned, and the fix can be verified. Q: How is Ziek different from dependency update tooling? A: Dependency update tools are excellent at managing declared package-version changes. Ziek is exploring a different layer: interpreting what an upstream software change means for each downstream codebase and deciding whether remediation is warranted. Q: What does Ziek do? A: Ziek analyzes how upstream API, SDK and dependency changes affect downstream codebases. It identifies which repositories are genuinely affected, filters cases where no action is needed, and helps produce verified remediation where migration is warranted. Q: Who is Ziek for? A: SDK and API providers, developer platform teams, and engineering organizations that manage large dependency surfaces. It is early; there are no customers or pilots to report. Q: Is Ziek production-ready? A: No. It is being validated through public engineering experiments, benchmarks and upstream contributions. ## Other pages - Homepage: https://ziek.dev/ - Founder: https://ziek.dev/founder - Writing index: https://ziek.dev/blog - RSS: https://ziek.dev/feed.xml