AI Answer & Citation Change Monitor — See What the Model Changed and Why It Matters

Ask Perplexity or ChatGPT "best crm for small business" today, and it cites five sources. Ask again next week and the wording might be rewritten, a competitor might get cited for the first time, or a source that used to show up might be gone. This Actor remembers what the answer looked like last time you ran it and tells you exactly what's different — new domains cited, old ones dropped, or the answer simply rewritten — so you don't have to read the whole thing again to notice.

What you get

• A diff, not a snapshot. Every run compares against the answer this Actor saved for you the last time you checked the same query × model × language — not just a one-off citation list.
• changeType tells you what kind of change it was: new-domains (a source got cited that wasn't before), lost-domains (one dropped out), answer-rewritten (the wording changed but the cited domains stayed the same), or none.
• Works out of the box with three listed models. Built-in access covers perplexity/sonar, openai/gpt-4o-mini, and google/gemini-2.5-flash. Sonar uses native retrieval; OpenAI and Google use OpenRouter's current openrouter:web_search server tool, not the deprecated :online suffix. A custom model ID requires your own OpenRouter key; provider token charges then go to your OpenRouter account, while the Actor's per-row price remains unchanged and additional.
• Grounding is measured, not assumed. Every row distinguishes structured URL annotations returned with the response from URLs merely written inline in the answer, and exposes groundingRequested, groundingObserved, citationEvidenceMode, direct citation URLs, titles where available, confidence reasons, and evidence gaps.
• Language-tagged watches. Set a language tag such as en, ru, or pt-BR; it is part of the baseline identity and the model is instructed to answer in that language.
• One row per check, in the normal case. Every completed query × model check produces one dataset row — filter changed yourself (in the dataset view, via the API, or downstream) if you only want to see what moved on a scheduled run. On the rare occasion this Actor's own storage hiccups right after a billed check, a second, unbilled follow-up row can warn you about it. A durable baseline or lease hold then blocks automatic paid replay until the ambiguous delivery is reconciled; if neither the hold nor the warning can be persisted, the run fails loudly instead of claiming clean success.
• Runs on Apify: schedule it daily or weekly, monitor it, call it from the API or the MCP server, export to JSON/CSV/Excel, or push straight into your own pipeline.

How to run it

1. Click Try for free — no card needed on the free plan.
2. Paste your queries into Queries and select up to three listed models. No API key is needed for those models. For a custom OpenRouter model, provide your own key and inspect the row's grounding fields before treating citations as retrieval evidence.
3. Press Start. The first run for each query × model creates a baseline (found: true, baselineCreated: true) — there's nothing to compare against yet, so changed is false. Schedule the same input to run again later (daily/weekly) and every row after that compares against what was saved last time.

Pricing

Pay per completed query × model check. The live Apify pricing panel is authoritative; the current tiered event prices are:

Tier	Actor start per billed GB	Completed answer check
Free	$0.005	$0.0500
Bronze	$0.00475	$0.0475
Silver	$0.00450	$0.0450
Gold	$0.00425	$0.0425
Platinum	$0.00410	$0.0410
Diamond	$0.00400	$0.0400

Apify charges the start event once per GB of allocated memory, minimum one event. The default 512 MB run therefore uses one start event. A completed check is billed whether it creates the first baseline, detects a change, or confirms no change: the model call and comparison work happened in all three cases. At the Free-tier prices, 20 queries against one model cost approximately $1.005; the maximum accepted input of 20 queries × 3 models costs approximately $3.005. At the current Diamond event prices the same two examples are approximately $0.804 and $2.404.

Rows where the LLM call itself failed, or where this Actor's own baseline lookup failed (found: false, with an error), are always returned for transparency and are never charged — this Actor checks its own deployed pricing at the start of every run and refuses to proceed (with a loud error, no paid work) if the platform ever charges anything for a plain dataset write on top of the two named events above, so the "never charged" and the "$3.005 maximum" claims above hold by construction, not by assumption.

Pass your own openrouterApiKey and provider token charges bill directly to your OpenRouter account. This does not remove or discount the Actor's pay-per-event row price; the two charges are separate. Built-in access is limited to the three models listed below.

Input

Field	Required	What it does
queries	yes	One to 20 non-empty prompts, at most 1,000 characters each. Each unique prompt is checked against every model and compared with its own baseline. Invalid or oversized input stops before model work and result billing; nothing is silently truncated.
models	no	One to three OpenRouter model IDs. The three listed grounded configurations work with built-in access. Custom IDs require BYOK and may be ungrounded. Default ["perplexity/sonar"].
lang	no	Valid language tag such as en, ru, or pt-BR, up to 35 characters. Default en.
openrouterApiKey	no	Optional secret, up to 512 characters. BYOK sends provider token charges to your OpenRouter account and permits custom model IDs; the Actor row price remains unchanged.
maxConcurrency	no	Parallel LLM calls, 1–3 (default 1), kept low to respect rate limits and to bound how many LLM calls can be wasted if a run's spend limit is hit mid-run.

{
    "queries": ["best crm for small business"],
    "models": ["perplexity/sonar"],
    "lang": "en"
}

Data path, privacy, and deletion

This is an AI inference monitor, not a private document vault. Each submitted query is sent to OpenRouter and then to the model provider selected for that request. OpenRouter states that provider logging, retention, and training practices differ by provider. Review OpenRouter provider logging, the selected provider's linked data policy, and OpenRouter's Privacy Policy before use. This Actor does not override those policies and does not promise zero-data-retention routing. Do not submit passwords, API keys, personal data, customer records, confidential strategy, or regulated content as a query.

What this Actor stores in your Apify account:

Location	Stored data	Retention and deletion
Run Input / default key-value store	Your original Input, including full queries. openrouterApiKey is a secret Input field and is not copied into result rows or monitor baselines.	The run's unnamed storage follows your Apify plan retention. Delete the run's default key-value store or its INPUT record when you no longer need it.
Default Dataset	Full query, model ID, bounded answer snippet, fingerprints, citation URLs/titles/domains, timestamps, decision fields, and explicit errors. The full model answer is not stored.	Dataset rows are append-only; remove the entire Dataset from its Actions menu or through an Apify API client when required.
Named key-value store ai-answer-baseline	An opaque query/model/language-derived key; answer fingerprint, cited domains, observation timestamps, and bounded provenance flags. New records do not retain the query or answer snippet. Compatible legacy records are accepted, then rewritten without their old snippet.	Apify documents named storage as retained indefinitely until the account owner deletes it. Delete one record to reset one watch, or delete the entire store to erase all watch history. The next successful run then creates a fresh baseline and cannot report a historical change.
Run logs	Model ID and a 12-character one-way queryRef for routine watch messages, not the full query.	Logs follow the run/account retention controls. Provider and platform operational logging remain governed by their own policies.

Apify's current storage and deletion rules are documented in Storage and Key-value store. Deleting Dataset or baseline evidence is irreversible and can break audit continuity, so export what your own retention policy requires first. The Actor developer cannot delete storage in a buyer's account and cannot recover a deleted baseline.

Output

One row per query × model pair, compared against the baseline this Actor saved last time. Both rows below are real historical rows and intentionally abridged; new runs also include the additive citation-provenance and decision fields documented in the field dictionary. The first is what a first-ever check for this query looks like, the second is the same query checked again minutes later, where the model rewrote its answer without changing which domains it cited:

First check — no baseline existed yet:

{
    "query": "best crm for small business",
    "model": "perplexity/sonar",
    "lang": "en",
    "found": true,
    "changed": false,
    "baselineCreated": true,
    "changeType": "none",
    "citedDomains": ["fayedigital.com", "fitsmallbusiness.com", "pcmag.com", "techradar.com", "zapier.com"],
    "addedDomains": [],
    "removedDomains": [],
    "answerSnippet": "The **best CRM for a small business** depends on what you need most, but **Bigin by Zoho CRM** is ranked **best overall** by PCMag for 2026, while **HubSpot CRM** is also widely recommended as a strong all-around option for small teams.[1][4]\n\nIf you want the quickest recommendat",
    "previousCheckedAt": null,
    "baselineWriteError": null,
    "summary": "perplexity/sonar on \"best crm for small business\": first check — baseline created, 5 domain(s) cited.",
    "checkedAt": "2026-07-28T19:20:15.000Z"
}

Same query, checked again — answer rewritten, same 5 domains still cited (citedDomains is always sorted, so an identical set always serializes identically):

{
    "query": "best crm for small business",
    "model": "perplexity/sonar",
    "lang": "en",
    "found": true,
    "changed": true,
    "baselineCreated": false,
    "changeType": "answer-rewritten",
    "citedDomains": ["fayedigital.com", "fitsmallbusiness.com", "pcmag.com", "techradar.com", "zapier.com"],
    "addedDomains": [],
    "removedDomains": [],
    "answerSnippet": "The **best CRM for a small business depends on your priority**, but the strongest all-around picks in current reviews are **HubSpot CRM** and **Bigin by Zoho CRM**.[1][4] If you want the simplest answer: choose **HubSpot CRM** for the best overall small-business experience, or **",
    "previousCheckedAt": "2026-07-28T19:20:15.000Z",
    "baselineWriteError": null,
    "summary": "perplexity/sonar on \"best crm for small business\": answer changed (answer-rewritten) — +0/-0 domain(s) vs 2026-07-28T19:20:15.000Z.",
    "checkedAt": "2026-07-28T19:24:46.330Z"
}

Field	What it means
query / model / lang	Echo of the input for this row
found	Whether the LLM check succeeded
changed	Whether the answer differs from the stored baseline
baselineCreated	true the first time this query × model × lang is checked — nothing to compare against yet
changeType	none, new-domains, lost-domains, or answer-rewritten
citedDomains	Normalized domains observed in the current citation evidence. A domain alone is not proof of endorsement or correctness.
citedUrls / citations	HTTP(S) URLs observed in the model response, optional titles, and whether each came from structured annotations or inline-text fallback. Tracking and sensitive-looking query parameters plus fragments are removed. The Actor does not separately fetch or verify citation-page reachability/content.
citationEvidenceMode	structured_url_annotations, inline_url_fallback, or none. Only the first is observable structured retrieval evidence in this response.
groundingRequested / groundingObserved	Whether the selected mode requested online grounding and whether structured URL annotations were actually returned. Requested is not the same as observed.
modelAccessMode / modelSupport	Included-access vs BYOK and listed-model vs custom-model classification.
addedDomains / removedDomains	Domains that appeared / disappeared versus the stored baseline
answerSnippet	First 280 characters of the model's current answer
previousCheckedAt	Timestamp of the run this one was compared against, or null on a first check
summary	Human-readable one-line summary of the change
baselineWriteError	Normally null. If a paid row was delivered but its new baseline could not be committed after retries, a second unbilled warning row is attempted and a durable hold blocks automatic paid replay. The hold requires reconciliation before that watch can resume; if the hold or warning cannot be persisted, the run fails.
found: false	The LLM call failed, or this Actor's own lookup of your stored baseline failed — same shape with an error field, no charge either way. A baseline-lookup failure is deliberately never treated as "no baseline yet": if it were, and this check then created a fresh baseline over a real one that this Actor simply couldn't read at that moment, whatever change your real baseline was tracking would be lost permanently the next time it compared successfully.

Related tools

Related tools for adjacent workflows in AI and search visibility.

Actor	What it does
AI Overview Citation Tracker	Pair it in the AI and search visibility workflow: For each query that matters, see which sources and domains AI assistants cite in their answer — grounded...
LLM Brand Visibility Tracker	Pair it in the AI and search visibility workflow: For each query that matters, check whether AI assistants recommend YOUR brand — and which competitors they...
Domain Health Checker	Pair it in the AI and search visibility workflow: Bulk-audit domains: DNS records, SSL certificate expiry, SPF & DMARC email authentication
AI Crawler Access Checker	Pair it in the AI and search visibility workflow: Check which AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended & more) can access your website
Social Preview Checker	Pair it in the AI and search visibility workflow: See exactly how your links look when shared on Telegram, WhatsApp, X, LinkedIn, Slack, Facebook & Discord

