Triage invalid-traffic and misrepresentation alerts, assemble the evidence a claim needs and track the window it has to be filed in — a person confirms fraud, blocks supply and files.
Take in verification-vendor alerts, exchange and DSP log anomalies, and platform invalid-traffic reports.
02
Attach the supply path, the ads.txt and sellers.json position, and the format each impression ran in.
Reason
03
Separate general from sophisticated invalid traffic, and separate both from a measurement artefact.
04
Test the declared domain, app and seller against the chain the bid record actually shows.
05
Size the exposure in impressions and spend, and count the days the notice period has left.
Decide
06
Rank findings by evidence strength and exposure, and drop the ones no claim can be built on.
07
Route every fraud call, supply block and claim to the person who owns that decision.
Out
08
Prepare the claim pack in the format the exchange, vendor or platform accepts, for a person to file.
09
Retain the alert, the evidence, the reviewer's call and what the counterparty paid or refused.
→Product statement
The agent triages, evidences and prepares. It does not confirm fraud, block supply or file a claim — a named person does each of those.
Example workflow
One alert, end to end
AgentHuman
1Alert arrivesA verification-vendor flag, a log anomaly in the exchange or DSP, or a platform invalid-traffic report
2Path reconstructedThe declared domain, app bundle and seller set against ads.txt, sellers.json and the chain on the bid record
3Finding classifiedGeneral invalid traffic, sophisticated invalid traffic, misrepresented inventory, or a measurement artefact
4Evidence and window assembledImpression-level records, the sources that agree, the exposure sized, and the days the notice period has left
No human action required
Stages 1 to 4 run without a person in the loop — the path reconstruction, the classification and the evidence pack are finished before anyone is asked to read anything.
5DecisionSplits on evidence strength and the claim window
Evidenced, window still open
Reaches the reviewer ready to file.
Thin evidence or artefact suspected
Held for triage, with no block proposed.
Verification lead and account owner
The verification lead confirms the finding and decides what is blocked; the account owner files the claim and carries the conversation with the counterparty.
Confirm · Reclassify · Reject
Approved — handed back▼
6Blocked and claimedOnly after a person confirms the finding, names what is blocked and files the claim
7Outcome evaluatedAlert precision against confirmed cases, claim acceptance, recovery, and what each block cost the publisher
Reclassified findings
Every finding a reviewer overturns is counted, in both directions.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Confirming that an impression was fraudulent.
Blocking a publisher, app, seller or supply path.
Filing a claim or refund request with a counterparty.
Accepting a make-good in place of a credit.
Automation boundaryAgent acts unaided
✓Reconstruct the declared path against ads.txt, sellers.json and the bid record.
✓Classify traffic as general, sophisticated, misrepresented or a measurement artefact.
✓Assemble impression-level evidence in the format the counterparty accepts.
✓Track the notice period and rank findings by exposure and evidence strength.
Write actions run only inside the approval boundaries agreed during implementation. Blocking supply and filing a claim are not among them.
Naming a publisher as fraudulent to a third party.
Changing an inclusion list or supply-path allowlist.
Setting the thresholds that trigger a block.
Withdrawing, settling or escalating a disputed claim.
Example output
One flagged impression, annotated
Everything the agent proposes is attached to the alert it came from.
Triage output · single findingIllustrative example
Alert source
Inventory
Window
Classification
Confidence
Claim
Verification vendor, post-bid
CTV app, resold path
Closes this week
Misrepresented inventory
91%
Prepared, not filed
As receivedThe alert and the bid record exactly as the vendor and the exchange logged them, with the path each one declared.
Evidence usedBid-record supply pathSeller line in ads.txtApp bundle mismatch
Why it is heldThe ads.txt check passes — the seller is authorised. The app in the bid record is not.
ActionConfirmReclassifyReject
What the score decidesIt decides how hard a reviewer looks before blocking a seller, not whether fraud occurred.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every alert and log lineFrom vendors, exchanges and platforms
03Path & evidence
Reconstruct the path that carried the impression
Set the declared domain, app and seller against ads.txt, sellers.json and the supply chain on the bid record, rather than against the label on the report.
01Approved path
Take the triage queue off the analyst
The deduplication, the path reconstruction and the evidence pack are done before a person opens the alert, so the hour goes on judgement rather than assembly.
02Human review
Reach the claim before the window shuts
Findings worth a claim are ranked and dated now, instead of surfacing after the counterparty's notice period has already run out.
04Build an evidence trail
Retain the alert, the bid record, the reconstructed path, the classification, the reviewer's call, the claim as filed and what the counterparty paid or refused — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the block list
Each control wraps the one inside it. A finding clears every layer before a block, judged under the vendor's definition — and the fraud call sits outside all six.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeReturn triage to the team and lift blocks if evaluations or signals degrade.Roll back
L5TraceabilityRecord the alert, evidence, reviewer call, claim and counterparty response.Record
L4Definition stampingEvery finding carries the vendor, definition and version it was judged under.Stamp
L3Block and claim gateNo supply is blocked and no claim is filed without a named person.Gate
L2Artefact testMeasurement gaps and server-side patterns are ruled out first.Rule out
L1Corroboration ruleNo finding stands on one source; the log has to agree with the alert.Corroborate
Model coreTriage — classification, reconstructed path, evidence pack, exposure and days remaining
L1 – L2Decide whether a finding may stand
L3Decides who blocks supply and files
L4 – L5Keep every finding traceable to its source
L6Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the triage — not only the alerts that were caught.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the queue a reviewer works through
Depth of coverage ▼
E1Final-output evaluationDid the finding hold when a person checked it against the evidence?
E2Step-level evaluationDid it reconstruct the path from the bid record, not the report label?
E3Tool evaluationDid it read the correct account, seller, app and date range?
E4Missed-fraud recallWhat did it miss where fraud was later confirmed by someone else?
E5Slice evaluationHow does performance change across formats, supply paths and vendors?
E6Business outcomeClaims filed inside the window, claims accepted, and supply blocked in error.
Floor — the spend recovered and the waste that stops
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle.
Agent lifecycleDirection of processing →
01 · Signal intake1 mode
AV-01
Artefact called fraud
A server-side or proxy pattern is read as invalid traffic.
Stage gathersVendor alerts, exchange logs and platform reports
02 · Classification2 modes
AV-02
Legitimate publisher blocked
A false positive cuts a real publisher's revenue.
AV-03
Authorised but misrepresented
The ads.txt chain checks out; the inventory does not.
Stage judgesDeclared domain, app and seller against the chain
03 · Evidence & claim2 modes
AV-04
Confirmed after the window
Fraud is called once the notice period has closed.
AV-05
Evidence the counterparty rejects
The pack lacks the impression records a claim needs.
Stage assemblesImpression-level proof in the format a claim needs
04 · Block / output1 mode
AV-06
Pennies chased, waste untouched
Small credits are worked while the bad path keeps running.
Stage returnsThe finding a person blocks, claims or rejects
05 · Change / Version1 mode
AV-07
Vendor definition moved
A threshold changes and the rates stop reconciling.
Stage tracksModel, prompt, threshold and definition changes
Sev-1 · legitimate supply is cut on a false callSev-2 · recoverable spend is written offSev-3 · the queue misleads and waste persists
A low rate for the account hides the path that is wrong
Invalid-traffic rates can sit inside benchmark overall while a few formats and supply paths carry nearly all of the findings a reviewer overturns and nearly all of the claims a counterparty refuses. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
CTV and SSAI inventory
6.3%
3.6×
Review
Resold and rebroadcast paths
4.9%
2.8×
Review
MFA-adjacent long-tail display
2.8%
1.6×
Watch
Direct premium web display
1.2%
0.7×
Normal
Bar: overturned-finding lift vs. direct-display baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The window closes whether or not the evidence is ready
Notice periods run from the invoice, not from the day a pattern becomes obvious. A cycle that sharpens detection but not speed still claims too late.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Alert precision, a missed case or claim acceptance moves on one path or format.
02Diagnose
Traced to the signal, the path reconstruction, the evidence pack or a threshold.
03Improve
The rule, threshold or pack format is changed, re-approved by the verification lead and version-linked.
04Verify
Re-run against confirmed cases and against the blocks a reviewer overturned.
05Learn
The refused claim becomes a regression case and the counterparty's evidence requirement is written down.
Learn → DetectThe return edge. Each cycle is re-timed against the shortest notice period in the stack, not the average one.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, alert and log access, classification and path reconstruction, evidence and evaluation, then the block workflow and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Triage discovery and automation-boundary definition.
02Verification-vendor and platform alert feeds.
03DSP, exchange and log-level data access.
04Supply-path sources: ads.txt and sellers.json.
05Invalid-traffic taxonomy and classification.
06Declared-path and misrepresentation checks.
07Measurement-artefact and unmeasured-impression handling.
08Evidence packs in each counterparty's format.
09Claim-window tracking and escalation rules.
10Evaluation suite, slices and regression cases.
11Block workflow and reviewer routing.
12Observability, deployment and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne channel, one vendorProductionProduction alert pipelineAdvancedMulti-vendor / multi-market
Introduced at Pilot
Alert intake and deduplication✓✓✓
Path reconstruction and classification✓✓✓
Evidence pack per finding✓✓✓
Named-reviewer sign-off✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Claim-window tracking and escalation—✓✓
Counterparty-specific claim formats—✓✓
Log-level and supply-path analysis—✓✓
Block workflow and allowlist controls—✓✓
Introduced at Advanced
Multi-vendor definition reconciliation——✓
CTV, retail media and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on the channels, vendors and exchanges in scope, log-level data access, the claim formats required, block controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01The alerts and reports you get today, and who acts on them→Triage discovery and automation-boundary definitionWeek 1
02Access to verification-vendor, DSP and exchange APIs→Alert feeds and log-level data accessWeek 2
03The invalid-traffic definitions and thresholds you buy on→Classification rules and measurement-artefact handlingWeek 2
04Your ads.txt, sellers.json and inventory-list sources→Path reconstruction and misrepresentation checksWeek 3
05Claims you have filed, including the ones that were refused→Evidence packs, evaluation suite and regression casesWeek 4
06Each counterparty's notice period and evidence requirement→Claim-window tracking and escalation rulesWeek 4
07Named reviewers and who is allowed to block a seller→Block workflow, allowlists and reviewer routingWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 carries both the evaluation slices and the first blocks and claims made under signature.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Alerts in scope, the definitions you buy on, and who may blockW2Vendor, DSP and exchange feeds, and log-level accessW3Path reconstruction, classification and artefact handlingW4Evidence packs, claim-window rules and evaluation suiteW5Block workflow, first claims filed and targeted correctionsW6Production validation, overturn review and Agent Care handover
Reading the bandThe claim-window rules and the evidence packs are built in week 4, before anything is blocked or filed in week 5. The bars show that dependency, not a smooth ramp.
At the end of W6Claims have been filed under a named reviewer and every block overturned in review has been counted, then Agent Care takes over monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Advertising AI agent
Build a fraud-triage agent around the alerts you already pay for.
Show us a month of verification alerts, the log-level data behind them and the last claim you filed or gave up on. We'll triage that month end to end and show you which findings would have survived a counterparty's review, and which would have cost a publisher money for nothing.
