Source Methodology

Last updated: October 15, 2026. Companion to the editorial policy. How facts on TTK Testing Wiki are gathered and dated.

Primary sources (highest first)

1. Roblox experience listing for TTK Testing — title strings (e.g. SERVERBROWSER), maxPlayers, public update wording. Rechecked on money-page refresh dates (October 15, 2026 on the current pass).
2. In-session observation — controls, UI labels, match flow a writer can see while playing. Used for beginner/controls/weapons framing, not for inventing hidden damage formulas.
3. Public code aggregators — cross-check only. If they disagree with the live game or show nothing redeemable, we keep codes at Active: none.

Secondary / not enough alone

Unaudited Discord pins, TikTok “new code” clips, and third-party wikis without a check date are labeled reported or ignored. They are never treated as studio documentation.

What “Checked” means

Checked is the date we refreshed the comparison against primary surfaces and updated on-page labels. It does not invent a redeem that did not happen.

October 15, 2026 codes pass (summary)

Active: none — honest empty state. Mid hubs (weapons, controls, loadouts) keep confirmed-vs-evaluate language rather than fabricated TTK sheets.

Dating and maintenance

Codes, updates, and home snapshot lines carry a visible Checked date when refreshed. When listing data changes (title, player cap), home and codes update first. Sitemap lastmod should move with those refreshes.

Disputes

Email hello@ttktesting.com with evidence URLs and dates. Related: About, Ads, Privacy.

Minimum evidence for Active codes

At least one primary surface (official listing/dev post) or two independent dated lists agreeing a string still redeems — and no stronger dated expiry. When none meet the bar, Active stays empty.

Weapons evidence

In-session feel notes and UI names are allowed. Spreadsheet DPS without a reproducible method is not promoted as fact on this wiki.

Reproducibility

Another editor should be able to open the Roblox listing, match our home snapshot lines, and understand why codes say Active: none. If they cannot, the page needs a clearer note.

Primary surfaces for TTK Testing

1. Roblox experience listing (title strings such as SERVERBROWSER, maxPlayers, update wording) on a named date.
2. In-session UI: controls labels, weapon names as shown, server browser text.
3. Official creator channels only when verified on official links.

Codes methodology (Active: none is a result)

When the official surface shows no redeemable codes on the check date, codes publishes Active: none. That negative result is first-class evidence — better than inventing rumor strings to match competitor word counts.

Weapons & loadouts sourcing

Prefer evaluation methods (recoil readability, situational roles, confirm-vs-evaluate framing) over fabricated TTK spreadsheets. Community sheets without a primary surface remain Reported or omitted.

Timezone & reproducibility

Checked stamps use Asia/Shanghai unless a citation carries its own offset. Another editor should be able to re-open the Roblox listing the same day and agree that Active is still none — or document the change.

Hierarchy

1. Live listing + in-session UI.
2. Verified official channels.
3. Dated reputable writeups.
4. Undated social — never sole Active proof.

Worked negative-result example

On a check date where the listing shows SERVERBROWSER-style title text and no code redeem UI, and in-session play finds no codes panel, the methodology output is Active: none — even if three undated TikToks claim otherwise. Those TikToks may be mentioned as Contested noise; they do not become Active rows.

Weapons sheet handling

If a community sheet lists numeric TTK values without a studio primary source, we either omit the numbers or label them Reported beside an evaluate-method section. We do not launder them into “meta” titles.

Change log habit

Material trust expansions (such as this October 15, 2026 pass) update the Last updated line. That is separate from a codes audit unless the listing also changed.

October 25, 2026 — grades, how often we re-check, and the verify page

This section was added on October 25, 2026. It is the methodology page's own statement of the source ladder. The matching player-facing page is how we verify. Read both. This page is the standing rule. That page is the pass that applied the rule to codes, Discord, controls, the player cap, and updates on October 25, 2026. The editorial policy says what we refuse to print even when a lower-grade source is loud. If a sentence on a guide cannot survive the table below, it does not belong on the guide. Mail hello@ttktesting.com when you find one that slipped through. The contact page explains the evidence a correction needs.

Source grades

Grades are a ceiling. A claim may use the grade it actually has. It may not borrow a higher grade because the page would look thin without it. The October 15 ladder on this page already put the live Roblox listing first, an in-session check second, and public code roundups as cross-checks only. The table below does not delete that ladder. It names the games API as part of the live primary grade, because that is how the October 25 pass read maxPlayers, created, updated, visits, favorites, and the name field. It also gives the June 2, 2026 DevForum post its own grade, so a plan cannot be rewritten as a live menu.

Two primaries can both be true without being the same claim. The June post can say CQB PVP was in the game on June 2. The October listing can describe a 12-player deathmatch test. We print both, with both dates. We do not average them into a single mode name. That habit is the whole point of the grade column.

How often we check

We do not run a promise of the form "every N hours." Publishing a number like that would invent a schedule this small static site does not keep, and the editorial rules forbid invented numbers. What we do instead is date every pass we actually finish, and we re-open a page when one of the following is true.

• We are about to add or correct a sentence, so the primary surface gets a fresh read before the file is saved.
• A reader sends evidence that a title, an updated field, a control line, or a mode label moved. The contact page tells them how to send it.
• We schedule a named pass, the way October 15, 2026 and October 25, 2026 were named passes. A named pass re-reads the listing, the API record, and the DevForum post that the pass depends on. It does not re-litigate every lead.

The game's own description says the project updates weekly and sometimes daily. The June 2 post says a missed week is usually a large update rather than silence. Those sentences are about the studio's cadence. They are not our crawl frequency. They do mean a checked date can age quickly. A reader should treat a page as current as of its stamp, then confirm anything that would change a decision, such as a code or a mode name, on the official page. The updates page keeps the dated rows: created 2026-04-27, DevForum 2026-06-02, updated field 2026-10-23 UTC, and this site's October 25 check. New rows should be added when a later read disagrees. Old rows should stay, so the history of the claim is visible.

Codes are re-checked inside those same passes, and whenever a correction claims a string exists. The absence of a string is a result we record. We do not re-check by typing strings from other websites into a box the official description does not mention. Weapons are re-checked by asking whether a primary surface has started publishing numbers. Until it has, the weapon pages stay qualitative. Map names are re-checked by asking whether a primary surface has started publishing a roster. Until it has, we do not compile one from videos.

How this page and the verify page split the work

How we verify walks claim types one by one: codes, Discord, controls, the player cap, the title string, and modes. It is the page to send a player who asks "why is the code list empty?" This methodology page is the page to send a writer, including a future edit of this site, who asks "which grade is this sentence?" Each page links back here, and this section links there, so neither file is the secret copy. The October 15 material above remains the earlier statement of the same ladder. Use it for the history. Use the table in this section and the verify page for the October 25 grades.

Worked consequence. A competitor page that prints a close-range build, an expired code, or a roadmap date is a lead. The grade table says a lead can justify a new read of the Roblox page. It cannot justify copying the build, the code, or the date onto this host. Our builds page, expired-codes page, and roadmap page exist to show the method and the sourced plan language. They cite this ladder. They do not cite the competitor as a source of fact. If the official description later publishes a code, the codes page moves, the verify page's codes section gains a dated line, and this table does not need to change. The table is about grades. The pages are about what the grades allowed that day.

Last checked for this section: October 25, 2026. The primary surfaces named above are the same ones linked throughout the guide. A future pass should add a paragraph under this heading rather than rewrite the October 15 examples into the new date.