Data Quality & Trust

How Signa sources, verifies, and maintains trademark data

Signa syncs trademark data directly from official government registries. Records are normalized to a canonical schema, deduplicated, and kept current as offices publish updates. This page explains what you can expect from the data and where to look when questions arise.

Office coverage

Signa currently syncs data from production offices covering trademark records, with more planned. See Data Freshness & Coverage for the full per-office table, sync frequency, and planned offices.

Record counts are point-in-time totals from each registry. Use GET /v1/offices to see live statistics for each office.

Data freshness

Every trademark record carries a data_freshness object in the detail tier that tells you exactly how current the data is:

{
  "data_freshness": {
    "source_data_date": "2026-03-18",
    "source_format": "xml",
    "last_updated_at": "2026-03-18T04:00:00Z"
  }
}

Field	Meaning
source_data_date	The date the office’s data was current. For bulk publications, this is the publication date. For API fetches, this is the fetch date.
source_format	The upstream data format the office published (for example XML, JSON, or CSV), so you know what kind of source document backs this record.
last_updated_at	When Signa last wrote to this record. If this is significantly newer than source_data_date, the record was reprocessed without new office data.

Use updated_at on any trademark to see when Signa last touched the record, and source_data_date to see when the office published that data. For time-sensitive decisions (filing deadlines, opposition windows), always cross-reference with the official registry.

Verification guidance

Trademark clearance

When conducting a clearance search, Signa provides a strong starting point but should not be your only source. Recommended practice:

1. Search Signa for phonetic, fuzzy, and exact matches across target jurisdictions.
2. Cross-reference high-risk results against the official registry.
3. Check common-law sources separately (Signa covers registered marks only).
4. Document the search date and the source_data_date from each result.

Ongoing monitoring

For ongoing portfolio monitoring, Signa’s daily sync frequency is sufficient for most use cases. Schedule periodic pulls against the API to detect:

• Competitor filings of confusingly similar marks (re-run a search with filing_date_gte)
• Status changes on your own marks (Trademark History)
• Approaching renewal or declaration deadlines (the deadlines[] array on each trademark response)

Due diligence

For M&A or investment due diligence, use Signa’s batch endpoint to pull full detail-tier records for an entire portfolio, then verify critical marks (high-value registrations, marks in dispute) against official sources.

Signa normalizes data from public government registries. It does not replace legal advice. Status classifications, deadline computations, and entity resolution are provided as informational tools. Always consult qualified trademark counsel for legal decisions.

Known gaps

No data source is perfect. Here are the known limitations:

Area	Detail
Common-law marks	Signa covers registered and pending marks only. Unregistered common-law rights are not included.
Image search	Design mark similarity search (image-to-image) is planned. Currently, design marks are searchable by Vienna classification codes.
Attorney data (WIPO)	Madrid Monitor provides limited attorney/representative information compared to national offices.
Historical events	Some offices provide limited event history for older marks. Recent filings typically have complete event trails.
Office coverage	See Data Freshness & Coverage for the current list of production and planned offices. For time-sensitive decisions, always cross-reference with the official registry.

Reporting data issues

If you find a discrepancy between Signa and an official registry, we want to hear about it. Because Signa is API-first, you can report it through the same API you already use, no dashboard or email thread required. This is the fastest path for both people and AI agents.

Submit a data_issue to POST /v1/feedback with the fields that make it actionable without a follow-up:

• resource_id: the Signa record that is wrong (tm_..., own_..., and so on)
• field: which field disagrees, for example owner.name
• expected_value: what the value should be, per the official registry
• message: any context, such as the registry reference number or a link to the source
• request_id: optionally, the request where you saw it, so we see exactly what you saw

import { Signa } from "@signa-so/sdk";

const signa = new Signa({ api_key: process.env.SIGNA_API_KEY });

const report = await signa.feedback.create({
  type: "data_issue",
  resource_id: "tm_9f8e7d6c-5b4a-3210-fedc-ba9876543210",
  field: "owner.name",
  expected_value: "Acme Holdings LLC",
  message: "Assigned to Acme last year per USPTO reel/frame 9999/001.",
});

console.log(report.id, report.status); // fbk_...  open

What Signa captures. At submit time the server snapshots the referenced record’s current state (office, version, source-updated timestamp, status) and, if you passed a request_id, the matching request log into a read-only context object on the report. That evidence is preserved even after the next sync overwrites the record or the request log ages out, so your report never loses its context.

Following the status loop. Every report starts open, moves to acknowledged when we begin investigating, and lands on resolved with a resolution_note explaining the outcome. Poll GET /v1/feedback/{id}, or filter GET /v1/feedback by status, to watch a report progress. Reports are visible only to your own organization. Confirmed data issues are typically resolved within one sync cycle after a fix is deployed.

Prefer email? You can still reach us at [e-mail] with the subject line “Data Quality Report”. Include the trademark ID, the official registry and reference number, the fields that differ, and a link to the official source.