This is a submission for the Hacktoberfest 2026 Open-Source AI Challenge, Week 3: Slow and Steady.
Live Demo | GitHub Repository | Recorded Demo
What I Built
Consider a Helm upgrade from Kong chart 2.25.0 to 2.26.0.
In the packaged example, the rendered Deployment changes its readiness probe:
- path: /status
+ path: /status/ready
The change is easy to spot. Reviewing its implications takes more work.
An engineer still needs to establish what changed, locate the relevant migration documentation, identify prerequisites and understand which questions cannot be answered from the manifests alone.
I built Chart Ledger to bring that preparation into one report.
It takes before-and-after rendered Kubernetes manifests and a migration guide, compares selected Deployment settings, ranks relevant documentation passages and produces a source-linked review.
The report contains:
- Changes to supported Deployment fields.
- An inventory of other changed resources.
- Relevant migration-guide passages and source locations.
- Input hashes and documentation coverage information.
- Unresolved questions requiring human review.
- JSON and Markdown exports.
The tool does not execute upgrades or declare deployments safe.
Every report remains REVIEW REQUIRED.
Demo
The hosted application includes two packaged workflows.
Run the model review examines the Kong readiness-probe change.
Review the version range examines a broader Kong example, retaining 16 documentation passages and evaluating 32 text windows with the model.
Both execute actual open-weight model inference and provide exportable results.
Watch the recorded browser demonstration.
The recording shows an earlier single-section workflow. The hosted application includes later improvements.
The public service allows one inference at a time. If another review is running, it returns HTTP 429 with a retry message. Try again after the active review finishes.
Use sanitised inputs because uploads are processed on the hosted server.
Code
Source code, tests and verification evidence
The repository contains the Python application, command-line workflow, example inputs, model integration, tests and verification records.
The application code uses the Apache-2.0 license. Upstream components retain their own licenses.
AI-assisted development tools were used during implementation.
How I Built It
1. Separate manifest comparison from model ranking
The comparison logic does not depend on the model.
It examines one selected Deployment, focusing on container images, HTTP probe paths and ports, and readOnlyRootFilesystem.
Other changes are inventoried without pretending that the tool understands every Kubernetes resource or Helm configuration.
For the broader Kong example, the inventory exposes edits involving the Deployment, Service and ServiceAccount.
That distinction prevents unsupported changes from silently disappearing from the review.
2. Rank documentation with an open-weight model
Chart Ledger uses BAAI/bge-reranker-base on CPU.
The model ranks migration-guide passages against questions derived from the supported manifest changes.
Its pinned revision is:
2cfc18c9415c912f9d8155881c133215df768a70
The application verifies recorded model-file identities and loads local files with remote model code disabled.
The model helps answer one question:
Which documentation should the engineer read first?
It does not generate migration commands, validate a live cluster or approve an upgrade.
3. Make the report traceable
The processing flow is:
Before/after manifests + migration guide
|
v
Validate inputs
|
v
Compare Deployment
|
v
Inventory other changes
|
v
Construct reading questions
|
v
BGE reranking
|
v
Source-linked report
|
JSON / Markdown
The report records input hashes, relevant source locations and remaining review questions.
The packaged Kong migration guidance refers to a specific upstream commit instead of a moving branch.
Uploaded documents are not independently authenticated against their supplied URLs. A recorded hash identifies the supplied bytes, not their publisher.
4. Run the model on Render
Render hosts the Python application and executes BGE inference on CPU.
The deployed configuration uses one worker, two threads and one active inference slot.
The /healthz endpoint reports readiness and deployment revision.
The application uses Render's native Python deployment process rather than a verified Docker image build.
Concurrency is deliberately bounded. Overlapping reviews can receive HTTP 429 instead of being accepted into an unbounded queue.
5. Verify the implementation
At recorded application revision 3cc347f, the local suite and clean-clone suite each passed 103 tests.
Separate hosted functional checks exercised the original example, version-range review and a sanitised upload with actual model inference.
The recorded end-to-end HTTP measurements were:
| Workflow | Successful | p50 | p95 |
|---|---|---|---|
| Readiness example | 20/20 | 10.300 s | 11.856 s |
| Version-range review | 10/10 | 19.403 s | 21.538 s |
These figures include client, network and application overhead. They are not model-only inference timings.
Concurrent requests produced HTTP 429 responses:
- Two-request burst: one HTTP 200, one HTTP 429.
- Five-request burst: one HTTP 200, four HTTP 429.
Read the measured results and source evidence.
What did the open model improve?
An earlier frozen, author-labeled Kong comparison placed both selected prerequisite passages within BGE's top two readings per change. The keyword baseline found one of the two.
That is a controlled example, not evidence of general superiority.
A pre-registered multi-chart comparison against BM25 and token-overlap ranking remains unfinished.
I cannot yet claim that neural ranking consistently performs better than simpler retrieval methods.
A reproducibility test failed: I kept the result
Ten runs on the same machine produced matching normalized report hashes.
A GitHub runner comparison failed because floating-point relevance scores differed, although passage order matched in that comparison.
The repository retains the failure and its supporting evidence.
Pinned models and inputs improve traceability. They do not guarantee byte-identical floating-point outputs across environments.
The Lazy Payoff
The repetitive part of a Helm upgrade review is gathering the material needed to make a decision.
That includes comparing rendered manifests, finding relevant migration passages, recording source references and tracking unanswered questions.
Chart Ledger prepares those materials automatically.
Instead of beginning with a diff and an empty review document, the engineer begins with a source-linked report.
The final deployment decision still belongs to the engineer.
I have not completed a controlled study measuring human time saved. The recorded application response times are not equivalent to end-to-end reviewer productivity.
Why Does Open Innovation Matter?
An open-weight model makes it possible to inspect the ranking implementation, run inference locally and compare it against simpler approaches without requiring a hosted inference API.
The source code, tests and evaluation records are public.
If a simpler retrieval method performs comparably in independent testing, the model should have to justify its additional runtime cost.
That is an advantage of an inspectable implementation: its technical decisions can be challenged with evidence.
This project builds on existing open-source work.
Chart Ledger's contribution is the workflow connecting selected manifest changes, ranked migration documentation and a traceable review artifact.
What Comes Next
The next engineering task is a multi-chart ranking benchmark with independent labels and comparable retrieval baselines.
After that, the workflow needs evaluation with engineers reviewing upgrades they actually maintain.
The questions are whether it surfaces relevant prerequisites, whether it misses important context and whether it reduces preparation effort without creating false confidence.
Until those tests are complete, Chart Ledger remains a working, bounded review-preparation tool.
Prize Categories
Best Use of Render
Render is the application's AI runtime. It hosts the Python service, runs the open-weight BGE model on CPU, accepts review requests and serves the resulting reports.
If you maintain Kubernetes applications through Helm upgrades, which part of preparing a release review requires the most manual investigation?
Top comments (0)