Data and Control Model

State of Stick separates descriptive content from authoritative state. This is the most important technical boundary in the platform.

Content versus authority

An experience can explain an offer, display a claim button, or describe a product. It cannot establish that an offer is still available, a claim is eligible, a payment succeeded, or a person is authorized.

Concern	Authority
Public copy and media	Approved experience version
Destination selection	Connected identity and lifecycle state
User access	Server-side identity, session, role, and customer scope
Claim eligibility	Claim workflow and current entitlement state
Price and payment	Current server-side commercial and payment records
Fulfillment	Operational order and fulfillment state
Object verification	Supported evidence evaluated by the verification service
Reporting	Stored first-party events interpreted under the active policy
AI recommendation	Approved inputs plus a reviewable generated draft

Tenancy

Customer-facing records belong to a customer organization and, where applicable, a program within that organization. Customer identities are provisioned into a bounded scope. Internal access and customer access are separate security contexts.

Conceptually:

organization
  ├─ authorized people
  ├─ programs and policies
  ├─ objects and identities
  ├─ experiences
  ├─ workflows and outcomes
  └─ reports

An identifier supplied by the browser is never sufficient by itself to broaden the signed-in user’s organization or permission scope.

State machines

Important records move through explicit states rather than relying on page presence or informal interpretation.

Examples include:

• experience: draft → review → published → paused → retired;
• object: planned → produced → configured → tested → active → retired;
• recommendation: generated → needs review → approved or rejected;
• proposal: draft → approved → sent → accepted or rejected;
• claim or fulfillment: workflow-specific pending, accepted, completed, failed, cancelled, or expired states.

Not every transition is reversible. Higher-impact transitions require the appropriate identity, permission, and evidence.

Event model

The platform records events to answer bounded program questions. An event typically needs:

• a program and experience context;
• an event name and timestamp;
• session or interaction context appropriate to the policy;
• object or campaign attribution when available;
• consent, geography, retention, and quality scope;
• business outcome linkage only when the authoritative workflow confirms it.

Events remain distinct from derived metrics. Reports may filter known tests, suspected automation, or excluded scopes, but filtering does not rewrite the underlying history.

Policy resolution

Collection and reporting behavior follows the most specific applicable active policy, such as a campaign policy before a customer default and a platform default. If a required policy cannot be resolved, the system should fall back to a more restrictive behavior.

The same principle applies to privileged actions: unresolved authorization denies access rather than expanding it.

Idempotency and replay

Business actions that may be retried—such as payment confirmation, claim submission, notification, or external webhook processing—should not create a new business outcome merely because the same valid request arrives again.

Verified physical interactions have a separate replay concern: repeated or invalid evidence must be evaluated according to the configured trust workflow. Public documentation describes the security property, not the confidential configuration or thresholds.

Auditability

Material operations should retain enough context to answer:

• who acted;
• within which organization or program;
• what record changed;
• which action occurred;
• when it occurred;
• which approved source, policy, or request informed it;
• what review or resulting state followed.

Audit records support review and incident response. They do not justify collecting unrelated personal data.

Deliberate abstraction boundary

This document exposes the platform’s reasoning model and safety invariants. It does not publish table names, infrastructure topology, credential design, anti-abuse thresholds, cryptographic material, secure-tag configuration, customer identifiers, or proprietary production-to-identity procedures.