CHAIN

Change Happened. Anyone Informed? Nope. Trace breaking APIs across repos before production finds out.

Comment

CHAIN — Change Happened. Anyone Informed? Nope.

An API changed. Nobody told the downstream team.

Try the live interactive demo · View the source code

Inspiration

A backend team can make a locally reasonable API change that silently breaks a product owned by another team two repositories away.

In the scenario behind CHAIN, an HR backend changes one endpoint from session authentication to Bearer tokens. The employee app never calls that backend directly—it calls a BFF—so neither team can easily see the full blast radius until the “My HR Info” screen fails in production.

That led to one question:

What if developers could see the blast radius before users do?

What it does

CHAIN — Change Happened. Anyone Informed? Nope. maintains a live REST dependency graph across repositories and catches breaking contract changes before they ghost downstream developers.

When GitHub sends a push webhook, CHAIN:

  1. Verifies the webhook signature and retrieves the commit diff.
  2. Re-analyzes only the repository that changed.
  3. Uses GPT-5.6 to determine whether the diff breaks an external API contract.
  4. Walks the dependency graph backward through any number of proxy or BFF hops.
  5. Resolves the affected repository owner and product feature.
  6. Sends a targeted Slack alert with the endpoint, change, dependency path, hop distance, owner, and feature at risk.

The interactive demo discovers this relationship directly from code:

employee-app → employee-app-server:GET /api/hr-info → hrm-server:GET /api/employee/profile

When hrm-server changes GET /api/employee/profile from a session-token header to Bearer authentication, CHAIN finds:

  • employee-app-server — one hop away
  • employee-app — two hops away
  • Affected feature: “My HR Info”
  • Target owner: the developer responsible for that feature

A comment-only push is classified as safe and generates zero notifications, avoiding alert fatigue.

Try the interactive demo

Judges can test the complete experience without installing or rebuilding anything:

Open the hosted CHAIN demo

The private judge instructions include the access code. Judges may optionally provide their own Slack Incoming Webhook URL or use the preconfigured demo channel.

The visual demo shows:

  • GPT-5.6’s breaking-change classification and rationale
  • The changed upstream endpoint
  • One-hop and two-hop downstream impact
  • The feature and owners at risk
  • Slack delivery status and alert previews
  • A safe-change scenario that produces no notification

How we built it

CHAIN is a Python/FastAPI application backed by an atomic JSON graph store.

Static repository analysis

The analyzer scans JavaScript and TypeScript for:

  • Express route definitions
  • Outbound fetch and axios calls
  • Constants and environment-backed base URLs
  • Calls made from inside route handlers

Associating outbound calls with their containing server route lets a BFF appear as both an API provider and an API caller—the bridge required for true multi-hop analysis.

GPT-5.6 semantic reasoning

The diff classifier uses the OpenAI Responses API with strict structured output to return:

  • Whether the change is breaking
  • Affected HTTP methods and paths
  • Change types
  • Human-readable explanations

GPT-5.6 can also resolve ambiguous, environment-driven HTTP calls against the known endpoint catalog with an explicit confidence score.

Incremental dependency graph

The graph store replaces only the nodes and edges produced by the pushed repository. Incoming evidence discovered in other repositories is preserved, so a later scan of an upstream service cannot erase its downstream callers.

Impact analysis then follows incoming edges to arbitrary depth and deduplicates affected repositories by their shortest hop distance.

Integrations and testing

The project includes:

  • GitHub HMAC SHA-256 webhook verification
  • GitHub Compare API diff retrieval
  • Slack Incoming Webhook delivery
  • Three runnable Node.js sample services
  • A deterministic offline demo fallback
  • A deployed interactive graph visualization
  • 23 automated tests

How Codex and GPT-5.6 helped

Codex accelerated the build process

Codex was the development partner from the initial PRD to the deployed judge experience. In one continuous workflow, it helped:

  • Turn the product idea into graph semantics and an implementable architecture
  • Build the JS/TS static analyzer and incremental graph store
  • Implement the GitHub webhook and Slack notification pipeline
  • Create the three-repository fixture and executable demo scenarios
  • Diagnose cross-repository evidence loss during incremental scans
  • Correctly model the BFF as both provider and caller
  • Build the visual judge experience and prepare Vercel deployment
  • Design and run the 23-test suite
  • Validate the hosted demo and real Slack delivery end to end

Key decisions remained explicit human choices

The most important product and architecture decisions were:

  • Model dependencies as a directed graph and traverse it in reverse.
  • Preserve caller-owned edges during incremental provider scans.
  • Keep deterministic static analysis on the common path.
  • Use GPT-5.6 only where semantic judgment improves reliability.
  • Alert only affected owners instead of broadcasting generic repository changes.
  • Provide a guarded browser demo that proves both positive and negative notification paths.

GPT-5.6 powers the running product

GPT-5.6 is used at two narrow semantic boundaries:

  • Breaking-change judgment: distinguish external contract breaks from harmless refactors and return typed endpoint details.
  • Fuzzy edge inference: match ambiguous HTTP calls to registered endpoints with explicit confidence.

The result is a hybrid system: static analysis provides speed and auditability, while GPT-5.6 supplies semantic reasoning at uncertain boundaries.

Challenges

The hardest modeling problem was preserving transitive evidence during incremental updates. Re-analyzing an upstream repository must not erase incoming edges discovered in downstream repositories.

A second challenge was associating outbound calls with their containing server route. Without that relationship, the BFF becomes two disconnected facts instead of the bridge that makes multi-hop impact analysis possible.

For demo resilience, CHAIN supports GPT-5.6 in production and a deterministic fallback when external credentials or connectivity are unavailable. Slack dry runs are explicitly labeled and never reported as delivered messages.

Accomplishments

  • ✅ The analyzer discovers the exact two-edge, three-repository chain.
  • ✅ A breaking authentication diff identifies both one-hop and two-hop dependents.
  • ✅ The transitive alert names the owner and the “My HR Info” feature.
  • ✅ A comment-only change generates zero notifications.
  • ✅ A subsequent push scans only hrm-server.
  • ✅ All 23 automated tests pass.
  • ✅ The three sample services complete a real app → BFF → HR request.
  • ✅ The hosted demo delivers real targeted Slack alerts.

Potential impact

API contracts matter, but ownership is fragmented across codebases and teams. CHAIN turns the code organizations already have into a living dependency map, then routes breaking-change context to the few people who actually need it.

This can replace production incidents and Slack archaeology with an actionable warning at push time.

See the blast radius before users do.

What’s next

Next steps include:

  • TypeScript AST adapters
  • OpenAPI-aware schema comparison
  • CODEOWNERS integration
  • GitHub App installation
  • Queued webhook processing
  • Historical graph visualization

The MVP intentionally stays focused on the core developer-tool experience: detect one real breaking change, trace it through a real multi-hop chain, and notify the right developer before users notice.

Built With

Share this project:

Updates