Deployment verification and provider retest
Prove the public implementation, compare before with after and recover interrupted runs safely.
Public verification is the retest gate
| Implementation mode | Action | Required evidence |
|---|---|---|
| Aetherion Project | Check deployment | A successful production deployment newer than Apply, plus the correct live route, HTML, indexability, canonical and visible task evidence. |
| External Website | I’ve published · check live or Check live page | The latest published package, a changed public fingerprint and the expected live content, metadata, canonical, schema and indexability. |
Scan now can also verify a limited set of eligible applied tasks automatically. Every route uses the same deterministic verifier and saves the individual checks in Action Center. A pass sets Ready to retest, not Verified.
Run the before → after comparison
Review Retest ready
Open AI Visibility and choose Retest ready · N. Only tasks with a current public verification pass are included.
Confirm the exact prompts and estimate
Aetherion repeats the original measured questions with the same provider method. Review the prompt fingerprint, task count, credit estimate and balance before approval.
Wait for retained evidence
Each after answer is stored beside the original before snapshot. A failed provider response is kept as evidence instead of being presented as a successful comparison.
Read the task outcome
Action Center displays the public verification and provider before → after evidence together so the implementation and measured result remain auditable.
The original baseline is preserved
A later retest still compares with the first retained before evidence for that task. Repeating a failed iteration does not quietly replace the baseline with a more convenient result.
Understand every outcome
| Outcome | Meaning | Next step |
|---|---|---|
| Verified | The completed after answer shows the required new brand or domain evidence compared with before. | The task closes as Verified; retain the evidence and continue monitoring. |
| Not verified | The provider completed the answer, but the required improvement was not present. | Keep the task at Ready to retest or reopen it for another content iteration. |
| Inconclusive | The selected provider answer failed or could not support a reliable verdict. | Review the failure and retry only after confirming the previous run and billing state. |
| Stale / blocked | The prompt, task, baseline or deployment context no longer matches the reviewed preview. | Reload AI Visibility and review the exact current context before starting a new billed operation. |
Recover an interrupted provider run
- Aetherion saves the operation as Running before the first provider request and assigns one recoverable run ID.
- A double click is blocked, and an identical run ID returns the existing operation instead of starting another provider call.
- After a refresh or lost connection, AI Visibility polls the same run and shows Running / recovering… while the result is unresolved.
- A clear validation error before the provider starts unlocks the form without creating a paid retry.
- An uncertain network or server error never starts an automatic paid retry.
Check Money Flow before a new run
If recovery expires without a confirmed result, inspect Money Flow and the stored Provider Run before approving another billed operation. Do not create a new run merely because the browser lost the previous HTTP response.
Open AI Visibility
Need project-specific help?
Open the private Help Center or create a support ticket with the affected project, route and request ID.