1. Decide which change the evidence must establish
The official announcement establishes a published change: removal of the five-hour cap for verified Ultra accounts. Current help explains eligibility and temporary limits, without disclosing the decision algorithm. Starting removal, one account qualifying and an algorithm changing are different propositions.
Our question is what public evidence supports, rather than how to guarantee approval. We distinguish policy text, dated document metadata, contextualized personal reports and our analysis. No account was accessed, verification submitted or capacity experiment performed.
2. A timestamp identifies a document state, not its complete history
We read Article JSON-LD in official HTML, separating publication, modification and retrieval. Singapore times below are UTC plus eight hours; October 30 abroad and October 31 in Asia need not indicate separate announcements.
| Evidence, 2026 | UTC | Singapore |
|---|---|---|
| Ultra document dateModified | Oct 30, 17:11:53 | Oct 31, 01:11:53 |
| Official post publication | Oct 30, 17:29:07 | Oct 31, 01:29:07 |
| Identity document dateModified | Aug 11, 20:14:18 | Aug 12, 04:14:18 |
A publisher's dateModified does not establish when each sentence first appeared or when a process launched. An earlier identity document also cannot establish inherited Ultra eligibility. Reconstructing wording requires readable versions.
An April 16 capture of official identity help already describes the Persona document process. That establishes presence by the capture date, not its launch. The historical identity page does not substitute for an Ultra policy comparison.
3. Separate six easily confused processes
| Process | Published purpose | What it cannot substitute for |
|---|---|---|
| Automatic Ultra check | Removal of the relevant temporary cap. | A universal verification credential. |
| SMS phone check | Access to a phone number. | Proof of Ultra eligibility. |
| Payment-method check | A payment confirmation prompt. | A published Ultra application. |
| Persona identity/business check | Selected capability, integrity or compliance checks. | A guaranteed cap-removal mapping. |
| CVP access grant | Security-work eligibility and controls. | A subscription-usage decision. |
| API-credit eligibility and linking | A benefit and its receiving organization. | Ultra verification; claiming credits is a separate entitlement process. |
Several can affect the same account. Their full internal relationship is undisclosed. A shared word such as verification does not establish a shared backend status.
4. Separate disclosed factors from unknown thresholds
Ultra's specific explanation names account and payment history among the factors. Checking and cap removal happen automatically; checkout phone verification is explicitly separate. This describes the public rule, not a reproducible scoring formula.
| Question | Supported | Missing evidence |
|---|---|---|
| Does an older account guarantee approval? | History is a stated factor. | Age threshold and other conditions. |
| How many payments are needed? | Payment history may matter. | Count, amount and weighting. |
| Can status ever be withdrawn? | The document describes the effect of approval. | Reassessment and withdrawal conditions. |
| How long remains? | Some accounts retain temporary limits. | Published deadline and individual progress. |
No published threshold found does not mean none exists internally. Automatic does not mean instantaneous at purchase. These findings cannot become an account-aging or payment recipe promising approval.
5. Why phone, payment and Persona are not interchangeable
The SMS guide concerns receiving a code; payment help concerns a payment prompt; identity help describes Persona, physical identification and a possible selfie. Each provides a different observable result.
Completing an identity check before losing a cap would not alone establish causation. Rollout, payment settlement or another state update could coincide. Establishing a necessary or sufficient relationship requires an explicit official mapping or evidence capable of excluding alternatives.
Conversely, automatic Ultra checking does not promise freedom from identity checks elsewhere. Identify a prompt's purpose and use the corresponding official flow. Do not send credentials to a third party selling guaranteed removal.
6. Three published intervals are not an Ultra deadline
Seven days for API credits is a new subscriber's eligibility condition. Seven business days for CVP is a review-decision or information-request target. The 24-hour payment interval concerns a reminder. None supplies an Ultra processing commitment.
A timing claim needs a start, an end, calendar or business days, and a distinction between target and guarantee. Without those definitions, waiting reports cannot be compared reliably.
7. What a before-and-after account report can establish
Vanja Petreski's direct account describes an Ultra label with a session bar, followed by disappearance of web and CLI five-hour indicators and a confirmation email. The email reportedly arrived 44 minutes after article publication. That interval starts at publication, not signup, purchase or review initiation; it is not a general verification-duration measurement.
The longitudinal observation is useful because it records one account in two states. It lacks the internal review start and complete input factors. It supports asynchronous rename and cap removal, without estimating approval rates, average waits or hidden thresholds.
In the Ultra discussion, one commenter reports removal while another explicitly reports an Ultra label with the cap remaining. Another describes a previous CVP face check without the new verification status. A rename-thread reply reports verification without submitting identification. These are public self-reports; account records, emails and payment histories were not independently authenticated.
They challenge claims that everyone is waiting or that an identity check guarantees approval, without proving a universal exemption or formula. Our collection date is October 31, 2026; unavailable exact posting times are not invented. Self-selected posters are not a random sample.
8. Agreement across publications is not independent replication
Magica and MACCUS preserve qualifications, but much of the substance comes from the same announcement and help. Repeated coverage does not create additional account observations. Republishing Vanja's update does not create additional experiments.
A public product explanation offers naming and usage-window context, not a support decision for an individual. Where direct X access failed, official embed data checked announcement identity and time, while a public mirror supplied the long-post tail. A mirror is a carrier, not an independent witness.
Search snippets and later article updates can represent different versions. Check retrieval dates and actual text before interpreting a missing explanation as a policy contradiction.
Distinguish original writing, independent source access and observations of different accounts. An original analysis may interpret the same announcement without adding eligibility outcomes. Match the evidence type to the question rather than treating publication count as sample size.
9. Build evidence that can establish a rule revision
- Record official URL, language, retrieval time and product scope; retain the relevant body.
- Separate announcement publication from dateModified. Compare the same clause's meaning.
- Preserve both versions and content hashes. Dynamic HTML changes do not automatically mean policy changes.
- Open archived bodies and inspect capture timestamps; a nearest result may postdate the requested date.
- Log account-state changes separately from document changes, labeling remaining inference.
Our Ultra/Max archive-body requests returned 429, leaving no readable before-and-after policy pair. Index and nearest-capture metadata cannot fill that gap. Current policy and a dated announcement are established; a complete revision history is not.
If only an account meter changes, initially classify it as an account-state observation. A comparable clause difference supports a published revision. Unchanged wording with gradual activation is consistent with rollout, but does not identify the internal cause without server evidence.
10. Check current status without inventing an unlock procedure
Confirm the correct personal Ultra account, then open Settings → Usage. The published indicator is disappearance of Current session. Consider the fully loaded page and weekly allowance; a plan label, rename email or third-party status line alone is insufficient.
For official support, retain the time, plan, relevant label and a redacted interface image. Specify whether the issue is the temporary cap, identity or payment. Keep session cookies, complete card details and identity documents out of public discussions; enter formal checks through the official account.
No published acceleration procedure does not establish that support can never help. Verify anomalies through official channels and reject guaranteed-approval claims.
11. What would change the conclusion?
An official mapping or deadline would resolve some unknowns. Dated historical bodies could identify a wording revision. More checkable longitudinal reports could illuminate rollout differences, with sampling bias disclosed.
Present evidence supports automatic published eligibility, distinct verification purposes and a separation between individual activation and global policy. The internal formula, complete history and any particular account's outcome remain separate unknowns.
Reviewable material: sources, evidence ledger, timestamps and content hashes.