I don’t want AI to pick stocks. I want it to tell me what changed.

The idea started in a slightly ridiculous place: Transcendence.

Not because I expect an all-knowing machine to take over the market. The film simply pushed me back toward an old question: if software could watch more information than I can, what should I actually ask it to watch?

Years ago, when I traded more actively, I learned a simple lesson: by the time something becomes a news story, it is usually no longer a signal. It has already been selected, interpreted, rewritten, published, shared and, in many cases, priced in.

The more useful place to look is the primary source.

For US public companies, one of those sources is EDGAR: the SEC’s database of company filings. Annual reports, quarterly reports, material events and insider transactions arrive there before they are reduced to headlines such as “Company beats expectations” or “Investors react to weak guidance.”

That led me to build SEC Watcher, a small personal research tool.

It is not a Bloomberg terminal for people who do not want to pay for Bloomberg. It does not predict prices, recommend trades or generate a magic number called “AI confidence.” Its job is narrower:

new filing
→ extract useful facts
→ compare them with earlier facts
→ apply personal rules
→ flag anomalies
→ summarize what deserves manual review

That is enough.

Why I care more about changes than numbers

A financial number without context is often close to useless.

Revenue of $500 million may be excellent or terrible. Debt of $200 million may be harmless or existential. Inventory growth can mean preparation for demand, or products that are no longer selling.

The interesting part is movement:

• revenue is still growing, but the rate has slowed for three quarters;
• gross margin deteriorated while management kept emphasizing “strong demand”;
• inventory grew much faster than sales;
• receivables increased while reported revenue looked healthy;
• free cash flow turned positive, but only because payables jumped;
• the share count quietly expanded;
• debt moved from optional financing to a refinancing risk;
• guidance language changed from “expect” to “aim”;
• a risk factor that had been boilerplate suddenly became specific;
• an insider transaction was a routine tax sale—or an unusual discretionary sale.

None of these facts automatically means buy or sell. They mean: look here.

This distinction matters because a language model is very good at producing a fluent explanation of a filing. Fluency is not the same as analysis. A generic summary may save reading time, but a change detector can redirect attention.

What SEC Watcher does today

The current version is a FastAPI application with a PostgreSQL database, a background worker and a simple dashboard.

I add a ticker to the watchlist. The worker polls SEC submissions for active companies, downloads new filings and stores the original text. The filing then goes through a form-specific analysis path.

• Form 4 filings receive deterministic insider-transaction analysis.
• 8-K filings receive deterministic classification for material corporate events.
• 10-Q and 10-K filings receive XBRL metric extraction and investment-rule checks.
• Other supported filings can receive a cautious LLM-generated summary.
• Results appear in the dashboard.
• Telegram alerts are sent only when the analysis contains a positive or negative signal.

The SEC provides JSON APIs for company submission histories and extracted XBRL facts. They require no API key, are updated throughout the day and cover data from forms including 10-Q, 10-K, 8-K, 20-F, 40-F and 6-K. The only important operational constraint is to behave like a reasonable client: identify the application, cache responses and stay within the SEC’s fair-access guidance of no more than ten requests per second.

For a personal watchlist, that is not a difficult limitation. There is no reason to hammer the source.

Why I do not send every filing to an LLM

The easiest prototype would be:

download filing → send entire document to AI → ask for summary

It would also be the wrong architecture.

First, filings are long. Paying to process the same boilerplate every quarter is wasteful. Second, language models can confuse periods, units and similarly named metrics. Third, many useful checks do not require AI at all.

Code should handle what code handles well:

• accession numbers and duplicate detection;
• form types and filing dates;
• numeric comparisons;
• XBRL units and reporting periods;
• personal thresholds;
• known Form 4 transaction codes;
• known 8-K item categories;
• history and auditability.

An LLM should handle the smaller fuzzy layer:

• explain why a detected change may matter;
• summarize a new disclosure;
• compare management wording;
• identify language that became more cautious or more specific;
• turn structured findings into a compact alert.

This is also why I do not want the project tied to an expensive hosted AI model. I do not want every polling cycle or reprocessing job to burn paid tokens. I plan to keep experimenting with Ollama and local models, especially for summaries and textual comparisons where a small model may be good enough.

The system should still work when the AI layer is unavailable. A filing monitor with reliable rules is useful. A filing monitor that becomes blind when an API balance reaches zero is not.

The rules are personal, not universal

I am not trying to invent one financial score that works for every company.

A young SaaS company, a bank and an industrial manufacturer should not be evaluated with the same thresholds. Even two software companies may have completely different reasons for being on my watchlist.

For a growth company, I might care about:

revenue growth
free cash flow and FCF margin
GAAP profitability trend
gross margin
stock-based compensation as a percentage of revenue
share-count growth
cash and net debt
material weaknesses

For a manufacturer, inventory, receivables, order backlog and capital expenditure may matter more. For a lender, funding costs, delinquencies and credit losses are central.