FAQ

Do I need an API key? No for the three listed models: their access is built in and covered by the row price. A custom model requires BYOK. Passing your key creates separate provider token charges and does not remove the Actor's row price.

Why was I charged for a run where nothing changed? The Actor still had to call the model and parse its citations to know nothing changed — that work is what you're paying for, not just the alert. This applies to the very first run too (it creates the baseline).

What this is NOT. It is not a general web-search monitor. It records what the selected model answered for the exact query and labels the evidence it actually returned. Structured URL annotations support an observable retrieval statement; inline URLs only prove that the model wrote those URLs in its answer. Citation URLs and titles are not independently fetched, licensed, or checked for current content by this Actor. Model output can shift because of nondeterminism even when underlying web facts did not change.

Concurrency boundary. Before any model call, each query × model × language watch writes a uniquely keyed contender, waits through two visibility-settle passes, elects one stable owner, and later force-verifies ownership inside the paid-delivery lock. A foreign owner, malformed lease state, storage error, lost ownership, or retained delivery hold stops that watch before result billing. This is materially stronger than the former single get-then-set lease. Apify Key-Value Store still provides no transactional compare-and-swap, so this is not a mathematical exactly-once guarantee under unbounded consistency delay or a total storage outage. Keep one schedule per watch set, avoid overlapping manual runs, and deduplicate downstream on eventId plus the Apify run ID.

