Connect exclusions to the intended offer and actual resource scope

Google Ads negative-keyword audits for enterprise: assess coverage, commercial relevance and precise approved exclusions

Distinguish a presence check from a relevance review. Preserve business context, choose exact supported targets and keep shared-list membership separate from campaign attachment.

Define the enterprise's exclusion question

A negative-keyword audit should begin with the decision the organisation needs to make. The team may want to know whether campaigns have any negatives, inspect a particular shared list, identify poor-performing search terms or prepare an explicit exclusion. These questions overlap, but their evidence and completion conditions differ. A presence finding should not become a claim that the account's entire search traffic has been commercially assessed.

Resolve the customer and relevant campaign before discussing a scoped change. Enterprise accounts can share regional naming conventions, and several campaigns can contain similarly named groups. Use the authenticated connected context and actual resource identity internally. Display readable names and correct relationships so the owner can recognise the intended scope without decoding raw provider identifiers.

Establish whether the owner wants an explanation, creative suggestions or measured account research. Brainstorming possible irrelevant intentions can use confirmed offer context without API calls. Identifying actual terms that spent above a threshold needs the appropriate observations. A live addition needs supported capability and confirmation. Routing should preserve those intentions rather than treat every negative-keyword discussion as a provider query or mutation request.

A useful review can finish without an edit. The owner may decide a term remains relevant, that the evidence is insufficient or that a shared-list purpose needs clarification. Record the actual decision. An audit succeeds when it provides a defensible next step, rather than when it produces the greatest number of exclusions or changes the most fields.

Understand negative matching

Google's negative-keyword guidance distinguishes negative matching from positive matching and explains that exact negatives do not block searches merely because extra words are present. It also distinguishes Search behavior from other inventory. A review should preserve the actual match type and campaign context rather than describe every exclusion as a universal topic ban.

A negative criterion describes a particular exclusion rule. Its text alone does not identify the complete range of traffic affected without the matching context. The owner should understand whether the prepared action is exact, phrase or another supported operation. The app's dedicated addition path has its own explicit match choice, which should not be silently broadened to satisfy a loosely worded request.

Use examples as explanation, not proof about the customer's delivery. An invented query can help illustrate why excluding an exact term is narrower than excluding every related intention. It does not establish that the customer's ads actually appeared on that query. Account-specific claims need actual returned evidence and a clearly defined reporting population.

Keep exclusion purpose distinct from future outcome guarantees. A correctly created criterion can establish configuration, but it cannot prove that every remaining query will be useful or that conversion performance will improve. The audit should explain the intended relevance boundary and the verified field effect, leaving subsequent commercial evaluation as a separate measured task.

Interpret the presence finding

The current audit checks whether enabled Search, Shopping and Performance Max campaigns have negatives through the supported observed sources. It reports campaigns without observed coverage. This is a presence check. A positive result means the check found coverage in its population, not that it assessed the relevance or completeness of every exclusion.

A missing-coverage result is a review prompt rather than a ready-made term list. The audit does not offer a universal automatic remedy because appropriate exclusions depend on the account's actual offer and search evidence. The enterprise owner should confirm the relevant intentions before approving terms, rather than attach an arbitrary list merely to make a presence finding pass.

A campaign with one observed exclusion can satisfy the presence check while still needing a broader commercial review. Conversely, a new campaign may have no negatives because the team has not yet established an appropriate policy. The audit's status should remain attached to its actual rule, rather than be interpreted as a complete judgment of the campaign's economic quality.

Read failures are not proof of no negatives. If a relevant source is unavailable, explain that evidence gap. A missing current inventory should not produce a confident empty-account claim or an unnecessary live addition. The owner needs to distinguish actual absence in a successful read from a failed attempt to establish configuration.

Establish the observed population

Define the campaigns included in the report. Enabled-only coverage differs from an inventory that also includes paused campaigns. A presence audit should not be described as the complete historical account. When the owner asks about one named campaign or group, keep that narrower scope instead of replacing it with an account-wide summary.

