Debug Reports

debug reports gives you a single place to answer "what actually happened to this report?" you search by any identifier you have a correlation id, a content id, an account id, or a case id and get the complete lifecycle of that report, from the moment it entered nima through ai assessment, routing, the moderation decision, user notifications, appeals, and the delivery of the action back to your platform it is the only view that also covers reports that never reached a queue when proactive detection clears content below the review threshold, no case is created for moderators so that report is invisible in the moderation workspace and in the case lists debug reports shows it, with the model and confidence score that produced the decision typical uses a reporter says they submitted a report you can't find; an action didn't land on your platform and you need to see whether nima sent it; a piece of content was cleared and you want to know which model cleared it and at what score where to find it debug reports is available at /dashboard/flag/debug in your nima workspace the lifecycle timeline is built from the last 30 days of events reports older than that still appear in the list, but opening one will not return its event history searching for a report the search box accepts any one of the following, and matches it exactly correlation id — the identifier that ties every event of one report together content id — returns every report submitted against that piece of content reporter id — every report submitted by that account reported account id — every report submitted against that account case id — the case the report belongs to leave the search empty to browse all reports, most recent first each row shows the correlation id, report id, content id, reporter id, reported account id, source , reason for report, content type, status, priority and creation time every identifier can be copied with one click select a row to open the full lifecycle status reads as one of new , proceeded , appealed , or no policy violation reading a report's lifecycle the detail page has three parts identifiers the correlation id, case id, content id, reporter id and reported account id, plus the final decision and the total time the case spent in queue copy all ids puts the whole set on your clipboard — useful when escalating to support case summary what the case resolved to, in one panel policy violation — the policy and sub policy recorded at moderation rule matched — the proactive detection or routing rule that fired, and whether that rule is currently enabled moderation queue — the queue the case was handled in webhook delivery — every attempt nima made to deliver the resulting action to your platform, with the http response code, the action name, the attempt number, the response body, and the timestamp successful deliveries are green; anything that returned no response or a 4xx/5xx is amber failed attempts — the failed deliveries on their own, so a retry sequence is readable at a glance lifecycle a chronological timeline of everything that happened to the report each event can be expanded for its detail event what it records content received the report entered nima ai assessment the detection provider that assessed the content, its confidence score, and which threshold was reached — automated enforcement , routed to queue for human review , or no policy violation routed to queue the queue the case was placed in escalated source queue, destination queue, and the moderator who escalated rerouted source queue, destination queue, and the moderator who moved it report moderated the action taken, its action id, the moderator who decided, the policy recorded, and whether the resulting webhook was delivered no policy violation the case was closed without a violation, and whether that was a moderator or automation notification sent which party was notified — reporter, reported account, or both — the recipient's name and email address, and the subject of the template used cascaded the originating case, when a decision propagated from another case on the same content appeal submitted the appeal id, the reason selected, and the text the appellant wrote appeal moderated the appeal decision and who made it diagnosing a failed action when an enforcement action doesn't take effect on your platform, the webhook delivery section tells you which side the problem is on a report moderated event with no successful delivery, followed by attempts returning 4xx or 5xx, means nima issued the action and your endpoint rejected or failed to accept it — the response body carries the error your service returned a report moderated event with a successful 2xx delivery means the action was accepted, and the investigation moves to your own systems searching by content id is the fastest way to see whether a piece of content was reported several times each report has its own correlation id and its own lifecycle, even when they resolve into the same case