Skip to main content
An attestation is a filable, monthly record that a watch was actually evaluated during a period, with the office-data horizon it covered and the outcome (including the negative outcome). It is the artifact a law firm keeps on file to show that a monitoring instruction was in force and was executed. 
curl "https://api.signa.so/v1/watches/wat_.../attestation?period=2026-06" \
  -H "Authorization: Bearer $SIGNA_API_KEY"
Requires an API key with the portfolios:manage scope. The period is a UTC calendar month. Omit period to get the previous (most recently closed) month.

​
What it proves, and what it does not

An attestation certifies that evaluation occurred against the stated data horizons: which query was in force, how many times it ran, the sync runs it consumed, and the office-data coverage timestamps it reached. It does not certify that every relevant mark was surfaced. Recall is bounded by connector coverage and the match strategy you configured. This is a deliberate bright line: the attestation is evidence of diligence and process, not a guarantee of exhaustive detection. The statement field states this in plain language, and the wording is subject to founder and counsel review.

​
The “no alert” versus “not looking” model

The whole point of an attestation is to make silence provable. If you received no alert for a period, the attestation shows whether that silence means “we looked and found nothing” or “we were not looking”.
  • We looked and found nothing. evaluations_count is greater than zero, changes_evaluated shows the volume assessed, match_count is 0, and there are no gaps. That is a real negative result you can rely on.
  • We were not looking. The period carries a gaps[] entry (see below), the office is marked no_evaluations (a supported office with zero evaluations in the period, disclosed with a full-period gap and no coverage claims), or the office is marked unsupported. Silence never implies coverage that did not happen.
If the watch is paused or disabled at the moment you fetch the artifact, the response carries watch_status_at_generation so the current state is on the record. Pause history within the period itself is not reconstructable in this version (there is no status audit trail yet); that is a documented limitation.

​
Per-office fields

Each entry in offices[] reports one office in the watch scope.
FieldMeaning
statusevaluated (a supported, ingested office with real claims), no_evaluations (a supported office with zero evaluations in the period: zero counts, no coverage claims, and a full-period gap), or unsupported (see below).
evaluations_countNumber of successful evaluations during the period. A failed evaluation is not counted as an evaluation.
changes_evaluatedChanges evaluated against your query this period (candidacy volume). This is the number of candidate changes assessed, not the size of the whole office corpus.
match_countCandidate changes that matched your query.
alerts_emittedAlerts produced from those matches.
coverage_from / coverage_throughThe office-data timestamps the watch was current through at the start and end of the period. This is office-data time, not wall-clock time.
coverage_basisWhich signal the coverage timestamp came from: source_dates (strongest), date_range, or run_completed (weakest).
gapsDisclosed intervals where coverage fell behind (see below).

​
changes_evaluated is candidacy volume

changes_evaluated is the count of candidate changes assessed against your query, summed across the evaluations in the period. It is not a claim about how many records exist at the office. It tells you the volume of change the watch weighed before deciding there was nothing to alert on.

​
Coverage gaps

gaps[] is where honest degradation is disclosed. A gap is an interval in the period where the office-data coverage the watch had evaluated through fell behind the internal freshness target for that office. Gap disclosure is permanent: it stays in the artifact for that period even after coverage recovers, because it is a fact about what happened. 
"gaps": [
  {
    "from": "2026-06-11T06:00:00.000Z",
    "through": "2026-06-20T06:00:00.000Z",
    "reason": "office_lagging",
    "resolved": true
  }
]
  • reason: "office_lagging" means coverage was stale beyond the office target for that interval.
  • resolved: true means coverage caught back up within the period. resolved: false means it was still behind at the period boundary.
In this version, gaps cover coverage-staleness only. Evaluations that failed outright do not write a receipt, so they are not reconstructed as gaps here. The evaluation_failed reason is reserved for a future version. Two special gap shapes to know:
  • A supported office with zero evaluations in the period is marked no_evaluations and carries a single gap spanning the whole period. It is resolved: true only if evaluation demonstrably resumed after the period.
  • Evaluations recorded before coverage snapshots existed cannot state what office-data horizon they covered. They are disclosed as incomplete coverage evidence (a gap with a null coverage_through), never presented as covered.

