This is a technical walkthrough of SENTINEL's architecture. If you want to understand how a behavioral child safety detection system actually works at the service level, this is for you.
SENTINEL is a 13-microservice platform. Each service is independently deployable. You can start with just the event ingestion and risk scoring services, add the compliance layer when needed, and opt into federation later. Here's what each service does and why it exists as a separate service.
Why microservices?
Content moderation systems get bolted into platform infrastructure and then never changed. A monolithic design locks you into the same detection logic, the same compliance reporting format, and the same infrastructure footprint — even as your platform scales and your regulatory obligations evolve.
SENTINEL's services are small, replaceable, and independently testable. A platform that wants to swap SENTINEL's linguistic model for their own detection model can do that without touching the audit log service or the NCMEC reporting pipeline. A platform that doesn't need the federation service doesn't deploy it.
The 13 services group into four layers: ingestion, analysis, infrastructure, and output.
Ingestion layer
Event API Service is the single entry point. Platforms send behavioral events over REST: message sent, session started, relationship formed, contact frequency change. The service validates the schema, assigns a platform-specific event ID, and queues the event for the analysis layer. Webhook callbacks are supported for real-time risk score delivery.
SDK layer is not a service itself, but the Python and Node.js SDKs abstract the API call. Most platforms integrate at the SDK level, not the raw API. The SDKs handle batching, retry logic, and async callback handling.
Analysis layer
These four services are the core of SENTINEL's behavioral detection. Each is independently scalable.
Linguistic Analysis Service builds a session-by-session profile of how a user's communication style changes over time. It is not a keyword scanner. It watches register shifts — vocabulary level, formality, pronoun use, topic focus — and compares them against session history to detect the style changes associated with manufactured intimacy. The model runs on behavioral metadata about language; it does not read or store message content in the traditional sense.
Graph Analysis Service maintains a social graph for each platform: who communicates with whom, at what frequency, and through which channel types. It detects coordinated targeting (multiple accounts approaching the same minor), asymmetric relationship formation (high contact frequency on one side), and escalation from group channels to private channels. Graph signals are some of the most reliable indicators of grooming intent — they are hard to game because they reflect structural behavior, not surface-level content choices.
Temporal Analysis Service watches time-domain signals: contact frequency acceleration, unusual-hours patterns, cross-session escalation velocity. A user who contacts a minor three times in week one, eight times in week two, and daily by week three is exhibiting a velocity pattern. The temporal service tracks this trajectory across sessions and integrates with the risk scoring aggregator to weight recent escalation more heavily.
Fairness Evaluation Service does not produce risk scores. It runs before any detection model deploys and computes demographic parity metrics across the user population. If the linguistic, graph, or temporal models produce false positive rates that differ significantly across demographic groups, this service blocks deployment. Once deployed, it runs periodic re-evaluation to catch drift.
Risk scoring layer
Risk Score Aggregator takes outputs from the linguistic, graph, and temporal services and combines them into a unified risk score between 0 and 100. The combination is not a simple average: each signal layer is independently weighted, and the aggregation logic is configurable per platform. The aggregator also produces the plain-language explanation that accompanies each score — synthesizing the specific signals that contributed, in a format that a human moderator can read and a court can understand.
The risk score aggregator assigns a tier label: trusted (0–29), watch (30–59), restrict (60–84), and critical (85–100). These thresholds are configurable.
Infrastructure layer
Audit Log Service maintains SENTINEL's tamper-evident audit chain. Every risk score, every model deployment decision, every fairness evaluation, and every compliance export is written to a cryptographically chained log. Records cannot be altered without detection. Retention is seven years by default, configurable for jurisdictions requiring longer retention. This is the primary documentation artifact for regulatory audit requests.
Federation Service manages the opt-in cross-platform threat intelligence network. When a platform confirms a grooming case (human-reviewed), the federation service generates a behavioral signature — a non-reversible vector representation of the behavioral pattern — and submits it to the federation pool. When analyzing new users, the service queries whether their behavioral profile matches any known signature. No user PII or message content crosses platform boundaries.
Data Retention and Erasure Service handles GDPR Article 17 erasure requests, COPPA deletion requirements, and jurisdiction-aware data retention policies. When a user deletion request arrives, this service coordinates with the other services to remove personal data while preserving the audit log integrity required for compliance. The audit log entries are pseudonymized rather than deleted, maintaining the evidentiary chain while honoring erasure obligations.
Output layer
NCMEC Reporting Service assembles CyberTipline evidence packages when behavioral indicators meet mandatory reporting thresholds. The package includes the structured event timeline, risk score history, platform context, and whatever user metadata is required for the report. Platform operators review and file; SENTINEL prepares the documentation. This service integrates with the audit log to ensure the evidence package and the audit record are consistent.
Moderation Dashboard Service presents the moderation queue to platform trust and safety teams. Flagged users appear with their risk scores, tier labels, and plain-language explanations. Moderators can review the behavioral signal history, take action, and record the outcome. The service feeds outcomes back into the audit log.
Compliance Export Service generates structured documentation for regulatory submissions: risk assessment records for DSA Article 28 compliance, transparency reports, and audit extracts. These are exportable in machine-readable formats compatible with the EU's Digital Services Act transparency database requirements.
How services communicate
Within a SENTINEL deployment, services communicate over a message queue (Redis by default) for asynchronous analysis jobs and over REST for synchronous queries. The event API places analysis jobs on the queue; each analysis service processes them and writes results to PostgreSQL. The risk score aggregator subscribes to completed analysis outputs and triggers score generation.
Federation queries are synchronous REST calls to the federation service (with caching for high-frequency platforms). Audit log writes are append-only over a dedicated internal API.
Starting small
You do not need to deploy all 13 services. The minimum viable deployment is the Event API, the three analysis services (linguistic, graph, temporal), and the risk score aggregator. This gives you behavioral risk scoring with plain-language explanations.
Add the audit log service for compliance infrastructure. Add the NCMEC reporting service when mandatory reporting becomes relevant. Add the federation service when your platform is large enough to benefit from cross-platform threat intelligence.
The Docker Compose configuration in the repository defines the full stack. Individual services can be commented out for minimal deployments.
SENTINEL is open source. Every service's code, model training scripts, and data handling policy is in the repository.
GitHub: https://github.com/sentinel-safety/SENTINEL
Free for platforms under $100k annual revenue and all non-commercial and research use.
Top comments (0)