Notice Watcher

What it does

Small organizations can miss funding because nobody has time to read every new posting. I built a pipeline that reads a month of funding postings from Grants.gov and sorts them for an imaginary community non-profit, recording which rule applied to each posting and why. The postings are real and public, and the organization is invented.

Reading the flow

Each line is one posting from the last 30 days. Every posting is checked against four rules in order: whether it is open to non-profits, whether it is about the topics the organization works on, whether the award is a size the organization can take on, and whether there is enough time to apply. A posting that fails a rule stops at that point and joins the pile underneath, and the postings that pass all four are either flagged or marked for a person to review. Selecting a line shows which rule applied to that posting.

The settings are live, so if you switch a topic off, lower the award limit, or require more days to apply, the postings re-sort. The page runs the same rules file as the pipeline, which means the result shows what the pipeline would have done with those settings, and the same input always produces the same result.

What it found

• Under the sample profile, which covers health, education, housing, and young people, the pipeline read 86 postings, flagged 12, marked 3 for a person, and stopped 71. Of the 71 that stopped, 42 failed the topic rule, 18 failed the size rule, and 11 failed the eligibility rule.
• The 3 postings marked for a person passed the rules but still need someone to read them. Each closes within a few days and lists only "Others" as its eligible applicants, so whether a non-profit can apply has to be checked in the notice itself.
• Several of the flagged postings are research grants that contain a word like "health" and therefore match the topic rule, even though they would not suit a community organization. Keyword matching produces this kind of false match, which is why flagged postings go to a person for review and why the rules are kept in one short file where they can be tightened.

How it works

A Node.js script calls the Grants.gov public API, which requires no key, lists the newest postings, and then reads each one in full to get its applicant types, closing date, award ceiling, and description. The script writes every posting and every decision to a log, and this page loads that log.

The decisions come from a short file of written rules that the pipeline and the page both read. A local language model, ministral-3 running through Ollama on my laptop, writes only the one-sentence summary shown beside each flagged posting and is not used to decide which postings are flagged. I would run the same setup over tenders, regulations, or an inbox of requests.

What to keep in mind

• The topic rule uses keyword matching, so it misses relevant postings that use different words and flags irrelevant postings that use these words.
• The pipeline reads only postings listed as open ("posted") in the last 30 days, so forecasted opportunities are not included.
• Applicant types come from fields in the posting itself, and when those fields say "Others" only a person can determine whether the organization is eligible.
• The summaries come from a small local model and can be wrong, so each one should be checked against the posting.
• The limits in the sample profile, 14 days and $1 million, are placeholders I chose, and the settings above let you change them.