School-club campaign reviewer

IDEA 1

Marketing claims still need evidence

A campaign is a coordinated set of messages and channels used to tell an audience about something. In this classroom project, the audience is a fictional school club and the channels are invented poster options. Persuasive writing can be useful, but it cannot establish that an event has a certain date, location, or donation promise.

Separate the draft from the event fact record. Check dates and venue exactly, and allow only claims listed in the fixture's supportedClaims array. This deliberately narrow matcher is not a general language fact checker. It teaches the architecture: proposed text is evaluated against independent evidence before being treated as ready.

A draft must match the fact record

1. Event facts. Read the approved fictional date, venue, and supported claims.
2. Draft. Inspect the promises actually present in the proposed announcement.
3. Review issue. Flag a promise absent from the fact record.

Claims use exact authored strings so the classroom check is inspectable.

Check every proposed claim

const unsupported = draft.claims.some(claim => !facts.supportedClaims.includes(claim));

One unsupported claim is enough to require review. Good spelling or a matching date cannot make that claim supported.

Think it through: The draft promises 'All proceeds donated,' but the fact record does not. What should happen?

IDEA 2

Budget and approval belong at the action boundary

The campaign's channel plan has its own constraints. A known total must fit the budget; an unknown channel price is a missing-cost issue. These checks are separate from factual review. A truthful announcement can still exceed the planned spend, and an inexpensive one can still contain a false promise.

Approval is tied to the exact draft version. If version 1 was approved and the text changed to version 2, the earlier approval does not cover the changed action. Here publishPreview returns only a simulated receipt: no ad is purchased, no student audience is profiled, and nothing is posted. A real application would obtain version-specific permission from its authenticated review flow.

Three independent gates

1. Facts. Require every explicit claim to be supported.
2. Cost. Require a known total at or below budget.
3. Version. Match the approved version to this draft.
4. Simulated action. Return a receipt only after all gates pass.

Passing checks prepares the draft; it does not manufacture human approval.

A changed draft needs review

const draftVersion = "v2";
const approvedVersion = "v1";
// The approval does not cover this version.

The rule prevents a reviewed draft from being replaced with different content just before an action.

Think it through: All facts and costs pass, but there is no approval. Which result fits?

Put it into practice

Block unsupported claims and stale approvals while preserving exact campaign costs.

1. Run the unsupported-promise case and inspect the starter's publishPreview call.
2. Insert the claim-evidence gate.
3. Run all cases and confirm the stale-version case makes no publication call.
4. Set approvedVersion to null in custom input to prepare a reviewable preview.

Your next experiment: Remove approval to obtain a preview, then set the channel price to null. How is missing permission different from missing cost evidence?

A convincing draft still needs factual support, an affordable plan, and approval for that exact version.

Key terms

Campaign

A coordinated set of messages and channels for communicating an event or offer.

Source of truth

The designated record used to check a defined set of facts.

Version-specific approval

Permission tied to the exact reviewed draft or action.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.