Recently Updated: 17 min read

Pre-Publication Approval Matrix: Who Signs Off What

Pre-Publication Approval Matrix: Who Signs Off What

A pre-publication approval matrix answers one question for every article: who signs off on what before it goes live? On a site with several writers and editors, it replaces assumptions ("the editor will have checked the sources") with a single table that names an owner for each check. If you run a publication with more than one contributor, or manage a small agency's internal review, the matrix keeps accountability from slipping between roles.

Short answer: list the checks (facts, sources, language, images, links), give each check exactly one approving role, separate the person who prepares a check from the person who approves it, and add a second approver only for higher-risk articles.

The problem the matrix solves

Each role assumes someone else looked

Take an astronomy club newsletter with three writers and one editor. A writer submits a piece about the next meteor shower and cites an observatory page. The editor reads for flow and fixes grammar. The publisher sees a finished draft and presses publish. Nobody opened the observatory page to confirm that it supports the peak-date claim. Each role did real work, and still the one check that mattered fell between them.

A matrix makes that gap visible before it costs anything. When the table has a column called "source check" and the cell beside "editor" is marked, the editor knows the check is theirs. When the cell is empty, the team sees at once that the process has a hole.

What Google's helpful content page asks

Google Search Central's page on creating helpful, reliable, people-first content (Opens in a new tab) frames self-assessment around three questions: who created the content, how it was created and why. Under "who" it asks whether it is self-evident to visitors who authored the content and whether pages carry bylines where readers would expect them. Under "how" it asks whether the use of automation, including AI generation, is evident to visitors. Under "why" it asks whether the content exists to help people or mainly to draw search visits. The page also asks whether the content has easily verified factual errors. These questions translate into matrix columns: author information, production method, purpose and accuracy. Google's wording can change, so check the live page before relying on it.

What a matrix does not do

The matrix does not rate quality. A post can pass every sign-off and still be thin. For quality scoring, a separate tool such as the helpful content guidelines and article quality scoring table fits better. The matrix records responsibility; the scoring table records level.

The five checks and who owns each

Facts

A newsletter item about the night sky is full of factual claims: peak dates, visibility times, viewing locations, how long an eclipse lasts. The writer prepares by marking each claim and attaching a source. The editor approves by opening the source and finding the sentence that supports the claim. Practical suggestion: ask writers to highlight claim sentences in the draft, so the editor checks a short list instead of rereading everything.

Sources

The commitments of the International Fact-Checking Network (IFCN) are written for fact-checking organizations, not for every publisher, so they are a reference point rather than an obligation here. The commitments page on IFCN's Code of Principles (Opens in a new tab) states that sources should be named and linked where possible, that primary sources are preferred, that key claims are checked against more than one source and that the interests of sources are disclosed where they could affect the evidence. An astronomy newsletter can borrow the habit: an event date should point to a primary source such as an observatory's published calendar, and a claim backed only by a retailer's page should say so. For citing formats, see citing sources in articles.

Language

Spelling, punctuation, consistent object names and clear sentences belong to the language check. Keep it separate from the fact check: reading for both at once risks shortchanging one. The steps in editing articles for spelling, punctuation and consistency work as a base.

Images

For an astronomy newsletter, images do heavy work. The image check covers usage rights, credit line, alt text and what the photo shows. A sky photo needs the correct object name and date in the caption; a mislabelled nebula is a factual error in image form. Whether an image may be used is a publisher policy question. The pages read for this matrix do not state image rules, so decide them in your own policy.

Every link needs three answers: does it work, does it relate to the sentence it sits in, and is there a commercial tie. The link check is a yes-or-no check. The editor approves it, and the publisher can sample it at release.

Dates, times and numbers

In a newsletter about the sky, dates, clock times, time zones and magnitudes are easy to copy wrongly. Treat them as part of the fact check: the editor compares each one with the source and records the time zone the source uses. Practical suggestion: write times with the zone attached, and mark in the draft any figure converted from another unit, so the editor can redo the conversion rather than trust it.

