This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
A copywriting brief includes three welcome emails. The next request asks for five onboarding emails. The wording has changed, and so has the amount of work.
I built Brief Ledger to make that comparison easier. It runs locally and puts a new request beside the nearest agreed deliverable, with the original wording still visible. In this example, it matches the onboarding request to the welcome sequence and shows that the requested total is two emails above the agreed total. The writer then chooses a decision and adds a review note.
The intended customer is an independent English-language copywriter handling fixed briefs and repeated revision requests. I would test a one-time local installation and workflow setup service around the tool. That is my business hypothesis. I have no paying customer, no measured time saving and no external user test yet. The current app is free and has no payment flow.
I started this new project and repository on October 13, inside the second week's entry period. I reused an installed Python environment and cached model weights. The application, fictional brief and diagnostic cases are new for this week.
Demo
Watch the 35-second walkthrough using GitHub's Download raw file button. It shows real captured browser states, assembled into a video rather than a continuous recording.
The flow is deliberately small: enter agreed deliverables, enter new requests, compare, then review the evidence. Quantities are separate manual fields. A requested total of five against three agreed means two more. The tool does not read numbers out of prose or add separate requests together.
The example also asks for a warmer landing page and a video edit. The landing-page request finds related source text but still needs a person to check revision conditions. The video request has no clear match. Neither result approves work automatically.
I can leave a row unresolved, ask for clarification, keep it in the agreed scope or quote it separately. Prepare review notes produces a complete copyable text with those decisions and the original evidence. The actual example output includes unresolved rows. An optional Markdown download is present; download completion was not verified in my development browser, so I tested and retained the visible copyable output.
The README explains local installation. There is no hosted inference service. I checked the interface at a 375px viewport, with no horizontal overflow.
Code
MIT-licensed source, tests and results
The examples are fictional original material. The repository contains no client files, model weights, credentials or input history.
How I Built It
I used all-MiniLM-L6-v2, an Apache-2.0 open-weight embedding model, through Sentence Transformers on CPU. Its revision is pinned. Normalized 384-dimensional vectors rank each request against the agreed descriptions.
A score below 0.40 produces “No clear match.” A top-two gap below 0.08 produces “Ambiguous match.” These are heuristics, not probabilities. Quantity differences appear only when the match is clear and the units agree. A human still checks the original wording and any exclusions.
Seven tests passed, covering quantity changes, different units, ambiguous duplicates, unrelated requests, evidence preservation, invalid input and local HTTP guards. I ran inference from the model cache with offline flags enabled.
My 12 author-written diagnostic cases produced ten intended outcomes, including the two unrelated requests. Among ten related requests, eight received the intended match after the threshold. A simple token Jaccard baseline also ranked eight of ten first. This small set does not establish that the model is generally better than keywords.
The two failures matter. One request for a web page ranked email copy first, but the small score gap marked it ambiguous. Another intended landing-page request fell below the threshold. I left both in the report. Warm local analysis had a median of 6.83 ms, excluding model loading; this is a developer diagnostic, not an independent benchmark.
The Python server binds to loopback and does not log request bodies. The page uses local assets and no browser storage. Refreshing loses the workspace; copied or downloaded notes remain wherever the user keeps them. The model supports English descriptions here, and nearest-row matching cannot resolve a request that spans several deliverables. Brief Ledger is a review worksheet, not contract interpretation.
Why Does Open Innovation Matter?
A freelancer can cache the weights, disconnect and still compare a brief. Client text does not need to go to an inference provider, and each comparison has no API charge. Those properties fit a small installation-and-support service with predictable running costs. A laptop, setup time and the initial model download are still required.
The open code also exposes a decision that is easy to hide: when should a weak match stop being a suggestion? I can inspect the threshold, replace the model and rerun the same cases. The original brief and failed cases remain available while I make that choice.
My next validation would be watching a consenting copywriter use the tool on a brief they choose, then asking whether this comparison saves enough effort to pay for local setup. I have not done that test yet.
Top comments (0)