Humsana

One payout release, and the check that decides it

The screen below presents one action to a running authorization service. The service compares it, field by field, against the action it approved, and answers. Every code, field, value, rule, digest and count on this page is read from that answer.

One payout releasethe action as presented, and the service's answer

The action class is payments.release: one payout release of INV-88213. Amount, beneficiary, account and expiry are bound at approval, and the service's answer about each of them is below.

One action class, payments.release. Change the account, the name or the expiry and the release is refused before the rail is called; a lower amount is permitted, because the rule that governs an amount is MAY_NOT_INCREASE, and a higher one is not. The expiry is a field of the instruction, not the authorization's own window, which the case record shows.

Press Execute. The action on screen is presented to the service as it stands, and what comes back is what the page shows.

The signed recordswan.authz/1

no signed record is offered yet

The case recordfrom the claim to the execution

One record for the action on screen, from the claim to the execution. Every row below is a field of a response from the service in this session.

claimed5 fact(s) the caller asserted (actor.declared, agent.identity, operator.declared, requested_action.declared, provenance.declared); the service established 0 of its own
establishedas the receipt's own ledger counts them: 0 established by the service, 5 asserted by the caller, 3 unresolved
authorizedHUMAN_CONFIRM at the decision, then the confirmation's grant grant_VDPDLaAoLAK8El4fCFlyLy0SL5OkE1_5, single use True, authorization authz_xX8Hc2juzJV2iOS8bkwDfw
authorized actionamount_gbp=1800, beneficiary=Supplier X, expiry=14:00, payee_account=GB00SUPPLIER00004821, reference=INV-88213
presentednothing has been presented for execution yet
executednothing executed yet: the receipt's own effectuation block says NOT_YET_SUBMITTED
refusednothing refused on this action
policy version1
action digest, authorizedsha256:593625e634839ec0ae55d32ca84e28deffb204c61486f04d69f7a3633eeba50b
action digest, presentedthe service did not state it in this response
approval identityreviewer@northwind.example via the reference confirmer
timestampsreceipt issued 2026-10-03T02:42:05Z; approval valid until 2026-10-03T02:52:05Z; grant issued 2026-10-03T02:42:05Z; authorization obtained at 02:42:05 UTC

The two digests cover different things: the authorized digest covers the binding, which is the action with its conditions and its window, and the presented digest covers the action as it arrived. They are not meant to be equal, and whether the action is within its authorization is decided by the comparison above, never by comparing digests.

Reference confirmer - demo only. The sandbox signs this confirmation itself, because a visitor has to be able to press the button. A production integration accepts the customer's authenticated identity, assertion or signature instead. What the demo proves is that the confirmation is bound to the exact action: one digest, one set of fields, and a refusal the moment one of them moves.
every line below is a call to the running service, this session
02:42:05executorasks the boundary for an authorization of the approved action
02:42:05humsanaPOST /v1/authorize/verify -> 200 decision=HUMAN_CONFIRM reasons=NO_DELEGATION_PRESENTED, NO_VERIFIABLE_PRINCIPAL_BINDING, HUMAN_CONFIRMATION_REQUIRED
02:42:05humsanaPOST /v1/authorize/confirm/request -> 200 challenge issued to mlro:northwind adapter=reference
02:42:05humsanaPOST /v1/authorize/confirm -> 200 grant grant_VDPDLaAoLAK8El4fCFlyLy0SL5OkE1_5 single_use=True
02:42:05recordauthorization recorded, valid until 2026-10-03T02:52:05Z