Complete a first review without publishing
Use a small Northgate demo task to learn how evidence, drafts, review, and verification fit together.
A first session in Forge works best when it ends with a clear finding and a reviewable next step. You can learn the core workflow by examining one Northgate ESD Packaging page or product and documenting what needs attention before anyone publishes changes.
Pick a question with a visible answer
Use a narrow question such as: “Does our ESD packaging product explain the available sizes and how a buyer requests a quote?” Avoid beginning with a broad goal such as improving every page or increasing all AI visibility. Those goals need several kinds of evidence and are difficult to verify in one session.
Choose a demo record you can recognize by title and URL. Keep the question separate from any assumed answer: a field may already be supplied by the connected store, and Forge should preserve that ownership when it is correct.
Review one record
- Select Northgate ESD Packaging in the account selector.
- Open AEO & Agentic Storefronts.
- Confirm the selected storefront.
- Open Overview and read the reason attached to a relevant priority.
- Open Pages or Products, depending on the record named by that priority.
- Inspect the source evidence, freshness, and validation information for the record.
- Write down one specific improvement and the evidence that supports it.
For example, “Add a question explaining whether this insert is supplied in custom sizes, using the approved catalog specification” is reviewable. “Make this product better for AI” does not tell a reviewer which fact or field should change.
Separate the stages
| Stage | What it tells you |
|---|---|
| Detected | Forge observed content or an asset from a source |
| Draft | Proposed content exists for review |
| Validated | The draft passed the applicable checks |
| Published | A publishing action has completed for the relevant destination |
| Rendered verification | The result was checked on the storefront |
These stages answer different questions. A validation pass does not establish that every product claim is true. A saved draft does not establish that buyers can see it. Read the record's actual status and any task result before reporting completion.
If the source is stale, refresh the evidence before refining your recommendation. Working from an old snapshot can cause a reviewer to approve changes that conflict with newer storefront content.
Record the handoff
A useful handoff names the account, storefront, record, current issue, proposed wording, and person who should review it. Northgate's example might say that a sizing FAQ needs a catalog owner's factual review before publication.
Use Projects when you need a place for reusable copy and context. A project asset can hold a draft and placement instructions. It does not automatically update the AEO page or install itself into the storefront.
If the finding concerns a person rather than content, use the appropriate Journeys or Valkyrie record. Keep contact corrections in the reviewed CRM process instead of copying unverified research into the contact system of record.
Know when the review is complete
Your first review is done when someone else can locate the same record, understand the evidence, and decide on the next action. Publishing is a separate action for someone with permission after the draft has been reviewed.
Do not report a business outcome that the evidence cannot show. Correcting a schema block demonstrates a content change; it does not prove a new citation, a visit, or a sale. Later, use Citations and Journeys to inspect those separate observations.
If you cannot finish
An empty page inventory may require a managed scope and a completed scan. A product may need a current sync. A disabled Publish action may reflect permissions, disabled publishing, unsaved edits, or failed validation. Read the explanation beside the control and include it in your handoff rather than guessing which setting to change.