The State of Stick System

The State of Stick system coordinates a physical object and its digital life. It is best understood as six cooperating planes with a shared governance layer.

System planes

Plane	Core question	Public responsibility
Physical	What exists in the world?	Format, design, placement, durability, and production identity
Identity	Which object or batch is interacting?	Managed reference, lifecycle state, destination, and trust tier
Experience	What should the participant see or do?	Versioned content, accessibility, media, and calls to action
Workflow	What business action is allowed?	Claim, registration, payment, signing, fulfillment, service, or ownership state
Intelligence	What can be learned responsibly?	Policy-scoped events, quality controls, reporting, and approved AI assistance
Operations	Who configures and supports the system?	Sales, customer provisioning, production, publishing, access, and audit workflows

Governance crosses all six planes: identity and access, authorization, customer isolation, approval, privacy, retention, brand permission, and incident handling.

                         governance
┌──────────┐  ┌──────────┐  ┌────────────┐  ┌──────────┐
│ physical │→ │ identity │→ │ experience │→ │ workflow │
└──────────┘  └──────────┘  └────────────┘  └──────────┘
                    │              │              │
                    └──────────────┴──────────────┘
                                   ↓
                         ┌────────────────┐
                         │ intelligence   │
                         └────────────────┘
                                   ↕
                         ┌────────────────┐
                         │ operations     │
                         └────────────────┘

Core domain objects

The public conceptual model includes:

Domain object	Purpose
Customer	The organization responsible for an approved program
Program or campaign	The bounded business purpose, audience, policy, and measurement scope
Physical object or batch	The made item and its production/lifecycle context
Connected identity	The managed reference associated with an object or batch
Experience	The approved destination content and allowed actions
Interaction	A standard, verified, invalid, or otherwise classified access event
Participant action	An intentional step such as a media event, form, claim, or product action
Business record	Authoritative state for payment, fulfillment, authorization, ownership, or service
Report	A policy-scoped interpretation of interaction and outcome records
Source and recommendation	Approved evidence and generated internal guidance used in governed AI workflows

These objects are related but not interchangeable. A tap is not a person. A claim is not automatically ownership. A click is not payment. A verified object interaction is not automatically authorization for a business action.

Interaction path

1. A participant encounters a physical object.
2. NFC, QR, or another approved entry point presents a connected reference.
3. The platform resolves the reference and evaluates its state.
4. If a verified tier applies, the platform evaluates the supported evidence.
5. The current approved experience is selected.
6. The participant may take an allowed action.
7. The authoritative workflow independently validates that action.
8. Policy-scoped events become available for quality review and reporting.

The experience layer does not grant entitlement by displaying a button. The workflow layer decides whether the requested action is permitted.

Control path

1. An authorized operator creates or updates a customer, program, object, experience, or policy record.
2. Role, customer scope, and action-specific permission are checked.
3. Material content and brand use follow their approval state.
4. Configuration is tested before activation.
5. Changes are logged and can be paused, revoked, replaced, or retired.

This separation lets public interactions remain simple while administrative actions stay bounded and reviewable.

Data and trust invariants

The architecture is designed around several invariants:

• A public destination is not an administrative interface.
• Customer access is scoped to the customer’s organization.
• Object evidence and person identity are evaluated separately.
• Prices, eligibility, payments, fulfillment, and permissions remain server-authoritative.
• Standard interactions are never relabeled as verified presence.
• Reports preserve the distinction between raw records, exclusions, and interpreted metrics.
• AI output cannot broaden authority or publish itself.
• A failure to resolve a required policy or authorization narrows behavior rather than granting broader access.

From one program to a platform

A single connected product exercises the same fundamental system:

customer
  └─ program
      ├─ objects and identities
      ├─ approved experience
      ├─ participant workflows
      ├─ analytics policy
      ├─ reports
      └─ operational history

Scaling is therefore not only a matter of producing more objects. It means reusing controlled platform capabilities across more customers, programs, formats, locations, and verticals while preserving isolation and evidence.

Next: Capabilities and Evidence.