Your AI drafts a polished reply. The service description looks familiar. The delivery promise sounds confident.
There is one problem: you changed that offer last week.
More context is not always better context. An old document can preserve yesterday’s answer long after your business has moved on.
Give important business facts a review date, not a permanent place in every prompt. Pair that date with a source, an owner, and a rule for what happens when nobody can confirm the answer.
Start with the details you would not want copied incorrectly
You do not need to catalogue everything. Start with a few details that shape public promises: what a service includes, its exclusions, a booking link, current availability, or which product capabilities people can actually use.
Keep these separate from tone preferences and brainstorming notes. “Write in a calm voice” is guidance. “Every package includes ongoing support” is a business claim. The second needs evidence and a clear scope.
A recent timestamp alone does not prove a claim. Nor does an old timestamp automatically make a stable fact false. The review date simply tells your workflow when to ask again.
Make a small current-facts register
Use a document or table your team already maintains. For each important fact, capture:
Fact and scope: the exact statement, and where it applies.
Source: a specific approved page, record, or document version—not a vague “see the drive.”
Owner: the person who can confirm or change the statement.
Checked on and review by: when someone verified it and when to check again.
Status: confirmed, needs review, or replaced.
Used in: the templates, pages, or workflows that repeat it.
Keep the decision simple:
If the source and owner still confirm the fact for this use, use it within that scope. If the review is overdue, the source conflicts with another record, or nobody can confirm it, pause that claim and ask the owner. A review date is a checkpoint, not proof.
Example: a changed service package
Imagine a fictional business that used to include two revision rounds in a website package. Its owner now approves one round for new proposals. Older agreements still have their own terms.
The register should say more than “one revision.” It should identify the current approved offer, its effective date, and the boundary: new proposals only. It should point to the approved offer version and name the owner.
When AI helps draft a new proposal, give it that scoped record. When someone asks about an existing project, check the relevant agreement rather than substituting the new offer. If the records disagree, send the question for review; do not ask AI to invent a compromise.
This is an illustrative operating example, not CORA’s offer or advice about changing existing agreements.
Choose review triggers that match the fact
A campaign’s availability might need confirmation before each launch. A booking URL might need a check when you change scheduling tools. A feature claim should get another check when a release changes the product.
Use both planned reviews and change-triggered reviews. Do not wait for Friday if the owner changes an important detail on Tuesday. Mark the old record as replaced, add the new approved version, and inspect the places listed under “Used in.”
For AI-assisted drafting, try this instruction:
Use the supplied confirmed facts only within their stated scope. Identify missing, conflicting, or overdue facts in a review note. Do not turn them into customer-facing promises. Ask the named owner to confirm before I publish or send.
That instruction is a drafting aid, not a technical guarantee. A person still needs to inspect the result. If you build an automated workflow, enforce the check in the workflow itself and test the pause path rather than relying on prompt wording alone.
Check one downstream copy
Pick one changed fact and trace it into a real output: a saved reply, a landing page draft, or an onboarding message. Does it use the current approved version? Does it preserve the scope? Can you see where the statement came from?
Do not stop after updating the source document. Old snippets and templates may still repeat the earlier wording. Preserve the history where you need it, but clearly separate it from the material you supply for new work.
Where CORA fits
We frame CORA around a website and the workspace around it. You can explore CORA’s current public positioning here.
The register and review checks in this issue describe a system you can implement with existing tools. They do not announce a shipped CORA freshness checker or promise that an AI co-founder will catch every stale fact. We have not established measured error reduction for this method in CORA.
Today’s move: choose three facts your website, replies, or AI briefs reuse. Give each a specific source, an owner, and a review trigger. Then inspect one place that still copies an older version.
Reply with the kind of fact your team finds hardest to keep current—no private customer details needed.
— Dravya Bansal
Do it on CORA
