How a covenant monitoring API should handle evidence
A covenant monitoring API should return an identified obligation or threshold, the governing source language, a comparable prior disclosure when change is claimed, and an explicit verification state. It should not turn a keyword hit into a breach, compliance, materiality, or severity conclusion.
Event model
Useful covenant events include additions, removals, threshold changes, leverage and coverage tests, minimum-liquidity requirements, waivers, breaches, amendments, and forbearance terms. The structured record should preserve the metric, comparator, threshold, effective context, related facility, both accessions when applicable, exact evidence, evidence hashes, source locators, uncertainty, and refusal reasons.
False-positive controls
Dates, formatting, reordered definitions, cross-references, exceptions, baskets, and equivalent language can look like changes. A defensible system normalizes only when the evidence supports equivalence, compares the complete context, and declines to assign severity automatically. Downstream users should keep the source citation next to every alert and review the governing documents before acting.
How to evaluate FilingSift
Start with the published event rules, the REST contract, and the benchmark status. The public dataset currently has no covenant event and zero qualified-reviewed benchmark cases; that absence is stated rather than filled with an unsupported example.
Contract references
See the API documentation, OpenAPI specification, and verification methodology. Webhooks and MCP remain unavailable.
Content snapshot: . Current API data may be newer.