Four stages, not just four roles

Start with a flow view rather than a list of roles: follow one article from draft to live and mark who touches it at each stage. The stages in a small publication are draft, edit, check and release.

StageWhat happensWho actsWhat gets recorded
DraftWriter prepares text, sources, images, linksWriterSource list, image credits
EditEditor reads for clarity, terms, structureEditorEdit note
CheckFacts, sources, images and links verifiedEditor, image ownerCheck log per item
ReleasePolicy fit confirmed, publish decision madePublisherPublish record, date

The stage view prevents one specific confusion: the person who edits for language is not automatically the person who verifies facts. Separate the stages and the person who is accountable at each one is easy to name.

Author information and production method

Two extra columns come straight from Google's questions. Author information: is the name accurate, is there a byline where readers would expect one, does it link to an author page or further information? The page warns against deceptive authorship such as invented names or false credentials. Production method: if automation or AI contributed, is that evident to readers where they would reasonably expect it? The approving role for both is the editor. See how to build an author page for E-E-A-T for the author side.

ColumnQuestionApproverAllowed values
Author informationIs the byline accurate and linked to author details?EditorDone, missing, not applicable
Production methodIs automation use disclosed where expected?EditorDone, missing, not applicable

Who may approve what

RolePreparesApprovesMust not
WriterAll five checksNothing in their own draftApprove their own work
EditorEdit noteFacts, sources, language, linksOverride the publisher's policy
Image ownerRights recordImagesApprove text claims
PublisherPolicyReleaseTreat missing approvals as done

Why the writer never approves their own check

This rule is not about trust. Authors read what they meant to write, so they miss gaps a second reader sees. On a one-person newsletter the rule cannot be applied literally, but a delay helps: reread the draft the next day as if you were the editor.

Why the publisher does not recheck everything

The publisher's job is to confirm that the record is complete and that the post fits the site's policy, not to repeat every check. A publisher who rechecks everything turns the matrix into a bottleneck; a publisher who rechecks nothing and ignores empty cells turns it into decoration.

Decision rule: who takes the cell?

  1. Can someone other than the writer re-check this item? If not, the process is incomplete.
  2. Would a mistake here hurt the reader directly? If so, the approver should be the person farthest from the draft who knows the subject best.
  3. Are preparer and approver the same person? If yes, change the approver or the day.

Question two justifies an expert cell on high-risk posts. Google's page asks whether the content is written or reviewed by an expert or enthusiast who demonstrably knows the topic well, which is the cell's purpose.

Fast posts and high-risk posts

Not every article deserves the same depth. A reminder of meeting dates and a long piece on observing a solar eclipse safely need different treatment. Practical suggestion: set three risk tiers and write down which cells each tier requires.

TierExampleRequired sign-off
LowMeeting reminder, event noticeOne editor pass over facts, language and links
MediumMonthly sky guide, telescope comparisonEditor on four checks, image owner on images
HighAdvice on solar viewing, eye safety or equipment hazardsSecond reviewer with relevant knowledge on the fact check

The same Google page says that informational content should be factually accurate, and for topics where health, safety or similar stakes apply, the content must be highly accurate and consistent with established expert consensus. That supports a stricter tier for eye-safety or equipment-safety claims. The tier list is the publisher's choice, since the pages read provide no template for tiers.

Keep speed without dropping checks

When time is short, shorten the check; do not delete cells. On a low-risk post, the editor can do one pass and record one line. Never skip the source and link checks, because a missing source or a broken link is slow to repair once the article is live.

The record

What a sign-off note contains

A sign-off exists only when it is written down. For each article keep a short note with the check, the approver, the date, the version and any fix requested. A note such as "Source page opened, peak window matches" is more useful than a tick mark, because the next editor sees what was actually verified.

Corrections after publication

The IFCN commitments page describes publishing a corrections policy, following it scrupulously and correcting openly when credible evidence shows a mistake, so that people who saw the original also see the fix. Borrow the idea for a matrix row called "correction": who fixed it, who approved the fix and how it appears on the page.

