Give each knowledge change a content owner, an implementation owner, an effective date, and a verified path from publication to assisted answers. The owner of the policy should approve its meaning; the owner of the integration should confirm that the assistant receives the approved version. Do not leave either responsibility implied.
Level AI describes knowledge-based assistance. Google Cloud publishes generative knowledge evaluation guidance. These sources establish the relevance of managed knowledge, not a guaranteed refresh time or ownership model for your deployment.
What belongs in a knowledge change record?
For each policy or procedure, record its owner, audience, scope, version, approval date, effective date, and replacement relationship. Identify the customer situations that depend on it. Keep a small set of reference questions that should change when the policy changes, plus questions that should remain unaffected.
Distinguish content publication from assistant availability. A document may be visible in the knowledge system while the assistant still uses an earlier ingestion. Ask the supplier how a buyer can observe that distinction and what evidence confirms the new content is being used.
How should responsibilities be divided?
| Responsibility | Named owner | Required evidence |
|---|---|---|
| Approve policy meaning | Policy or process lead | Approved version and scope |
| Publish source content | Knowledge editor | Publication and effective dates |
| Verify ingestion | Application owner | Observed version or agreed test |
| Confirm assisted behavior | QA reviewer | Reference answers and citations |
| Handle urgent withdrawal | Assigned incident owner | Fallback instructions and closure check |
The roles can be combined in a small operation, but the checks should remain explicit. Vendor-managed ingestion does not remove the need for a customer-side person who can decide whether the policy itself is correct.
How should a changed policy be released?
Prepare the revised source, remove or clearly supersede conflicting instructions, and test the reference questions in an agreed validation environment. Include the policy boundary: an order placed before the effective date may need different treatment from a new order. Review whether the assistant asks for that condition.
After release, repeat the checks from the agent interface and capture the cited version where available. Monitor early exceptions and give agents a simple way to report suspected stale guidance. Avoid silently editing the source again without preserving the version that produced the disputed answer.
What should happen during an urgent correction?
Agree beforehand on who can stop the affected assistance, how agents receive interim guidance, and how service resumes after verification. Treat these as requirements to demonstrate, not assumed product controls. A manual fallback may be appropriate while a critical ambiguity is resolved.
Use grounded-answer testing for the validation cases and suggestion relevance review if old guidance persists after a topic or policy change.
How should a policy change be accepted or rolled back?
Consider an illustrative replacement-window change that takes effect Monday for new purchases, while earlier purchases retain the old rule. The content owner supplies both conditions; the integration owner proves which versions the assistant can retrieve. Deleting the earlier policy would erase an answer still needed for older purchases.
| Release check | Evidence required | Owner decision |
|---|---|---|
| New-purchase question | Answer cites the new version and effective condition. | Approve only if the condition survives retrieval. |
| Earlier-purchase question | Answer retains the applicable earlier rule. | Restore scoped historical knowledge if missing. |
| Purchase date unknown | Assistant asks for the missing condition. | Pause release if it guesses. |
| Urgent correction | Named person can stop affected guidance and issue an interim instruction. | Resume after the same cases pass review. |
Keep a release identifier, approved source hashes, test questions, observed answers and rollback decision together. Ask how deletion, reindexing and cached answers behave; do not equate “upload succeeded” with a verified answer change. Google's current generative knowledge guidance describes evaluation examples; use examples representing your policy conditions, without assuming a universal refresh interval.
What are the limits of this guide?
Sources were checked October 20, 2026. This operating model was not tested in a named product. Refresh intervals, deletion behavior, version visibility, and rollback mechanisms require written confirmation. The guide identifies the evidence and ownership needed before relying on changing knowledge.