SynEvid
Deterministic repository change analysis and policy evidence
A Rust research prototype that parses supported source code into a typed dependency graph, traces bounded change impact, evaluates configured rules, and emits reports for people and automation to inspect.
The repository publishes two different benchmark summaries.
The README describes a 50-task benchmark, while the committed JSON report records 10 tasks for each baseline. The reported metrics also differ: README versus reproduction report gives baseline recall of 68.27% versus 71.67%, and engine precision/F1 of 5.98%/10.80% versus 6.11%/10.87%. Both artifacts show 100% engine recall alongside very low precision; the report also records a failed token-cost gate. These are repository-reported artifacts, not reproduced for this portfolio review.
The README advertises 831 passing tests. No test command or current CI run was executed or independently checked for this write-up.
Make code change consequences inspectable
A repository snapshot and, optionally, a previous snapshot or Git revision.
Static parsing and rule evaluation over supported syntax; there is no LLM in the correctness crates.
Reachable entities, paths, findings, coverage state, and JSON, terminal, or SARIF reports.
This is a code-analysis system rather than a generative model: the inspected Rust core contains parser and graph algorithms, with no LLM inference path or training loop in that core.
A deterministic analysis core with separate adapters and interfaces
CORE ANALYSIS GROUPS
Repository scan and language adapters feed symbol, graph, diff, and contract models. Impact traversal and invariant evaluation consume those models. Temporal history, test selection, telemetry, co-change analysis, and service catalog features live in additional crates.
INTEGRATION BOUNDARY
The MCP server uses stdio and invokes a local autopsy process. The standalone web inspector consumes exported artifacts. GitHub Actions runs the CLI in CI; its presence in the repository is workflow configuration, not evidence of a successful latest run.
Bounded reachability over typed, provenance-aware edges
s is the seed symbol, d the maximum path depth, K the selected edge kinds, and D the requested traversal direction. The code uses breadth-first traversal, caps newly added impact nodes at a configured node budget B, and marks results truncated when depth or budget prevents further traversal. It ranks paths by length, then stable lexical identifiers. This is a static dependency estimate, not proof of runtime execution.
From a baseline to a policy result
Scan and store a repository snapshot.
Compare snapshots into file, symbol, edge, and contract deltas.
Traverse bounded dependencies from changed symbols.
Evaluate configured forbidden-dependency, layer, cycle, or API rules.
Inspect findings, paths, coverage, and report digest.
autopsy baseline --format json
autopsy diff --before <snapshot_id> --format json
autopsy impact -s "src/auth.ts::checkToken" --direction backward --max-depth 5
autopsy verify --strict --invariants-file .autopsy/invariants.yml
autopsy explain <finding_id>Stable output is part of the design
The receipt includes finding and rule identifiers, snapshots, analyzer version, locations, paths, and deltas. This is a content-integrity digest, not a digital signature or proof that the analyzer's conclusion is correct.
The invariant evaluator does not convert unknown or partial coverage into a pass. Test selection widens its plan when changed semantics or suite mappings cannot be resolved. The practical value depends on adapter coverage and the configured policies.
Published evidence, execution evidence, and limitations
Two adapters are present for TypeScript/JavaScript and Python. Dynamic or unresolved constructs can result in partial or unknown coverage.
The README claims 831 passing tests. This audit did not run the suite, and the number is not independently attributed here to a specific CI run.
The repository describes 50 tasks across five TypeScript repositories. Its README and committed reproduction report disagree on baseline recall and engine precision/F1.
The committed reproduction report reports 100% recall but 6.11% precision and 10.87% F1 for SynEvid, with token cost above the baselines. Treat this as provisional until the artifacts are reconciled and rerun.
The source describes read-only analysis and local execution. No independent security audit or production deployment is claimed by this case study.
Cargo workspace metadata declares 0.1.0 and the changelog labels work unreleased. This page uses a source commit rather than claiming a published release.
- Reconcile benchmark README, JSON, and Markdown from one reproducible run with per-task raw outputs.
- Measure precision and review burden alongside recall; define when a broad impact set is useful.
- Publish a commit-pinned CI result and a reproducible install/run path for each integration surface.
- Expand parser coverage only with explicit unsupported-syntax reporting and adapter conformance evidence.
Review the implementation at the audited commit
Audited public source snapshot: 05e11481575f59acda2f107badbad87ecb745dbd. Counts and lifecycle statements on this page describe that checkout; later commits may change them.