The client and the verifier are the standard library only, so nothing is installed.
Every command was run on 28 September 2026 against https://api.humsana.com, in one directory holding the boundary client and the offline verifier. Steps 1, 2 and 5 need the client. Steps 3 and 4 need the verifier and the two files it checks, the record and the public key.
This run uses yourteam.release, with three parameters bound to it.
$ python3 -m clients.swan_boundary --demo --anonymous --action yourteam.release
================================================================================================
Testing the authorization boundary with your own action
service https://api.humsana.com
your action yourteam.release
================================================================================================
1. no key, no account, no signup: this service accepts anonymous calls, rate limited per caller.
the action as authorized: {"amount_gbp": 1800, "destination_account": "4821", "reference": "INV-1DFC32"}
2. POST /v1/authorize/verify, for the action as you intended it
decision ALLOW code - matched None consumed None
receipt authz_585GcVURKYRNliWupLho1w issued 2026-09-28T15:52:15Z
bound to sha256:33c5df764997b88d6227ce09ff03c9d306f3854894a11c98be0c1d4c0dcf0592
policy version 1
Run on 28 September 2026 at 15:52 UTC against https://api.humsana.com.
$ python3 -m clients.swan_boundary --demo --anonymous --action yourteam.release
effectuation {"checked": false, "reason": "NOT_YET_SUBMITTED"}
authorized. the executor may now present the action it received.
3. POST /v1/authorize/effectuate with ONE field changed, as it would arrive if something altered it on the way
presented: {"amount_gbp": 1800, "destination_account": "9137", "reference": "INV-1DFC32"}
decision HUMAN_CONFIRM code EFFECTUATION_DRIFT matched False consumed False
drift parameters.destination_account: authorized 4821 -> presented 9137 rule MAY_NOT_CHANGE
reason EFFECTUATION_DRIFT: 1 field(s) outside the authorized tuple
effectuation {"checked": true, "checked_at": "2026-09-28T15:52:15Z", "matched": false, "decision": "HUMAN_CONFIRM", "drift": [{"field": "parameters.destination_account", "au
your executor does not run, because your code asks the service first.
4. POST /v1/authorize/effectuate again, presenting the action as authorized
decision ALLOW code MATCHED matched True consumed True
effectuation {"checked": true, "checked_at": "2026-09-28T15:52:15Z", "matched": true, "decision": "ALLOW", "drift": [], "reasons": []}
a refusal spent nothing, so the authorized action still ran.
5. POST /v1/authorize/effectuate a third time, with the same action
decision DENY code RECEIPT_ALREADY_USED matched False consumed False
reason RECEIPT_ALREADY_USED: this authorization has been spent
effectuation {"checked": true, "checked_at": "2026-09-28T15:52:15Z", "matched": false, "decision": "DENY", "drift": [], "reasons": [{"code": "RECEIPT_ALREADY_USED", "detail"
an authorization is spent once.
The same command and the same run as step 1, on 28 September 2026 at 15:52 UTC. The refusal arrives as HTTP 200 with a code, not as an error status.
The sandbox issues a signed record for the action it presented, and serves the public key beside it.
The record route answers only in a session that has pressed, so curl keeps the cookie in jar.txt.
$ curl -s -c jar.txt -o /dev/null -w 'GET %{url_effective} %{http_code}\n' https://api.humsana.com/sandbox/gregg/
GET https://api.humsana.com/sandbox/gregg/ 200
$ curl -s -b jar.txt -c jar.txt -o pressed.html -w 'POST %{url_effective} %{http_code}\n' -d 'do=execute' -d 'amount_gbp=1800' -d 'beneficiary=Supplier X' -d 'account_four=9137' -d 'expiry=14:00' https://api.humsana.com/sandbox/gregg/
POST https://api.humsana.com/sandbox/gregg/ 200
the two rows the press wrote into the case record on the page it returned:
verdict REFUSED code GRANT_DOES_NOT_COVER_THIS_ACTION
presented payments.release (amount_gbp=1800, beneficiary=Supplier X, expiry=14:00, payee_account=GB00SUPPLIER00009137, reference=INV-88213); digest sha256:b05f8abf4c1655ca1fadc6e1e1ec47d08afb00a4340be82ea477c9852c9b591c at 2026-09-28T15:53:32Z
executed code GRANT_DOES_NOT_COVER_THIS_ACTION, matched False, consumed False
refused GRANT_DOES_NOT_COVER_THIS_ACTION (this grant covers a different action: parameters.payee_account)
$ curl -s -b jar.txt -o record.receipt.json -w 'GET %{url_effective} %{http_code}\n' https://api.humsana.com/sandbox/gregg/record.receipt.json
GET https://api.humsana.com/sandbox/gregg/record.receipt.json 200
$ curl -s -b jar.txt -o key.pub.json -w 'GET %{url_effective} %{http_code}\n' https://api.humsana.com/sandbox/gregg/key.pub.json
GET https://api.humsana.com/sandbox/gregg/key.pub.json 200
$ python3 -m receipt.verify record.receipt.json --key key.pub.json
SIGNATURE VERIFIES: the signature verifies against the published key
schema swan.authz/1
receipt rcpt__1jUHq9QT1X725H0 issued 2026-09-28T15:53:32Z
issuer Humsana key swan-authz-2026
authority ref grant_0SHGNAlUz5Pb2sBgqzqLLl3pst85Im0t action class payments.release policy version 1
authorized sha256:12423cf78b4d083b sha256:5fabbb701e3b2afb
presented sha256:b05f8abf4c1655ca (the comparison decides, the digests differ by construction)
decision REFUSED GRANT_DOES_NOT_COVER_THIS_ACTION matched False consumed False
drift parameters.payee_account: GB00SUPPLIER00004821 -> GB00SUPPLIER00009137 MAY_NOT_CHANGE
execution NOT_EXECUTED rail called False
executor acknowledged_unsigned
the executor recorded what it received but did not sign back, so this is not yet a two-party record
record digest sha256:1db82f9285fff41da170305522174b80fd734bd590788ec3861b0f202cd506cd
scope This signature attests that Humsana issued this record and that it has not been altered since. It does not establish that the authority behind the action was legitimate, and it does not show that an executor relied on the decision. The acknowledgment block states whether the executor signed back.
exit status: 0
Run on 28 September 2026 at 15:53 UTC. The verifier reads two files, needs no network and no account.
The signature covers the record's canonical body, which is every value except the record's own digest field.
---- step 4: tamper with the record and verify again ----
$ python3 -c "import json,pathlib; d=json.loads(pathlib.Path('record.receipt.json').read_text()); d['decision']['verdict']='ALLOWED'; pathlib.Path('tampered.json').write_text(json.dumps(d,indent=2))"
$ python3 -m receipt.verify tampered.json --key key.pub.json
SIGNATURE DOES NOT VERIFY: the signature does not verify against this key
schema swan.authz/1
receipt rcpt__1jUHq9QT1X725H0 issued 2026-09-28T15:53:32Z
issuer Humsana key swan-authz-2026
authority ref grant_0SHGNAlUz5Pb2sBgqzqLLl3pst85Im0t action class payments.release policy version 1
authorized sha256:12423cf78b4d083b sha256:5fabbb701e3b2afb
presented sha256:b05f8abf4c1655ca (the comparison decides, the digests differ by construction)
decision ALLOWED GRANT_DOES_NOT_COVER_THIS_ACTION matched False consumed False
drift parameters.payee_account: GB00SUPPLIER00004821 -> GB00SUPPLIER00009137 MAY_NOT_CHANGE
execution NOT_EXECUTED rail called False
executor acknowledged_unsigned
the executor recorded what it received but did not sign back, so this is not yet a two-party record
RECORD DIGEST DOES NOT MATCH the record's own contents
record digest sha256:1db82f9285fff41da170305522174b80fd734bd590788ec3861b0f202cd506cd
scope This signature attests that Humsana issued this record and that it has not been altered since. It does not establish that the authority behind the action was legitimate, and it does not show that an executor relied on the decision. The acknowledgment block states whether the executor signed back.
exit status: 1
Run on 28 September 2026 at 15:53 UTC, on the record from step 3.
rail() is the one function an integrator replaces.
$ python3 -m clients.reference_executor --demo
================================================================================================
The seam: three attempts through the executor, and what the rail actually saw
service https://api.humsana.com
================================================================================================
ASK POST /v1/authorize/verify for the action the principal intended
decision ALLOW code - matched None consumed None
receipt authz_V1FFmooBBbllRG7vp0yUzA issued 2026-09-28T15:52:19Z
bound to sha256:ff73b8fb9c8a5b648289c5b2df183e577233c41651d2bb40e9efdcbd64ff10a5
policy version 1
effectuation {"checked": false, "reason": "NOT_YET_SUBMITTED"}
ATTEMPT 1 an action altered on the way (destination 4821 -> 9137)
rail not_called code EFFECTUATION_DRIFT parameters.destination_account: authorized 4821 -> presented 9137 (MAY_NOT_CHANGE)
ATTEMPT 2 the action as authorized
rail called code MATCHED {'executed': True, 'reference': 'TXN-0001'}
ATTEMPT 3 the same action again
rail not_called code RECEIPT_ALREADY_USED this authorization has been spent
------------------------------------------------------------------------------------------------
the ledger: [
{
"at": "2026-09-28T15:52:19Z",
"event": "refused",
"action": "yourteam.release",
"code": "EFFECTUATION_DRIFT",
"detail": "parameters.destination_account: authorized 4821 -> presented 9137 (MAY_NOT_CHANGE)"
},
{
"at": "2026-09-28T15:52:19Z",
"event": "executed",
"action": "yourteam.release",
"code": "MATCHED",
"rail": {
"executed": true,
"reference": "TXN-0001"
}
},
{
"at": "2026-09-28T15:52:20Z",
"event": "refused",
"action": "yourteam.release",
"code": "RECEIPT_ALREADY_USED",
"detail": "this authorization has been spent"
}
]
the rail ran 1 time(s) across 3 attempts, and never on a refusal.
That count is the claim. Everything else is our page talking.
Run on 28 September 2026 at 15:52 UTC against https://api.humsana.com.