Building an AI research process you can trust

A portfolio description was a lead, not the final answer

While researching the operator's projects for TrendsWhat, we began with a public portfolio. It named the products and described their design. That was useful for finding the right implementation, but it was not enough to establish the current behavior. We followed the description into the local source and recorded what the code actually showed.

That extra step changed the quality of the research. In MaybeTomorrow's outbox, a summary comment and the executable upsert behavior disagreed. A retry delay described as capped at five minutes actually stopped growing at 256 seconds under the inspected expression. In StockNote, a context field named “recent similar transactions” was populated by the latest ten expense rows, not by an observed similarity search.

These are small findings, but they demonstrate a practical research habit: use summaries to locate evidence, then inspect the evidence before writing the conclusion. This article documents the research process used for those source-backed case studies. It does not claim a comprehensive audit of the products or access to their private runtime outcomes.

Original TrendsWhat research workflow, based on the preparation of this publication's project case studies.

Define a question that evidence can settle

“Is this a good AI product?” invites broad opinion. “Where does an AI-generated expense draft become a committed record?” points to a specific boundary. The second question can be investigated by tracing the route, service, and persistence operations. It also makes the limits of a source-only answer clearer.

Before searching, write the decision your research will support. For a practical guide, the decision may be whether a reader should adopt a workflow pattern. For a product comparison, it may be which option meets a stated constraint. Then list the claims that would materially affect that decision.

This prevents research from turning into an inventory of interesting facts. A project may use many technologies, but a list of tools does not explain the approval boundary. Keeping the question visible helps you reject irrelevant detail and spend more time on the evidence that determines the answer.

Separate discovery from verification

Discovery identifies possible sources, terminology, and paths to investigate. Search snippets, AI summaries, documentation indexes, and portfolio pages can all help. Verification begins when you inspect the source that directly supports the claim you plan to make.

For the StockNote case, the portfolio's approval description led us to the AI CFO service and approval route. We then inspected the repository's pending-state check and transaction code. The public page established attribution and intent; the local implementation supplied the details discussed in the article.

Do not erase the discovery trail. It explains how you found the evidence and can help another researcher repeat the work. But keep the roles distinct in the final note. A search result saying a feature exists is different from an inspected implementation, and an inspected implementation is different from a successful production test.

Build a source register before drafting

A source register lists the materials you actually inspected. Record a stable title or file path, the access or inspection date, the source's role, and its limitations. For code, include the relevant function or operation. For a public document, include the direct page and revision date when available.

Our project inspection notes use project-relative file locations and plain-language observations. They deliberately exclude credentials, customer records, and private runtime logs. Readers can understand which mechanisms were inspected without receiving unrelated implementation material or sensitive data.

A register is especially useful when several sources describe different versions of the same system. The newest-looking page is not automatically the authority for every claim. Decide which source governs the question: current code for an implementation detail, a contract for a service commitment, or a runtime observation for deployed behavior.

Keep an evidence ladder

Think of evidence as a set of different kinds of support, not a single score. A public product description supports what the operator says about a feature. Source code supports statements about the inspected implementation. An executed test supports behavior under its recorded conditions. A production observation supports a bounded statement about the live system at that time.

These levels are related but not interchangeable. A test file's existence does not establish that it passes. A successful build does not establish that the production service updated. A production HTTP response does not establish that every authenticated feature works. Naming the evidence type prevents conclusions from expanding silently.

For each important sentence, ask whether its wording fits the evidence. “The code checks pending status” is appropriate after inspection. “Duplicate approvals are impossible” would require much broader analysis. The narrower sentence is not weaker writing; it tells the reader exactly what was established.

A contradiction is useful material

When sources disagree, do not immediately choose the one that matches your draft. Record the disagreement and inspect the boundary that could resolve it. In the outbox case, the body of the upsert function updated an existing mutation to an upsert, while a summary comment described a different precedence rule.

We reported the executable behavior and noted the comment mismatch. That is more useful than repeating the comment as fact or inventing a historical incident to explain it. The source did not establish when the comment became stale, why it changed, or whether users experienced a bug. Those questions remained outside the evidence.

