Specify a campaign-brief checker in Emergent

A useful campaign-brief checker flags missing information and tells the requester what to add. It should not invent a budget, approve an unsupported claim or mistake a filled form for a good campaign. The specification below is a small prototype plan for Emergent, using synthetic information. Use the copyable prompt and acceptance cases below as a starting point for building it.

Keep the first version narrow

Choose seven fields: campaign objective, audience, deliverables, budget amount, currency, deadline and approver role. Use structured inputs rather than asking a language model to infer everything from a pasted document. Required fields and simple numeric checks can be deterministic. A missing field should produce an error next to that field, while a complete submission should still say that human review is required.

Write down what the checker will not decide. It cannot certify advertising claims, confirm rights to an image, judge a fair budget or authorize publication. Keep those decisions in the campaign’s review process. To work on the creative input separately, use our image brief workflow; the app’s role is to collect the information that the people doing that work need.

Copy this bounded build prompt

Paste the following specification into a new Emergent web-app conversation. Ask the builder to explain the planned data flow before accepting added services. Treat any suggested login, database, analytics or model connection as a separate requirement to evaluate, because each expands the prototype’s scope and possible cost.

Create a single-page demo named Campaign Brief Check. Show a visible “Synthetic demo only” notice. Collect objective, audience, deliverables, budget amount, currency, deadline and approver role. Trim whitespace and require all fields. Budget must be a finite number greater than zero; currency must be selected explicitly. Reject a deadline before today in the browser’s local date. Display field-specific errors and preserve entered values after failure. For valid input, show a plain-text summary headed “Complete fields, awaiting human review”. Never generate missing values, evidence, clients or results. Use client-side state only: no database, analytics, external model call, file upload or account login. Add Reset and Copy summary buttons with visible success or failure feedback. Do not publish the app. Explain the validation rules and list the files changed.

The prompt is an original starting specification, not a guarantee of generated behavior. Ask for keyboard-accessible labels, a predictable tab order and a usable narrow-screen layout. If the builder proposes a different implementation, compare it with these requirements rather than assuming that a convincing preview means the same rules were implemented.

Prepare acceptance cases before clicking through

Use invented campaign information: objective “Introduce a weekend class”, audience “Adults trying a new hobby”, deliverables “One image and one short clip”, budget “250”, currency “USD”, a future deadline and approver role “Campaign owner”. The amount is synthetic, not a cost recommendation. Keep the same fixture while changing one field at a time, so each result has an identifiable cause.

Input or action	Expected behavior
All fields blank or whitespace	Field errors; no completed summary
Budget zero, negative or text	Budget error; other values remain
Deadline before today	Date error based on the stated local date
Complete synthetic brief	Accurate summary; human review still required
Reset after a valid brief	Fields and previous summary cleared
Copy blocked by browser permission	Visible failure; selectable summary remains

Review the preview as a user

Emergent’s preview documentation separates the temporary preview from a published application. Open the preview and run every acceptance case yourself. Try the form with a keyboard and at a phone-sized width. Follow the visitor-testing guidance to describe a failure as action, expected result and observed result, then repeat the same case after the change.

Inspect the generated code or ask a qualified reviewer to confirm that prohibited network calls and storage were not added. Client-side state in a specification does not prove that the generated app avoids all data collection. Never paste a real client brief, contact list or confidential commercial figure into the builder simply because the prototype form looks harmless.

Decide whether hosting is needed

Check the current publishing plans and your actual account balance before publishing. Hosting has its own recurring credit requirements; a working preview is neither a permanent URL nor proof of free operation. Review the subprocessor list and applicable privacy terms before expanding to real data. Authentication, retention, access control and deletion need a separate design if submissions will be stored.

For an occasional campaign, the seven-field template may be enough without an app. If you continue, keep a dated acceptance log and an approved requirements copy. Connect the resulting brief to the actual production tasks, such as our short-video editing workflow, and keep the person who approves the campaign separate from a screen that merely reports complete fields.