Worthy Trying Method

How We Test AI at Worthy Trying

Worthy Trying tests AI through real work, separates firsthand observations from broader claims, and reports both successes and failures.

In This Page

    Quick Answer

    Worthy Trying documents what happens when AI is used on real work.

    We do not treat every project as a laboratory experiment, and we do not claim that one result proves how every model or future version will behave.

    We use practical projects to expose useful patterns, verify claims when verification is needed, preserve meaningful failures, and explain the conditions under which a result worked or did not.

    Worthy Trying testing process from a real project through observation, external verification when needed, lessons learned, article creation, and a practical verdict.

    The Work Comes Before the Article

    Our articles often begin with a project rather than a keyword.

    We may be building a website, producing a large content collection, generating a visual set, troubleshooting code, comparing businesses, developing construction instructions or trying to make an AI workflow scale.

    The project creates problems.

    Those problems create questions.

    The questions become articles only when they contain a distinct lesson that may help someone else.

    We Separate Three Kinds of Claims

    Firsthand observations describe what happened in our own project.

    Broader factual claims describe something outside that project and are checked against appropriate current sources when they require external support.

    Interpretations and recommendations are our conclusions from the available evidence.

    Keeping those categories separate matters because “this happened to us” is different from “this always happens.”

    AI Helps Produce the Publication Too

    AI is part of the Worthy Trying production process.

    It helps organize accumulated project material, compare ideas, draft and edit articles, identify unanswered questions and connect related pages.

    That does not make generated wording the evidence.

    The underlying project, source, measurement, code execution, screenshot, visual comparison, specification or other external constraint determines how strongly we can make a claim.

    We Treat Failure as Data

    Not every test succeeds.

    A failed workflow, inconsistent image set, broken code change or article that had to be rebuilt can be more informative than a smooth first result.

    We preserve failures when they expose a repeatable lesson.

    We do not need every experiment to prove AI is good or bad. Mixed results are often more useful because they show where the boundary actually is.

    We Look for Repeatability

    One success can be interesting without being dependable.

    When possible, we ask whether the same approach continues to work across multiple outputs or related tasks.

    This became especially important when scaling article production. The first good result was not the real test. The 20th, 30th or 40th result showed whether the standard was actually repeatable.

    We Prefer External Checks When Correctness Matters

    The type of check depends on the work.

    Code can be executed.

    A website can be viewed at different screen sizes.

    A construction plan can be reconciled against dimensions, materials and assembly.

    A factual claim can be checked against a primary or authoritative source.

    An image that represents a specific object can be compared against its locked specification.

    A business hypothesis can be labeled as an inference rather than presented as proven fact.

    We Do Not Use AI Self-Agreement as Proof

    AI can critique its own work, and we use that capability.

    But a second AI answer agreeing with the first is not automatically independent confirmation.

    NIST's Generative AI Profile documents confabulation as a risk precisely because generated explanations can sound authoritative while being wrong.

    Self-review can improve an output. Verification needs an external anchor when the claim warrants one.

    What the Worthy Trying Verdict Means

    The Worthy Trying Verdict is a practical summary at the end of an article.

    It may report whether the approach worked, how repeatable it appeared, what human oversight remained necessary, the main limitation and the lesson we would carry forward.

    It is not a laboratory score.

    It is not a claim that every AI model, every user or every future version will behave identically.

    How We Use Outside Research

    Outside research has two main jobs.

    First, it verifies broader factual claims that our project alone cannot establish.

    Second, it helps us understand the current environment—for example, current search guidance, security recommendations or product behavior.

    We prefer authoritative sources for claims that matter and distinguish those sources from our firsthand observations.

    Why We Publish the Method

    The publication is stronger if readers can understand how conclusions were reached.

    Google's current guidance for generative AI search emphasizes unique, useful content and firsthand perspective rather than commodity summaries. Publishing the method also forces us to remain clear about what our own experience actually supports.

    Trust should come from visible reasoning and evidence, not from pretending every article is more scientific than it is.

    Worthy Trying Verdict

    Method: Practical project-based testing

    Primary evidence: Real work and observable outcomes

    Outside sources: Used for broader factual claims and current context

    Failures published: Yes, when they teach something useful

    AI used in production: Yes

    Final responsibility: Human

    Our goal is simple: do the work, learn from what actually happened, verify what needs verification, and publish the useful part.

    Sources

    1. NIST — Generative AI Profile
    2. Google Search Central — Optimizing for generative AI features