​

Composable safety primitives

​

Why this matters

​

The fields

​

cross_endpoint_modifier

​

vulnerability_profile

​

Example response

{
  "endpoint": "vulnerability-exploitation",
  "detected": true,
  "level": "high",
  "risk_score": 0.85,
  "recommended_action": "flag_for_review",
  "categories": [
    { "tag": "AGE_TARGETING", "confidence": 0.8 },
    { "tag": "EMOTIONAL_EXPLOIT", "confidence": 0.9 },
    { "tag": "FINANCIAL_EXPLOIT", "confidence": 0.9 }
  ],
  "cross_endpoint_modifier": 1.6,
  "vulnerability_profile": {
    "emotional_vulnerability": 0.8,
    "cognitive_vulnerability": 0.0,
    "situational_vulnerability": 0.0,
    "social_vulnerability": 0.0
  }
}

​

Composing with another detector

import Tuteliq from "@tuteliq/sdk";

const tuteliq = new Tuteliq({ apiKey: process.env.TUTELIQ_KEY });

// Run both endpoints in parallel (they fan out server-side too)
const [scam, vuln] = await Promise.all([
  tuteliq.fraud.romanceScam({ content }),
  tuteliq.safety.vulnerabilityExploitation({ content }),
]);

// Compound risk — amplify the romance-scam verdict by the vulnerability modifier
const compoundRisk = Math.min(
  scam.risk_score * vuln.cross_endpoint_modifier,
  1.0
);

// Route by the dominant vulnerability dimension
const dims = vuln.vulnerability_profile;
const route =
  dims.emotional_vulnerability  > 0.7 ? "gentle_human_review"   :
  dims.situational_vulnerability > 0.7 ? "transaction_hold"      :
  dims.cognitive_vulnerability   > 0.7 ? "guardian_notify"       :
  dims.social_vulnerability      > 0.7 ? "support_network_outreach" :
                                         "standard_moderation";

if (compoundRisk >= 0.85) {
  await escalate({ route, evidence: scam.evidence, profile: dims });
}

import asyncio
from tuteliq import Tuteliq

tuteliq = Tuteliq(api_key=os.environ["TUTELIQ_KEY"])

async def assess(content: str) -> dict:
    scam, vuln = await asyncio.gather(
        tuteliq.fraud.romance_scam(content=content),
        tuteliq.safety.vulnerability_exploitation(content=content),
    )

    compound = min(scam.risk_score * vuln.cross_endpoint_modifier, 1.0)
    dims = vuln.vulnerability_profile

    route = (
        "gentle_human_review"      if dims["emotional_vulnerability"]   > 0.7
        else "transaction_hold"     if dims["situational_vulnerability"] > 0.7
        else "guardian_notify"      if dims["cognitive_vulnerability"]   > 0.7
        else "support_network_outreach" if dims["social_vulnerability"]  > 0.7
        else "standard_moderation"
    )

    return {"compound_risk": compound, "route": route, "evidence": scam.evidence}

​

When to use this primitive

• You’re building an agent that takes graduated actions based on combined risk, not single-detector verdicts.
• You’re moderating populations where target vulnerability is highly variable — mixed-age platforms, fintech, dating apps, AI companion products.
• You want intervention workflows that adapt to the user, not just the content.

​

When not to use it

• You’re running a fixed-threshold per-message classifier and only need a single binary verdict — recommended_action from each endpoint is enough.
• You’re moderating content at the corpus level (e.g. AI training data) rather than per-user signals — vulnerability doesn’t apply.

​

Notes on safe composition

• Cap the compound risk at 1.0 (Math.min(scam.risk_score * modifier, 1.0)) so amplification never produces an out-of-band value downstream consumers don’t expect.
• The modifier is only meaningful when both endpoints actually detect — if vuln.detected === false, treat the modifier as 1.0.
• Cache the profile per-conversation, not per-message — a vulnerability read stays roughly stable across a single conversation, so re-running it on every message adds latency without changing the answer. This is guidance about your caching layer, not a Tuteliq-side store — see Privacy and data handling below. Refresh periodically or on context changes (e.g. a major life event surfaced in subsequent messages), and apply your own retention limits.
• Don’t expose the raw modifier to end users. It’s an integrator-level signal designed for routing logic, not for display. Surface the resulting route and the human-readable rationale instead.

​

Privacy and data handling

• No persistent identifier. No request or response field in this API — or anywhere in Tuteliq’s detection surface — asks for or returns a user_id, device_id, or other end-user identifier. vulnerability_profile is computed fresh from the content (and optional conversation_history) submitted in that one call; it is not looked up against, or written to, a stored profile of any individual.
• No server-side profiling. Tuteliq does not build, persist, or accumulate a vulnerability profile per user across calls. Each response reflects only what was in that request. If you want profile continuity across a conversation, that’s the client-side caching described above — a decision (and a data-retention obligation) that belongs to you as the integrator, not something Tuteliq does on your behalf.
• Server-to-server only. Detection runs on Tuteliq’s infrastructure. SDK calls (tuteliq.safety.vulnerabilityExploitation(...)) are thin clients that call the hosted API — nothing in this composition pattern, or in any Tuteliq SDK, runs inference on the end user’s device.
• The age_group / age fields elsewhere in the API are optional inputs, not requirements. Detectors that accept an age or age-bracket field (e.g. detect_grooming’s context.child_age) work without it; supplying it sharpens the analysis but is never mandatory.

​

Related

• detect_vulnerability_exploitation — full endpoint reference
• analyse_multi — batch multi-endpoint analysis (applies modifier internally when both fire)
• AI agents — composing Tuteliq primitives from an agent
• Incident logging — routing and reviewing what composition surfaces