Understand a project’s direction from the work behind it
PRA reads a project’s public GitHub history for a calendar month
and writes a readable engineering review: what changed, what those
changes mean for the project and its users, and what remains unfinished or
unverified. Every finding carries the pull requests it rests on.
Written for anyone who needs to know what an engineering team actually
shipped: investors and operators following a company, or the team itself.
PRA currently focuses on open-source projects. In the case of a private
repository, the scope of access, confidentiality, and data processing
procedures are agreed upon with each company before any materials from that
repository are read. Each report adds context between founder updates
without asking anyone to prepare another document, and is reviewed by a
person before being sent by email.
scope: one repo, one monthsource: public GitHubreview: humandelivery: email
[ 01 / what PRA does ]
pra.readmeproject-level context
Understand the change, not just the activity.
A new capability, a fix to an existing feature and the removal of
unused code tell different stories. PRA connects related changes
and explains what was there before, what is different now, and
which conclusions the evidence supports.
The brief brings the main developments into focus. The companion
technical review documents the implementation, available tests and
coverage, with unfinished work kept separate. You can read for
context or follow an individual finding back to its sources.
How the project started
PRA began as an experiment in reporting on a public open-source project.
The original task was to make a busy stream of engineering work readable.
That led to a broader question: how can the same evidence help people
follow a project's direction over time?
[ 02 / a real report ]
A shortened version of the review for
tracel-ai/burn. Follow a
finding to its PRs, or open the technical review for implementation
details, tests and WIP. September is the primary report; the August
report remains available and is linked wherever earlier work continues.
burn / 2026-09 / brief.mdprimary report
Tracel AI / Burn
Rust machine-learning framework · 1–30 September 2026 (UTC−4)
September continued the directions established in August. Burn moved
some unfinished integrations into main, deepened work on
backends, storage and training, and prepared version 0.22 without
completing the stable release.
01 / Backend selection is now explicit
After August’s move toward Flex and CubeCL, September made backend
configuration explicit. Device::default() now requires an
enabled backend and reports which Cargo feature to add. Builds that only
capture a computation graph can still work without an execution backend.
02 / The PyTorch reader became a separate component
The reader for .pt and .pth files became
independent of both Burn and PyTorch. It can now extract weights from
full-model saves and find tensors in lists and tuples, but it does not
restore the Python class, architecture or forward method.
03 / A failed save preserves the previous checkpoint
Atomic SafeTensors writing was unfinished at the August cutoff and
entered main on 1 September. A new checkpoint is now assembled
in a temporary file and replaces the old one only after completion.
Selected findings from seven September themes.
The technical review accounts for 246 PRs and no direct commits. WIP is
separate. Tests were inspected, not independently run.
Independent analysis of public code, not commissioned by Tracel AI.
[ 03 / how a report takes shape ]
PRA reads a repository the way a reviewer would — the metadata around a
change, the diff underneath it, and the history that shows where it landed.
That gives every report a basis in the work itself, not in the titles
written about it.
PRA generates the report from the collected evidence, connecting related
changes and explaining their context. Each report then goes through a
human quality review for accuracy, coverage and clarity before delivery.
report.pipelinecurrent workflow
Public history
Gather the available GitHub data in depth —
pull requests, commits, diffs and repository history — while keeping
unfinished work separate.
input / GitHub
AI-generated report
PRA’s AI pipeline connects related
changes and writes a clear, readable report with links to sources.
automated / PRA
Human review
Check the generated report
for accuracy, coverage and clarity before delivery.
quality check / human
Email delivery
A concise brief, with a technical review
for the details.
output / report
When a busy history does not fit in one pass, a one-off agent can miss
changes or mix up their context. PRA breaks the period into parts, groups
related work, and checks coverage against the repository history.
Reports stay consistent across projects and periods, traceable to their
sources, and connected to what came before — not just isolated summaries.
[ 04 / where we want to take it ]
The goal is to build a reliable history of how a project evolves. Each
report should show what changed since the previous period, which
developments continued, and whether new evidence supports or overturns
earlier conclusions.
nowin use
Reviewed reports by email
PRA collects and structures public GitHub data, then drafts a report.
Before delivery, a person checks the reporting period, coverage, facts
and wording against the sources. The final brief and its technical
review are sent by email.
When earlier reports exist, PRA uses them as context to show which
developments continued, changed direction or stopped.
nextplanned
A continuous view across projects
Once the method has been validated across projects and reporting
periods, the remaining manual steps can be automated. Reports can then
live in one place, showing how each project changes over time and giving
a comparable view across a portfolio.
[ 05 / scope and limits ]
Evidence, not a company score
Public code shows engineering changes, not revenue, adoption or
private work. PRA complements founder updates. It does not replace
them or rank individual developers.
Clear boundaries around each finding
Reports distinguish between merged, released and unfinished work.
They separate facts visible in the code from results reported by
contributors, including the conditions behind any measurements. Each
report also states its period and coverage.
[ 06 / start with one project ]
Would this help you follow a project?
Send one public repository and a line about what you want to
understand. We agree the month and the scope by email, then send the
brief and its technical review as a sample. If it is useful, the same
report repeats every month.
The first report for a project is free while we are taking on the
first projects. After that, pricing is agreed per project and follows the
size of the month: a repository with a steady trickle of changes costs a
fraction of one that merges hundreds. We quote once we have seen the
history.