§ Regression log · public record
Confirmed errors. And the fixes we shipped for them.
Per R12 D-R12-21 (board memo 2026-05-18), every confirmed Etymolt error and the release that fixed it is published here, in lockstep with the fix. The page is the accountability surface for the cardinal posture (R12 D-R12-1): transparent, audited, falling toward zero. Sarah (General Counsel) pre-reviews each entry before publication.
Last updated · 2026-05-19 · Monthly publication cadence · Source-of-truth memo: /trust
Methodology
How an entry lands here
An entry is added when: (a) internal QC, an adversarial probe, a customer report, or a sample-based audit (R12 §3.4) confirms a defect that affected — or could have affected — a customer-facing verdict; (b) a regression-test fixture is authored against the defect; (c) the fix is shipped in a release tagged here. Findings that did not materially affect customer verdicts (internal-only defects, doc drift, infrastructure refactors) are logged in the internal change-log rather than this surface; the bar for publication is customer-impact potential.
Review cadence
Publication cadence is monthly per R12 D-R12-21. Sarah (General Counsel) reviews each draft entry before publication for: (i) accuracy of the description against the underlying incident; (ii) prohibited-vocabulary scrub (per R12 D-R12-1, no “0%”, “perfect”, “guaranteed”, “infallible”, “never wrong”, “always right” — also no over-broad cause-of-action language); (iii) the regression-test fixture is in the corpus before the entry goes live. The mandatory-review surface is intentional: a public regression log is one of the highest-stakes legal artifacts Etymolt publishes.
What gets redacted vs published
- Published: defect description, affected axis class, resolution, release tag, regression-test fixture identifier, customer-impact disclosure.
- Redacted: customer identifiers, individual verdict_ids that surfaced the defect (the customer-facing correction-notice protocol covers notification), and any vendor-side identifiers protected by an NDA with an upstream registry or data partner.
- Embargoed (rare): when the same defect is under active disclosure with an upstream registry, the entry is held until the upstream disclosure completes (typically 14-30 days). The hold is recorded in the internal log so the publication delay is auditable after the fact.
Recent regressions
Most recent first. Each entry is auditable against the release tag; every release tag corresponds to a public commit or a cron-tagged ingest run.
| Date | Description | Class | Resolution | Release tag |
|---|---|---|---|---|
| 2026-05-19 | USPTO bulk re-ingest schema repair via SQLite .recoverAn upstream USPTO schema rotation truncated the in-flight bulk re-ingest, leaving the local SQLite mirror with a corrupted b-tree. The fix used SQLite's .recover output stream to salvage indexed rows and re-applied the schema migration; the row-count floor (≥3.5M live rows) was preserved through the recovery. No customer-facing verdicts were issued from the corrupted state — the cron gate halted ingest before the mirror went live. | InfraTM | Bulk re-ingest restarted from the recovered checkpoint; schema migration applied; row-count gate re-asserted before live mirror promotion. | uspto-recover-2026-05-19 |
| 2026-05-19 | intl_search path-resolution fixThe international-search route resolved against an outdated jurisdiction-code table when the request omitted the optional jurisdiction parameter, defaulting to a stale alias rather than the current canonical code. Verdicts could surface a jurisdictions_consulted entry that no longer matched the per-jurisdiction Coverage Spec. Fix-forward: the path resolver now reads the canonical code from the live Coverage Specs table at request time and emits an INSUFFICIENT_SIGNAL if the requested jurisdiction is not in the active spec set. | TMInfra | Path resolver reads canonical jurisdiction codes from the live Coverage Specs table; alias table deprecated. | 10080f0 |
| 2026-05-19 | Domain axis P0 — reserved_names + tlds_consulted hardeningReserved-name guard did not catch IANA-reserved labels (example.com, test.net) or single-character SLDs (a.com, b.com), which surfaced as 'available' through the DNS-fallback path. tlds_consulted receipts did not always reflect the actual TLDs queried for a request. Fix-forward: reserved-name guard now blocks per RFC 2606 / RFC 6761 / ICANN gTLD Spec 5, with explicit per-name overrides for documented releases (x.com, q.com, z.com, et al.); tlds_consulted is computed from the live probe stack at verdict time. | Domain | Reserved-name guard implemented; tlds_consulted populated from live probe stack. | domain-axis-p0-2026-05-19 |
| 2026-05-19 | Sound axis P0 — advisory tier + non-ASCII INSUFFICIENT_SIGNALThe sound-symbolism and pronunciation axes were shipped on /v1/verify and the MCP path as if they carried claim-grade confidence; in practice, the deterministic phoneme-class rule set is English-derived and the pronunciation heuristic is a static consonant-cluster check. Non-ASCII inputs (CJK, Devanagari, Cyrillic, Arabic, Hebrew, diacritic Latin) were silently collapsed to ASCII rather than routing to INSUFFICIENT_SIGNAL. Fix-forward per R12 D-R12-7 + R13 Sound + Pronunciation Audit §8: both axes ship as ADVISORY (axes_confidence.sound_symbolism.advisory: true / axes_confidence.pronunciation.advisory: true), are excluded from the critical-axis confidence gate, and route non-ASCII inputs to INSUFFICIENT_SIGNAL with an explicit reason. | Sound | Sound + pronunciation axes ship as advisory; non-ASCII inputs route to INSUFFICIENT_SIGNAL on these axes; /v3/voice/hazard endpoint reserved for the full ElevenLabs + Whisper round-trip. | sound-p0-53b3ab1 |
| 2026-05-19 | Cultural axis P0 — sacred_names catalog addedThe cultural-screen axis did not surface a sacred-name appropriation flag for religious or culturally-protected terms. A candidate name carrying sacred-name signal (e.g. a Sanskrit deity name on a consumer-goods brand) routed through without a caveat. Fix-forward per the 2026-05-19 Cultural Axis Audit §3.7: a hand-curated sacred_names catalog now ships alongside the HurtLex lexicon and the disaster catalog; cultural_sources_consulted lists the catalog when consulted; verdicts carry a cultural caveat with the regional context. | Cultural | sacred_names catalog added; cultural_sources_consulted receipt populated; cultural caveat surfaces regional context. | cultural-p0-162b6bd |
| 2026-05-18 | Disclaimer surfacing — short-form rendered in long-form slotsTwo integrator surfaces (a downstream MCP host and a Claude plugin) were rendering the DISCLAIMER_SHORT one-liner where the full three-sentence canonical disclaimer was required. Per R12 D-R12-2, the verbatim disclaimer is mandatory on every verdict surface. The short form is permitted only in tight UI slots paired with a link to the full disclaimer elsewhere on the same page. Fix-forward: the API response now includes both disclaimer (full) and disclaimer_short fields with explicit usage notes; the integrator agreement was amended to require the full form on the primary verdict card. | Infra | API response carries both disclaimer fields with usage notes; integrator agreement amended; quarterly compliance audit (R12 D-R12-2) tracks remediation. | disclaimer-surfacing-2026-05-18 |
| 2026-05-17 | Famous-marks denylist — over-permissive class matchA famous-mark short-circuit was firing only when the candidate's inferred class matched the registered class of the famous mark. The famous-mark doctrine protects across classes; the class filter was creating false negatives on cross-class candidates. Fix-forward per R12 D-R12-8: the famous-marks denylist now short-circuits on the mark string regardless of class; the auto_famous Tier-2 catalog complements the legal-vetted denylist and surfaces at DUE_DILIGENCE (not BLOCKED) per the famous-marks deep-dive §10 recommendation. | TM | Famous-marks denylist short-circuits regardless of class; Tier-2 catalog ships at DUE_DILIGENCE. | famous-marks-2026-05-17 |
| 2026-05-15 | WIPO Madrid IR — truncated daily-delta ZIPThree consecutive daily-delta ZIPs from ftpird.wipo.int landed truncated, causing the WIPO Madrid IR mirror to silently skip ~4,200 IRs across the affected dates. Detection fired on the per-source row-count drift watchdog (R12 D-R12-13). Fix-forward: the recovery cron is in flight; the missing IRs are being back-filled from the next full-bulk window; the affected verdicts have been flagged for opt-in re-run per R12 D-R12-20. | TMInfra | Recovery cron in flight; affected verdicts flagged for re-run per the correction-notice protocol. | wipo-madrid-recovery-2026-05-15 |
Submit a finding
If you have a verdict you believe is wrong, or a class of inputs you believe Etymolt mis-handles, please file a finding. The triage path:
- GitHub Issues — file at github.com/etymolt/etymolt/issues with the verdict_id (if you hold one) and a description of the expected vs observed behavior. The regression label routes the issue to the QC triage queue.
- Email — for findings you would rather not disclose publicly, write to regressions@etymolt.com. Sarah (General Counsel) reads this inbox and triages within five business days.
- Opt-in re-run — if you hold a historical verdict and a finding here retroactively affects it, request a free re-run per the opt-in customer re-run feature documented on /trust#rerun.
Confirmed findings are published here on the next monthly cadence; the submitter is credited unless they request otherwise. Findings that do not meet the customer-impact threshold are logged to the internal change-log and the submitter is notified.