Open Work 001 keeps its seven answers out of a database.

Open Work 001 asks seven questions about a proposed AI intervention. Some answers may reveal weak ownership, sensitive data, uncertain risk or a service that should not use AI at all.

That made the first product decision straightforward: Kingsbury should not receive the answers merely because someone used the diagnostic.

The diagnostic requires no account or database. Selections live in a JavaScript object for the current page. The scoring runs locally. The decision record is assembled locally and downloaded through a temporary browser object. Close or reload the page and the answers are gone. If analytics is configured, it can record bounded completion metadata, not the selected answers.

The shipped path never sends the answers. A visitor can download the decision record locally; the report form is absent unless a delivery endpoint has been configured.

This was not a privacy line added after the tool was built. It shaped the tool.

What Open Work 001 gains without a database

There is no consent ceremony before using the diagnostic because the default path transfers no answers. A visitor can start immediately, inspect the rules and leave with a decision record without becoming a lead. The optional emailed report is a separate, explicit request made after the result.

The core architecture is smaller too. There is no authentication, saved-session data model, deletion flow or protected results page. Configuring email delivery would add an endpoint and its own retention and access responsibilities, which is why it remains separate from the local diagnostic.

Most importantly, the incentive stays clean. The tool exists to help someone make a better decision. It does not need to turn uncertainty into contact data before providing value.

The implementation is inspectable in the public decision engine. Its seven questions, weighted choices, hard-stop conditions and result logic are readable without a build process or account.

What Open Work 001 gives up without a database

Local-only state is not universally better. It has consequences:

• answers do not follow a person to another device;
• a closed or refreshed page cannot recover the session;
• optional analytics can show bounded completion events, but not which answers an individual chose;
• a team cannot share a live result link;
• there is no central history of past decisions.

Those could become features. They would also change the data responsibility and the nature of the relationship. The absence of a diagnostic database is justified for this version because the diagnostic takes minutes, produces a downloadable record and does not need continuity to fulfil its purpose. The optional report changes that responsibility only when a visitor asks for it.

If later evidence shows that saved sessions materially improve the decision, storage can be reconsidered with an explicit retention and access design. It should not arrive because persistence is the default shape of a web product.

The Open Work 001 data rule

Data minimisation is easiest when it is an architectural decision, not a policy promise.

“Nothing leaves your browser unless you request the report” is a property of Open Work 001 that a reader can test against the code. The local path never submits the answers. Report delivery, when present, begins with an explicit request. That is stronger than collecting every answer by default and asking the reader to trust an explanation about what happens next.

The limitation exists. So does the freedom it creates.