Delivery reconciliation boundary. If linked row delivery and billing return an ambiguous error, or a confirmed paid row cannot advance its baseline, the Actor attempts a durable baseline hold first and an indefinite lease hold as fallback. Future scheduled runs remain free and blocked for that watch until an operator inspects the prior run and clears the held KVS record. Never clear a hold merely to make a red run green; reconcile Dataset, charge, and baseline evidence first.

Why did my run FAIL instead of complete? In the rare case where this Actor cannot even manage to warn you about a storage problem after retrying (see baselineWriteError above), it deliberately crashes the run instead of quietly reporting success — a check you were billed for must never disappear into a log line nobody reads. If you see a FAILED run, check the run log; retrying the schedule normally resolves it once the underlying storage hiccup clears.

Found a wrong result, or need a model we don't list? Open an issue on this Actor's page.

---

Built by zinin. Questions? Telegram @timzinin.

Commercial guide: AI Answer & Citation Change Monitor

Re-run the same query, model, and language on schedule and receive explicit answer/citation diffs, compatible baselines, citation provenance, materiality, confidence, direct URL evidence, and fail-closed delivery diagnostics.

This guide is written for buyers, operators, analysts, and automation builders. It explains what the Actor observes, how to turn the Dataset into a controlled workflow, and where human verification remains mandatory.

The decision this product supports

Did the grounded AI answer or its cited-domain set materially change since the prior comparable check, and what should a GEO or content analyst inspect next?

The Actor reduces collection and first-pass triage work. It does not remove responsibility for source verification or authorize an external business action. The commercial value comes from a structured, repeatable evidence layer: stable identity, observation time, source evidence, confidence, gaps, recommended action, and failure semantics travel with the raw facts.

Who uses it

User	Value
Small-business marketers	Track buyer questions that influence discovery without rereading every full AI answer.
GEO and SEO agencies	Deliver citation additions, losses, rewrites, confidence, and evidence for client-approved query sets.
Content strategists	Review changed source domains before updating content or outreach plans.
Brand teams	Monitor a stable set of category and recommendation prompts across grounded models and languages.
Competitive-intelligence teams	Store answer transition events with explicit before/after fingerprints and source-domain sets.
Automation builders	Schedule bounded query-model pairs and route only reviewed change events to downstream workflows.

Input contract

Input field	How to use it
queries	Required list of up to 20 prompts. Each query is checked against every selected model and gets a separate persistent baseline.
models	One to three OpenRouter IDs. Three listed online models use included access; custom IDs require BYOK and may return no structured grounding evidence. Every query × model pair is separately billed after completion.
lang	Requested answer language that also forms part of the stable baseline identity.
openrouterApiKey	Optional secret caller-owned key. BYOK permits custom IDs and creates direct provider token charges while leaving the Actor row price unchanged; never put a real key in a Dataset, Task description, README, or client application.
maxConcurrency	One to three parallel LLM calls. Low concurrency limits rate pressure and wasted calls near a buyer spend boundary.

Recommended first Input

{
  "queries": [
    "best crm for small business"
  ],
  "models": [
    "perplexity/sonar"
  ],
  "lang": "en",
  "maxConcurrency": 1
}

Start with this bounded example, inspect every Dataset field, and only then expand the scope. Input limits are product controls, not inconveniences: they make cost, completeness, and error handling visible.

Field dictionary