How long to keep records

The pages read give no retention period. Practical suggestion: keep the record as long as the article is live, add a line for each update and never overwrite the earlier line. Let approvers and the publisher write to the record; let writers read it.

Updating a live article

Sky content returns as events repeat, and updates are where sign-off habits collapse. A monthly sky guide gets a new paragraph when a comet is announced; nobody treats a paragraph as an article, so nobody approves it. Treat every substantive change as a small publication. The matrix row for an update lists what changed, which checks the change touches and who approved them. A new paragraph that adds a factual claim needs the facts and sources cells. A swapped photo needs the image cell. A typo fix needs none, but the record still gets a line saying the change was cosmetic.

Practical suggestion: define "substantive" in one sentence in your policy, for example any change to a claim, a source, an image or a link. Anything else is cosmetic and needs only a note. Without that sentence, teams argue about each edit.

Type of updateChecks touchedApprover
New claim or changed dateFacts, sourcesEditor
Replaced or added photoImagesImage owner
New or changed linkLinksEditor
Spelling or wording onlyLanguageEditor, noted as cosmetic

Do not change dates to look fresh

Google's helpful content page lists, among warning signs, changing the date of pages to make them seem fresh when the content has not substantially changed. The record helps here: a visible updated date should match a record line that describes a real change. If the line says "cosmetic", the date stays.

Setting it up in four weeks

A new matrix works better introduced in steps than announced in one meeting. Practical suggestion for a team that has never had one:

  1. Week one: collect the last few posts that needed a correction and mark which check missed the problem. This gives you your columns.
  2. Week two: write the roles as they actually work today, not as the org chart says, and assign one approver per column.
  3. Week three: run two real posts through the matrix with a note in every cell, and list every hole that appears.
  4. Week four: fix the holes, write the tier definitions and move the matrix into the shared sheet or publishing tool.

Expect resistance at week three. Writers feel watched and editors feel overloaded. Present the matrix as a way to stop blaming people for gaps in a process; the first time it catches a real error before publication, the argument for it is made.

Practical suggestion: name a backup approver for every column at the start, so a holiday or an illness does not stall publication. The backup works from the same sources under the same rule, and the record notes who stood in.

Roles the team may add later

As the publication grows, roles can be split: a copy editor for language, a fact checker for the facts and sources columns, a picture editor for images. The matrix absorbs this without redesign, because each new role simply takes over a column. What must not change is the rule that preparer and approver differ. If a new fact checker also prepares the source list, someone else approves that column.

Conflicts between checks

Sometimes the checks disagree. The language editor wants to simplify a sentence, while the fact check says the simpler version loses a condition from the source. The tie-breaker should be written: accuracy wins over style. Put that one line in the policy so the editor does not negotiate it each time.

Keeping the matrix to one page

A matrix that spills onto three pages is not used. Limit it to five checks plus two columns, four roles and three tiers. Put H, A or N in each cell (prepares, approves, notified). Anything needing explanation goes into the policy document rather than into the table.

Review the matrix itself twice a year. Count which cells were left empty and which approvals produced corrections; remove a column that never catches anything and split one that catches too much. A matrix that is never reviewed drifts away from how the team actually works, and the team stops trusting it.

ArticleTierFactsSourcesLanguageImagesLinksRelease
Post AMediumEditor, dateEditor, dateEditor, dateImage owner, dateEditor, datePublisher, date
Post BLowEditor, dateEditor, dateEditor, dateEditor, dateEditor, datePublisher, date

A shared spreadsheet with one row per article keeps pending approvals visible. If you also run an editorial calendar, add the sign-off cells as columns to the editorial calendar and topic ownership sheet so schedule and approval sit on one row.

How it differs from client approval and the writer-editor handoff

