sign-receipt

Sign Receipt

Record a bounded attestation about something that happened outside Runx so a later governed run can cite exactly what was claimed, by whom, on which evidence, and for what reliance scope. The native Runx receipt signature proves the attestation packet was sealed without later modification. It does not prove the external action itself happened.

That distinction makes this skill useful without turning a signature into a fictional provider verifier. The actual proof remains in the referenced commit, provider object, approval record, transaction, or other evidence system.

When to use it

Use sign-receipt when an operator performed a legitimate off-runtime action and downstream automation needs a stable, auditable assertion about it. Examples include a manual console change, an externally approved decision, or a provider operation completed before a native adapter existed.

Do not use it to launder an unsupported claim, copy raw evidence into a receipt, or replace a provider readback surface that Runx can actually call. If the external record is available through a governed reader, prefer that stronger evidence path.

How it works

1. Supply the action, named principal, exact claim, optional reliance scope, and bounded opaque evidence references.
2. Each evidence item names only a stable ref, SHA-256 digest, and what that evidence is asserted to prove. Raw messages, receipts, secrets, and personal records are not accepted.
3. Native receipt.attest validates completeness, rejects duplicates and secret-shaped material, and computes a deterministic attestation digest.
4. The normal Runx receipt signer seals that packet into the parent run.
5. Later consumers can verify the receipt and decide whether its declared reliance scope is sufficient for their own action.

The skill never calls the provider named in the claim and never appends to an external ledger. Its signature mode and proof boundary are explicit in the result.

Inputs and result