Platform
The intelligence layer
BIE processes community interaction data through a six-stage pipeline — from raw platform events to structured behavioral intelligence reports. Each stage transforms data into a higher-order representation, producing outputs that no single stage could generate alone.
Architecture
From raw data to behavioral intelligence
Stage 01
Event ingestion
Every interaction from a connected platform arrives as a structured event. The ingestion layer normalizes data from Discord, Slack, and other platforms into a unified event schema — stripping platform-specific formatting while preserving the structural metadata that matters for behavioral analysis.
Raw message content is never stored. Instead, a one-way content hash is generated for deduplication and reference integrity. The system retains metadata — who spoke, when, in what context, in reply to whom — because behavioral patterns emerge from structure, not content.
Events are validated against a Zod schema at the boundary, then pushed onto a BullMQ queue for asynchronous processing. No AI work happens synchronously in the request path.
Ingest event payload
{
"community_id": "comm_8f3a2b",
"actor_id": "actor_7742",
"event_type": "message",
"content_hash": "sha256:e3b0c44298fc1c14...",
"channel": "general",
"timestamp": "2026-03-12T14:23:01Z",
"metadata": {
"reply_to": "msg_9f1e3d",
"thread_depth": 2,
"platform": "discord"
}
}Stage 02
Behavioral classification
Each event is analyzed by the Layer 1 micro-analysis pipeline. The AI model receives the interaction in its full conversational context — the thread history, the actors involved, and their recent behavioral trajectories — and produces a structured classification across five independent behavioral dimensions.
Beyond dimensional scores, the system identifies the social function of the interaction: bridge-building, de-escalation, knowledge-sharing, status assertion, provocation, and dozens of other functional categories. Each classification includes a confidence score and a reasoning trace explaining the analytical basis.
This is not sentiment analysis. Sentiment captures how a message feels. Behavioral classification captures what a message does to the dynamics of a conversation.
Layer 1 signal output
{
"event_id": "evt_4a8f2c",
"dimensions": {
"relational_dynamic": 0.72,
"epistemic_behavior": 0.85,
"emotional_register": 0.63,
"influence_vector": 0.41,
"trust_impact": 0.78
},
"social_function": "bridge_building",
"confidence": 0.89,
"reasoning": "Actor introduced a framing that connected
two previously divergent positions in the thread,
reducing polarization while preserving both
perspectives. High epistemic openness with
moderate relational assertion."
}Stage 03
Signal aggregation
Individual signal classifications are aggregated over configurable time windows — typically weekly — to produce a statistical summary of each actor's behavioral output. The aggregation layer computes dimensional averages, variance measures, and trajectory indicators from the raw signal stream.
Variance is as important as averages. An actor with a stable 0.7 relational dynamic score behaves fundamentally differently from one who oscillates between 0.4 and 1.0 to arrive at the same average. The aggregation layer captures this distinction explicitly.
Dominant social functions are ranked by frequency, and trajectory direction (strengthening, stabilizing, weakening, volatile) is computed from the slope of recent windows. This aggregated data becomes the input for the profile synthesis layer.
Aggregated signal summary
{
"actor_id": "actor_7742",
"community_id": "comm_8f3a2b",
"window": "2026-W11",
"signal_count": 47,
"averages": {
"relational_dynamic": 0.68,
"epistemic_behavior": 0.81,
"emotional_register": 0.59,
"influence_vector": 0.44,
"trust_impact": 0.74
},
"variance": {
"relational_dynamic": 0.08,
"emotional_register": 0.15
},
"trajectory": "stabilizing",
"dominant_social_functions": [
"bridge_building",
"knowledge_sharing",
"de_escalation"
]
}Stage 04
Profile synthesis
The Layer 2 pipeline synthesizes aggregated signals into a behavioral profile for each actor. This is where raw numbers become interpretive intelligence — the system identifies archetypes, computes dependency scores, maps behavioral triggers, and generates individual-level predictions.
Archetypes are not fixed labels. They are dynamic classifications that reflect what an actor is actually doing in the community over the current analysis window. A “stabilizer” is someone whose behavioral pattern demonstrably reduces volatility. A “bridge” is someone who connects otherwise disconnected conversational clusters. These designations shift as behavior changes.
Dependency scores measure how much the community's health metrics would degrade if a specific actor disengaged. High dependency on a single actor is a structural risk, not a compliment — and the system surfaces it as such.
Layer 2 profile
{
"actor_id": "actor_7742",
"archetypes": ["stabilizer", "bridge"],
"trajectory": {
"direction": "strengthening",
"momentum": 0.12,
"since": "2026-W08"
},
"dependency_score": 0.67,
"triggers": [
{
"condition": "conflict_in_thread",
"response": "de_escalation",
"frequency": 0.84
}
],
"prediction": {
"statement": "Will increase cross-channel activity
if #dev conflict persists past W12",
"confidence": 0.71,
"basis": "Historical pattern: 3 of 4 prior
escalation events triggered bridge behavior
within 48 hours"
}
}Stage 05
Community intelligence
The Layer 3 pipeline operates at the community level. It ingests all actor profiles, cross-references behavioral trajectories, and produces a structured intelligence report that explains what is happening beneath the surface of daily conversation.
The structural story is the core output — a narrative analysis that identifies the 1–3 dynamics explaining most of the community's current behavioral state. This is not a summary of activity. It is an analytical interpretation of what the behavioral data reveals about underlying group dynamics.
Early warnings surface patterns that are not yet crises but show structural precursors. Predictions are specific and falsifiable — each one is reviewed against reality in the following reporting period, building a calibrated track record over time.
Layer 3 report excerpt
{
"community_id": "comm_8f3a2b",
"report_period": "2026-W11",
"health_score": 0.73,
"structural_story": "Cross-channel bridge activity
contracted 40% over 14 days. Three primary
bridge actors reduced output simultaneously,
suggesting systemic cause rather than individual
disengagement.",
"early_warnings": [
{
"type": "dependency_risk",
"severity": "medium",
"detail": "Channel #dev depends on 2 actors
for 68% of stabilization signals"
}
],
"predictions": [
{
"statement": "Polarization index between #general
and #dev will rise 15-20% by W13 if bridge
activity does not recover",
"confidence": 0.74,
"falsifiable_by": "2026-W13"
}
]
}Stage 06
Intelligence delivery
The admin dashboard surfaces pipeline outputs through four primary interfaces: weekly intelligence reports written in analyst-grade prose, community health metrics with historical trend lines, behavioral drift charts tracking trajectory changes over time, and an early warning feed that highlights emerging structural risks.
Reports are not dashboards full of numbers. They are structured analytical documents that explain what is happening, why it matters, and what is likely to happen next. The format is closer to a senior analyst briefing than a metrics dashboard.
Intelligence is delivered exclusively to community administrators. Individual members never see behavioral scores or classifications about themselves or others. The system informs human decision-makers — it does not automate decisions or assign public reputations.
Dashboard surfaces
Intelligence Reports
Weekly structured analysis with narrative, evidence, and predictions
Health Metrics
Community health score with dimensional breakdown and trend lines
Drift Charts
Behavioral trajectory visualization for actors and community-level signals
Early Warnings
Emerging structural risks surfaced before they become visible incidents
API
Endpoint signatures
Available endpoints
POST /api/ingest/event
GET /api/community/:id/health
GET /api/insights/:communityId
GET /api/insights/:communityId/:reportId
GET /api/queue/statusResponse envelope
// Success
{
"success": true,
"data": { ... }
}
// Error
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid community_id format"
}
}