This matrix is the publisher's internal record. Client sign-off, revision limits and delivery terms belong to the agency-client relationship, and the writer-editor workflow for a writing service follows the buyer's side of a handoff. If you work in an agency, add client approval as a separate column, and never let it stand in for the editor's fact check. A client saying "the text looks good" has not opened your source pages.

Worked example: an astronomy club newsletter and an eclipse post

Example scenario: An astronomy club newsletter with four writers and two editors prepares a post on watching a lunar eclipse from a suburban backyard. The matrix tier is medium. The writer submits the draft with a source list and four photos.

The editor marks claim sentences and opens the sources. One sentence says that the eclipse is "visible everywhere in the country". The source page says visibility depends on location and on cloud cover, so the sentence is changed to match. A claim that a homemade filter improves contrast is not supported by any page in the source list, so it is cut. In the language pass, the writer used two different names for the same feature, "the umbra" and "the dark core"; the editor picks one and defines it once.

The image owner finds that one photo was taken by a member who sent it by email, with no written permission. The photo is replaced by one the club owns. Alt text on the other three is rewritten to say what each image shows. The publisher sees every cell filled, reads the note and publishes. Two weeks later a reader reports that a link has broken; the editor repairs it, the publisher confirms and the record gets a correction line.

FindingCheckDecision byOutcome
Visibility claim stated as absoluteFactsEditorSentence changed to match source
Filter claim without sourceSourcesEditorClaim removed
Two names for one featureLanguageEditorOne name, defined once
Member photo without permissionImagesImage ownerPhoto replaced
Broken link after launchCorrectionEditor and publisherLink fixed, record updated

When the matrix fails

Rubber-stamping

After a few weeks, sign-offs can turn into ticks without looking. Require a short note in each cell stating what was opened. If the note cannot be written, the check was not done.

One person, four roles

On a small team, one person may hold every role. Keep the matrix, but apply a different-day rule: the person who wrote the post rereads it as editor on another day. It is not ideal, but it adds distance between preparer and approver.

Deadline pressure

Under pressure, teams cut the source and link cells first. Mark those as not cuttable. If a deadline cannot be met with the checks in place, move the date rather than downgrading the tier.

Pre-publication checklist

  • The article has a risk tier.
  • All cells required for that tier are filled.
  • No check has the same person as preparer and approver.
  • The editor opened the source for every flagged claim.
  • Image rights, credit and alt text are recorded.
  • Links work, relate to their sentences and carry a mark for any commercial tie.
  • The byline is accurate, and the production method is disclosed where readers would expect it.
  • The sign-off note has a version and date.
  • The publisher confirmed the record before releasing.

Frequently Asked Questions

What does a pre-publication sign-off matrix contain?

A one-page table showing who signs off each check before an article goes live. The checks sit in columns, the roles in rows, and each cell says who prepares, who approves and who is only informed.

How big should the matrix be?

The pages read give no number. Practical suggestion: five checks (facts, sources, language, images, links) and four roles fit one page for a small publication, and you can add columns as needs grow.

May the author be the approver of their own piece?

Practical suggestion: no. The writer prepares and someone else approves. On a one-person site, reread the draft on another day in the editor's role.

Is an approval workflow a Google requirement?

Google's helpful content page does not require one. It offers questions about who created the content, how and why, and the matrix is one way to keep a record of the answers.

Are the IFCN commitments binding on all publishers?

No. The IFCN commitments are written for fact-checking organizations. Naming sources, explaining methodology and correcting openly can be borrowed as habits, but they are not presented here as obligations.

Can a client's approval stand in for the editor's check?

No. Client approval is a separate step in the agency-client relationship. It does not replace an editor opening the sources, and you can record it as its own column.

Conclusion

An approval matrix for a multi-author site turns "somebody looked at it" into a record of who verified what. Five checks, four roles and three risk tiers fit on a single page. Separate preparers from approvers, shorten checks under time pressure without removing them, and write every sign-off down.

If you would rather hand part of the production work to a team, the content writing service page lists the options.

0 Comments

No comments yet for this article.

Post a comment

Please log in to leave a comment. Login