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:- Records the raw event in the audit trail
- Maps the
event_typeto a canonical signal type and base risk score - Enriches the signal with available metadata (issuer trust tier, geo, device)
- Stores a
risk_signalrecord ready for policy evaluation
Built-in Event Mappings
| Event Type | Signal Type | Base Score |
|---|---|---|
verification.failed | behavior | 60 |
verification.invalid_sig | behavior | 75 |
login.failed.repeated | ato | 70 |
login.suspicious_geo | geo_anomaly | 65 |
attestation.deepfake_suspect | deepfake | 85 |
session.hijack_suspect | ato | 90 |
behavior.
Request
The system that generated this event:
attestation, verification, login, consumer_portalThe raw event name (e.g.
login.failed, verification.failed, attestation.deepfake_suspect)Identifier of the entity involved in the event.
External reference ID (attestation_id, session_id, etc.) for cross-referencing.
Source IP address.
Raw event payload for enrichment context.
Response
UUID of the recorded raw event source.
UUID of the normalized risk signal created from this event.
The normalized signal type derived from the event.
The base risk score assigned during normalization.
true if the event matched a known mapping; false if it used the generic fallback.
