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.