> ## Documentation Index
> Fetch the complete documentation index at: https://docs.signa.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Quality & Trust

> How Signa sources, verifies, and maintains trademark data

export const marksCovered = "~36M";

export const officeCount = 10;

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 {officeCount} production offices covering {marksCovered} trademark records, with more planned. See [Data Freshness & Coverage](/guides/data-freshness) for the full per-office table, sync frequency, and planned offices.

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

## Data freshness

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

```json theme={null}
{
  "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. |

<Tip>
  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.
</Tip>

## 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](/api-reference/trademarks/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.

<Warning>
  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.
</Warning>

## 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](/guides/data-freshness) 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`](/api-reference/administration/create-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

```typescript theme={null}
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}`](/api-reference/administration/get-feedback), or filter [`GET /v1/feedback`](/api-reference/administration/list-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 [support@signa.so](mailto:support@signa.so) 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.