From a finding to reviewed work
Approve a page change with its evidence.
A useful change record connects one proposed edit to a buyer question, the source that supports it, the person responsible and the date it reached the page. Keep those records together before asking whether later answers changed.
By the Broadcastwell team. Updated 7 November 2026.
Review the proposal against the source
Open Fixes in your account. Each delivered finding links to its buyer question, a source page and a retained answer where one exists. Read the complete answer before deciding what the page should say. A cited address identifies a source; it does not prove that changing that page will change an engine's recommendation.
- State the exact proposed change. Keep the current passage and replacement together in the working document.
- Check the replacement against the approved source. Retain the source date, the relevant passage and any limits that affect the claim.
- Name the person or role who owns the work. Ownership tells the team who will act; it does not establish who approved a claim.
- Record what you reviewed and why it supports the change. Reject a proposal whose source is missing, contradictory or outside the agreed scope.
Use the evidence reviewer to inspect retained answers and compare their scope. Use the ledger to record the work that follows the finding.
Keep approval separate from publication
A draft in the ledger can move to Approved or Declined. It cannot jump straight to Sent, Acknowledged or Published. To approve it, choose Approved, name the owner, write the review note and confirm that you reviewed the change and its evidence.
| State | What the record means | What to retain |
|---|---|---|
| Drafted | A proposed change is awaiting a decision. | The question, source, proposed edit and owner. |
| Approved | A reviewer recorded the decision. | The review note, date and owner at that step. |
| Sent or Acknowledged | The team recorded an outside communication or response. | The dated correspondence in the approved working record. |
| Published | The team recorded that the change reached a page. | A publication note, actual date and evidence link. |
| Measured again | A later scheduled run asked at least one linked question again. | The later run and its measurement scope. |
| Declined | The team decided against publication. | The reason for the decision. |
For a page your team owns, an approved change can move directly to Published. Sent and Acknowledged are useful when another publisher controls the page. Saving any state in this ledger sends no message, edits no website and starts no measurement.
Dates move forward from the source measurement and the preceding recorded step. A future date is not accepted as completed work. Earlier delivery and source records keep the dates they already held. Their history identifies those prior records without inventing a reviewer or a missing review note.
Attach the publication evidence
When you record Published, include the responsible owner, a note explaining what was checked and an HTTP or HTTPS link to the live page or retained publication evidence. A link is a supplied reference. The ledger does not fetch it or independently certify that the page changed.
A fictional review task
Suppose a source page describes a product limit incorrectly. The content lead compares the proposed correction with the dated product specification, records approval, then checks the page after the publisher applies it. The publication note identifies the corrected passage and links to the retained evidence. None of those steps establishes an improvement in AI answers.
In the fictional Kalvenor ledger (Sample data, fictional company), inspect the question, receipt and dates for one change. Find the later measurement separately. The sample demonstrates the record structure; Kalvenor is not a client.
Open Dates and review notes to see the history. New state records retain the note and the owner at that step. A later reassignment does not rewrite that earlier owner. Account access rules still determine who may read or update the ledger.
Keep the outcome question open
A publication date is context for a comparison. It is not an outcome. The ledger marks a change as measured again only when a later scheduled run asks one of its linked questions. It does not claim that the change caused a difference.
Read Proof for the experiment and its limits. Compare the same questions, engines, measurement method and scheduled observation rule. Keep failed observations visible. If the scope changed, describe the two periods separately instead of presenting a lift.
The export guide shows how a numerator, denominator and excluded records travel with the evidence.
Export the decision as well as the number
The ledger's CSV, Jira CSV and Markdown exports include its review and publication history. Each state keeps its date, note, recorded owner and publication reference where those fields exist. The history distinguishes a signed-in record from a prior imported date or a state derived from a later run.
Keep the export with the original evidence package and working draft. That gives the next reviewer enough context to question the decision, reproduce the comparison or reconsider the work through the team's normal review process.
Build a client report from retained evidence, or return to the free toolkit.
Choose what to review next
Rank the work with explicit value, effort and confidence estimates. Keep the assessment beside its source evidence and retain earlier revisions.
Assign a person and keep the handoff
A task needs a person who knows what happens next. Open Assign owner beside the work, enter that person's name and explain the responsibility in the handoff note. Name the next step, the review it needs and any dependency. Leave the name empty when responsibility is unassigned.
The owner is a recorded responsibility. Entering a name does not invite the person, create an account or grant access. Agree the handoff through your team's existing process. The work stays in its current state; assigning an editor does not approve a draft or record a publication.
Expand Owner history to read the earlier name, new name, note and recorded date. A new handoff keeps the earlier ones. If someone changes the owner or work state while your form is open, reload the record and read that change before saving. Older edits that carried no handoff note remain labelled that way.
Use Filter by owner with a state filter to inspect one person's work, or choose Unassigned to find work that needs an owner. The CSV, Jira and Markdown exports still contain every item and every handoff. The complete account archive and existing read-only fixes responses retain the same history.
Open your account's work to record a handoff. If history storage is unavailable, the app keeps the existing owner visible and prevents an unrecorded change.
Check which client workspace holds the change
When an assistant hands off the work
Use a separate work handoff permission to preview the named owner and required note. Check the saved action record after confirmation. The existing work state and evidence stay with the entry.
Keep the reviewed source beside the work
Inspect and approve an exact source version before using it to support a claim. The source library keeps its original text, review note and expiry in the selected client account.