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.1.0.tar.gz (201.0 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.1.0-py3-none-any.whl (154.9 kB view details)

Uploaded Python 3

File details

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

File metadata

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

File hashes

Hashes for blindspot-0.1.0.tar.gz
Algorithm Hash digest
SHA256 1fe9da8ce848d1f46e6609a74263acea9e60dc754bb13e16b48b6ad34856c4d3
MD5 80882dff9461d7a703591d160146a822
BLAKE2b-256 8c8880800c1f1f98f6cea76291fc64598082098eafe254ef556ac10b5e7296d0

See more details on using hashes here.

File details

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

File metadata

  • Download URL: blindspot-0.1.0-py3-none-any.whl
  • Upload date:
  • Size: 154.9 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.1.0-py3-none-any.whl
Algorithm Hash digest
SHA256 6204913ab30ccfa7ddbe8faa3e0a4d4eec2436225e7dad6d6938e4c6062afaf1
MD5 b60ddc1ff924f401bbd9b1e71d9e9680
BLAKE2b-256 f714f7df5011031b62f69047ba1903f7f7bb8f08e1c330e3574e26c9dfca1cb5

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