Physical software objects

State, not just revoke

The product is programmable state transitions for physical objects. Revoke is one transition (pointer off). Expiry, claimed, recovered, and replaced are others. The resolver stores object state - not who scanned, when, or where. Shipped today: active, expired, revoked, disabled; see docs/REVOKE_AND_LIFECYCLE_V1.md.

Printing is deployment

Software usually lives on servers, apps, and browsers. A printed QR places a small software reference in the world - with status, permissions, lifecycle transitions, memory, affiliation, and routing that can change after the ink dries.

• status
• permissions
• ownership
• revocation
• expiration
• memory
• affiliation
• game logic
• public instructions

What you can deploy

• Sticker Active · revoked · claimed · captured · part of a route or game · bench memory node
• Hoodie patch Event pass · faction badge · rotating pseudonym · verified affiliation
• Flyer Live campaign node · current instructions · revoked misinformation
• Card Public credential · membership pass · recovery-backed · revocable identity

100 stickers = 100 objects

Old model: 100 dead links. Humanity model: 100 deployed references - each with its own live state:

• 001 · active
• 002 · captured by Blue faction
• 003 · revoked
• 004 · unlocks after midnight
• 005 · bench memory node
• 006 · verified for tonight’s event

The sticker does not change. The live object behind it does.

Software becomes spatial

Deploy references to:

• a wall
• a jacket
• a market booth
• a bench
• a protest flyer
• a wristband
• a trail marker
• a table · garden sign

The physical world becomes addressable. Addressable → state.

Deployable public objects

Create a live object, print the QR, place it, manage state over time:

• active
• revoked
• disabled
• updated
• claimed
• transferred
• trusted
• expired

Not apps. Not IoT hardware. Cheap printed objects with live network status.