​

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.

​

Carrying a signal forward

1. Store the suggestion on your side. When a response carries minor_disclosure, save minor_disclosure.suggested_age_group against that user in your own records.
2. Send it back as the declared age. On that user’s later requests, pass the stored value as context.age_group. It is always a minor band (under 18, under 13, 13-15 or 16-17), so the detectors apply a minor’s protections.
3. A declared child beats an adult setting. With conversation_type dating, adult_community or workplace, a declared minor age group means the adult audience is not used for that request. You do not need to change your platform-wide setting.

const res = await fetch("https://api.tuteliq.ai/api/v1/fraud/romance-scam", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TUTELIQ_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    text,
    context: {
      conversation_type: "dating",
      age_group: user.suggestedAgeGroup ?? "18+",
      minor_disclosure_check: true,
    },
  }),
}).then((r) => r.json());

if (res.minor_disclosure && !user.suggestedAgeGroup) {
  // Kept in your own user store, under your own retention policy.
  await users.update(user.id, {
    suggestedAgeGroup: res.minor_disclosure.suggested_age_group,
  });
  await reviewQueue.add({ userId: user.id, reason: res.minor_disclosure.reason });
}

• The check does not repeat. Once a request declares a minor, it no longer declares an adult, so minor_disclosure_check does not run and minor_on_adult_platform_raised is not returned again. The declared age group is now the signal, and the account decision (asking the user to verify their age again, for example) belongs to your own process.
• On /safety/grooming, which takes ages rather than an age group, declare the user’s messages with a child sender_role, or pass their age, instead of age_group.
• Decide how long to keep it. The stored value is your data, in your systems, under your own retention and review rules. Tuteliq’s involvement ends with each response.
• Let a person decide. A finding is a reason to review an account, not proof of age. Route it to a person before you restrict anyone.

​

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