Grant Evidence
What a grant proves
A grant is a bounded execution authority object issued by KiLu after an approval
event is verified. Possessing a valid grant proves a constrained set of facts.
It does not prove more than that.
A grant proves
- An approval event occurred — biometric-signed, non-replayable
- KiLu adjudicated the approval and decided to issue authority
- The authorized action is constrained to a specific class and toolchain
- The grant is time-bounded — TTL enforced at the Hub level
- The JTI ensures single-use — replay produces a hard deny
- The subject is explicitly bound — grant is not transferable
A grant does not prove
- That execution has occurred — the grant predates execution
- That the underlying action is safe or correct
- That the approver had full information about the action's outcome
- That execution was contained within non-Hub surfaces
- Anything beyond the grant's defined scope and TTL
Receipt Evidence
What a receipt proves
A receipt is the post-execution artifact. It is cryptographically linked to the grant
that authorized the execution. A signed receipt is stronger than a log — it is tamper-evident
and verifiable without contacting KiLu infrastructure.
A receipt proves
- An execution event occurred at a specific timestamp
- The execution was linked to a specific, named grant
- The intent hash at execution time matches the authorized intent
- The receipt has not been modified — tamper-evident flag + signature
- The Ed25519 signature is verifiable with the authority public key
- The deny path also produces a receipt — denial is verifiable evidence
A receipt does not prove
- That the execution result was correct or benign
- That no additional actions occurred outside the grant boundary
- That the system is universally safe for all threat classes
- That the approver's intent was correctly represented in the AVO
- Continued compliance beyond the receipt timestamp
Happy-Path Evidence Fragment
Authorized execution — full chain
The following is a normalized representation of a successful execution event from the
2026-03-23 smoke tests. Field values are representative — this is a curated proof surface,
not a raw log dump.
2026-03-23 · R3.1-alpha smoke test · run 2/3 · Linux Hub
✓ Happy path
✓ E2E confirmed
Linux Hub · R3.1-alpha
Normalized · not raw log
Execution event — authority chain
ALLOW
Ingress
channeltelegram:operator
task_idtsk_f2e9a1...
actionweb:fetch// proposed, not yet authorized
targethttps://klimacoach.com/overview
Approver
subjectapprover:dev_9a2d
keystoreandroid:biometric-bound// non-exportable
approval_siged25519:390a...82f1
signed_at2026-03-23T11:14:02Z
avo_hashsha256:4c3b2a...// action value object
KiLu
grant_idgrt_a4f8e2...
action_classweb:fetch
scopeallowlist:klimacoach.com
toolchain_idtc_default_web
ttl300s
jtisingle-use · replay → deny
issued_at2026-03-23T11:14:04Z
Hub
hub_typelinux:r3.1-alpha
grant_validtrue · in-scope · not expired
executionPROCEEDED
runtime_idrt_b3d6c2...
Receipt
receipt_idrec_b7c2a1...
linked_grantgrt_a4f8e2...
statusALLOW
intent_hashsha256:a1b2c3...
tamper_evidenttrue
signatureed25519:9f3a...c1e0
issued_at2026-03-23T11:14:09Z
✓ Execution authorized and receipted — authority chain complete
Deny-Path Evidence Fragment
Deterministic denial — system working correctly
A denial event is not a system failure. It is proof that the fail-closed boundary
is enforced. When the executor lacks a valid grant, it does not attempt execution —
it emits a denial artifact. That artifact is evidence of correct behavior.
The deny path was explicitly tested as part of the 2026-03-23 baseline. Both the
missing-token and expired-grant scenarios produced hard denials — no execution,
denial record emitted.
2026-03-23 · R3.1-alpha smoke test · deny-path run · Linux Hub
✕ Deny path
✓ Fail-closed confirmed
Linux Hub · R3.1-alpha
Normalized · not raw log
Execution event — missing token scenario
DENY
Ingress
task_idtsk_2c7d11...
actionweb:fetch// no approval event — no grant issued
grantABSENT
Hub
grant_checkNO VALID GRANT PRESENTED
fallback_modeNONE — fail-closed
executionBLOCKED
Denial record
denial_idden_9e1f3b...
reasonMISSING_GRANT
statusDENY
task_idtsk_2c7d11...
issued_at2026-03-23T11:22:41Z
tamper_evidenttrue
✕ Execution blocked — denial artifact emitted as structured evidence
Path Comparison
What the two paths produce
Both paths produce artifacts. Neither path is silent. The presence of a denial record
is stronger evidence of a correctly functioning system than the absence of any record.
Happy path — ALLOW
Deny path — DENY
✓ Approval event present and verified
✓ Grant issued: scoped, TTL-bound, JTI-protected
✓ Hub validates grant before execution
✓ Execution proceeds within scope
✓ Signed receipt emitted, linked to grant
✓ Verifiable offline with authority public key
✕ No approval event — or grant absent / expired / mismatched
✕ No grant issued — or grant rejected at Hub
✓ Hub detects boundary violation — no fallback mode
✕ Execution blocked — fail-closed enforced
✓ Denial artifact emitted — tamper-evident, timestamped
✓ Denial record is auditable proof of correct behavior
Verification Path
How authority linkage is verified
Any principal with the authority public key can verify the full chain — offline,
after the fact, without contacting KiLu infrastructure. Verification confirms
the unbroken chain from approval through to execution evidence.
01
Obtain the authority public key
The KiLu authority public key is available publicly. It does not change between verification sessions. Any verifier can hold it independently.
02
Obtain the receipt artifact
The receipt object contains: receipt_id, linked_grant, status, intent_hash, timestamp, tamper_evident flag, and signature. No live system query required for verification.
03
Verify the Ed25519 signature
Signature verification confirms the receipt was issued by the KiLu authority and has not been modified. An invalid signature means the receipt cannot be trusted.
verifyReceipt(receipt, authorityPublicKey) → boolean
04
Confirm the intent hash matches
The stronger verification path: confirm that the receipt's intent_hash matches the sha256 of the original intent payload. This proves the receipt covers the specific action — not just any action under that grant.
verifyReceiptForIntent(intent, receipt, publicKey) → VerificationResult
05
Confirm grant linkage
Cross-reference the receipt's linked_grant field against the known grant_id. This confirms the receipt corresponds to an authorized execution event — not an unrelated or forged receipt.
Boundaries of Interpretation
What cannot be concluded from evidence
A receipt is not a promise of universal safety. It is a bounded record that an
authorized execution event occurred, or was deterministically denied, under defined
conditions — at a specific time, within a specific scope, by a specific executor.
-
A receipt does not certify the result.
It certifies that the execution was authorized and occurred. Whether the result
was correct, complete, or free of side effects is outside KiLu's scope.
-
A receipt does not certify containment.
If the executor has access beyond its assigned toolchain or scope, execution may
have occurred outside the bounded surface. KiLu enforces the authority boundary —
it does not enforce process isolation or network containment.
-
A receipt does not certify the approver's intent.
It certifies that the approver signed an AVO. Whether the AVO accurately represented
the approver's understanding of the action's consequences is not something KiLu can verify.
-
A denial record certifies refusal — not attempted execution.
A DENY artifact confirms the Hub did not proceed under that grant condition.
It does not certify whether other execution paths outside KiLu's boundary were attempted.
-
Evidence correctness depends on executor integrity.
KiLu's evidence chain is sound only when the Hub is operating correctly and has
not been compromised. A compromised Hub can emit false receipts.
This is a known limit — see Security.