Risk register
Known risks in marketscout, what is already in place, and what is still open. Likelihood (L) and impact (I) are the developer's own assessment on a three-point scale (low, medium, high) and are meant to be challenged. Reviewed 26 October 2026.
| ID | Risk | L | I | Controls in place | Status and next action |
|---|---|---|---|---|---|
| R1 | A published claim is not supported by its sources | M | H | Citation rules; second-pass verification against cited evidence only; summary written from surviving claims; claim trail; evaluation set | Partly mitigated. Verifier and drafter usually share a model. Next: use a different model to verify; add a review queue for flagged claims |
| R2 | A wrong number is published | M | H | Prices and changes computed in code from feeds; rule-based number check on every claim, recorded in the trail and in evaluation | Partly mitigated. The number check does not block publication. Next: decide whether a failed number check should remove the claim |
| R3 | Stale or incorrect source data | M | M | Retrieval time recorded on every item; required sources must answer or no brief is published | Open. Next: show source age and outlet count per claim |
| R4 | Data source terms or licences are breached | M | H | Sources named on every brief; SEC contact header set; public pages labelled as research | Open. Terms of the news feeds, the Yahoo chart endpoint, CoinGecko and the other sources have not yet been formally reviewed. Next: review each and record the outcome here before wider promotion |
| R5 | Model provider outage or rate limits | H | L | Ordered fallback across providers; waits and retries; ledger flags fallback and waiting; failed subjects do not stop the digest | Mitigated for the free tier. A paid tier would remove most waits |
| R6 | A provider changes or retires a model, and quality drifts | M | M | Model names set in configuration; every run records the model used; evaluation re-runnable | Open. Next: run the evaluation on a schedule and alert on a drop |
| R7 | Prompt injection through news headlines | L | M | The pipeline has no tools and takes no actions, so injected text can at worst distort a brief; the verifier checks claims against the same headlines; drafting rules limit claims to what the headline states | Accepted for now. Next: add injection cases to the evaluation set |
| R8 | A key or token is leaked | L | H | Keys in an ignored local file and in GitHub secrets only; the Telegram token is removed from error text; keys never printed | Mitigated. Next: enable secret scanning on the repository |
| R9 | A brief is read as investment advice | M | M | Every page and message states it is not advice; claims are attributed; no recommendations are produced | Mitigated. Wording is reviewed with any change to the pages |
| R10 | Cost or quota overrun | L | L | Free tiers during development; token budget per brief and a ledger flag when exceeded | Open. The budget warns but does not stop a run |
| R11 | Personal data is collected | L | M | The pipeline and the static site collect no reader data of their own; the web host's standard request logs are outside the project's control | Accepted. Any feedback form or analytics added later needs a privacy notice first |
| R12 | The record of what was done can be altered | L | M | Ledgers, trails and briefs are committed to git, so history shows any change | Accepted. Records are not signed |
| R13 | The scheduled run fails without anyone noticing | M | M | The run is visible in GitHub Actions; a successful run sends a Telegram digest | Open. Next: send an alert when a run fails |
| R14 | The verifier over-trims and loses attribution | M | L | Trimmed claims are labelled in the trail with the original text | Monitoring. Seen in evaluation (one case in 22); tracked in each run |
| R15 | Narrow coverage misleads about the market | M | L | The scope is stated on the site and the method page | Accepted while the watchlist is small |
How this register is used
Each open item has a next action. Items move to mitigated when the control exists and a test or evaluation case demonstrates it. The register is reviewed whenever a feature that changes risk is added.