Seven of eight had not moved at all.

Before relying on a saved access result

Check when and how it was obtained. The repeat measurement below shows what stayed stable and what changed.

Same eight targets, same two controls, one mainland host. This time every host was requested three times with a bare command-line client and three times with the same client sending only a browser user-agent string.

Over a fortnight, seven of the eight returned identical codes. The refusals are a standing condition. They are not a bad afternoon. The row that moved is the enforcement-records host: it stopped refusing command-line clients and now answers both. Nothing about its content changed; what changed is which callers it admits. That is the whole case for re-testing rather than citing a snapshot: what drifts is not usually the data behind the door, it is the door.

The one that moved is the court enforcement host. On 8 August a command-line client got 403 there while a browser got 200, the classic shape of a host that turns plain scripts away. On 15 August the bare client got 200 on all three rounds. It stopped refusing.

What that means for an answer you saved last week

We went into this expecting to find drift, partly because we had just caught ourselves misreading a client-profile difference as a host changing between dates. The data says the opposite: on a seven-day horizon these hosts are boring, and boring is useful.

Two practical readings follow.

A refusal looked structural, not like a bad day. Over the one week I measured, seven of the eight sources repeated their baseline behaviour exactly, and the single change was a refusal that lifted. On that evidence, retrying the same tooling a few days later is unlikely to help by itself, but one week on one panel is the whole of the evidence.

But a source can quietly become more open, and nobody announces it. The court enforcement host went from turning scripts away to answering them, within a week, with no notice anywhere. Anything you built on “that source refuses automation” is now slightly wrong, and would have stayed wrong indefinitely if nobody re-measured.

This is the argument for repeating a measurement rather than publishing it once. A single-date panel, including our own from 8 August, tells you what happened on that date and quietly implies it generalises. Only the second run tells you which parts were stable and which were not.

What we changed in the method, and why

The original panel recorded a command-line result and a browser result in separate columns, which was the right instinct. What it did not do is treat the client profile as part of the finding. Earlier the same week we paid for that. We compared a bare-client result against a user-agent result from a different run and reported a host as having drifted between dates when nothing had drifted at all. That correction is documented on the entry-point page.

So this retest records the profile against every single cell. It also carries one extra reference row, for a host outside the original panel that genuinely does discriminate. Bare requests get 403, the identical request with a browser user-agent string gets 200, five out of five each way.

That row exists to keep the finding honest in both directions. User-agent discrimination is real, but on this panel it is rare: none of the ten hosts measured here behaved differently under the two profiles. Having caught ourselves over-reading one case, the corrective is not to assume it everywhere.

Boundaries: root paths only, one mainland vantage point, two dates. No search was performed and no record was retrieved. A 200 means the door opened. It does not mean the data behind it is complete or that a query would succeed. Both dates are single-session snapshots, so “unchanged” here means unchanged between two points, not continuously monitored.

Why this matters if you are buying from China

Most of what a buyer is told about official Chinese sources is undated. “That system is unreliable” and “you can't check that from abroad” circulate as permanent facts. This panel now has two dated points. They support a narrower statement: the pattern of which sources answer and which refuse held steady across a week, and one source relaxed.

When someone tells you a check could not be completed, the useful questions are which source, on what date, and with what client. All three are recoverable from a measurement like this one; none of them are recoverable from “the system was down”.

The panel's anchor source is the GSXT, the National Enterprise Credit Information Publicity System, the China company registry itself. Anyone who needs to verify Chinese company identity eventually depends on it, directly or through a reader on the China side. That is why its answer pattern is worth measuring on a date rather than asserting from memory. For China due diligence work, that means the honest citation is never "the registry is unreliable". It is this panel's row, with its date.

If it is not a bad day, waiting is not a plan. Two checks were unaffected by every status code on this page, because neither depends on those hosts being up. Check an 18-character code offline → It recalculates the check digit in your own browser. Search candidate registered names from an English name → Free, and it returns the registered Chinese name with its code.

Related: the 8 August baseline panel · six official registry entry points, six answers · five client profiles against the registry front page · how to search the registry once you are in.

The same rule, turned on our own newer measurements

The conclusion above is simple: a single availability snapshot expires. The same limit applies to every measurement this desk publishes, including the ones taken this month. On 21–22 August 2026 I ran a much larger measurement against the same kind of source, and it inherits the same shelf life.

The second row is more perishable than the first, not less. Availability changed for one host in two weeks; company records change continuously, and our own history measurement found that 41 of those 45 already carry a change record. A fill-rate figure describes the batch on its query date and nothing after it.

Which is why every table on this site carries the date it was queried, and why we would rather re-run a measurement than defend an old one. If you are citing a figure from here, cite it with its date. If the decision is expensive, ask us to re-run it. Raw records for both: china-official-source-retest-2026-08-22.json, per-company records kept on file, available on request.

Citing this

Archived copies, each with its own DOI, resolving independently of this site: Zenodo · Harvard Dataverse.

Quote or reproduce these results freely, including commercially. Keep both dates (8 and 15 August 2026), the vantage (one cloud host inside mainland China), the client profiles and the stated limits attached to them.

Currawong, “Seven days later: re-running the eight-source availability panel with two client profiles”, baseline 8 August 2026 and retest 15 August 2026, three rounds per profile from one mainland Chinese host with same-session controls. https://currawongweb.com/verify/china-official-source-retest/

@dataset{currawong_china_official_source_retest_2026,
  author    = {Bao L. Zhou},
  title     = {{Eight official Chinese verification sources re-measured after seven days, under two client profiles}},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.22004759},
  url       = {https://doi.org/10.5281/zenodo.22004759}
}

Machine-readable evidence, every host and round: the observation table (CSV, CC BY). It carries the baseline values, the per-round retest values under both client profiles, a changed flag and a user-agent-discrimination flag. The page states the finding, the file lets you check it.

If you re-run this from another network or date and see something different, we want to hear it. Corrections that survive checking get published here with attribution, including ones that contradict us. Browse all measured studies and methods in the research index.

This page reports connectivity observations on root paths. It is not legal advice, it is not a statement about any company, and it is not a claim about the completeness of any official database.