Coverage sources have different relationships. A campaign criterion, an ad-group criterion and an attached shared list are not interchangeable resource records. The report can explain how observed coverage is established without pretending one row describes every child group or every list item. Current relationships need their own evidence when the question concerns their exact effect.

Keep list existence separate from attachment. A named list can contain terms while being attached to none of the selected campaigns. A campaign can have direct negatives without using that list. Reporting list count as campaign coverage would conflate two populations. The enterprise should see the actual relationship that supports the conclusion.

If the result is bounded, state the boundary. A selected search-term report can help research candidates without representing every query. A limited inventory can support a focused decision without proving complete portfolio coverage. The AI should not retrieve a convenient sample, filter it locally and present its count as universally exact when the source evidence is narrower.

Confirm the offer before judging relevance

Commercial relevance depends on what the enterprise actually provides. A term that appears unsuitable for one division can be valuable for another. Confirm the product, service, market and intended customer task. Do not assume a generic industry definition describes the selected campaign or treat a word as irrelevant merely because it looks unfamiliar to the analyst.

Distinguish business facts from hypotheses. The owner can confirm that the company does not offer repairs, sells only finished equipment or supports a specific region. These facts can inform exclusion planning. A guess about the business should be labelled and resolved before it becomes a live negative proposal that could block intended traffic.

One enterprise can serve several intentions. A central shared list may be suitable for a broad corporate policy while a local group needs a narrow exception. The review should preserve that difference. Adding a term to a shared list can have wider consequences than adding it to one group, so the target decision needs the confirmed organisational purpose.

A term's poor recent result does not independently establish permanent irrelevance. The selected period, volume, offer and outcome definition matter. The review can show the actual performance and ask the owner whether the intention belongs in the campaign. That produces a better decision than labelling every low-return term useless and excluding it without business context.

Use actual search-term evidence where requested

A request for actual search-term candidates needs supported search-term observations at the intended scope and dates. Do not substitute the positive keyword inventory for the user's actual-query question. A targeted keyword and a reported search term are different evidence. The resulting table should identify which population was read and which conditions selected the candidates.

Keep the requested measures attached to the query rows. Cost, primary conversions and selected value can support different decisions. A term with high cost is not necessarily the lowest-return term. A threshold request needs its explicit operator and outcome scope. Do not invent a worst-performing ranking without establishing what the owner means by worst.

Missing or unavailable observations should remain distinct from zeros. A returned zero conversion count is an observation under the selected definition. A failed read or absent metric is not evidence that the term produced no outcomes. Treating every missing value as zero can create a misleading exclusion list, especially when the selected source cannot supply the requested grain.

Use focused filtered requests where supported. The task does not necessarily require every campaign asset or all account products. Local definitions can establish which fields and relationships are valid, while provider reads supply actual observations. The AI should select from that shared capability library rather than depend on a dedicated patch for one example phrasing.

Select the commercial outcome

Define whether the review concerns all primary conversions, purchases, leads, calls or a named action. Those selections answer different questions. All primary conversions includes the selected primary population and excludes secondary actions. Purchase-specific performance is narrower. The tool should retain that scope when the owner later asks for a graph, a threshold or an explanation.

Several primary actions can contribute to the selected aggregate. The report should include them honestly rather than silently deduplicate or demote one because its name resembles another. An implementation investigation can assess overlap if requested, but the purpose of the current report is to measure the configured selected outcomes, not redesign them inside the arithmetic.

Value does not automatically mean purchase revenue. Primary lead and call actions can carry values, and an all-primary conversion-value aggregate can therefore contain nonpurchase contributions. Use the correct label. A purchase-specific revenue selection should retain its category boundary, especially when the owner compares it with GA4 purchase revenue.

For leads, do not invent a hierarchy of quality from category naming. Use the confirmed named action when the business wants a particular milestone. Offline and call outcomes remain available where supported without needing an automatic GA4 counterpart. The negative-keyword decision should use the owner's actual commercial measure rather than whichever total is easiest to retrieve.

