Skip to main content

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.

​
What monitoring does

Signa monitoring turns ingestion into a stream of customer-relevant events. Every record we store passes through a watch evaluator on the same sync that indexes it; matches produce immutable Alert rows and (optionally) push deliveries to your webhook endpoint. By the time a new mark is searchable in our index, your watch alerts have already fired. The platform was designed around four things our customers told us mattered most:
  • Coverage. 21 international offices, 24 jurisdiction-specific opposition-window engines, and a deadline rules engine that knows the difference between USPTO Section 8+9 and DPMA’s end-of-month rule.
  • Latency. Alerts are produced inside the same sync run as the data — not minutes later by a separate job that scans for changes.
  • Faithfulness. Alerts snapshot the trademark version at evaluation time. They do not change. Your audit trail is yours, not ours.
  • Operability. Webhooks are signed (Standard Webhooks), retried with exponential backoff, auto-disabled after sustained failure, and rotatable with a 24-hour overlap.

​
The five watch types

A single query shape covers every monitoring use case. The watch_type field tells the evaluator which match dimension to optimize for; the query.match object carries the type-specific descriptor.
TypeUse caseMatch descriptor
markTrack a specific mark you own (renewals, opposition windows, status drift).{ trademark_id: "tm_..." }
portfolioWatch every mark in a saved portfolio at once.{ portfolio_id: "ptf_..." }
ownerTrack a competitor by entity.{ owner_id: "own_..." } or { owner_name: "Acme" }
classWatch new filings in a Nice class (or set of classes), optionally by jurisdiction.{ nice_classes: [9, 42] }
similarityConfusingly-similar mark detection — the CompuMark replacement.{ reference_mark: "ACME", strategies: ["phonetic", "fuzzy"] }
All five compile to a single query DSL — see the Watches guide for the full schema, and VAL-PRODUCT-001 for the parity contract.

​
How the pipeline works

ingestion sync ─► trademark_changes ─► watch evaluator ─► watch_alerts (immutable)
                                                            │
                                                            └─► event_outbox ─► SNS ─► SQS
                                                                                       │
                                                                                       └─► webhook dispatcher
The evaluator runs per-watch, per-office, with a 15-minute lease so crashes are tolerated. Replay (operator-only, POST /v1/watches/{id}/replay) bumps the evaluation_epoch and forces re-evaluation of every watched office on the next sync.

​
What you get

​
Where to start