The important question is not “Is this company good?” It is:

Is the reason I started following this company becoming stronger or weaker?

Eventually, I want each ticker to have a small investment-thesis file with its own rules. The watcher can then report a thesis change instead of producing another generic company score.

Telegram is the real interface

The project has a dashboard, but I do not want another dashboard that I must remember to open.

Useful monitoring tools should enter an existing reaction loop. In my case, alerts go to my Telegram bot for fast reactions. The dashboard is for adding companies, reviewing history and inspecting the evidence. Telegram is where the system earns its place.

A useful alert should be short enough to scan and specific enough to verify:

NEW 10-Q — Example Corp

Revenue growth: 24% → 19%
Gross margin: 76.2% → 74.8%
Share count: +4.1% YoY
Receivables grew faster than revenue.

Language change:
Management removed “accelerating enterprise demand”
and now expects “measured customer expansion.”

Review reason: growth is slowing while dilution increased.
Source: filing and extracted facts attached.

The wording should remain cautious. “Review reason” is honest. “Sell signal” would be theatre.

The hardest part is not the AI

The code for calling a language model is trivial. The difficult parts are much less glamorous.

XBRL data is structured, but not perfectly uniform

Companies can use different tags for economically similar facts. Periods can be quarterly, year-to-date or annual. Units can differ. Restatements and amended filings complicate comparisons. A number that looks comparable may refer to a different duration or context.

The extraction layer therefore needs validation before scoring. The AI should never be allowed to invent or silently “repair” financial values.

Different forms need different logic

An 8-K is a current report for material events, not a miniature quarterly report. A Form 4 is an ownership transaction disclosure, not evidence of insider conviction by itself. A 10-Q is more abbreviated than a 10-K and contains a different disclosure rhythm.

Treating every document as unstructured text loses information that the form already provides.

Summaries need provenance

Every claim in an alert should be traceable to a filing, a metric and a comparison period. If I cannot quickly verify why the system raised a flag, the alert becomes noise.

Historical records need migration

I recently made English the primary language throughout the application: dashboard labels, dates, accessibility text, generated summaries, rule results and Telegram headings. New filings now follow that format, but older database records remain unchanged until they are reprocessed.

That sounds like a minor interface task. It is actually a reminder that even a personal data product accumulates state. Changing a prompt does not change history. Backfills, rechecks and versioned logic are part of the product.

What is still missing

The current version handles monitoring, storage, form-specific analysis, XBRL checks and alerts. It is useful, but it is not yet the full radar I originally imagined.

The next valuable layer is not a prettier dashboard. It is better comparison.

I want to add:

1. Reliable filing-to-filing metric deltas. Compare equivalent periods, not merely the latest two values returned by an API.
2. Management-language diffs. Focus on MD&A, guidance, liquidity and risk-factor changes rather than comparing entire documents.
3. Company-specific thesis rules. Let each ticker have different assumptions and failure conditions.
4. Evidence-first summaries. Attach the exact source section or fact behind every important statement.
5. Outcome tracking. Record what happened to the company and its price after each flag—without pretending correlation proves predictability.
6. Alert quality metrics. Track which alerts caused a useful manual review and which were false positives.

The fifth point is the experiment behind the experiment. I want to know whether systematic conclusions from filings can improve my decisions or returns. I do not assume they can. The only honest way to find out is to record alerts before knowing the outcome and evaluate them later.

Otherwise, it is easy to look backward and discover that every warning was “obvious.”

What I deliberately would not build

Scope is the main defense against turning a useful personal tool into an unfinished platform.

I would not start with:

• coverage of every listed company;
• real-time price prediction;
• automatic trading;
• social sentiment;
• portfolio allocation;
• a universal AI investment score;
• a chat interface over thousands of filings;
• subscriptions and billing before I know whether I use the tool myself.

There are already large products for financial search, terminals, alternative data and automated research. Competing with their breadth would remove the exact advantage of this project: I can make it opinionated around my own watchlist and decision process.

A small data product with real utility

SEC Watcher fits the kind of software I increasingly find interesting: small tools built around a specific information bottleneck.

The raw data is public. The individual components are not especially exotic. FastAPI, PostgreSQL, a worker, XBRL parsing, a few deterministic rules, a local model and Telegram are enough to build the first version.

The value is in the pipeline and the discipline:

primary source
→ structured extraction
→ explicit comparison
→ personal rules
→ cautious explanation
→ manual decision

AI sits inside that pipeline. It does not sit above it pretending to be an investor.

Maybe the tool will eventually reveal patterns that improve my results. Maybe it will only save time and make me read filings more consistently. The second outcome is already useful.

I do not need AI to tell me which stock will go up.

I need it to notice that something changed before I forget why I was watching the company in the first place.

---

SEC Watcher is a personal research experiment, not investment advice. EDGAR filings and extracted XBRL facts are available through the SEC’s public APIs. Developers should also follow the SEC’s fair-access guidance.