Screenshot evidence should be structured data

Screenshots are useful because they are quick. They are also terrible evidence once they leave the moment they were taken.

A PNG in a folder can show what a marketer saw. It cannot reliably answer when they saw it, which URL it came from, what number mattered, whether the number changed later, or whether the image belongs to the right deal. That is fine for a casual note. It is weak for client reporting, influencer proof-of-work, or any workflow where an agent has to read the evidence later.

That is the product reason LinkShot exists inside the DealDash system: capture the screenshot, extract the important visible numbers with local OCR, and keep URL and timestamp metadata attached to the deal record.

Sources: LinkShot case study, DealDash case study, Chrome extension Manifest V3 documentation, Chrome offscreen documents documentation, Asha.News public digest checked during this run.

A screenshot is not a record

The first version of a screenshot workflow usually looks innocent:

1. Open the influencer post.
2. Take a screenshot.
3. Copy the short link.
4. Paste view counts into a tracker.
5. Upload proof to the deal notes.

Nobody designs that as a system. It just grows around the work.

Then the questions start:

• Which screenshot is the final one?
• Did the view count come from this URL or another repost?
• Was the number copied before or after the campaign window closed?
• Can the client see the evidence without opening a messy folder?
• Can an agent summarize the deal history without guessing?

The screenshot itself cannot answer those questions. The metadata can.

The capture moment has to do more work

The best time to structure evidence is the second it is captured. After that, the work becomes cleanup.

For LinkShot, the useful record is not only the image. It is closer to this:

source_url: creator-post-123
captured_at: 2026-10-05T09:14:00+03:00
ocr_fields:
  views: 14823
  followers: 221000
asset: screenshot.png
deal_id: autumn-campaign-42
review_status: needs-human-check

That is still small. It is also enough for a human, a CRM, and an agent to agree on what the screenshot means.

The review_status field matters because OCR is not magic. A system that extracts numbers should admit when a person still needs to check them. Pretending OCR is perfect only moves the error into the report.

MV3 makes the architecture more honest

Chrome Manifest V3 changed extension architecture around service workers, host permissions, and background work. For LinkShot, the relevant constraint was simple: long-running or DOM-like work does not belong in the service worker. OCR needed an offscreen document so the extension could process the captured image without pretending the background worker was a tiny web page.

That kind of constraint is annoying in the moment. It is also good pressure.

It forces the product to separate the pieces:

• the browser action that starts capture;
• the page URL and tab context;
• the offscreen OCR work;
• the confirmation UI;
• the DealDash API sync.

That separation makes the evidence path easier to test. It also makes failure less mysterious. If OCR fails, the screenshot can still be saved. If sync fails, the user can retry with the same metadata instead of taking another screenshot and creating a second version of the truth.

Agents need evidence with handles

This is where the small product decision becomes larger than DealDash.

Agents are bad at loose piles of proof. Give an agent a folder of screenshots and a campaign brief, and it may produce a confident summary with weak grounding. Give it records with source URLs, capture times, OCR fields, review status, and deal IDs, and it can say something more useful:

Campaign has 12 proof captures.
10 were OCR-confirmed.
2 need review because the view count was unclear.
All captures link back to source URLs.

That is the difference between content and evidence.

A screenshot is content. A screenshot with handles becomes a record.

The pattern I would reuse

Any workflow that uses screenshots as proof should ask five boring questions at capture time:

1. What URL or app state produced this?
2. When was it captured?
3. What fields should a machine read?
4. Which human or deal owns it?
5. What confidence state should follow it?

This applies to influencer deals, QA bugs, social analytics, compliance checks, and agent run reports. The shape is the same: capture the artifact, attach context, expose uncertainty, and keep the evidence tied to the work item.

The screenshot is the artifact. The record is the product.