Keep scale and uncertainty beside the decision

A striking ratio can come from little activity. Show the base cost and selected outcome count beside any return or efficiency measure. A term with one outcome can rank differently after another observation, and a small cost amount can have a different operational significance from substantial spend. The owner should understand the scale without an invented universal certainty threshold.

Do not equate a zero returned outcome with proof that the intention can never convert. The selected period and business process matter. The enterprise may still choose exclusion on confirmed irrelevance, but that reason differs from a performance claim. A useful proposal distinguishes the owner's commercial boundary from the observation that motivated further review.

Keep excluded-traffic savings claims bounded. Historical cost on a candidate term is not guaranteed future savings, and associated rows can overlap depending on the report. The action can prevent the intended supported matches through its configuration; it does not independently establish how future traffic, bids or commercial outcomes will change.

A review can recommend observation or a narrower scoped test when evidence is limited. That is an accountable outcome, not an incomplete audit. Record the selected period, measure and next decision point. The enterprise should not feel compelled to add arbitrary negatives simply because a presence or performance report raised a question.

Allow creative exclusion discussions without unnecessary calls

An owner can ask for possible irrelevant intentions around a confirmed product or service. The AI can brainstorm using that context without Google Ads calls. It should label suggestions as ideas, rather than claim they were observed in the account. This creative support is useful when planning a new offer or discussing a campaign before measured search evidence exists.

The same principle applies to headlines, descriptions and campaign structure ideas. Ordinary creative conversation should not become a mandatory provider workflow. When the owner asks for measured traffic, actual performance or live changes, the tool can obtain the needed evidence and supported action. Routing should distinguish intention generally rather than create a keyword-only brainstorming exception.

Keep the ideas commercially specific. If the enterprise sells training for administrators, suggest intentions that clearly concern a different product or audience only where the owner confirms that boundary. Avoid filling a generic list with terms such as cheap, free or jobs without considering whether those intentions could be legitimate for the selected offer.

When the owner turns ideas into a live request, prepare the exact terms and target with clear matching behavior. A brainstorming answer is not an account mutation. The confirmation stage should preserve which suggestions the owner selected, rather than automatically add the entire earlier list or broaden an exact exclusion into a more extensive policy.

Choose campaign, ad group or shared list

The dedicated tools can add exact negative terms to supported campaign, ad-group or shared-list targets. These have different scope. A group-level decision needs the actual group and its campaign parent. A campaign decision needs the selected campaign. A list decision needs the correct shared set, with attachment examined separately where relevant.

Choose scope from the confirmed intention. If one group's offer makes a query irrelevant, adding it to a broadly attached list can affect other offers. If the organisation confirms a general policy, repeated isolated group additions may be harder to maintain. The tool can explain the available targets without deciding a broader organisational policy from one term's recent performance.

Display actual parents correctly. An ad group belongs to a campaign; it should not show another ad group as its parent. Raw IDs and undefined labels should stay outside the client message. The internal resource identity provides exact execution, while readable names and relationships make the scope understandable to the approving owner.

A shared-list term addition does not automatically attach the list to campaigns. Say that explicitly when it matters. A list can be a useful reusable container while having no effect on the selected campaign until a supported relationship exists. The final result should describe the criteria and attachment effects actually requested and verified.

Preserve the dedicated exact-match operation

The dedicated negative addition builder fixes the match type to EXACT. That is its current declared operation. The article should not advertise phrase or broad through that tool simply because the provider supports those match options generally. A broader requested outcome needs its actual supported capability rather than a silent substitution.

When the owner asks for an exact exclusion, preserve the submitted term text and target. The proposal should say exact match in readable language. Do not change word order, add synonyms or expand the list without confirmation. The exact criterion is the concrete effect the owner reviews, not a loose semantic request to suppress every similar intention.

If the wording asks to exclude a whole topic, clarify the intended scope and available operation. A narrow exact term may not satisfy that broader request. The tool should explain the mismatch honestly and ask for a supported rephrase or selected terms. Executing a convenient exact addition while implying a topic-wide ban would deliver a different outcome from the owner's intention.

