Deadlines You Can Docket Against

Signa Research · Version 1.1 · October 2026

​

Abstract

Most trademark data errors cost analysis quality. Deadline errors cost the trademark: a missed renewal or maintenance filing does not degrade a registration, it cancels it. Signa computes these deadlines (renewal cycles, declarations of use, grace periods, restoration windows, and opposition periods) from statutory rules, with every rule citing its legal sources and the full rule set published through the API for inspection. The rules covered 22 jurisdictions when the evaluation ran. Current coverage (October 2026): maintenance rules for 30 jurisdictions, the international registration’s renewal for a Madrid designation of any other Madrid member, and 48 opposition-window rules; see the deadline-rules guide. This study measures those computations against the register itself. We froze a sample of 31,547 registrations across ten trademark offices, then a tenfold expanded same-seed sample of 306,896 (a strict superset of the first, drawn with the same seed), and compared our computed deadlines against the dates offices publish on their own records, against 27,562 renewal and maintenance filings that actually took place, and against 34,132 real opposition proceedings. The engine does not guess. Where a record does not carry the input the statute requires (three documented kinds of record) and the office has not stated an expiry to anchor on, it says so, with the reason, instead of computing a date. That policy lives in the product and is applied identically in the evaluation, so the population the engine is scored on is exactly the population it claims to compute. Every comparable record in the study is either verified or declared: 99.68 percent of 29,295 are computed and match the office’s own published date exactly, or are explicitly declared as requiring the office’s date. On the records the engine computes (26,800, or 91.5 percent of the comparable population), the pure statutory computation, with the office’s date withheld, matches the office’s published date in 99.65 percent of cases, 99.82 percent when weighted by how often each kind of record occurs in production. The schedule the API actually serves, which anchors on the office’s stated date where one exists, reproduces that date for 29,292 of 29,295 records (99.99 percent); because that number uses the office’s date as an input, it describes what customers receive rather than proving the rules on its own. Every disagreement was investigated and classified by cause; 95 records disagree after the declared kinds are set aside, and the unexplained residual remains 3 records. The study also worked in both directions: it caught and fixed defects in our own rules, each published with results from before and after the fix, and it identified 311 records classified as register-data errors, with per-record evidence, where the register, not the computation, carries the wrong date. This is a first-party evaluation: Signa selected the metrics, wrote the evaluator, corrected the system under test, and classified the disagreements. It has not been independently audited. The artifacts (frozen manifests, samples, events, oppositions, and per-record results) are published at github.com/signa-so/research so any reader can check the work.

​

Results at a glance

How to read the table: the first two rows score the statutory computation on its own, with the office’s date withheld; “declared” means the engine stated that it needed the office’s date rather than guessing. The row on the schedule the API serves is a description of what customers receive, not evidence: it anchors on the office’s own date, so agreement there is close to circular by construction. For continuity with version 0.91, which scored the engine’s guesses on the declared kinds against it: full-population exact agreement under that older framing was 96.08 percent of 282,393 comparisons at expanded scale. Version 1.1 refreshes every figure and carries two corrections, a scoring error in our evaluation tool that understated the served schedule and a withdrawn Swedish rule finding; the report’s changelog lists every move. Correction (4 October 2026): this page first gave the served-schedule filing figure as 93.2%. That run predated an October 2026 engine change that stops projecting a renewal term past an office-stated expiry that lapsed with no renewal on record, reading WIPO’s renewal of the international registration as that record where IP Australia did not update a Madrid designation. Re-measured on the released engine it is 92.7%. The drop is almost entirely Australian Madrid designations for which the evaluation data holds no WIPO renewal evidence (see the report, sections 5.3 and 7). No other figure moved.

​

What the study found

1. The statute and the register audit each other. Where a computed deadline disagreed with the register, investigation attributed the disagreement to the register more often than to the computation: 311 records classified as register-data errors, with per-record evidence, against no further rule defect identified among the investigated residuals. Computing deadlines from the law catches register errors that a system echoing stored dates would repeat.
2. Verification improved the product, in public. The study surfaced defects in our own rules and data handling. Each was fixed, tied to its statute, and published with agreement measured before and after. No correction was accepted on empirical fit alone; each required a statutory or documented-data-source justification.
3. The engine says when it cannot know. Three kinds of record do not carry the input the statute needs (pre-1996 Australian and pre-1999 Singapore filings under repealed cadences, and Madrid designations with no international-registration anchor). Version 1.0 makes the engine decline those with a stated reason instead of guessing, resolves Madrid designations through the WIPO parent registration where one exists, and scores itself on exactly the population it claims to compute.
4. Deadlines are computed fresh, never stored. Every correction applied to every record instantly. The frozen evaluation runs on every code change and now also pins the opposition cells, so a change that moves even one date in the sample blocks release until it is re-verified. In August 2026 the rules package was also put through mutation testing: 2,946 mutants, every one killed or classified.
5. You can check the rules yourself. Every deadline rule, with its legal citations and the date it was last verified, is available through the API, and any deadline in the study can be recomputed with an API key. See the deadline rules guide.

​

Scope and limitations

For offices not yet modeled, the API states that plainly rather than guessing. Current coverage (October 2026): maintenance rules for 30 jurisdictions, the international registration’s renewal for a Madrid designation of any other Madrid member, and 48 opposition-window rules; see the deadline-rules guide. Opposition verification is strongest where the underlying data is cleanest, and the report documents where it is bounded by data quality rather than by the rules. Ground truth is the register itself, which contains errors; the report treats that honestly in both directions rather than assuming either side is right. The full report contains the complete methodology, per-office tables, statistical protocol, and every limitation stated plainly.