Audit results

Each update produces a corrected Parquet candidate and then audits a random sample of its filing rows. The audit asks a simple question: does the timestamp in the candidate agree exactly with the timestamp reported by the SEC?

Collecting an SEC reference for every filing would require millions of requests. Random sampling gives a direct estimate of the disagreement rate at a practical collection cost. Targeted checks are also used to investigate specific risks, but they are kept separate from the random sample because they do not provide a population-wide error estimate.

How the audit works

For every update, the audit follows the same sequence:

1. Freeze the candidate Parquet file and record its checksum.
2. Draw a reproducible random sample of filing rows.
3. Save each sampled timestamp before collecting any new reference evidence.
4. Retrieve an SEC timestamp for each sampled filing.
5. Compare the two as exact instants.
6. Report the observed disagreement rate and a one-sided 95% upper confidence bound.

The primary SEC reference is <ACCEPTANCE-DATETIME> in the filing's SGML header. If that tag is absent, the audit uses the filing index's labelled Accepted value. Both SEC clocks are interpreted in America/New_York, called Eastern below. Request failures and missing values remain in the results; the audit does not replace them with easier cases.

An accession is one SEC filing, identified by its accession number. The random sample is drawn from Parquet rows, so the same accession can be sampled more than once if the data contain more than one appearance of that filing.

How timestamps are established before the audit

The processor can resolve many timestamps without making a new SGML or filing index request. The audit then checks a random sample independently.

Carried-forward evidence

The May 2024 SEC submissions archive used a consistent Eastern-clock convention. Timestamps established from that archive are carried forward by accession number, together with their provenance, when the same filing appears in a later update. A downloaded corrected Parquet already contains these established instants; users do not need the original 2024 archive or a separate reference database.

Only a previously supported instant can resolve a later raw clock. A provisional or unresolved interpretation cannot confirm itself.

Exact clock pairs

The same accession can appear with two different source clocks across ZIP snapshots, duplicate CIK records, or live JSON. The filing is resolved when there are exactly two clocks and both describe the same instant under the following assignments:

• interpret the earlier clock as Eastern;
• interpret the later clock as UTC; and
• require exact equality after timezone conversion.

For example, 08:01:07 Eastern and 13:01:07 UTC on a winter date represent the same instant. The calculation uses named timezones, so it handles daylight saving time and changes of date. A four- or five-hour difference by itself is not enough, equal clocks provide no timezone evidence, and unexplained differences remain unresolved.

No SGML lookup is required for an exact, uncontradicted pair. As a separate empirical check, all 1,544 pair-resolved rows in the original audit for which SGML was available agreed with the SEC header. We found no SGML counterexample to the pair rule.

Direct evidence already collected

An SGML timestamp collected during an earlier update can also be reused for the same accession. This is direct SEC evidence rather than another inference rule. When an SGML header has no acceptance timestamp, the filing index can establish the acceptance time or support a historical date-only value.

A timezone convention inferred for an entire live JSON response is retained only as a provisional working value. A single response can mix UTC and Eastern clocks, so a response-wide convention cannot establish ground truth or become an anchor for later corrections.

The timestamp methodology gives the complete evidence and provenance rules.

Result for the current update

The independently frozen 10,000-row sample was fully verifiable: 9,234 rows used SGML and 766 used the filing index. Two timestamps disagreed with the SEC reference.

Measure	Result
Candidate filing rows	27,272,863
Randomly sampled rows	10,000
SGML references	9,234
Filing-index references	766
Unavailable references	0
Timestamp disagreements	2
Observed disagreement rate	0.020%
One-sided 95% upper confidence bound	0.06294%

The observed rate is two disagreements per 10,000 sampled rows. The confidence bound says that, under the sampling model, rates above approximately 6.3 per 10,000 are not supported by this audit. It is an upper bound, not an estimate of how many errors remain and not the probability that the whole file is error-free.

Both disagreements had been inferred from a live-response-wide timezone convention:

Accession	Filing date	Candidate (Eastern)	SEC (Eastern)
0001172661-26-004193	2026-08-28	09:32:53	13:32:53
0001213900-26-095042	2026-08-28	12:10:02	16:10:02

