There's a fork the instant a user opens an AI-generated artifact after a meeting. Either they think "this is close enough that I can shape it," or they think "I have to rebuild this from scratch." Everything about whether the tool helped rides on which reaction they have - and that's the lesson building Earmark kept teaching us. Generating an artifact isn't the win. The artifact has to be editable, shareable, and immediately useful. It sounds obvious; it's a surprisingly high bar.

The user wants to edit, not reconstruct.

People don't want to admire what AI made. They want to use it, and use it now. So the failure modes are easy to name: if they have to rebuild the logic, the artifact failed. If they have to re-add all the context, it failed. If they have to rewrite the ticket before engineering can parse it, it failed. If they can't forward it to a teammate without wincing, it failed. None of this requires perfection - it requires usability, which mostly means respecting the format of the work. A spec needs scope, rationale, tradeoffs, and open questions. A ticket needs context, expected behavior, constraints, and acceptance criteria. A customer follow-up needs the right tone and a real next step. A decision log needs the decision and the why behind it. Each one has to be shaped for the person who picks it up next.

This is exactly where a lot of AI output quietly breaks. It can sound good without being operational, read well without being actionable, look complete without being complete enough - the worst version is the one that seems finished right up until someone tries to use it. Which is why the real test was never whether an artifact looks impressive on its own. It's whether it survives the workflow. Can the PM edit it in minutes? Can engineering build from it? Can leadership see the delta? Can the customer-facing team actually send the follow-up? Will the decision still be trustworthy next week? Can the team move without another clarification loop?

That test pushed us to think about output less as "content" and more as a work object - something that has to move. It gets shared, edited, assigned, discussed, copied into another system, used as the starting point for the next decision. If it just sits there as a nice-looking summary, it didn't go far enough. And the point of getting it close isn't to remove humans from the process; it's to move them to the right part of it - reviewing, correcting, approving, sharpening, deciding - instead of rebuilding from zero. Because the moment someone has to rewrite everything, the magic is gone.

So the standard is concrete: outputs close enough to use, clear enough to share, structured enough to edit. The product was never the generated text. It's the shrunken distance between the meeting and the work someone can actually use.