The same habit applies to external research. A pricing page and a help article may refer to different plans. A release note may describe a feature that has not reached every account. Preserve the scope and date of each source before declaring a contradiction or combining them into a single claim.

Copy this research ledger

A ledger row should be short enough to review. If it contains several claims with different sources, split it. This makes unsupported clauses easier to spot and allows you to revise one conclusion without invalidating unrelated observations.

Use the ledger while researching, not only after writing. Retrofitting citations into a finished narrative encourages you to look for support for sentences you already like. A source-first record makes it easier to let the evidence shape the article, including findings that are less dramatic than expected.

Let AI assist the queue, not replace the inspection

An assistant can suggest search terms, identify candidate functions, organize a source register, and extract claims from a draft. Those tasks reduce organizational effort. Treat their output as a queue of things to inspect rather than a completed verification report.

A useful instruction is: “For each proposed claim, identify the exact supporting passage or code operation, label any inference, and state what was not checked.” That instruction is a reusable prompt, not a benchmarked result from this article. The assistant may still choose the wrong source or miss a qualification, so the evidence must remain available for review.

Our citation lab explains one reason. A real quotation can accompany an unsupported claim. A source register with filled cells can therefore look complete without establishing the conclusion. The research process needs a support judgment as well as a provenance trail.

Use the smallest sufficient excerpt

When discussing a source, include only the material needed to explain the observation. A short function name, a state transition, or a paraphrased operation may be enough. Copying an entire private file adds exposure without necessarily improving the reader's understanding.

For public sources, link directly to the relevant page and distinguish quotation from paraphrase. For original project diagrams, explain that they are redrawings based on inspection rather than screenshots of a live system. A diagram can communicate the mechanism clearly, but its caption should not imply that a runtime event was observed.

The same principle improves privacy and readability. Remove unrelated personal details, identifiers, and operational configuration from research notes. If a detail is not needed to support the article's claim, it usually does not belong in the published evidence package.

Write limitations while the evidence is fresh

A limitations section should name the missing evidence that matters. “Results may vary” is too vague. “We inspected test definitions but did not execute the iOS suite” tells the reader precisely what remains unverified. “No customer records were queried” clarifies that the article cannot report actual user outcomes.

Write these limits during the investigation, when you know which steps were skipped and why. Later, a polished draft can make the research feel more complete than it was. The ledger helps preserve the original boundary even as the prose becomes smoother.

Limitations can also guide the next useful experiment. The StockNote case suggests a synthetic test that creates a draft, verifies no final transaction exists, approves edited fields, and checks the stored result. That is a concrete follow-up. It should not be written in past tense until it has actually been performed.

Turn findings into a reader decision

A research article should do more than display sources. Explain what the evidence allows the reader to do differently. The approval case suggests making proposed actions reviewable before commitment. The outbox case suggests distinguishing queued, in-flight, and acknowledged work. The context inspection suggests checking whether field names overstate the retrieval method behind them.

Keep these recommendations proportional. They are design lessons drawn from the inspected mechanisms, not proof that the same architecture is optimal for every product. A small manual workflow may need only a review checklist, while a persistent action tool may need durable state and version checks.

A strong conclusion includes the recommendation, its basis, and the condition that would change it. That makes the article useful to someone whose situation differs from yours. It also leaves room for correction when better evidence becomes available.

Preserve the research package

Save the question, source register, claim ledger, relevant observations, and unresolved issues beside the manuscript. Keep original experiment results separately from diagrams derived from them. Record the inspection date and the actual execution environment when tests are run.

When revising an article, revisit claims affected by changed sources rather than changing the date automatically. A new publication timestamp does not make old evidence current. Explain material corrections in a way that readers can understand, especially when the conclusion or recommended action changes.

The goal is not to accumulate paperwork. It is to make the path from question to conclusion inspectable. A future reader, editor, or your future self should be able to tell which parts were observed, which were inferred, and which remain open.

Sources, materials, and limits

• Project inspection notes: the actual source register behind the StockNote and MaybeTomorrow articles.
• Approval-boundary case study and outbox case study: bounded implementation findings.
• Citation experiment: directly executed distinction between provenance and support.
• Original research ledger and workflow. This article describes the publication's source-inspection process; it does not claim a comprehensive product audit or unperformed production tests.