Outcomes

Sentriq scores an event and hands back a decision the instant it happens — but whether that decision was actually right is only knowable later, from your own systems. Outcomes are how you feed that back in: did MFA pass, did a chargeback land, did an analyst confirm account takeover. This is plain REST — there is no dedicated outcome helper in the browser SDK.

Three things, kept separate

A risk assessment (Sentriq's score at the time) and a policy decision (what Sentriq told you to do) are never edited after the fact — they remain exactly what Sentriq computed in the moment, forever. An outcome is a separate, later record of what actually happened, attached to an event after you find out.

Two independent fields

Every outcome carries up to two fields, and at least one of them must be present on any submission:

Field	Meaning	Allowed values
`authentication_outcome`	What happened in your own auth flow.	`login_success`, `login_failed`, `mfa_passed`, `mfa_failed`, `password_reset_completed`, `password_reset_rejected`, `account_locked`, `session_revoked`
`label`	The fraud-truth verdict.	`legitimate`, `fraud_confirmed`, `account_takeover`, `bot_confirmed`, `automation_legitimate`, `credential_stuffing`, `brute_force`, `multi_account_abuse`, `payment_fraud`, `unknown`

mfa_passed does not imply legitimate

A sophisticated attacker can pass MFA — SIM-swap, session hijack, social engineering. authentication_outcome and label are submitted independently and mean different things. Never derive one from the other.

Recording an outcome

Server-only — requires a secret key or an authenticated dashboard session, never a public key. A browser asserting "this was legitimate" would be trivially spoofable.

POST /v1/events/{event_id}/outcome
Authorization: Bearer sec_test_xxx
Content-Type: application/json

{
  "label": "legitimate",
  "authentication_outcome": "mfa_passed",
  "reason": "MFA completed successfully"
}

reason (max 500 characters) and metadata (max 10 keys, each value max 200 characters) are optional, bounded free-text/structured context.

Reading outcome history

GET /v1/events/{event_id}/outcomes
Authorization: Bearer sec_test_xxx

Returns the full ordered revision history for the event, oldest to newest.

Revision history, not overwrites

Outcomes are append-only. Resubmitting for the same event behaves differently depending on whether anything actually changed:

Identical label and authentication_outcome as the current row — returns the existing row unchanged. Safe to retry the same API call.
Different — a new row is created and becomes the current one; the previous row is kept, just no longer current. Nothing is ever deleted or mutated after creation, so the full history — including who submitted each revision and when — stays visible.

Every other view of an event (dashboard, metrics, webhooks) uses only the current outcome by default; GET /v1/events/{event_id}/outcomes is how you see the full trail.

Evaluation semantics

Once a label is attached, Sentriq computes a separate, read-only evaluation field from the decision that was made and the label you supplied:

Decision	`legitimate` / `automation_legitimate` / `unknown`	Confirmed fraud (any other label)
`allow`	`correct_allow`	`potential_false_negative`
`monitor`	`correct_monitor`	`potential_false_negative`
`challenge`	`correct_challenge`	`correct_challenge`
`block`	`potential_false_positive`	`correct_block`
no label yet	`inconclusive`

challenge is never scored as a false positive or negative

Applying friction to a legitimate user isn't necessarily wrong — that's what challenge is for, a proportionate response rather than an accusation. Challenging genuinely risky activity is correct even if the label later says fraud; whether the attacker then passed or failed that challenge is a separate authentication_outcome question.

"Potential", not "confirmed" — a false-positive or false-negative evaluation is a signal worth investigating, not an automatic admission Sentriq was wrong. Your own label can itself be mistaken.

Why this matters

Every outcome you record — together with the risk score, the signals that contributed to it, and the policy version that made the decision — is data Sentriq keeps intact for future tuning of thresholds and rules. To be direct about where things stand today: there is no machine-learning pipeline reading this data yet. Recording outcomes now is what makes that kind of tuning possible later; it doesn't change how events are scored today.