The provider's general matching rules remain relevant to explanation, but they do not extend the local tool's capability. Keep documentation, action definition and live resource eligibility as separate sources of truth. That distinction lets the framework expand later without making today's guide promise operations that the current dedicated path does not perform.

Read current terms and add only missing criteria

The current builder reads the relevant keyword criteria in the target and compares the requested text and match information with existing entries. It prepares missing additions rather than recreating the whole set. This preserves unrelated exclusions and reduces unnecessary writes. The proposal should retain the actual selected target rather than gather broad account inventory for a narrow addition.

Existing text with a different match type is a distinct configuration observation. The builder's comparison should remain attached to the exact requested criterion rather than claim that any similar text proves the requested exclusion already exists. Readability can simplify the display, but preparation must preserve the actual identity and matching fields.

If all requested criteria are already present, a no-change answer can be appropriate. Explain that established state rather than create duplicate entries or claim a fresh mutation occurred. If a prior submission had an ambiguous outcome, obtain focused current evidence before retrying. This is different from trusting a stale report or blindly replaying the earlier operation.

An add operation should not remove other terms. The resulting-state check can establish that the intended requested criteria are contained in the current target. Do not treat the requested list as a replacement inventory unless the owner explicitly requested and approved a supported replacement effect. Preserving unrelated configuration is part of the operation's precise scope.

Separate list creation from its contents

The dedicated list-creation action creates an empty negative-keyword shared set with the selected name. It checks for an enabled list with that name before preparing creation. Creating the container is not the same action as adding terms to it. The owner should see both effects when the request requires them.

Google's shared-set guide separates the container, shared criteria and campaign relationship. This supports a useful dependency model: a new container must exist before its contents or attachment can refer to it. The app's actual supported sequence still needs to be established rather than assumed from the documentation alone.

A list name should reflect its intended policy without implying universal applicability. A regional repair exclusion list can be meaningful within that region while inappropriate for another division. Confirm the purpose and owner. The name helps recognition, but the internal resource identity determines the exact list used in subsequent operations.

A successful empty-list creation should be reported as that result. It is not proof that terms were added or any campaign uses the list. If a later dependent effect fails or remains unverified, show the established container separately. The owner needs to know which parts of the requested chain completed, rather than receive a broad list-created message that conceals missing contents or relationships.

Review attachment as its own relationship

The dedicated attachment path verifies an enabled negative-keyword list in the selected account and reads the campaign's current enabled list relationships. It creates a missing relationship or removes the selected relationship for detachment. These are explicit operations. Adding a term to the list is not the same effect as changing which campaigns use it.

Current relationships determine the reach of a list-content change. If several supported campaigns use the same list, modifying its contents can affect their shared policy. A useful proposal should make that context available when it matters. Do not infer attachment from the list's name or claim it affects only the campaign currently being discussed when other actual relationships exist.

Detaching a list is not deleting the list or removing all negative keywords from the campaign. Direct criteria and other attachments can remain. The final message should describe the exact relationship removed. A follow-up asking why the campaign still has exclusions can be answered through the relevant current inventory rather than treating preserved unrelated criteria as execution failure.

Do not promise universal campaign-type attachment. Provider eligibility and live state can impose restrictions. The declared operation and actual target need appropriate validation. An unsupported relationship should be explained precisely, with the remaining intention preserved, rather than replaced by an unrelated exclusion or reported as complete because the container exists.

Sequence dependent resources correctly

Dependent actions need a valid order. A new shared-list container must be available before criteria or campaign relationships refer to it. An existing campaign can already provide its identity, while a newly created parent needs the appropriate planned reference or verified resulting resource. The AI should use the shared dependency framework rather than rely on a special case for one example.

A structural table can establish valid relationships locally without provider calls. It cannot establish that a particular list currently exists or that a campaign already has the relationship. Current evidence serves those actual-state questions. Separating structure from observations prevents unnecessary discovery while preserving the exactness of a live proposal.

