Skip to content
PR
← All work
02Pre-alpha prototype

PARTHA

Repository intelligence that turns fragmented codebase knowledge into structured evidence.

What it solves
Gives engineers and AI tools one reusable source of truth for a codebase, so architecture, dependencies and technical context do not have to be re-derived for every task.
Engineering decision
Builds React, TypeScript, FastAPI and PostgreSQL services around one shared repository intelligence model.
Proof
Each supported fact keeps its repository revision, file path and line source, so reports and AI features can be checked against the code that produced it. A golden benchmark with adversarial fixtures checks extraction determinism, alongside CI and CodeQL.

React · TypeScript · FastAPI · Python · PostgreSQL · Redis · Docker

Scope note: PARTHA is an active pre-alpha prototype for self-hosted, trusted environments, not a hosted production service. Claims about production hardening, contributor counts or production usage are deliberately not made here.

RepositoryWebsite
Animated diagram: scattered repository files resolve into a layered architecture map, with a provenance path traced back to source.

Scattered repository files resolve into a layered architecture map, then one provenance path is traced from a source back to the root.

(Case study)

How PARTHA is built

Constraints, decisions and limits, in the order they shaped the system.

Use case

  • Repository understanding, review, architecture exploration, and documentation workflows that need structured facts rather than raw file dumps.

What I built

  • Builds a reusable repository intelligence model.
  • Produces structured analysis snapshots rather than passing unstructured source files directly to downstream AI providers.
  • Preserves source provenance so stored facts remain inspectable.
  • Supports repository understanding, review, architecture exploration, and documentation workflows.
  • Uses a full-stack architecture with clear frontend/backend responsibilities.
  • Serves architecture, dependency graph, engineering review, insights and documentation from one sealed, revision-bound snapshot.

Constraints

  • Repository knowledge is spread across code, configuration and convention.
  • Downstream AI consumers degrade when handed unstructured file contents.
  • Any derived fact is useless if it cannot be traced back to a source.

Approach

  • Model the repository as structured, reusable intelligence rather than a prompt payload.
  • Emit analysis snapshots that can be stored, compared and inspected.
  • Keep provenance attached to every extracted fact.

Architecture

  • FastAPI + Python analysis backend, PostgreSQL for snapshots, Redis for queued/cached work.
  • React + TypeScript frontend with clear separation from backend responsibilities.
  • Docker for reproducible local and CI environments.

Key decisions

  • Structured snapshots over raw source hand-off, for stability and inspectability.
  • Provenance as a first-class field, not a debugging afterthought.

Limitations

  • No claims are made about production usage, adoption, or security hardening.

What I learned

  • Giving a model better-shaped evidence beats giving it more text.