A feature announcement describes a launch at one point in time. A current help article describes the workflow a provider currently documents. A feature status comparison connects those records and explains whether the feature’s name, access, behavior, or limitations have changed. Its output is a practical status note rather than another launch recap.
Primary sources checked on 8 October 2026. Worked examples and sample records below are illustrative; they do not represent product tests or real customer findings.
Identify the feature beyond its marketing name
Record the announcement date, product surface, feature name, stated audience, and promised behavior. A name can be reused for a broader product or a different interaction. Break the feature into actions such as importing a source, selecting it in chat, creating an output, or exporting that output. These actions give you something concrete to compare.
Choose a user question such as whether a team can still perform the originally announced source workflow. Avoid a broad question like is the product still good. The status note should explain documented availability and behavior, not invent a quality judgment from a changed help page. Keep the original wording and the current interpretation in separate columns.
Collect dated announcement and live help
Find the original provider announcement and the current primary help article for the same workflow. Follow redirects and record the destination. Google’s notebook help pages currently use Gemini Notebook terminology; this demonstrates why a current help page may not retain the exact name readers remember from older NotebookLM materials.
A changed name does not by itself prove that a feature was removed. Check the action described, its access requirements, and the relevant limitations. Keep publication date, last-updated date if supplied, and observation date separate. A live page may change without a visible revision history, so a comparison should not invent an exact date for the change.
Build a behavior-focused comparison
Use rows for feature action, announcement statement, current help statement, access conditions, difference, and practical consequence. Classify differences as renamed, expanded, restricted, relocated, or unresolved only when the evidence supports that label. If the current page is silent on an older claim, mark it undocumented in the inspected page rather than immediately withdrawn.
For an illustrative source-import review, an announcement may describe broad document support while the current help lists specific formats and import limitations. The consequence is to plan around the currently documented route. Avoid calling that a broken promise unless the original statement and current restriction are directly comparable and the relevant context has been established.
Check account and surface differences
Desktop, mobile, consumer, enterprise, and API documentation can describe different feature sets. A current page for one surface may not answer a claim made about another. Record account type and platform beside each row. If a limitation applies to mobile, do not spread it across all users. If a feature requires a paid plan, do not infer free access from an announcement that omitted plan details.
When documentation differs, use a separate evidence row for each surface. A test in your own account can help verify access, but it should be labeled as a dated observation for that account. It does not establish universal rollout status. Keep the product’s published policy and the observed interface distinct.
Explain missing and contradictory evidence
If the announcement and help page conflict, quote only the necessary short passages and show the dates. Investigate whether one refers to preview access, a phased rollout, or an older feature version. Ask whether the help page’s restriction is conditional. Contradictory words can become consistent once surface and date are aligned, but do not force agreement when the evidence remains inconsistent.
If a primary page is unavailable, record the failed route and seek an official replacement. A secondary copy can preserve wording, but label its status. Your final note may need to say that the original announcement could not be directly inspected. That is more useful than confidently reconstructing it from repeated summaries.
Deliver the feature status note
Write the current practical outcome first: which documented action a reader can plan around, on which surface, with what qualifications. Then summarize the historical change and unresolved questions. Link both primary records and provide the date of the check. Keep promotional language out of the conclusion unless it is the wording being evaluated.
Assign a recheck trigger such as a revised help article, model change, or product rename. Preserve the earlier comparison so future readers can see what changed. The finished note should help someone use the current workflow while maintaining a fair historical account of the announcement, rather than treating every documentation edit as a new product launch or a withdrawal.
Review and preserve the finished feature status comparison
Before handing over the result, perform a review that starts from the evidence rather than the generated prose. Pick a clearly supported item, a disputed item, and an item with missing information. Write the expected treatment of each before reading the proposed conclusions. Then open the cited originals and compare the result with those expectations. Check the surrounding text, headings, dates, and qualifications, because a citation can point to the correct document while supporting a narrower statement.
Ask a colleague to use the finished deliverable without your explanation. They should be able to locate the original records, identify unresolved questions, and understand which statements are direct evidence and which are your interpretation. Revise any place where they must guess. Keep the reviewed output, source manifest, prompt, and correction history together. Record the review date and the event that should trigger another check. When a source changes, preserve the earlier assessment and explain which conclusions were affected rather than silently replacing the evidence.
Do not equate an empty result with the absence of a problem. Check that all intended inputs were included and readable. Explain exclusions and merged records. A useful handover makes incompleteness visible and assigns a next action to the person who can resolve it.
Frequently asked questions
Does a renamed feature mean it was removed?
No. Compare the documented actions, access, and limitations before assigning a removal label.
What if the help page omits an old claim?
Record that it is not documented in the inspected page and investigate further; silence alone does not prove withdrawal.
Can my account prove a universal rollout?
No. It provides a dated observation for that account and surface.
Which date belongs in the comparison?
Preserve announcement, visible update, and observation dates separately rather than treating them as interchangeable.
What is the final output?
A dated behavior table and a concise current-status note with source links, qualifications, and unresolved questions.