A combined request should show each logical effect clearly. Creation, population and attachment remain visible steps even if the implementation uses a coordinated supported sequence. The owner should know whether the list starts empty and which campaign receives it. A vague add-negative-list instruction can hide missing effects or imply an attachment that was never prepared.

If the required chain is unsupported or exceeds the shared safety limit, ask for a supported split or rephrase. Do not execute a partial convenient subset while claiming the whole request completed. A precise proposal and result can identify the established parent and remaining steps, allowing the owner to continue from actual state rather than repeat completed creation blindly.

Check actual resource eligibility

Provider documentation describes available concepts, while the local catalogue describes current operations. Neither alone proves every live target accepts the same request. Resolve resource type, account ownership and applicable state. A campaign with a familiar name can still have a type whose negative-list relationship needs different treatment.

Do not confuse PMax asset groups with standard ad groups. A request involving PMax needs its actual campaign and supported resource relationships. The dedicated ad-group negative operation should not be advertised as a PMax asset-group setting merely because the owner's conversational wording uses group. Correct structure should come from the generic capability definitions.

Schema visibility is not universal mutation acceptance. Some fields are creation-only or read-only, and relationships can have resource-specific restrictions. The proposal should use the actual declared operation and appropriate current checks. If a removal or rename is requested, resolve that specific supported lifecycle capability rather than infer it from an addition tool.

A precise limitation helps the enterprise progress. State which target or operation is unavailable and what information or rephrase is needed. Avoid a broad can't-edit response that hides available alternatives, but do not promise that every provider setting has an interchangeable dedicated tool. The actual request should determine the next supported action.

Maintain regional and organisational ownership

A shared exclusion policy needs an accountable owner. Regional teams may have different offers, terminology and service coverage. A central list can be useful when its purpose is truly shared, but the enterprise should not infer that every term belongs across all regions. Confirm the commercial boundary before proposing a wider list-content change.

Record who approved each policy and which targets it applies to. This can be an organisational planning task without additional API calls. Actual account facts still need evidence. The distinction lets the AI help with governance and handover while avoiding an expensive inventory when the user is only discussing responsibility.

Keep customer identities distinct across channels and conversations. Similar regional campaign names do not establish the same resource, currency or list. A follow-up should use the current account's resolved target. Reusing another customer's internal identity because it has a matching display label would undermine the exactness of the live request.

A deliberate exception should be documented rather than hidden. One division may sell an item another does not. The review can explain why a term remains allowed in that scope while excluded elsewhere. This is a business decision, not evidence that one configuration is broken. A useful handover preserves both the shared rule and its actual exceptions.

Investigate conflicts without assuming complete delivery evidence

A negative can interact with intended targeting, but a configured conflict needs careful interpretation. The presence of similar positive and negative text does not establish every delivery consequence without match and scope context. The owner should understand which resource, criterion and relationship were inspected before the tool describes an intended route as blocked.

Current configuration also differs from historical serving evidence. A campaign may have recorded traffic before the exclusion was added. That does not prove the current rule failed. Conversely, a quiet period does not independently prove the rule caused the absence. Use relevant timing and available observations when investigating a specific claim.

A request to remove an exclusion needs the actual supported operation and exact criterion. Deleting a list item can affect multiple attached campaigns, while detaching a relationship has another scope. The tool should not substitute one for the other simply because both could make a term eligible in a selected campaign under some circumstances.

After a supported removal, verify the requested configuration effect rather than promise restored traffic. Bids, budgets, eligibility and demand can still influence delivery. The final result should identify what changed and what remains outside the check. A later performance review can establish actual subsequent observations under the selected commercial definition.

Keep dates and configuration history distinct

Use the intended reporting period exactly. Last thirty days is a rolling window, not last calendar month. Preserve the dates when the owner asks for a graph or threshold follow-up. Identify a partial current day when included and use the account's relevant time context instead of silently ending the series at a different date.

Current negative inventory describes today's configuration. It does not prove the same terms or list relationships applied throughout the performance period. If the question concerns historical exclusion timing, use available bounded change evidence or the organisation's actual records. Do not fill missing history with the current state.

