Causal Action Receipts

The repeatable rule for humans, AI, devices and IoT: an action is valid only when it extends a grounded parent with a fresh hardware-bound signature.

The recurrence

The compact form is deliberately small:

E_n = Hash(E_(n-1) || Action || Nonce || Sign_TPM(E_(n-1) || Action || Nonce))

The production form carries the context a verifier needs. The canonical body is length-prefixed field framing, not delimiter-joined text, so binary fields verify byte-for-byte across implementations:

body_n = domain
       || actor_id
       || mode
       || principal
       || action
       || target
       || capability
       || policy
       || E_(n-1)
       || nonce
       || ttl

sig_n  = Sign_TPM(body_n)

E_n    = Hash(domain || body_n || sig_n)

E_n is the event id: the TIBET node for this action. The signature is made by the hardware-bound .aint key where available — TPM, Secure Element, StrongBox, HSM, hardware token, or another attested key store. The private key never leaves the device.

What each field means

The governance fields carry the rest of the contract: actor_id and principal express who acts and on whose behalf; action, target and capability bind the deed to the right; policy and mode say which governance lane applies; and domain separates this receipt family from every other protocol use.

The verifier's question

Every layer can ask the same thing before it lets anything happen:

Where is your parent?
What are you allowed to do?
Which hardware or runtime key signed this now?

If the answer cannot be verified, the action does not become real. It goes to quarantine, not execution. A receipt is not a log line; it is a signed causal step. Without the E_(n-1) binding, there is no causality — only loose state.

Human actions

A human .aint can create relationships and approve temporary elevation. The receipt binds the consent screen to a real action.

jasper.aint accepts henk.aint into a family pool

E_n records:
  actor       = jasper.aint
  action      = relation.accept
  target      = henk.aint
  capability  = family.pool.member
  policy      = bilateral-consent
  parent      = the event that made the consent prompt appear
  proof       = fresh hardware-bound signature

The phrase, number, QR code or alias may help the human find the moment. It does not create the relationship. Consent creates the relationship, and the receipt proves what was accepted.

AI actions

An AI actor is never trusted because it produced plausible text. It may act only inside a mode, a principal, a policy and a capability.

{
  "actor_id": "jis:ai:planner:jasper",
  "mode": "on_behalf_of",
  "principal": "jasper.aint",
  "action": "calendar.propose",
  "target": "henk.aint",
  "capability": "calendar.propose",
  "policy": "requires_human_confirm",
  "ttl": "10m"
}

This is the anti-hallucination rule as infrastructure: no parent, no actor; no policy, no action; no proof, no route.

IoT and device actions

IoT devices usually do not grant consent themselves. They act under an owner, install attestation and narrow device policy.

{
  "actor_id": "jis:iot:doorbell:home",
  "mode": "owner_scoped",
  "principal": "home.vandemeent.aint",
  "action": "ring.notify",
  "target": "jasper.aint",
  "capability": "notify",
  "policy": "local_or_attested_edge_only",
  "ttl": "30s"
}

A hardphone, sensor, router, actuator or relay can be useful without becoming ambiently trusted. It gets the exact capability the owner granted, for the exact chain that called it.

How it meets .paint

.paint is what happens when something appears without enough grounding.

valid chain + valid proof + policy grant -> .aint posture for this context
missing parent/proof/grant              -> .paint quarantine
proven escape, poison or impersonation  -> .taint
traffic shaping or decoy envelope       -> .faint
temporary human maintenance             -> maint lane
sealed hardware/core event              -> saint lane

BEAMER and KNOCKER are protocol roles inside a temporary rendezvous. They are not identity classes.

t-1  no relation
t0   BEAMER opens a temporary attested hatch
t1   KNOCKER proves phrase/capability and presents actor proof
t2   CONSENT: show peer .aint + 6-digit SAS; no route exists yet
t3   accept: Relation materialises + sealed E_n

reject / timeout -> back to t-1

What this lets builders reuse

The same receipt shape covers very different systems:

• a human accepting a contact;
• an AI acting on behalf of a person;
• an autonomous AI spending budget;
• an IoT sensor reporting state;
• a hardphone registering under an owner;
• a runtime process writing, reading or modifying a resource;
• a maintenance action under maint;
• a voice call rebind or bearer handover.

Different actor classes, same rule:

previous event -> scoped action -> fresh proof -> sealed receipt

What can be public

The recurrence is safe to publish. It is not a secret; it is the security property other implementers need to build against.

Minimal verifier checklist

• E_(n-1) exists, or is an accepted genesis event.
• The nonce is fresh for this actor and context.
• The signature verifies against the actor's attested key.
• The actor key resolves to the claimed .aint / JIS actor.
• The policy permits this action on this target under this capability.
• The TTL has not expired.
• Recomputing the domain-separated event hash over domain || body_n || sig_n equals E_n.