# Creator and partner campaign brief

Use this worksheet to agree on the next deliverable, its reviewer and what acceptance means. It is a planning and feedback resource. It is not a contract, payment instruction or automated campaign tracker.

## 1. Shared objective

| Item | Your agreed description |
|---|---|
| Project/campaign name | |
| Owner and participating organization | |
| Creator or delivery partner | |
| Intended audience | |
| Audience problem and useful outcome | |
| Main message | |
| Desired audience action | |
| Planned publication channel, if agreed | |
| Working language and time zone | |

Keep personal contact details and private customer information out of publicly shared copies. Assign only people who have agreed to the role.

## 2. Deliverables and responsibility

| Deliverable | Named owner | Format / length | Required assets or inputs | Due date + time zone | Reviewer |
|---|---|---|---|---|---|
| | | | | | |
| | | | | | |

Record missing inputs before the work starts. Confirm where the current version will be stored and who can access it. Do not treat a link as permission to view its destination.

## 3. Acceptance criteria

Write observable criteria for each deliverable. For example: the agreed message is present; the demonstrated product behavior matches the tested release; the call to action opens the intended destination; required captions are readable; supplied assets and approved brand colours are preserved.

| Deliverable | What must be true | How the reviewer will check | Evidence / reference |
|---|---|---|---|
| | | | |
| | | | |

Separate business acceptance, publication approval and technical validation. A positive creative review is not a security assessment or proof of legal rights. Record questions requiring the appropriate specialist rather than assuming them resolved.

## 4. Submission and feedback record

Give each submitted version an unambiguous identifier. A changed version needs a fresh decision.

| Version | Submitted by / date | Exact asset or version link | Reviewer | Decision | Requested change / reason | Next owner |
|---|---|---|---|---|---|---|
| v1 | | | | Awaiting review | | |
| v2 | | | | Awaiting review | | |

Use explicit decisions: **Awaiting review**, **Changes requested**, or **Accepted for the stated criteria**. Acceptance applies only to the specified version and criteria. Record who can approve publication separately.

## 5. Supporting evidence and handoff

| Reference | What it supports | Who may access it | Checked date | Expiry / remaining limitation |
|---|---|---|---|---|
| | | | | |

If a reference expires or access is removed, mark it unavailable. Do not copy private or short-lived engineering reports into this worksheet to bypass their access or retention rules. A proposed technical repair and a performed validation check should be recorded separately.

## 6. Next action

- Current deliverable and version:
- Next action and named owner:
- Expected review date and time zone:
- Missing input or unresolved question:
- Publication decision owner, if publication is in scope:
- Where the participants will check the current status:

## Clearly labelled fictional example

**Objective:** create a short tutorial clip showing a harmless sample finding and the next decision.

**Deliverable:** one captioned 45-second clip. The agreed reviewer checks that the sample is labelled, the product shown matches the tested release and the final link opens the relevant tutorial. No customer code or unsupported automatic-review claim appears.

**Version v1:** changes requested because the clip calls a sample walkthrough a live code review. **Version v2:** the label and narration are corrected; the reviewer accepts v2 against the agreed criteria. Publication remains a separate decision. No campaign result, payout or contract execution is claimed.

Prepared 15 October 2026. Published as a manual CodLab worksheet; no collaboration application, campaign or external communication is created by using it.