A verified execution establishes a configuration boundary. It does not rewrite the historical search-term report or independently show future savings. The handover should retain the exact effect and timing internally so a later analyst can interpret before-and-after observations without claiming every change was caused by the exclusion.

Longer reporting periods may include offer or campaign changes. Record known boundaries when they matter. A search-term candidate selected across two different propositions can be useful, but it should not silently become evidence for the newer proposition alone. The business and period definitions should remain attached to the conclusion.

Apply exact conditions at the requested grain

Preserve higher than, lower than, equal to and inclusive comparisons. A request for cost at or above a threshold differs from strictly above it. Keep AND and OR distinct when combining cost, selected outcomes and current configuration. These operators should come from shared report logic so changing the metric does not change the user's condition.

Define the grain before filtering. Search terms whose period total qualifies differ from daily term rows that qualify. Campaign totals differ from group totals. The resulting count should state what was counted and which scope qualified. A convenient local aggregation should not replace the requested population merely because it produces a simpler table.

Ratios need aligned base measures. Cost per selected outcome uses selected cost and count; combined return uses summed compatible value and cost. Do not average row ratios as if they were the combined result. An absent or zero denominator should not become a misleading zero ratio, and missing observations should not be assigned zero for threshold filtering.

Retain the same selection through output formats. A chart, CSV or PDF should preserve the named action, campaign scope, dates and operators from the original request. Presentation is not permission to broaden the query or drop a condition. The framework should carry these definitions so the AI can work consistently from available data instead of needing a new subject-specific patch.

Follow an illustrative enterprise review

The following example is invented. Pine Workshop supplies industrial equipment and operates separate training campaigns. Its central owner, Ada Reed, asks which enabled campaigns lack observed negative coverage. The app reports the presence finding for the actual supported population. It does not claim every query in those campaigns is irrelevant or that campaigns with coverage are fully optimised.

Ada asks for ideas around equipment enquiries. The AI uses the confirmed offer to suggest possible unrelated intentions as creative hypotheses, without claiming measured search evidence. Ada then requests actual candidate terms above a cost threshold with no selected primary equipment enquiries. The tool obtains the relevant scoped observations and preserves the strict condition and period.

Ada chooses a small set for exact addition to a named equipment campaign. The proposal shows the campaign, each selected term and exact matching effect. It does not add them to the training policy or create a shared list implicitly. After Confirm and Execute, visible progress appears while current checks and the prepared operation run.

The resulting-state check establishes the requested criteria, and the final message makes executed and verified prominent. The handover records the chosen terms and retained training scope. A later report can inspect actual performance without claiming guaranteed savings from historical candidate cost. The example illustrates a complete bounded decision, rather than a broad unverified account cleanup.

Reuse context and narrow provider reads

A named-term addition needs the selected target's current relevant criteria, not an inventory of every account asset. The local action definition already establishes the criterion relationship. Provider calls should answer actual-state and live-check questions. Repeated structural discovery wastes capacity without improving the accuracy of a known resource target.

A presentation-only follow-up can reuse returned observations. Drawing a chart from established term performance or simplifying the explanation should not automatically repeat the entire research query. New dates, a different outcome or a live action can justify focused additional evidence. Preserve those distinctions when many enterprise conversations share provider capacity.

Short replies should retain resolved context. If the owner has reviewed one campaign and says add these there, use that campaign when the intent is clear. Ask which target when several remain genuinely plausible. Do not lose context immediately or infer a different target from the most recent unrelated list name.

Creative and planning conversation can remain useful without provider calls. The AI can explain matching, draft a policy checklist or propose ideas from confirmed business context. Actual account facts require evidence and live changes require approval. This general routing distinction reduces unnecessary work without weakening the checks that make a concrete edit dependable.

Make every proposed effect visible

A proposal should identify the readable target and exact effect in clear step sections. For a group target, show the actual campaign parent. For a shared list, show the list name and any requested relationship separately. Keep raw IDs, undefined parents and JSON-like payload details outside the client-facing message.

