Skip to main content

The bus factor for the AI era. Map team knowledge blindspots before someone leaves.

Project description

blindspot

Engineering resilience for AI-accelerated teams. Detect hidden organizational fragility — concentrated ownership, shallow reviews, knowledge decay, single-engineer dependencies — before they become delivery risks.

pip install blindspot
blindspot scan /path/to/repo

One self-contained HTML report. No server. No signup. No telemetry.

🚧 Pre-alpha. APIs and metrics will change.


What you get

One report, grouped for both audiences.

blindspot scan /repo produces a single HTML file organised under four headers — TL;DR (executive summary, resilience score with A–F grades, top actions, trend), then People & Ownership, Knowledge State, Process Quality for drill-down. A board reads the top; an engineering manager scrolls.

A specific question, answered.

blindspot scan /repo --simulate-departures "alice@x.com,bob@x.com,carol@x.com"

"If these three engineers leave together after a re-org, how many files become orphans, which services take the hit, and what should we do first?"


Why this exists

AI coding tools made engineering teams faster. But faster does not mean understood. Codebases now carry a new kind of risk: services that shipped quickly, owned by one person, reviewed by no one in depth — and that one person can leave tomorrow.

Existing tools measure velocity. blindspot measures resilience.

The product is built around three rules:

  • Service-first, not person-first. Default views show service-level risk; person views require service context.
  • Evidence over inference. Signals come from observable git/PR/filesystem state — not from guessing how someone codes.
  • Reports, not surveillance. blindspot answers "is this service fragile?", not "is this person slacking?".

What it measures

Signal What it tells you
Ownership concentration Who actually understands each part of the codebase, weighted by recency and review depth
Bus factor per service / folder How many people would need to leave before knowledge is critically lost
Departure simulation What happens if a specific person — or a specific group — leaves: orphan files, affected services, coverage loss
Knowledge decay Code volatility and contributor drift, projected 30 / 60 / 90 days forward
Review lineage Where approvals land without substantive comments (rubber-stamp ratio), and where one reviewer carries everything (diversity HHI)
Correction load Share of recent commits to each file that are follow-up fixes or reverts — observable evidence of stability debt, not a verdict on people
AI-native operational context Per-service coverage of agent rules, specs, prompts, architecture decisions and skills. How much organizational memory exists for new humans and AI agents to load. Not an AI-generated-code detector
Engineering Resilience Score Composite 0–100 number + letter grade, with band (Strong / Moderate / Fragile / Critical)

Each signal that's actionable generates a concrete recommendation in the Top actions table, tagged with the relevant fragility pattern (single-owner-concentration, review-without-scrutiny, fragile-velocity).


Quick start

# Install
pip install blindspot

# Full report (grouped: TL;DR + People · Knowledge · Process)
blindspot scan /path/to/repo --output report.html

# Multi-person departure scenario (combined card at the top)
blindspot scan /path/to/repo \
    --simulate-departures "alice@x.com,bob@x.com"

# Single-person deep-dive
blindspot simulate --person alice@example.com /path/to/repo

A rule-based narrator ships in the package — the executive summary is deterministic, in-process, no network, no key required. Configure a cloud LLM key (Anthropic or OpenAI) for richer prose; the report itself shows you how.


Documentation

Full end-to-end documentation lives in docs/ — the algorithms (with formulas and parameters), the architecture, the CLI reference, configuration, and how to read every section of the report.


Roadmap

Phase Surface Status
1 CLI + static HTML report Shipping
1 Multi-person departure scenarios Shipped (0.0.5b)
2 Knowledge graph visualization Planned
2 Hidden silo detection + Change fear index Planned
3 GitHub Action + Checks API output Planned
3 Self-hosted dashboard Planned
3 Slack / Jira / incident integration Planned

License

MIT. See LICENSE.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

blindspot-0.0.6.tar.gz (182.2 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

blindspot-0.0.6-py3-none-any.whl (140.1 kB view details)

Uploaded Python 3

File details

Details for the file blindspot-0.0.6.tar.gz.

File metadata

  • Download URL: blindspot-0.0.6.tar.gz
  • Upload date:
  • Size: 182.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.12.13

File hashes

Hashes for blindspot-0.0.6.tar.gz
Algorithm Hash digest
SHA256 d634f5a05eb105b206ade8fc65c179275d96bd4dbe3e1401d4ffdcf54872e757
MD5 9d911e18399a6882756409b91e4fef40
BLAKE2b-256 bf594f72e0c434cbe04591f678c38280cae760f629d0cd5498222742b4e84725

See more details on using hashes here.

File details

Details for the file blindspot-0.0.6-py3-none-any.whl.

File metadata

  • Download URL: blindspot-0.0.6-py3-none-any.whl
  • Upload date:
  • Size: 140.1 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.12.13

File hashes

Hashes for blindspot-0.0.6-py3-none-any.whl
Algorithm Hash digest
SHA256 b719fe0e753e76f85f83fb09bc3183499461b271f67879ee86b0791b51bc64be
MD5 18b60245ca1f2880e3396d7fd657e2ea
BLAKE2b-256 6875ae867ef450a01dc68a9a166a45d06ac8e24afbe7b396d15deaf9b0b289dd

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page