Traditional change detectors ask: did text differ since last fetch? ScoutPing conditional monitoring asks on every scheduled check: does current evidence satisfy your rules? That distinction — AI evaluation every check — shapes when Pings fire, how deduplication behaves, and why semantic conditions can match paraphrased copy diff tools miss.
This technical guide connects the fetch pipeline in how website change monitoring works to AI website monitoring semantics and operational expectations operators should hold.
Pipeline per scheduled check
Each tick of your Scout interval:
1. HTTP fetch public URL (Page Scout) or search candidates (Web Scout)
2. Parse HTML → extract readable text
3. Normalise text (whitespace, common boilerplate handling)
4. Evaluate each active rule:
- exact keyword present/absent
- price threshold
- semantic AI condition (Pro)
- meaningful text change (where configured)
5. Compare evaluation result to stored event state
6. If newly satisfied → queue email Ping
7. Update state for deduplication
Step 4 runs whether or not step 3 produced identical text to prior fetch.
Diff-first vs evaluate-first
| Model | Trigger | Blind spots |
|---|---|---|
| Diff-first | text ≠ previous_text | First fetch; masked diffs in noise |
| Evaluate-first | condition(text) newly true | Wrong condition; extraction limits |
ScoutPing is evaluate-first with optional change-oriented modes on scoped URLs — change detection vs semantic monitoring.
First-fetch behaviour
You add Scout while registration already open:
- Diff-first tool: silent until something edits
- Evaluate-first ScoutPing: Ping when first check finds condition true (if newly satisfied from Scout's empty prior state)
Important for mid-event onboarding — you still get signal if state is new to the Scout.
Caveat: if page already matched before Scout existed and state tracking treats as known — product dedup rules apply; first Ping should still arrive for new Scouts when condition satisfied on first evaluation.
Paraphrase without visible diff threshold
Page rewrites "Registration now open" → "Apply today — spots available":
- Naive diff: may or may not fire depending on noise and thresholds
- Semantic evaluation every check: asks if registration-open intent satisfied now
Interaction with deduplication
Evaluation every check could email every hour while condition stays true — unacceptable.
Event state tracks satisfaction across checks:
| Check | Condition | Ping? |
|---|---|---|
| 1 | true | Yes — new |
| 2 | true | No — deduped |
| 3 | false | No |
| 4 | true | Yes — transition |
Operators sometimes misread dedup as "missed check" — manual page still shows open, no email — correct behaviour.
Transient matches and interval
Evaluate-first samples current text each interval:
- AB test variant shows "in stock" one hourly fetch → may Ping
- Variant reverts next fetch → state may flip
Daily interval filters many one-fetch glitches; hourly increases sampling of transient false positives — false positives monitoring.
Tune interval after condition trustworthy.
Semantic AI cost and plan boundaries
Semantic evaluation invokes model inference — Pro feature in ScoutPing positioning. Every check means:
- More consistent decision coverage
- Processing per fetch, not per diff
Exact keyword evaluation is lighter — rules vs AI monitoring.
Portfolio design: exact where possible, semantic where paraphrase requires.
Web Scouts — evaluation at search scale
Web Scouts search then evaluate candidates — every check may hit multiple URLs sequentially or in batch per product design. Evaluation-first prevents "only alert if snippet changed" missing new search result URL.
Discovery noise risk — tighten conditions — search alert vs website alert.
Confidence on each evaluation
Each semantic evaluation may emit confidence strength — alert confidence scores. Computed per check against fresh evidence, not cached from prior diff.
Borderline cases evaluated repeatedly — if text clarifies, confidence may rise check-to-check.
Security evaluation every check
Untrusted page text re-evaluated each fetch — adversarial injection attempts must not accumulate trust. Defensive parsing each time — prompt injection web monitoring, untrusted web content AI.
Meaningful text change mode
On changelog URLs, meaningful text change compares snapshots but still runs on schedule — hybrid of change detection and evaluate-first philosophy — AI meaningful website changes.
Not identical to semantic "registration open" — mode choice matters.
Operator implications
Do
- Write outcome-shaped conditions
- Expect first-fetch Pings
- Trust dedup on stable true state
- Start daily before Pro hourly
Don't
- Assume silence means "not checked"
- Treat every hourly evaluation as new event
- Use any-change mental model on dynamic URLs
Why something changed alerts fail.
Comparison to browser extension polling
Extensions may diff DOM when you have tab open. ScoutPing cloud checks run regardless — monitor website computer off, cloud monitoring vs browser extension.
Evaluate-first cloud checks = consistent schedule, not tied to your laptop.
Debugging silent Scouts
If condition should be true but no Ping:
- Confirm fetch succeeds — public HTML
- Read extracted text visibility — view source
- Remember dedup — already Pinged for this state?
- Semantic too strict?
- Interval lag — false negatives monitoring
Not "evaluation skipped because no diff."
Future state changes
If page toggles condition rapidly vs check interval, you may get Ping on one transition and miss brief opposite state — scheduling limit, not evaluation skip.
Summary
AI evaluation every check means ScoutPing judges your conditions against fresh extracted text on each scheduled fetch — semantic, exact, price, or scoped change — independent of naive diff detection. Deduplication prevents repeat Pings while state persists; interval choice balances transient false positives against capture lag.
Read the full pipeline on how it works, and design Scouts for current truth of your decision, not merely difference from yesterday's HTML.
Observability for operators
When debugging Scout behaviour, ask support or review dashboard history:
- Last fetch time — did check run?
- Last evaluation result — match true or false?
- Last Ping time — dedup suppressing?
- Extracted text sample — if available, does it contain expected phrases?
Evaluate-first systems confuse users who expect "no diff = no work." Checks still run; evaluation still returns false when condition unsatisfied. Understanding every-check evaluation prevents unnecessary Scout deletion during normal deduplicated silence.
Comparison to webhook-driven diff services
Some integrations fire webhooks on any content hash change. ScoutPing email Pings fire on conditional state transitions after evaluation every check. Migrating from webhook diffs requires rewiring automation triggers from on_diff to on_condition_newly_true — a semantic shift teams underestimate during tool switches.
SLA language for stakeholders
When setting expectations with bosses or clients, say: "ScoutPing checks on schedule and emails when the condition is newly true — not continuously." Map check interval to worst-case lag:
| Interval | Worst-case awareness lag |
|---|---|
| Daily | Up to ~24 hours after HTML updates |
| Pro 90 min | Up to ~90 minutes after HTML updates |
Neither replaces human urgency for sub-minute trading — honesty prevents false negative blame when evaluation ran correctly but schedule lagged behind Twitter.
Health checks for evaluation pipelines
Operators cannot see internal model calls, but can observe symptoms:
- Sudden burst of false positives after site redesign — extraction or condition drift
- Complete silence after long true period — verify dedup vs fetch failure
- Identical Pings on duplicate Scouts — architecture issue not evaluation bug
When symptoms persist after URL and condition tune, contact support with Scout title, URL, and approximate timeline — evaluation-every-check systems need fetch logs to diagnose.