The audit therefore improved the processing rule as well as measuring it. File-wide inference is now provisional, and direct SGML evidence corrects both sampled disagreements. Rechecking both saved 10,000-row samples against the repaired candidate finds zero disagreements. Those checks demonstrate that the known errors were repaired, but they are regression checks rather than a new independent estimate for the repaired file. A newly frozen random audit remains the release gate for that candidate.

The audit summary records the checksum of the independently audited candidate, and the discrepancy records retain the two SEC comparisons.

Additional high-risk checks

The two random-sample disagreements showed that some live JSON responses mix UTC and Eastern clocks. We therefore targeted response versions already known to contain both interpretations and collected SGML for every remaining provisional or unresolved accession in them. Repeating the selection until no new mixed versions appeared required three rounds of 10,738, 343, and 17 accessions.

All 11,098 SGML requests succeeded and included ACCEPTANCE-DATETIME; none needed filing-index fallback. SGML classified 11,044 distinct accessions as UTC and 54 as Eastern. Every live clock exactly matched its ZIP clock, confirming that equal ZIP and live values do not reveal which timezone the clock uses.

There were 11,228 observations because some accessions appeared in more than one archived response version. The Eastern observations were recent and clustered:

Filing period	Observations	Eastern	Eastern share
2023–2025	7,075	0	0%
2026	4,153	54	1.300%
At most 30 days before live retrieval	205	48	23.415%
31–90 days before live retrieval	759	6	0.791%
More than 90 days before live retrieval	10,264	0	0%

All 54 Eastern observations fall between August 27 and September 29, 2026; 45 occur on September 16, and 26 come from one live source URL. The Eastern cases span 15 URLs.

The “more than 90 days” group contains 10,264 observations of 10,147 distinct accessions filed from April 6, 2023 through July 1, 2026. All use UTC clocks. This is strong evidence for the UTC convention among older filings in this high-risk population. It does not test filings before April 6, 2023 or justify a universal rule for older SEC filings.

The targeted references identified 141 incorrect provisional predictions affecting 155 Parquet rows. After applying them, the candidate agrees with all collected references and the mixed-response queue is empty. The machine-readable summary, year table, age table, and final verification preserve the results and candidate checksum.

These checks deliberately focus on a suspected failure mode. They support the repair and help explain when live clocks use Eastern, but they do not replace the random audit or provide a population-wide error rate.

Historical date-only filings

The earlier release audit found 770 sampled filings whose SGML headers lacked an acceptance timestamp. Every filing index supplied an Accepted value. Seven contained an acceptance time and agreed exactly with the Parquet value. The other 763 were historical date-only records from January 7, 1994 through May 14, 2002.

For all 763, the filing index and the original 2024 source agreed on the date. Some later raw clocks represented midnight Eastern as 04:00:00 or 05:00:00 UTC. The processor had interpreted 52 of those clocks as Eastern a second time, creating an exact timestamp discrepancy even though the filing date remained correct. Exact Eastern/UTC pair matching now resolves these cases and stores date-only values as midnight Eastern.

Midnight is a storage convention for these records, not evidence that the SEC accepted the filing at midnight. Their provenance must continue to distinguish them from observed acceptance times.

Statistical interpretation

When an audit observes no disagreements among \(n\) independently sampled and verifiable rows, its one-sided 95% binomial upper bound is

\[ p_U = 1 - 0.05^{1/n}. \]

When disagreements are observed, the audit reports the corresponding exact binomial upper bound. The sampling fraction is small, so the binomial result is a conservative approximation to sampling rows without replacement.

The bound applies to the frozen candidate and sampling population named in the audit artifacts. It should not be transferred to a repaired candidate, a small evidence subgroup, or rows without a verifiable reference. Agreement means agreement with SEC metadata under the stated Eastern interpretation; it does not independently prove that the SEC source itself is correct.

Reproducibility artifacts

The sample identifiers and predicted instants are saved before reference collection. Row-level outcomes retain source URLs, retrieval times, failures, and comparisons. A seed alone is not sufficient to reproduce an audit from a different candidate, so the artifacts also record the candidate checksum.

The dated September 30 release retains its original audit files:

• sample identifiers;
• row-level outcomes; and
• the release summary and manifest.

The supplemental historical comparison is available as row-level CSV with a summary and checksum.

The update workflow explains how to run the same SGML-first, filing-index-fallback audit for a new candidate.