Integrating Internal Tools

nima is designed to work seamlessly with your existing infrastructure you can integrate your internal tools directly into nima’s automated workflows and reporting systems via signals this allows you to leverage your proprietary technology for moderation while benefiting from nima's robust rule engine what is a signal? a signal is the specific outcome from any of your internal detection tools this could originate from a machine learning (ml) model a keyword blocklisting technology a spam detection rule engine configuration process to integrate your internal tool, you must first send a detailed description of the semantics of your detection tool to the product and tech team submit semantics provide the product and tech team with a definition of your tool’s output for example, if you have a spam detection tool, you would provide the structure and meaning of its results signal title signal description signal keyword signal possible values mass friending hour a platform user has been identified sending x number of friend requests within an hour, which is considered an spam mass friending hour 0 or 1 mass friending day a platform user has been identified sending x number of friend requests within a day, which is considered an spam mass friending day 0 or 1 system setup once received, the product and tech team will configure the signal within your environment workflow configuration after setup, the signal becomes available in the ai marketplace when building a rule, select internal tool as the provider the list of configured signals will then appear in a dropdown for you to select handling boolean signals nima’s automated detection workflows operate on the concept of probability if your internal tool returns a boolean outcome (0 or 1), you should configure your thresholds as follows 0% probability (false) this will be considered a green threshold match (flag will be skipped) 100% probability (true) this will be considered a red threshold match (policy will be applied automatically) sending signals via the api once your configuration is complete, you can begin sending signals to the api the signal scores travel with the content they describe, so they belong in the customerspecific node of the content , next to any other content attributes { "priority" "severe", "channel" "automated detection", "reason for request" "content flagged by internal tool", "label" \["flag"], "content" { "content id" "post 12345", "title" "parent content", "rawtext" "…", "type" { "id" "txt" }, "status" "published", "customerspecific" { "summary" "", "probs" "{\\"mass friending day\\" 1, \\"webspam score\\" 0 72}", "detectedby" "internal tool" } }, "reporter" { "id" "internal tool", "name" "internal tool" }, "reportee" { "id" "user 987", "name" "…" } } three details are required for the signal to be evaluated by the rule engine label — include "label" \["flag"] at the root of the payload without it the request is accepted but the rule engine does not run, so no case is created probs — provide the scores as a json encoded string (not a nested object) under content customerspecific , keyed by the signal keyword you configured (e g mass friending day ) send "detectedby" "internal tool" alongside it content type id — set the content type (e g txt , img ) so type specific rules can match each signal score is compared against the orange and red thresholds you set on the rule score below the orange threshold → green (skipped, no case) score at or above orange, below red → orange (routed to the rule's queue for review) score at or above red → red (the rule's policy is applied automatically) for a boolean tool that returns 0 or 1 , this means 0 resolves to green and 1 resolves to red