Capabilities and Evidence

Sophisticated evaluation requires more than a list of features. It requires a clear distinction between what a system can support, what has been implemented, what has been demonstrated, and what has been deployed for a customer.

Evidence vocabulary

Label	Meaning
Conceptual pattern	A technically plausible application described for planning; not evidence of implementation or adoption
Implemented capability	Code and operating workflow exist and can be evaluated in the applicable environment
Internal demonstration	State of Stick has exercised the capability through its own controlled project or prototype
Customer-scoped pilot	A customer has authorized a bounded evaluation with defined scope and success criteria
Production deployment	The capability is operating for an authorized program with applicable support and controls
Planned capability	A direction under consideration or development; not currently available

Documentation should use the strongest label supported by evidence and no stronger.

Capability is not deployment

A platform may support claims, verified interactions, customer reporting, connected packaging, or enterprise workflows without every pattern having been deployed for a named customer. Likewise, a working internal demonstration does not establish market adoption, regulatory acceptance, or a completed pilot.

State of Stick therefore avoids treating:

• a proposal as a partnership;
• a mockup as production authorization;
• a route or prototype as a completed customer deployment;
• test data as customer performance;
• a technical possibility as a contracted feature;
• AI-generated analysis as evidence;
• an interaction count as revenue or long-term value.

Types of evidence

Technical and commercial review may draw from different evidence:

Evidence type	What it can support
Running software	Implemented behavior, interfaces, and state transitions
Automated checks	Regression protection and expected behavior under tested conditions
Migration and data model	Persistence design and operational concepts
Live route or workflow probe	Availability and response behavior at a point in time
Physical prototype	Form, placement, fit, finish, and interaction feasibility
First-party event record	A recorded interaction or outcome under the stated policy
Customer authorization	Permission, scope, and responsibility
Paid pilot or production order	Commercial commitment within the documented scope

No single form of evidence proves the whole company thesis. The system is evaluated by how its physical, software, trust, operational, and commercial evidence fit together.

Current documentation posture

This public documentation describes:

• the system State of Stick is building;
• implemented and reusable platform patterns;
• internal controls and customer responsibilities at a public-safe level;
• potential vertical applications with explicit non-affiliation boundaries;
• a framework for evaluating future pilots and production deployments.

Named customer claims, confidential performance, commercial terms, security evidence, and proprietary technical materials should be shared only through an appropriate authorized review process.

Questions an evaluator should ask

1. Does the physical product create a credible reason to keep and interact?
2. Can identity and experience change independently without breaking lifecycle records?
3. Are business decisions separated from page content and client-side state?
4. Are standard and verified interactions represented honestly?
5. Can customer access and reporting remain isolated?
6. Are raw activity, quality exclusions, and business outcomes distinguishable?
7. Can a program be paused, changed, supported, and retired?
8. Does the evidence support the exact maturity claim being made?
9. Which parts of delivery become reusable across programs?
10. Which details are withheld for legitimate security, customer, or trade-secret reasons rather than used to avoid technical scrutiny?

For a structured review path, see the Technical Evaluation Guide.