A learning product should show its working

Read the status before the promise

A learning product can have a public app, an experimental feature, a future service, and a long-term vision at the same time. Trouble begins when those different states are compressed into one confident sentence. A school evaluating a tool, a parent downloading an app, and an investor considering a business each need different information—but all need to know which claims describe today.

For SASHA, the public business website is where the story, resources, and current download routes should meet. The application remains a separate destination for sign-in and use. This article sets out the publication standard we are adopting: make it possible to distinguish an available release from a beta invitation, a proposed service, or a question still being researched. It is an editorial commitment, not an independent certification.

Use four labels consistently

Available means that a specified audience can access the feature through the stated release and route, subject to any documented account or regional restrictions. Beta means that testing conditions apply and behaviour may change. Planned means that work is intended but should not be relied on as a present capability. Research means that an idea is being investigated and may never become a product feature.

These labels should accompany the specific claim rather than disappear into a footer. If a demonstration shows a prototype, say so on the demonstration. If a store is not ready to accept orders, do not send customers to it with a purchase promise. If a paid service has not passed its provider and operational checks, collect an enquiry rather than imply that payment and delivery are already available.

Separate release evidence from learning evidence

A release number tells us which software we are discussing. A successful test may show that a defined action worked on a defined device. Neither establishes that the product raises grades, saves every teacher time, or meets every institution's legal requirements. Those are different questions requiring their own evidence and boundaries.

NIST's Generative AI Profile treats risk management as ongoing work across a system's lifecycle, including evaluation and documentation. That is a useful reference for product conversations, but citing it does not mean NIST has assessed or endorsed SASHA. Our practical recommendation is to ask for the observation behind a claim: what was tested, when, with what limits, and by whom?

For an educational outcome, ask whether the evidence concerns that outcome rather than an adjacent measure. More completed prompts is not automatically better understanding. A positive testimonial is not a controlled evaluation. A small pilot can reveal valuable usability problems without supporting a population-wide conclusion. A careful product team should be able to explain what its evidence does not establish.

A useful update has a boundary and a next step

Consider an illustrative update: 'We changed the sign-in error message and tested recovery on the listed devices. This does not change the authentication provider or introduce a new paid feature. If you still cannot recover access, use this support route.' That is more actionable than 'Everything is better.' It connects a change to its scope, verification, and a way to report failure.

A useful roadmap item does the same for unfinished work: explain the intended audience, the dependency that remains, and what people can do now. An institution could request a discussion; a tester could volunteer for a defined scenario; a reader could subscribe for a later announcement. None of those actions should be mistaken for buying something that does not yet exist.

How to read SASHA from here

Use the download page for current app destinations and availability labels. Use release updates for dated changes. Use Learning Brief articles for sourced analysis and practical exercises. Historical milestones remain part of the story, but should carry their dates. Financial projections belong in the investor context, where assumptions can be explained, rather than being presented as customer outcomes.

Before choosing a learning tool, write down one task you need it to support, one question about information handling, and one condition that would make you pause adoption. Ask for those points to be demonstrated or answered. The goal is not to demand that a product be finished forever. It is to make its present state intelligible enough for you to make a responsible decision.