A receipt is signed evidence of how a protected action ended. It comes as a bundle (a .kbundle file) that holds the signed receipt, every signed object it covers and the identity documents of each signer, so anyone can verify it offline without trusting K-Block Cloud. The Receipts page lists your organization's receipts and verifies them. See Receipts and evidence bundles for the concept.
Every role can open the receipts list and every receipt.
Which actions get a receipt
| How the action ended | Receipt |
|---|---|
| Executed: succeeded or failed (including an interrupted execution that was recovered) | yes |
| Rejected by an approver | yes |
| Cancelled by an owner or admin | yes |
| Authorized for the caller (decision only) | yes: an authorization receipt, which proves the authorization, not an execution |
| Denied by the policy | no: nothing was signed |
| Expired or superseded | no |
A receipt is signed by the K-Block Gateway's identity. See What a receipt proves before you rely on one.
The receipts list
Each row shows:
| Column | What it shows |
|---|---|
| Receipt | The tool and action, linking to the receipt, with the receipt object ID. |
| Outcome | Succeeded, Failed, Rejected, Cancelled or Authorized (decision only), with hosted copy deleted once the bundle was deleted after the retention period. |
| Agent | The agent that made the call. |
| Issued | When the receipt was issued. |
| Issuer | The issuer's KID. When every listed receipt has the same issuer, this column is left out and an Issued by line above the table names it once. |
K-Block Cloud hosts each bundle for the organization's retention period. Download the .kbundle of a receipt you need to keep (Download .kbundle on its page): a downloaded bundle stays verifiable offline after the hosted copy is deleted. The page of a receipt whose hosted copy was deleted says Hosted copy deleted after the retention period, that the receipt is not invalid, and shows the record that stays, with the bundle's SHA-256 to match your copy.
A summary line counts the listed receipts by outcome. The list loads 50 receipts at a time; use the load-more control for more. It cannot be filtered in the dashboard.
With no receipts yet, the page says "No receipts yet" and offers View protected actions.
Verify a receipt file
At the bottom of the list, Verify a receipt file checks any .kbundle file entirely in your browser. Nothing is uploaded.
- Select Choose .kbundle file and pick a file of at most 16 MiB.
- Optionally choose attesters under Trust attestations from (see Attestations).
- Select Verify file. The verification report appears under the card.
The verdict says whether the K-Block Gateway (the Gateway identity pinned in the dashboard) issued the receipt. A bundle from another issuer is NOT THIS GATEWAY, or CONSISTENT when the dashboard has no pinned Gateway identity. The verdict does not compare the file with your organization: check Organization (signed) in the report, marked this organization or another organization. See Verdicts.
The receipt page
The header shows the tool and action, the outcome, when it was issued, the agent, the amount and the environment.
Two verifications
The top of the page shows two verdicts side by side. They answer different questions.
| Verification by the Cloud | Independent check in this browser | |
|---|---|---|
| Who checks | The Cloud API, each time the page loads | Your browser, when you select Verify in this browser |
| What it checks | Reads the stored bundle, checks its bytes against the SHA-256 recorded at issuance, and verifies it (the result for the same bytes and inputs can come from a cache). No signer may have conflicting identity documents. | Fetches the bundle, compares its SHA-256 with the recorded value, then runs the K-Block verifier on every signature, identity chain and workflow rule. |
| Checked against the pinned Gateway identity | No | Yes, when the dashboard has a pinned Gateway identity (otherwise the best verdict is consistent) |
| Result shown | valid or invalid, plus whether it was also valid when it was issued | valid, consistent, not this gateway, mismatch or invalid, with how many checks passed and Read the full report |
Verdicts
The browser check gives one of five verdicts:
| Verdict | Meaning |
|---|---|
| VALID | Every check passed, and the receipt was issued by the K-Block Gateway (the Gateway identity pinned in the dashboard), which also signed its thread. |
| CONSISTENT | Every check passed against the identity documents inside the bundle, but the dashboard has no pinned Gateway identity, so it cannot tell whether the K-Block Gateway issued the receipt. Compare the issuer KID with the Gateway KID that K-Block gave you. The dashboard normally has a pinned Gateway identity, so if you see this verdict, contact K-Block support. |
| NOT THIS GATEWAY | The bundle is internally consistent, but the Gateway identity pinned in the dashboard did not issue it or did not sign its thread. Do not rely on it as a receipt of the K-Block Gateway. |
| MISMATCH | The bundle verifies, but it is not the receipt this page shows. |
| INVALID | The receipt did not verify. |
The full report (Verification in this browser) lists every check, errors and warnings, what the verified bundle says, What this verification cannot establish, the verified chain and the attestations.
Download .kbundle
Download .kbundle saves the bundle as a .kbundle file named after the receipt object ID (its letters, digits and underscores only). The Cloud API serves it only after checking its bytes against the SHA-256 recorded at issuance. Under the buttons, the page shows the bundle's size and SHA-256.
To verify the file outside the dashboard, see Verify a receipt and the Receipt verification SDK.
Attestations
A K-Block-aware upstream server verifies the evidence it receives and signs an attestation about the call. Trust attestations from lists the organization's registered K-Block-aware servers. An attestation counts in the browser check only if you choose to trust its attester. When no such server is registered, the page says that no attester can be trusted. A plain upstream signs nothing, so its result is only the Gateway's own record.
Signed steps
The Signed steps timeline shows the thread behind the receipt in order (task, proposal, approval or rejection or cancellation, execution, attestation, result) and who signed each step, as the Cloud API resolved the signers: a member's name and role, an upstream server's name, or a role such as gateway or principal. The receipt itself comes last with its issuer. A rejection, or a failed result, is marked as a failure.
A cancellation receipt covers the path from the task to the cancellation. The proposal and any approval are not part of it.
Policy decision
The Policy decision card shows the decision that applied to the call:
- Before you verify, it shows the Cloud API's record: enforcement level, decision and deciding rule.
- After the browser check passes as this receipt, it reads the decision from the signed task instead, including the enforcement level the Gateway signed into it and the observe window, if one applied.
Re-check decision asks the Cloud API to recompute the decision from the task's signed members and the stored policy version with the signed digest. It shows what was signed, what was recomputed and the policy version. Nothing is written. If no policy version decided the call, the card says so.
Receipt facts and identities
- Receipt: the action (linking to its page), the outcome (for
final, also the action's status), the result status when it differs, the issuer, when it was issued, and the workflow. - Identifiers: receipt object, thread (task), head object, result digest, workflow digest, bundle SHA-256 and bundle size.
- Participants: every signer of the verified chain, resolved to this organization's members, services and upstream servers.
- Raw reports: the Cloud verification report and the report recorded at issuance.
What to do when verification fails
| You see | What to do |
|---|---|
| Cloud invalid | The stored bundle still matches its recorded hash, but it does not verify now, or a signer has conflicting identity documents. Open Raw reports or download the bundle and verify it offline to see which check fails, then contact K-Block support and give them the address of the page and the check that fails. |
| Browser consistent | The dashboard has no pinned Gateway identity. Compare the issuer KID with the Gateway KID that K-Block gave you, and let K-Block support know that the dashboard trusts no specific Gateway identity. |
| Browser not this gateway or mismatch | Do not rely on the bundle. Check that you opened the right receipt, or chose the right file. |
| "Could not load the receipt" or "Could not fetch the bundle" with "K-Block could not complete this request because of a problem on its side." | K-Block could not read the stored receipt file, or the file no longer matches the SHA-256 recorded at issuance. The Cloud API serves neither the page's report nor the file, and the file cannot be repaired from the dashboard. Try again later; if it keeps happening, contact K-Block support and give them the request ID shown in the error, and the address of the page. |
| "Could not fetch the bundle" (other reasons) | The Cloud API could not serve the bundle. Try again; see Receipt verification. If it keeps failing, contact K-Block support with the code and the request ID the error shows (when it shows neither, tell them when it happened). |