I released an early open-source Rust project called service-impact.
Repo:
The goal is fairly narrow:
given a service manifest and a set of changed paths, compute:
impacted services
verification hooks to run
a smaller verification plan
I built it for the common situation where multi-service repos end up rerunning a wide default CI scope because the actual impact boundary is unclear.
What it does today:
validates a service registry / manifest
computes impact in strict and conservative modes
provides human-readable CLI output by default
supports --format json for automation
includes starter examples and a GitHub Actions example
ships prebuilt binaries via GitHub Releases
What it does not try to do:
it is not a CI orchestrator
it is not a build system
it is not runtime dependency discovery
it is not trying to infer hidden coupling automatically
It is still an early, rules-based tool, and the current matching is intentionally simple:
path-prefix matching plus explicit capability/dependency rules.
If you work on platform tooling, monorepos, or CI scope reduction, I would be glad to hear whether this direction seems useful.
