AI demos that never reach production safely

What usually goes wrong

• Demo autonomy is higher than production risk tolerance
• PII or regulated fields enter the path without an explicit gate
• No written “done when” or success check for the first slice
• Teams expand write access before a reversible pilot works

What this packet will not claim

No production deployment certificate, no invented readiness score, and no publish or deploy into your systems. You get a plain-language first slice: ship this first, do not do yet, still need, and how you'll know it worked.

The job is a first AI project for a small company

A small company does not need a platform program to try a first AI project. It needs a slice small enough to approve: what ships first, what stays off, which data is in the path, and how you will know the pilot held. Deployment Trust Radar at /deployment-trust asks for a public URL and the use case, then returns that packet. The full packet is free. There is no paid tier on this check, and there is no deploy.

The packet is plain language. It names the problem, the first slice to ship, the list of things not to do yet, and the check you will use afterward. Autonomy stays at draft with a person approving the send, unless you explicitly describe a narrower or wider gate. Data sensitivity is named. PII, regulated fields, and write access are gates, not footnotes. If the page cannot be read, the packet says so. It does not invent a readiness score or a certificate that production is safe.

“Done” for this check is not a launch. Done, inside the packet, is a written list: the human step before any external send, a small set of real examples with pass and fail, and zero unapproved sends in the window you chose. Expanding write access, automatic refunds, or automatic deletes is on the do-not-do-yet list until that first slice has been watched.

One example of what comes back

The landing example is a fixture, not a customer story and not a live capture of anyone’s systems. Its honest scope limit is: Example only — synthetic illustration, not a live capture of your systems. The context label is Support · PII. The problem line is: Ticket draft assistant fails to redact PII before human send. The use case on the fixture is: Draft support replies from past tickets; human must approve before send; ticket text may include PII.

The one recommended change is the first slice: Basic ticket draft assistant — human must send every reply. Autonomy on the card is Draft with human approval. Data on the card is PII. The fixture says you will know it held when: Zero PII exposure incidents in the two-week pilot. That sentence is the example’s success check. It is not a measured incident rate from a company.

What the example says not to do yet: Advanced PII auto-redaction with production write access, and Fully automatic send, refund, or delete. The written “you will know” lines on the same fixture are a human approve step before every external send, a golden set of real tickets with pass and fail checks, and zero unapproved external sends in the pilot window. Those lines teach the packet shape. They are not a case study.

The receipt beside the packet

The harness keeps a receipt for the change you are asked to approve. The public sample at /receipt/sample is the shape. Nothing runs from that page. Its verdict is “This homepage title is leaking first-visit clicks.” Its honest scope limit is “Sample shape. Not live proof. No traffic or rank guarantee.” Before: “Unclear title. Primary action buried.” After: “One title. One action. Sample shape only.” Next: “You approve, skip, or revise.” The boundary is no publish, no deploy, no outbound send, and approval required.

That sample is a homepage receipt, not the support-draft fixture above. Use it to see how a honest scope limit, one change, and a receipt sit together. Your integration packet is filled from the URL and the use case you submit. It does not borrow the sample’s homepage sentence, and it does not borrow another company’s tickets. If you have not described the data, the packet should say the data gate is still open rather than marking the path safe.

What to decide before anyone builds

Write the use case as a person would say it. Name who reads the draft, who is allowed to send it, and which fields can appear. A support reply that may contain a customer name, email, or account number is PII even when the demo used fake text. A docs assistant that only quotes public pages is a different sensitivity. The packet should not collapse those into one “AI project.”

Keep the first build reversible. A draft that a person must send can be turned off by stopping the draft. A tool that refunds, deletes, or writes into production cannot. The example’s recommended change is the reversible one: a basic draft, human send, no automatic redaction project and no production write on day one. If your real use case is narrower, the packet should get narrower, not more impressive.

Bring one public URL: a docs page, a product page, or a help article the assistant is allowed to read. Do not paste secrets into the form. The check is about scope and the approval gate. It is not a penetration test, a legal opinion, or a statement that a model will be accurate. Accuracy still has to be checked on examples you already have.

Where this sits in the harness

Launchfiles is the launch operator for AI-built products: it takes a product to its first paying customers and keeps them, through agents acting inside a policy you approve, with a receipt for every public act. This page is the check for a first AI project. The output is a packet you can show to the person who has to approve sends. It is not a deploy, and it is not a publish. Launchfiles will not publish, deploy, or spend without approval. Getting the free packet does not turn those switches on.

If the problem is a landing page people cannot use, start at Design UX Radar. If the problem is a page that search shows and nobody clicks, start at Search Repair Radar, and connect Search Console before expecting a repair. If the problem is a draft that must not invent facts, start at Page Draft. This check stays on scope: ship this first, do not do that yet, and say how you will know.