Trust Model

State of Stick treats trust as a chain. A polished interface does not create trust if identity, authorization, object state, or business rules are weak underneath it.

For the broader public essay behind this framing, see Trust Infrastructure Starts With Physical Systems.

Trust layers

1. Person — who is acting, and for which organization?
2. Object — which object or batch is involved, and what trust level applies?
3. Experience — which destination and version are approved?
4. Action — is the requested claim, change, payment, or release allowed now?
5. Record — what evidence, consent, and retention rule applies?

Core principles

• Separate audiences. Internal operators, customers, private recipients, and public visitors do not share one universal identity boundary.
• Least privilege. Access is scoped to the work or customer data a person needs.
• Server authority. The server decides permissions, state transitions, pricing, eligibility, and payment truth.
• Fail closed. If a required authorization or policy lookup fails, privileged access is denied and data collection becomes more restrictive.
• Revocability. Sessions, service access, and private recipient access can be disabled or expired.
• Purpose limitation. Data and experiences stay tied to the approved program purpose.
• Honest verification. Standard interactions are not described as authenticated physical presence.
• No secrets in public content. Credentials, secure configuration, customer-private data, and proprietary methods do not belong in documentation or client-side code.

Shared responsibility

State of Stick secures the platform and operates the controls included in scope. Customers and partners remain responsible for accurate content, authorized users, prompt offboarding, lawful instructions, brand permission, and reporting suspected misuse.

For sensitive procurement or security review, request the appropriate confidential materials through an authorized State of Stick contact.

For the corresponding domain, state, event, and policy boundaries, see Data and Control Model.