​
Unsupported offices

If a watch is scoped to an office Signa does not currently ingest, that office appears with status: "unsupported" and no evaluation claims at all. Signa will never render a clean, zero-alert attestation for an office it does not cover, because that would read as “we looked and found nothing” when the truth is “we do not cover this office yet”. If every office in the scope is unsupported, the endpoint returns 422 attestation_unsupported_scope rather than an empty artifact.

​
Configuration changes and the fingerprint

The query_fingerprint is a stable hash of the watch query and trigger events. Its fingerprint_basis is current_configuration: it describes the configuration as it exists when you fetch the artifact, because a full evaluated-time configuration history is not stored yet. Two flags keep this honest:
  • configuration_changed_in_period: true means the configuration changed during the period (the receipts carry more than one evaluation epoch); the epochs_in_period array lists them.
  • configuration_changed_since_period: true means the configuration changed after the period closed. The fingerprint in the artifact then describes the current configuration, not the one that was in force during the period.
Practical rule for firms: fetch and file the attestation promptly after the month closes, before making configuration changes. A filed artifact with both flags false pins the fingerprint to the period unambiguously.

​
Reconciliation

The artifact cross-checks the alert counts recorded on the evaluation receipts against the alert rows stored for the period, scoped to the same supported offices the artifact reports on. When they agree, reconciliation is consistent. When they disagree, it is mismatch, surfaced honestly rather than silently reconciled to one number. One caveat: alerts that cannot be attributed to an office (their ingestion-run reference is null, for example because the run record aged out) are included in the cross-check total. In rare cases this can produce a mismatch that reflects attribution loss rather than a missing or extra alert.

​
Verifying integrity with content_hash

The content_hash is a SHA-256 over the canonical, sorted-key form of the artifact, excluding the fields that describe the moment of generation rather than the period: generated_at, request_id, the hash itself, watch_status_at_generation, watch.name (display-only), and watch.configuration_changed_since_period. Because the artifact is computed deterministically from stored receipts, re-fetching a closed period later yields the exact same content_hash. To verify a filed copy: re-fetch the JSON for the same period and compare the content_hash to the value on the copy you filed. A match proves the artifact was not altered after issue. Note that the fingerprint of the current configuration is part of the hash. If you change the watch configuration after filing, a later re-fetch will show configuration_changed_since_period: true and a different hash; that is the disclosure working as intended, not tampering. This proves the integrity of the artifact. It is not a third-party authenticity signature. Cryptographically signed and timestamped documents (for example RFC 3161 timestamps) are on the roadmap.

​
Filing the PDF

For a business record you can file, request the PDF: 
curl "https://api.signa.so/v1/watches/wat_.../attestation?period=2026-06&format=pdf" \
  -H "Authorization: Bearer $SIGNA_API_KEY" \
  -o proof-of-monitoring-2026-06.pdf
You can also request it with Accept: application/pdf. The PDF is rendered from the same data as the JSON, so the numbers match. It includes the configuration, a per-office coverage table, the gaps, the totals, the statement, and the content_hash with instructions for verifying it against the JSON endpoint. A typical firm workflow: fetch the PDF once a month for the closed period, file it in the matter record, and store the JSON alongside it so an auditor can re-fetch and hash-verify later.

​
Periods and errors

  • Periods are closed UTC calendar months. The default is the previous month.
  • The current, in-progress month returns 422 attestation_period_open. Pass partial=true to get an interim artifact marked "partial": true.
  • A period beyond the 25-month retention window returns 410 attestation_expired. The window is rolling (day-granular, matching the evidence retention clock): once any part of a month is past the horizon, the whole month is treated as expired. File monthly, within the window.
  • An unknown watch, or a watch belonging to another organization, returns 404.