How can a monitoring system detect new and quietly edited tender notices?
Reliable notice monitoring follows an authorized source register, scheduled retrieval, normalized snapshots, body and attachment version comparison, and reviewed notification. Each result retains the source URL, source timestamp, retrieval time, and content fingerprint. Detect additions, edits, replaced files, and withdrawals while separating template noise and access failures. Do not rotate IPs or evade CAPTCHA and access restrictions to claim wider coverage.
Watching list titles misses an edit made in place and a replacement attachment with the same filename. Hashing a whole page produces false alerts from traffic counters, recommendations, or footer clocks. Compare business objects instead: title, notice number, issuer, publication and deadline, budget, body paragraphs, attachment names, and file bytes each need a stable representation and version.
| Change | Identification | Common false positive | Alert evidence |
|---|---|---|---|
| New notice | Stable notice ID, canonical URL, or business key first appears | Pagination or pinned-item movement | Title, issuer, time, and original link |
| Body edit | Paragraph diff after normalization | Navigation, counters, and recommendations | Added and removed text with snapshot times |
| Replaced attachment | SHA-256 of downloaded bytes changes | Temporary signed URL changes | Name, size, digest, and both authorized versions |
| Deadline edit | Parsed time field changes | Timezone or parser error | Old and new values plus source context |
| Withdrawal or loss of access | Repeated explicit terminal result and review | Temporary 500, 403, DNS, or maintenance | Last success, failures, and review state |
When decomposing features, data, and acceptance scenarios, also compare How can region-specific reporting templates be generated and maintained automatically?; the linked guidance adds context that should be considered in the same decision.
Preserve enough evidence without retaining everything forever
For each successful fetch, store status, canonical URL, retrieval and declared times, source fingerprint, normalized text, and parser version. Retain full bodies and files in controlled storage only where permitted. Otherwise keep necessary metadata, the diff, and the original link. Retention follows the evidence need, source terms, and data type.
Normalization removes scripts, styles, navigation, ads, and random parameters before paragraph comparison. For PDF or Word, compare bytes first and extract text only after a change. OCR may be needed for scans, but OCR variation is not a source-document edit; label original file, extracted text, and OCR result separately. Validate structured fields such as issuer and deadline with format rules and sampled review.
A failed fetch does not mean there is no new notice
Prefer official APIs, RSS, email subscriptions, sitemaps, and explicitly permitted public pages. Observe source terms, reasonable request frequency, cache semantics, and robots.txt. RFC 9309 defines robots behavior but does not grant authorization. When login, CAPTCHA, or technical restrictions appear, request an interface or written permission instead of disguising a browser or rotating addresses.
Give every source its own schedule, concurrency, and backoff. Use conditional requests with ETag or Last-Modified where supported, following HTTP semantics in RFC 9110. Show network failure, parser failure, consecutive empty output, and source redesign as health incidents, separate from “no business change.” Confirm withdrawal after retries and human review.
Acceptance replays historic examples: new notice, one-character body edit, deadline change, same-name file replacement, template redesign, temporary outage, and true withdrawal. Measure recall and false alerts for business changes, source-to-alert delay, file completeness, parser failure, and human-review volume. Keyword tests include synonym, negation, region, and industry boundaries. Without a common replay set and window, “nothing missed” is not a supportable claim.
Wavesteam first selects a small set of high-value sources with clear access permission and creates source adapters and replay tests. Each source has an owner, schedule, parser version, and stop condition. Users receive evidenced changes with original and diff. A prohibited or unauthorized source moves to official subscription or manual monitoring; technical evasion is not a feature. Wavesteam's enterprise solution provides the relevant integration context.