Technical Evaluation Guide

This guide is for readers evaluating State of Stick at a technical, commercial, or systems level.

Recommended reading path

1. Company and Product Thesis — the problem, product thesis, platform logic, and value architecture.
2. The State of Stick System — the six system planes, domain objects, interaction path, and invariants.
3. Capabilities and Evidence — the maturity vocabulary used to prevent prototype, pilot, and deployment claims from being conflated.
4. Platform Architecture — runtime layers and responsibility boundaries.
5. Data and Control Model — authority, tenancy, state, event, policy, idempotency, and audit concepts.
6. Trust Model — identity, object, experience, action, and record trust.
7. Analytics and Privacy — measurement policy and reporting limitations.
8. AI Foundation and Responsible AI — model routing and human-control boundaries.

System questions

A technical reviewer should be able to determine:

• what remains physically fixed and what remains digitally changeable;
• how an object reference resolves to a current experience;
• how ordinary access differs from verified physical presence;
• which service is authoritative for eligibility, payment, fulfillment, and permission;
• how customer data and administrative access are separated;
• how interaction events become reportable outcomes;
• how updates, pauses, revocation, and retirement work;
• where AI is useful and where it is explicitly non-authoritative.

Commercial questions

An investor or strategic partner should be able to evaluate:

• why the physical product is more than a link carrier;
• which capabilities become reusable across customer programs;
• how one-time creation can lead to ongoing platform operation and expansion;
• why vertical applications share an underlying system;
• what evidence would convert a technical capability into a credible production or market claim;
• which operational knowledge can compound as programs are delivered.

Diligence materials by sensitivity

Review level	Appropriate material
Public	This documentation, public experiences, published policies, and authorized examples
Mutual evaluation	Scoped architecture discussion, product demonstration, pilot design, and sanitized evidence
Confidential diligence	Customer-authorized performance, security controls, operational evidence, commercial model, and selected implementation detail
Restricted	Credentials, cryptographic secrets, personal data, supplier economics, secure configuration, and trade-secret production methods

Confidentiality is not a substitute for evidence. It is a control on how sensitive evidence is shared.

Suggested pilot design

A technically meaningful pilot should define:

1. a real physical format and distribution context;
2. the intended participant and useful action;
3. the lowest sufficient trust level;
4. the authoritative workflow behind the action;
5. the event and outcome measurement plan;
6. internal-test and data-quality treatment;
7. content, brand, privacy, and launch approvers;
8. success, failure, pause, support, and retirement criteria.

A pilot should test the integrated lifecycle, not only whether a phone can open a URL.

Claims this documentation does not make

The documentation does not imply:

• completed deployment for every described vertical;
• endorsement or affiliation by a named prospect or institution;
• patent issuance or exclusive ownership of commodity technologies;
• unqualified product-authenticity or legal-ownership proof;
• guaranteed engagement, conversion, revenue, or cost reduction;
• certification, regulatory approval, or fitness for a sensitive use without the appropriate review.

Contact for deeper review

Use the State of Stick contact form to request an appropriately scoped technical, commercial, or security discussion. Describe the organization, evaluation purpose, desired depth, and any confidentiality requirements.