Field or group	Meaning
entityId, eventId, query, model, lang	Stable query-model-language watch identity and one observed answer event.
found, baselineCreated, changed, changeType	Completed, first-check, and answer/citation transition semantics.
before, after, changedFields, changeFlags	Prior/current fingerprints and cited domains plus normalized change labels.
citedDomains, addedDomains, removedDomains	Current normalized cited-domain set and exact domain-set differences from the compatible baseline.
citedUrls, citations, citationEvidenceMode	Normalized URLs observed in the response, optional titles, and whether evidence came from structured annotations, inline text, or nowhere observable. Reachability and page content are not independently verified.
groundingRequested, groundingObserved, modelAccessMode, modelSupport	Requested-vs-observed grounding and included-vs-BYOK model policy. These fields prevent a custom or annotation-free response from being mislabeled as grounded evidence.
answerSnippet, answerFingerprint	Bounded current answer excerpt and comparison identity; full answer text is not retained in this decision layer.
observedAt, previousCheckedAt, firstSeenAt, lastSeenAt, freshness	Comparison and observation timing.
materialityScore, materialityBand	Deterministic triage significance based on rewrite and citation-domain movement.
confidenceScore, confidenceBand, confidenceReasons	Support for the precise comparison statement, reduced by baseline, storage, or concurrency limitations.
sourceEvidence, dataGaps	URL/domain evidence plus explicit structured-citation, model-nondeterminism, full-text, baseline, and atomic-storage gaps.
recommendedAction, actionPriority, safeToAutomate, failureType, retryable	Human GEO review and operational recovery routing.

Common decision fields

The Actor-specific dictionary above is authoritative for this product. The common table below defines the shared Ryan20 integration vocabulary; consumers must not invent a field that is absent from a real row or treat an omitted optional value as a negative fact.

Field	Operational meaning
recordType	The semantic row family. Use it to distinguish a business result from an advisory or terminal record.
schemaVersion	Version of the additive decision-intelligence contract. Pin or validate it in strict consumers.
entityId	Stable entity identity for deduplication and joins. It is not necessarily a legal identifier.
inputRef	The relevant submitted input reference after normalization.
observedAt	When the Actor observed or finalized the evidence. It is not necessarily the source publication time.
firstSeenAt and lastSeenAt	Always-emitted observation boundaries. Stateful monitors use the compatible baseline/current boundary. Stateless rows set both equal to observedAt for the current run; that equality does not establish historical tenure.
freshness	A structured statement about evidence age or availability, not a prediction. Its basis and age unit follow the source-specific field definition.
eventId	For monitors, the stable identity of one observed transition or monitor outcome. It is distinct from entityId.
before and after	For monitors, the bounded comparable snapshots used for the decision. Null means that side of a comparison was not honestly available.
changedFields and changeFlags	Machine-readable monitor deltas and normalized change labels. Empty arrays mean no supported changed field was established, not that every possible real-world fact stayed constant.
materialityScore and materialityBand	Magnitude of an observed monitor change when the Actor can calculate it. Materiality is separate from evidence confidence and may be unknown when the source lacks the required facts.
confidenceScore	Evidence support on a 0–100 scale. It is separate from materiality, lead score, or business value.
confidenceBand	Readable high/medium/low/unknown grouping of evidence support.
confidenceReasons	Observed facts that raise confidence.
confidenceRisks	Missing, partial, ambiguous, inferred, or conflicting aspects that reduce confidence.
confidenceConflict	Explicit consistency warning when structured evidence does not reconcile.
sourceEvidence	Source-linked observations supporting the row. Preserve this during export.
dataGaps	Important evidence the Actor did not observe or cannot establish. Keep these gaps visible in CRM, spreadsheet, and automation exports.
negativeSignals	Machine-readable risks or gaps. A negative signal is not automatically a negative business outcome.
recommendedAction	Bounded review label produced from the available evidence.
actionPriority	Suggested queue priority, not urgency guaranteed by the source.
actionReason	Plain-language explanation for the recommended action.
safeToAutomate	Whether the narrow recommended action is deterministic enough for automation. Organizational policy still applies.
failureType	Normalized terminal or partial failure classification. Null means no classified failure.
retryable	Whether a later retry may legitimately change an operationally incomplete result.
recommendation	Human-readable handling guidance, especially for terminal rows.

Evidence, confidence, and honest boundaries

What the evidence supports

• Every successful query × model pair runs the configured model and compares a fingerprint and sorted cited-domain set with its own stored baseline.
• structured_url_annotations means structured URL annotations were observed in that response. inline_url_fallback means the model only wrote a URL in prose; none means no auditable citation URL was returned.
• Included access is limited to the three listed model IDs. Custom IDs require BYOK, do not change the Actor row price, and are never assumed to be grounded merely because they returned text.
• The first successful check establishes a baseline and cannot claim a change.
• new-domains and lost-domains mean cited-domain set differences; answer-rewritten means text changed while the domain set stayed stable.
• Model nondeterminism is an explicit data gap: a rewritten answer does not necessarily imply that underlying web facts changed.
• Baseline-read failures stop before the LLM call and charge; they never become a false fresh baseline.

What this Actor never claims

• The Actor does not prove search ranking, traffic, impressions, click-through, brand sentiment, buyer intent, source authority, or causality.
• A cited domain does not prove endorsement, accuracy, importance, or a durable recommendation.
• A cited URL/title is provider-output evidence only; this Actor does not fetch the page or prove that its current content supports the answer.
• A missing domain does not prove deindexing, removal from the web, or a deliberate model decision.
• It does not preserve or redistribute complete model answers as a source archive.
• The contender-election lease, two settle passes, and forced pre-charge ownership check reduce overlapping-run duplication but cannot create transactional compare-and-swap semantics that Apify KVS does not expose.
• A durable delivery hold intentionally blocks a watch after an ambiguous billing/delivery outcome. It must be reconciled from run, Dataset, charge, and KVS evidence before manual clearing.

