Skip to content

Reading delivery evidence

What the evidence record for a published deliverable holds, how the acceptance verdict is derived, and why no post on this build has ever been confirmed as still live.

Updated

A submitted URL does not prove the work was done. Delivery evidence is the record of what was actually published: which provider account the post belongs to, which post identifier the provider returned, which version of the agreed acceptance criteria it was judged against, and which required tags, links, codes and disclosures were actually observed on it.

The acceptance verdict is a separate fact from the evidence, and both are shown. A post can meet every agreed criterion and then be deleted a week later, so the page reports the verdict and the liveness position side by side and never merges them.

BEFORE YOU START

  • The "view" permission for a workspace with a collaboration in it.
  • A recorded deliverable that was published and verified against a connected or ownership-verified provider account. Evidence is recorded when publication is verified, not when a link is pasted.
  • Acceptance criteria agreed before the work began. The verdict is derived against the version the evidence names, so a deliverable with no agreed criteria has nothing to be judged against.

STEPS

  1. Open Delivery evidence from the sidebar, under Engage.
  2. Read the table. Each row is one published deliverable with its acceptance verdict and its liveness position.
  3. Read the verdict statement rather than the chip. Where a verdict says "could not check", the criteria named nothing this product is able to check, which is not the same as a pass.
  4. Read the "Still live?" column. It has three answers, not two: observed live, breach observed, and never observed.
  5. Scroll to the evidence record beneath the table for the full detail of any row: the canonical URL, the criteria version, whether a disclosure was observed, and whether a content hash was retained.
  6. Read the "How liveness is checked" card at the foot of the page to see what the scheduled sweep can and cannot do on this build.

WHAT YOU SHOULD SEE

Each row naming the provider account the post belongs to. That is the check that matters most in §38.8: a post published from a different account than the one that owed the deliverable does not satisfy it, however good the post is.

You will also see an orange band saying no network can be re-read. On this build that is true of every platform.

WHAT THIS WILL NOT DO

  • It will not confirm that any post is still live. Social Studio holds no interface for re-reading a published post on any network, so the scheduled sweep records that it could not look. An absence of breach observations here is an absence of observation, not compliance.
  • It will not guarantee performance. Verified publication establishes that the contracted work went out from the correct account. It says nothing about views, reach, engagement or sales, and every evidence record states so.
  • It will not judge a deliverable against criteria agreed after it was published. The verdict uses the criteria version the evidence was recorded against.
  • It will not treat a screenshot as evidence of publication. A screenshot may support a record; it never replaces provider evidence.
  • It will not prove that a post was later changed, unless a content hash or an authorised retained representation was stored at the time. Where none was, the record says so.

IF IT DOES NOT WORK

  • "No publication evidence recorded" means nothing has been verified against a provider account. It does not mean every delivery was fine.
  • "Verdict unavailable" means the acceptance criteria version the evidence names is no longer recorded. That is missing data, not a pass.
  • A liveness cell reading "never observed" on a deliverable with a contracted live period is the expected state on this build, and the sentence beside it explains why.
  • A row with no live period says so. Where no minimum live period was agreed before work began, a post taken down breaches nothing that was recorded.

COMMON QUESTIONS

Why does every post say it has never been checked?

Because no network on this build can be re-read. The scheduled sweep records that Social Studio could not look, which is deliberately different from recording that the post is still up.

Does a verdict of "met" mean the campaign worked?

No. It means the contracted work was published from the correct account and met the criteria agreed before the work began. Reach, views and sales depend on the platform and are not part of it.

  • Checking what is proved about a creator

    Reading the ten separate verification dimensions, why there is no single verified badge, and why an ownership challenge cannot be checked on any platform on this build.

  • Reading a creator settlement

    The business ledger and the creator ledger, what "released" actually records on this build, and why a dispute pauses only the amount it names.

  • Running a creator collaboration

    Recording a piece of work a creator has been engaged for, moving it through its lifecycle, tracking deliverables and reviewing what they submit.