Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.truthlocks.com/llms.txt

Use this file to discover all available pages before exploring further.

How Normalization Works

When you submit an identity event, the platform:
  1. Records the raw event in the audit trail
  2. Maps the event_type to a canonical signal type and base risk score
  3. Enriches the signal with available metadata (issuer trust tier, geo, device)
  4. Stores a risk_signal record ready for policy evaluation

Built-in Event Mappings

Event TypeSignal TypeBase Score
verification.failedbehavior60
verification.invalid_sigbehavior75
login.failed.repeatedato70
login.suspicious_geogeo_anomaly65
attestation.deepfake_suspectdeepfake85
session.hijack_suspectato90
Unknown event types are accepted with a base score of 10 and signal type behavior.

Request

event_source
string
required
The system that generated this event: attestation, verification, login, consumer_portal
event_type
string
required
The raw event name (e.g. login.failed, verification.failed, attestation.deepfake_suspect)
subject_id
string
required
Identifier of the entity involved in the event.
event_ref_id
string
External reference ID (attestation_id, session_id, etc.) for cross-referencing.
ip_address
string
Source IP address.
payload
object
Raw event payload for enrichment context.

Response

event_id
string
UUID of the recorded raw event source.
signal_id
string
UUID of the normalized risk signal created from this event.
signal_type
string
The normalized signal type derived from the event.
risk_score
integer
The base risk score assigned during normalization.
normalized
boolean
true if the event matched a known mapping; false if it used the generic fallback.