The Virality Predictor as a Pre-Publish Gate

Every prediction tool for short video has the same structural problem: it has never seen your account. It does not know your follower base, your posting time, your niche's baseline watch time, or how the last six things you published performed. So the absolute number it hands back — high, low, or middling — is a statement about the video in isolation, and the video is never in isolation.

That makes an absolute score close to useless as a publish/don't-publish decision. It makes the same model extremely useful for a different question: given two cuts of the same video, which one is stronger? Hold the subject, the offer, the audience and the account constant, change one thing about the edit, and the difference between the two readings is the only part of the output that carries real information. That is a gate. Used that way, the Virality Predictor stops being a score to chase and becomes the thing that picks which file goes out.

What the predictor actually reports

Versely's Virality Predictor takes a video and returns an interactive dashboard covering virality potential, engagement, attention, audience response, retention risk, hook strength and creative performance. You start an analysis from a video that already exists as a file — a confirmed upload or a completed generation — and you can re-open a finished dashboard later rather than re-running the analysis.

It reaches Versely users through the MCP connector, which is how the predictor and the rest of the toolset get driven from a chat client rather than the app. That matters for the gate specifically, because a gate is a step in a loop, and a loop you can run from the same place you assembled the cut is a loop you will actually run.

Three things it is not, all of which get confused with it:

Tool	Input	Question it answers
Virality Predictor	Your own video file, unpublished	Which of my cuts is stronger?
analyze_trend	A published social post URL	Why is someone else's post working?
review_generation	A generation plus its prompt	Did the model make what I asked for?

Analysing a viral video or post is the second row — it takes a public link and returns a viral score, hook analysis and recreation tips at 1 credit per analysis, and it is a research tool, not a QC step. The third row is prompt adherence, which is a completely separate failure mode. Reaching for the wrong one gets you a confident answer to a question you did not ask.

Why the absolute number is the weakest part

A prediction model scores a video against whatever population it was trained to generalise over. Your account is not that population. A cooking channel with 400 engaged subscribers and a B2B software account with 40,000 disengaged ones will produce videos that read identically to a model looking only at the file, and behave nothing alike on publication.

The scores also compress badly at the top. Once a cut is competent — hook lands, captions readable, pacing tight — the difference between two competent cuts is a small delta, and small deltas on an absolute scale invite exactly the wrong behaviour: fiddling with a cut for another two hours to move a number that was never anchored to your distribution in the first place.

The differential does not have that problem. If cut A and cut B are the same video with one deliberate change and B reads better on hook strength and retention risk, that is a claim about the change, not about the video's destiny. The model's calibration error mostly cancels because it applies to both cuts equally.

The gate: two cuts, one variable

The whole procedure:

1. Finish one cut properly. Not a rough assembly — the one you would ship if nobody stopped you. A gate comparing a finished cut to a sketch will always pick the finished cut and teach you nothing.
2. Change exactly one thing. Not three. The list below is the useful set.
3. Run the predictor on both. Same tool, same day, same settings.
4. Ship the winner. If the two read the same, ship whichever is cheaper to produce again — that is real information too, because it means the variable you tested does not matter for this format and you can stop testing it.
5. Log the pair. Which cut won on the dashboard, and which cut you shipped.

What to hold constant and what to vary:

Hold constant	Vary (pick exactly one)
Subject, offer, call to action	The first 1.5 seconds — cold open vs. context line
Voice track and script	Caption style or caption timing
Aspect ratio and resolution	Where the first cut lands
Music bed and levels	Whether the product appears before or after the hook
Total runtime	Opening shot: face vs. hands vs. product

The single most productive variable is the opening. Almost every difference the predictor reports on hook strength and retention risk traces back to the first second or two, which is also the cheapest part of a video to rebuild.

Building the two cuts without paying twice

The gate only works if producing a second cut is cheap, otherwise nobody produces one. In the editor, that is what the preview pass is for: edit_video with preview: true renders a free 480p version subject to a short per-user cooldown, and the charged export happens once, on the cut you confirm. So the honest shape of a two-cut test is: iterate both candidates in preview, decide, then export the winner — how previews and the final export are charged lays out the billing.

One caveat that matters for the gate specifically: the predictor takes a video that already exists as a file, so whichever candidates you feed it have to be real renders. Nothing here is free in the sense of costing nothing — the editor's 480p preview pass is the only zero-credit operation on the platform, and it carries that cooldown. Budget the gate as one analysis pass per candidate plus one export, and it stays proportionate to the cost of the video itself. Quality per credit is the wider version of that arithmetic.

Calibrating the gate against your own account

The gate has one job on day one — pick a cut — and a second job that only appears after about ten uses: tell you whether the predictor's ranking correlates with your account's actual results.

Keep a two-column log. Column one: which cut the dashboard preferred. Column two: how the shipped cut actually performed, pulled from your own numbers via social performance in the agent. You are not checking whether the predicted score matched the real view count — those units are unrelated. You are checking whether, on the occasions you shipped the cut the predictor did not prefer, it underperformed your median.

After ten or so pairs you will know one of three things: the predictor's ranking tracks your account (use it as a tiebreaker with confidence), it is uncorrelated (keep it as a cheap sanity check on hook strength and stop weighting it), or it is inverted for your niche (genuinely useful information, and rarer than people assume).

What it does not know, and what to check instead

The predictor reads the file. It cannot see posting time, caption copy, the first comment, thumbnail choice on platforms that use one, or whether you posted three things that week or none. It also cannot see conversion — a video can be structurally excellent at holding attention and still sell nothing, which is the distinction virality versus conversion is about.

Run it as one gate among several rather than the only one. The pre-publish sequence that actually catches problems is: prompt-adherence check on the generations, then a structural check on the assembled cut, then the two-cut comparison, then publish. Checking a video before you publish it covers the middle step, and a detailed breakdown of a video — style, per-timestamp beats, on-screen text, optional transcript — is what you run when the predictor flags retention risk and you need to know where.

FAQ

Should I keep re-editing until the score goes up?

No, and this is the failure mode the gate is designed to prevent. Once you are optimising against the number rather than choosing between two real alternatives, you have lost the thing that made the comparison meaningful — the shared baseline. Two cuts, one variable, one decision, ship. If both cuts read the same, that is your answer: the variable does not matter here.

How is this different from asking the agent to analyse a viral video?

Different input and different purpose. analyze_trend takes a URL to something already published — usually someone else's — and explains why it is working, with recreation tips, at 1 credit per analysis. The Virality Predictor takes your own unpublished file and reports on attention, hook strength and retention risk. One is research before you write; the other is a gate before you post.

Can I run the gate on a 480p preview instead of a full export?

The predictor needs a video that exists as a confirmed upload or a completed generation, so whatever you analyse has to be a real rendered file. The practical consequence is that you decide how much resolution to spend before you gate, not after — and since the comparison is between two cuts rather than against an absolute threshold, both candidates should be rendered the same way so the comparison stays clean.

What if I only ever make one cut of anything?

Then the gate does not apply and you should not pretend it does. The minimum viable version is to rebuild only the opening two seconds as a second candidate and compare those — same body, same ending, different first beat. That is a fraction of the work of a second full cut and it targets the variable that moves hook strength more than anything else in the edit.