Reading data gaps correctly

A data gap is part of the result. Nulls, partial flags, confidence risks, source failures, and unavailable fields must survive export. Removing these fields makes the remaining facts look more complete than they are. When two sources conflict or a required identity cannot be proven, lower confidence and keep safeToAutomate=false.

Source evidence is not permission

A public source proves only that a value or statement was observable at the recorded time and URL. It does not establish consent, contractual rights, legal status, accuracy after observation, or authorization for a downstream action. Your organization remains responsible for source terms, privacy rules, outreach policy, retention, and human review.

Decision policy and action routing

Action	How to use it
WAIT_FOR_NEXT_COMPARABLE_CHECK	Keep the same query, model, and language and run again after the intended observation interval.
REVIEW_AI_ANSWER_CHANGE	Open the current answer and cited sources, verify relevance, and investigate before changing GEO content.
NO_ACTION_MONITOR	Keep the comparable quiet event without creating unnecessary work.
RETRY_CHECK	Retry only after resolving a retryable model, source, baseline, or delivery failure.
RECONCILE_DELIVERY_HOLD	Inspect the prior run, Dataset delivery, charge receipt, and held KVS state before clearing the hold or retrying.

Confidence is not attractiveness

confidenceScore answers “how strongly does the available evidence support this factual classification?” It does not answer “how valuable is this lead, property, account, or address?” A high-confidence negative fact may be commercially uninteresting; a low-confidence positive signal may deserve research but not action. Keep the concepts separate in dashboards, exports, and CRM fields.

Why safeToAutomate is conservative

safeToAutomate is intentionally false whenever the next step could amplify an uncertain inference. It may be true only for narrow deterministic actions explicitly supported by the row, such as suppressing an email with invalid syntax. A true value does not waive legal, privacy, consent, contractual, or organizational rules.

Retry policy

• Retry when retryable=true and the failure is operational, such as a temporary source or DNS problem.
• Do not endlessly retry deterministic invalid input, policy refusal, or confirmed absence.
• A retry must preserve the original input reference and must not create duplicate downstream actions.
• Budget exhaustion is not negative evidence about the entity. Resume only the unprocessed scope with an authorized budget.
• A failed Actor run is an operational event. Never transform it into “no listing,” “no contact,” “bad lead,” or “invalid email.”

Commercial use-case playbooks

1. Category recommendation watch

Goal. Monitor a buyer-style “best X for Y” prompt weekly and review newly cited or lost domains with the full current answer.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

2. Client GEO report

Goal. Deliver exact query/model/language scope, transition type, citation changes, run URL, confidence, and limitations.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

3. Brand source watch

Goal. Track whether an approved source domain enters or leaves the cited set without equating citation with endorsement.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

4. Competitor citation research

Goal. Use added domains as an investigation queue and verify what the answer actually says about each source.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

5. Multilingual observation

Goal. Create separate language baselines and avoid comparing outputs generated under different language settings.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

6. Model comparison

Goal. Run the same queries across up to three models while treating every model as an independent watch and billed check.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

7. Content refresh queue

Goal. Route material answer changes to a human content audit; never auto-edit or publish pages from the alert alone.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

8. Concurrency and failure lane

Goal. Use one schedule per query set, flag concurrentRunSeen, and quarantine baseline/delivery uncertainty before retrying.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

Integration recipes

All examples use placeholders. Keep the Apify token in a secret manager and never write it into a Dataset, README, screenshot, or client-side application.

cURL: start a run and wait briefly

curl -sS -X POST 'https://api.apify.com/v2/acts/zinin~ai-answer-change-alert/runs?waitForFinish=60' \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"queries":["best crm for small business"],"models":["perplexity/sonar"],"lang":"en","maxConcurrency":1}'

The run response includes defaultDatasetId. Read clean JSON rows with:

curl -sS "https://api.apify.com/v2/datasets/$DEFAULT_DATASET_ID/items?clean=true&format=json" \
  -H "Authorization: Bearer $APIFY_TOKEN"

JavaScript with apify-client

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const input = {
  "queries": [
    "best crm for small business"
  ],
  "models": [
    "perplexity/sonar"
  ],
  "lang": "en",
  "maxConcurrency": 1
};
const run = await client.actor('zinin/ai-answer-change-alert').call(input);
const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });

for (const row of items) {
    console.log({
        entityId: row.entityId,
        confidenceBand: row.confidenceBand,
        recommendedAction: row.recommendedAction,
        safeToAutomate: row.safeToAutomate,
        failureType: row.failureType,
    });
}