The shared safety limit bounds logical actions per request. If a request exceeds it, ask the owner to split or rephrase rather than executing an arbitrary subset. Creating a container, adding terms and attaching a relationship are different effects. Each requested supported effect should remain visible even when the tool prepares a coordinated dependency sequence.

State “No changes have been made yet. This proposal expires in 15 minutes.” Confirm and Execute authorises the displayed scope. Agreement with a suggestion or a prior unrelated approval does not execute this request. If the target or selected terms change during discussion, prepare an updated reviewable proposal.

Use the enterprise approval guide for the decision boundary and the enterprise audit guide for wider review context. The owner should understand the actual live consequences without reading resource syntax or assuming that a presence audit supplied an appropriate term policy automatically.

Verify criteria and relationships after execution

Immediately after the confirmation click, show prominent change-in-progress feedback and inactive controls. The owner should know that execution started while current checks and provider work proceed. The interim state should not mention the user. A quiet unchanged button can encourage repeated clicks before the first result arrives.

Validation concerns the prepared supported request. Verification concerns the resulting criteria and relationships. A successful list creation does not verify list contents, and successful contents do not verify campaign attachment. Each requested effect needs its corresponding evidence before the complete chain is described as executed and verified.

If a write may have succeeded but readback is incomplete, reconcile current state before retrying. Show established effects separately from unresolved ones. Blind replay can create duplicates or repeat a completed relationship change. A generic failure message should not imply nothing happened when the actual state has not yet been established.

When checks pass, make the verified result prominent and describe the exact configuration outcome. Do not claim measured savings, restored traffic or better lead quality without later evidence. The account task can close clearly while the business review continues with stable selected measures and an appropriate completed period.

Present readable reports and native charts

A term table should show readable text, relevant scope, match type and selected useful measures. A configuration inventory needs actual criterion or relationship labels. Keep internal payload fields, emails, customer IDs and operational timestamps outside ordinary client reports. The same display discipline should apply to Slack, web and file outputs.

A requested native chart should normally combine compatible labelled series where supported. Respect the series limit and request a selection when the owner asks for more. Longer periods can use stated weekly or monthly aggregation when daily detail is not explicit. Explicit daily requests beyond twenty points per series need split native charts and the reason, rather than silent fragmentation or an unrequested image.

Show readable dates and actual week ranges. Current-year daily labels can omit unnecessary years, while older periods need sufficient context. Display no more than two decimals and compute ratios from full-precision base measures first. Missing observations and undefined ratios should remain distinct from genuine zeros in both tables and charts.

Offer a fuller readable file when the requested detail would overwhelm a useful conversational answer. Preserve scope and avoid redundant rows that inflate a small result into an unnecessary report. In normal AI replies, place the user mention before feedback text and controls so feedback stays last. The presentation should clarify the decision, not suggest broader evidence than the tool obtained.

Leave an accountable exclusion register

The handover should record the actual target, confirmed relevance reason, selected matching effect, approved operation and verified result. For a shared list, preserve its owner and applicable relationships. A later reviewer should understand why terms were chosen and where they apply without reconstructing the decision from a long provider payload.

Record deliberate non-actions. If the enterprise preserves a term for a training campaign while excluding it from equipment enquiries, state that business distinction. If a list remains unattached, do not imply it affects campaign delivery. If evidence was insufficient for a live change, retain the observation and next review question rather than treat the absence of a mutation as an unfinished automatic remedy.

Define the next review around an actual need: changed offer, new campaign, revised list policy or completed performance period. Reuse the established method while obtaining current evidence where relevant. An earlier verified criterion is historical evidence, not perpetual proof of current inventory before another live request.

An enterprise negative-keyword audit is strongest when it connects presence, commercial purpose and precise supported scope without conflating them. It can reveal missing coverage, support creative planning, research actual candidates and complete approved changes. The result leaves configuration effects verified and future business outcomes open to their own measured evaluation.