Surfaces · Presence
Presence - adaptive human verification layer. Presence evaluates behavior, device trust and liveness, stepping up verification only when needed before sensitive actions execute.
Decionis decides whether the action may execute. When policy says a person must decide, Presence — the adaptive human verification layer — verifies that the authorized person is really present on their own device, and seals a signed Presence Record that Decionis re-checks before the action commits.
The dossier's execution binding carries a verifiable reference to the Presence Record — approver identity, role, action digests, expiry — re-checked before the action commits. A Presence approval is not a transferable human ALLOW.
The demo needs no signup. Production enforcement is sales-assisted.
Stated plainly, so the integration you plan is the integration that exists.
decionis.request_presence_verification and decionis.get_presence_verification_status run against a held ESCALATE. They cannot bypass a BLOCK, and they refuse Shadow Mode evaluations; the action stays held until a new Decionis verdict returns PROCEED.
You wire the ceremony — a Presence Check requires local device authentication before a hardware-key signature — and Decionis verifies the signed Presence Record it seals. The step-up primitive is Adaptive Step-Up; the approval primitive is the Human Approval Gate.
The asynchronous authority loop is not yet enabled. Requesting a Presence Check is an explicit call your integration makes; production enforcement is sales-assisted.
Presence appears as a named pilot-phase component on the fintech lane, and at the ESCALATE step of the MCP server docs.