Python with apify-client

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("zinin/ai-answer-change-alert").call(run_input={
    "queries": [
        "best crm for small business"
    ],
    "models": [
        "perplexity/sonar"
    ],
    "lang": "en",
    "maxConcurrency": 1
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items(clean=True):
    print({
        "entityId": row.get("entityId"),
        "confidenceBand": row.get("confidenceBand"),
        "recommendedAction": row.get("recommendedAction"),
        "safeToAutomate": row.get("safeToAutomate"),
        "failureType": row.get("failureType"),
    })

Apify MCP call

{
  "name": "call-actor",
  "arguments": {
    "actor": "zinin/ai-answer-change-alert",
    "input": {
      "queries": [
        "best crm for small business"
      ],
      "models": [
        "perplexity/sonar"
      ],
      "lang": "en",
      "maxConcurrency": 1
    }
  }
}

Generic webhook consumer policy

1. Trigger on a terminal Actor run event.
2. Confirm the run status is SUCCEEDED before reading business rows.
3. Retrieve rows from defaultDatasetId.
4. Reject or quarantine rows whose failureType is non-null unless your policy explicitly handles that failure.
5. Send safeToAutomate=false rows to a human-review queue.
6. Store entityId, observedAt, sourceEvidence, confidence, action, and the Apify run ID together.
7. Make retries idempotent by keying the destination on the stable entity ID plus the intended observation or event identity.

Where this fits in a practical stack

Destination	Recommended pattern
Apify Console	Use the visual Input form, start the run, then open the default Dataset overview. This is the fastest path for a one-off review and the best place to inspect evidence before automating anything.
Apify API	POST JSON input to the Actor run endpoint, wait or poll for completion, then read the default Dataset through the URL returned by the run object.
JavaScript client	Use apify-client from a Node.js service, pass the same JSON object as the Console Input, and preserve the returned run and Dataset IDs in your own audit log.
Python client	Use apify-client in a Python enrichment job, iterate Dataset items, and route rows by recommendedAction, confidenceBand, failureType, and retryable.
Make	Start the Actor from a scenario, wait for the run, retrieve Dataset items, filter unsafe or low-confidence rows, then insert review-ready rows into the destination application.
Zapier	Use an Apify run action or webhook trigger, fetch Dataset items, apply a Filter step, and send only review-approved fields into the next sales or operations step.
n8n	Use HTTP Request or Apify nodes, branch on failureType and retryable, keep a manual-review lane for safeToAutomate=false, and write sourceEvidence together with the business fields.
Google Sheets	Export the Dataset directly or append rows from an automation. Keep stable entityId as a hidden key so reruns update the correct record instead of creating ambiguous duplicates.
Airtable	Map entityId to a primary or deduplication field, store confidence and evidence in separate columns, and expose recommendedAction as the triage view.
Webhook	Configure an Apify webhook for terminal run states, retrieve the Dataset after SUCCEEDED, and treat FAILED or TIMED-OUT runs as operational events rather than negative business evidence.

A safe automation shape

The Actor is a collection and decision-support component. A production workflow should keep raw evidence, decision metadata, and business action in distinct layers:

1. Collect: run the Actor with explicit bounded input.
2. Validate: require a successful run and schema-valid Dataset rows.
3. Triage: branch on failureType, retryable, confidenceBand, and safeToAutomate.
4. Review: open source evidence for rows that may affect a person, campaign, investment, compliance decision, or customer record.
5. Act: execute only the action approved by your own policy and authorized operator.
6. Audit: retain run ID, Dataset ID, observation time, input reference, source evidence, and the final human decision.

This separation prevents a common automation error: turning “data was observed” into “a business action is justified.”

Operating guide

Before the first production run

1. Write the business question in one sentence: Did the grounded AI answer or its cited-domain set materially change since the prior comparable check, and what should a GEO or content analyst inspect next?
2. Confirm every submitted input is within your authorized scope.
3. Use the prefilled small example and review all returned row types.
4. Map stable identifiers, confidence, evidence, actions, gaps, failure, and retry fields into the destination.
5. Establish a human owner for review exceptions.
6. Set a run budget and output bound appropriate to the test.
7. Verify that secrets are stored only in the platform or workflow secret manager.

After every scheduled run

1. Check terminal run status and logs.
2. Compare the number of submitted entities, produced business rows, and advisory rows.
3. Review partial, unknown, conflict, and low-confidence buckets.
4. Inspect a sample of source evidence, including at least one positive and one negative result.
5. Confirm the destination deduplicated on the intended stable key.
6. Verify that no downstream action was triggered from an error row.
7. Track cost per useful reviewed row rather than cost per raw request alone.

Production monitoring signals

Monitor source-unavailable rate, partial-row rate, low-confidence share, missing evidence, retry volume, run duration, Dataset row count, and spend. A sudden shift may indicate source drift, input drift, or an upstream outage. Stop automation and investigate before accepting a new pattern as business truth.

Cost control

Begin with one query, one model, and concurrency 1. Inspect the paid baseline row, then run the identical input again. Model the exact query × model pair count and verify live charges before adding prompts or models.

Use maxTotalChargeUsd when calling a monetized Actor if your workflow supports it. Treat a buyer-set cap as a hard safety boundary. If the cap stops work, the unfinished items remain unprocessed; they do not become negative results.

Review templates and quality reporting

Row-review worksheet

For every material row, an analyst should be able to answer the following without relying on memory or an unstated assumption:

1. What submitted entity or query does this row refer to?
2. Is it a business result, a baseline/advisory row, a partial observation, or a failure?
3. Which exact source evidence supports the headline fact?
4. When was the evidence observed, and is there a different source publication time?
5. Which fields are direct observations, which are normalized, and which are deterministic derivations?
6. What important evidence is null, missing, partial, ambiguous, or conflicting?
7. Does confidence describe evidence support only, or has someone incorrectly treated it as business value?
8. What recommended action is present, and what additional verification does its reason require?
9. Is the narrow action marked safe to automate? If yes, does organizational policy also permit it?
10. What final human disposition was made, by whom, and from which run and Dataset item?

Field-group review prompts

1. entityId, eventId, query, model, lang

Contract meaning: Stable query-model-language watch identity and one observed answer event.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

2. found, baselineCreated, changed, changeType

Contract meaning: Completed, first-check, and answer/citation transition semantics.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

3. before, after, changedFields, changeFlags

Contract meaning: Prior/current fingerprints and cited domains plus normalized change labels.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

4. citedDomains, addedDomains, removedDomains

Contract meaning: Current cited-domain set and exact set differences from the compatible baseline.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

5. answerSnippet, answerFingerprint

Contract meaning: Bounded current answer excerpt and comparison identity; full answer text is not retained in this decision layer.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

6. observedAt, previousCheckedAt, firstSeenAt, lastSeenAt, freshness

Contract meaning: Comparison and observation timing.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

7. materialityScore, materialityBand

Contract meaning: Deterministic triage significance based on rewrite and citation-domain movement.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

8. confidenceScore, confidenceBand, confidenceReasons

Contract meaning: Support for the precise comparison statement, reduced by baseline, storage, or concurrency limitations.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

9. sourceEvidence, dataGaps

Contract meaning: Direct citation URL/domain evidence and explicit structured-annotation, model-nondeterminism, full-text, baseline, or atomic-storage gaps.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

10. recommendedAction, actionPriority, safeToAutomate, failureType, retryable

Contract meaning: Human GEO review and operational recovery routing.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

Weekly quality report

Create a recurring internal report with these measures. The report is about pipeline health, not market demand unless the source contract explicitly measures demand.

Metric	Why it matters	Investigate when
Submitted inputs	Defines the actual denominator and scope of the run.	The count differs from the approved batch or schedule.
Business result rows	Shows how many usable observations were produced.	The rate changes sharply without an input explanation.
Advisory/failure rows	Prevents operational failures from disappearing in a results-only dashboard.	Any terminal class grows or is unmapped.
Partial-result rate	Measures incomplete source coverage or configured truncation.	It rises, or analysts stop seeing the partial warning.
Low-confidence rate	Shows the share of rows requiring more evidence.	It rises by source, cohort, or input pattern.
Retryable failure rate	Distinguishes temporary operational issues from deterministic outcomes.	Retries repeat without improving evidence.
Evidence-link coverage	Confirms material facts remain traceable after export.	Links or evidence objects are missing from delivered records.
Safe-automation share	Shows how little or much of the workflow can be deterministic.	A mapping change makes unsafe actions appear safe.
Manual-review backlog	Measures whether human verification capacity matches collection volume.	Rows age beyond the campaign or decision window.
Duplicate destination writes	Tests idempotency and stable identity mapping.	The same entity/run creates multiple external actions.
Cost per reviewed useful row	Relates platform spend to approved, decision-useful output.	Raw volume rises but reviewed utility falls.
Source-drift exceptions	Detects changed markup, response shape, policy, or source availability.	A new unknown pattern survives more than one bounded check.

Client-facing delivery note template

Use a note like this when delivering exports to a client or another team:

This Dataset contains bounded public-source observations produced by the Apify Actor for the submitted Input. Each row includes observation time, evidence confidence, recommended review action, and explicit gaps where available. A positive row is not proof of buyer intent, permission, legal status, future outcome, or any fact listed in the Actor's “never claims” section. Partial and failure rows are included so coverage is not overstated. Validate material rows at their source before acting.

Add the Actor URL, run URL, Dataset URL, build/version, exact Input scope, observation window, pricing model observed for the run, reviewer name, and date of approval.

CRM disposition vocabulary

Keep collection results and sales dispositions separate. A practical downstream vocabulary is:

• needs_evidence_review: useful signal exists but a reviewer has not approved it.
• needs_identity_review: entity or ownership association is not sufficiently proven.
• needs_policy_review: contact, privacy, suppression, legal, or contractual policy must be checked.
• approved_for_research: an analyst may perform more research; this is not approval for outreach.
• approved_for_authorized_action: a named operator approved one specific action under the organization's policy.
• retry_operational_failure: the source or infrastructure failed and a bounded retry is appropriate.
• closed_no_supported_signal: the completed bounded check found no supported signal; this is not a universal negative fact.
• closed_out_of_scope: the input should not have entered this workflow.

Never overwrite recommendedAction with the CRM disposition. The first is Actor-produced decision support; the second is your organization's accountable decision.

Sampling plan

For a new workflow, review every row in the first small run. When the contract is understood, sample all failure and partial rows plus a representative set of high-, medium-, and low-confidence results. Re-expand to full review whenever the source changes, the schema version changes, a new input cohort is introduced, the error distribution shifts, or a downstream user reports an unexplained result.

Change-management record

When you change field mappings or automation policy, record:

1. Previous mapping or rule.
2. New mapping or rule.
3. Actor build/version and schemaVersion used for validation.
4. Test run and Dataset URLs.
5. Positive, negative, partial, retry, and budget fixtures inspected.
6. Security and privacy review outcome.
7. Approver and activation time.
8. Rollback condition and responsible operator.

This makes a commercial data workflow supportable. Without the record, a later operator cannot distinguish a real source change from an undocumented mapping change.

Delivery patterns for marketing and small-business teams

One-off research

Run the Actor in Console, inspect the overview table, open evidence for each material row, and export only the approved subset. Record the run URL in the client or campaign notes.

Recurring watch or hygiene job

Use an Apify schedule. Write rows into a staging table keyed by entityId. Compare current and previous observations only when the Actor supplies valid state or your own pipeline implements an explicit comparable baseline. Never infer a change from a failed run.

Agency client delivery

Deliver three views: business results, evidence/quality exceptions, and operational failures. Include the run URL, observation time, configured scope, and a plain-language statement of what the Actor does not prove. This makes the deliverable auditable and reduces disputes caused by overclaiming.

CRM enrichment

Write into staging fields first. A human or approved policy promotes values into canonical CRM fields. Keep raw source values separate from normalized and decision fields, and do not replace a verified value with a lower-confidence observation.

AI-assisted review

An LLM can summarize rows, but it must receive the evidence, confidence risks, negative signals, and limitations. Require citations to sourceEvidence and prohibit invented identity, intent, legal, funding, mailbox, valuation, or availability facts.

Buyer and operator acceptance checklist

Use this checklist before calling the workflow production-ready.

Product fit

• The business question matches: Did the grounded AI answer or its cited-domain set materially change since the prior comparable check, and what should a GEO or content analyst inspect next?
• The submitted entities were selected through an authorized process.
• A human owner understands the positive, negative, partial, and failure row types.
• The team accepts the boundaries listed in “What this Actor never claims.”
• The destination keeps evidence confidence separate from business scoring.

Input and run controls

• queries is explicitly reviewed and bounded.
• models is explicitly reviewed and bounded.
• lang is explicitly reviewed and bounded.
• openrouterApiKey is explicitly reviewed and bounded.
• maxConcurrency is explicitly reviewed and bounded.
• The first production-like run uses a small representative sample.
• A maximum charge or internal spend alert is configured where appropriate.
• The workflow records Actor ID, build/version, run ID, Dataset ID, and input hash.

Data handling

• entityId is mapped to an idempotent destination key.
• observedAt and source-specific time fields remain distinct.
• sourceEvidence, gaps, and nulls are preserved.
• Advisory and failure rows cannot enter the positive-results lane.
• Low-confidence and partial rows have a visible manual-review view.
• Retention and deletion rules match the type of data collected.

Action safety

• recommendedAction is treated as a review label.
• safeToAutomate=false blocks automatic external action.
• Consent, suppression, legal, contractual, and platform rules are evaluated downstream.
• A reviewer can trace a material action back to source evidence and run metadata.
• Retry logic cannot duplicate a downstream action.

Ongoing quality

• The team monitors failure, retry, partial, low-confidence, and empty-result rates.
• A source-drift threshold pauses the workflow for inspection.
• Sample evidence is manually reviewed on a recurring basis.
• Cost per useful reviewed row is measured.
• Documentation and field mappings are updated when schemaVersion changes.

Frequently asked questions

Is this a database?

No. It is an on-demand observation tool. Each run collects or evaluates the submitted scope and records evidence at that time.

Does a found row prove commercial interest?

No. A found row proves only the factual observation described by its fields. Buyer intent is never inferred.

Can I automatically contact every result?

No. Use recommendedAction as triage, verify the evidence and identity, and apply your own consent, privacy, suppression, and outreach rules.

Why is safeToAutomate often false?

Because a useful observation can still require identity, context, legal, or source verification before action. Conservative routing prevents false certainty from scaling.

What should I do with low confidence?

Open confidenceRisks and sourceEvidence, close the important gap, or keep the row in a manual queue. Do not hide the confidence field.

What does partial mean?

The Actor obtained some usable evidence but could not support a complete observation of the configured scope. Partial is not the same as empty.

What is a confirmed zero?

Only an explicit source or deterministic rule can support a confirmed absence. An outage, truncation, or unreadable response is not a zero.

Should I retry every failure?

No. Retry only when retryable is true. Invalid input, policy refusal, or deterministic classification should be corrected or handled, not looped.

Can I delete failure rows?

You can exclude them from a business-results view, but retain them in operational logs so Dataset completeness and retry decisions stay explainable.

How should I deduplicate?

Use entityId for the entity and, for stateful monitors, eventId for the observed transition. Also retain the Apify run ID.

Can I treat confidence as conversion probability?

No. Confidence measures evidence support, not purchase probability, revenue, suitability, or expected return.

Can I change the recommended action?

Yes. It is an explainable default. Your downstream policy can be stricter, and should encode organization-specific authorization and risk tolerance.

How do I estimate cost?

Run the smallest representative input, inspect live event prices and run usage in Apify, then model the number of billable result events. The live pricing panel is authoritative.

Why use a small prefill?

It produces a cheap, fast, inspectable first run and reduces the chance of scaling a wrong input or workflow assumption.

Can I schedule it?

Yes. Use an Apify schedule, but make the destination idempotent and review changes in failure, partial, and confidence rates.

Can I export CSV or Excel?

Yes. Apify Datasets support common export formats. JSON is recommended when you need nested evidence and decision fields.

Can I send results to Sheets or Airtable?

Yes. Preserve entityId, confidence, evidence, gaps, actions, and failure fields instead of mapping only the headline value.

Can I use it from Make, Zapier, or n8n?

Yes. Start the Actor, wait for a successful terminal state, read Dataset items, then branch on decision and failure fields.

Can an LLM consume the output?

Yes, but pass the structured evidence and limitations together. Instruct the model not to invent missing facts and to cite sourceEvidence.

What happens when a source changes?

The run may become partial, unavailable, or fail validation. Monitor these rates and inspect logs before treating changed output as a real-world shift.

Does public mean unrestricted?

No. Public visibility does not remove source terms, privacy obligations, retention rules, or the need for a legitimate downstream purpose.

Is a source URL permanent?

Not necessarily. Store observation time and material facts because web content can change or disappear.

Can I rely on one row for a high-stakes decision?

No. High-stakes legal, financial, employment, compliance, safety, or personal decisions require appropriate primary evidence and qualified review.

How do I report a suspected parsing issue?

Provide the Actor run ID, a redacted input, affected field, expected source evidence, and whether the issue reproduces. Never include tokens or private data.

What does success mean?

A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.

Support information to include with an issue

Provide the public Actor name, Apify run ID, Dataset item index or stable entity ID, a redacted Input, the relevant source URL, expected behavior, observed behavior, and whether retrying produced the same result. Do not include an Apify token, API key, private customer record, or unnecessary personal data.

Final interpretation rule

A change row proves that the current model output fingerprint or cited-domain set differed from the stored compatible baseline. It does not prove web-fact change, ranking, traffic, authority, endorsement, intent, or causal business impact.