Expiry dates for internal docs that assistants still use

What goes wrong when old docs stay active

A process document can look harmless long after it stops matching reality. It still sits in the shared folder, still sounds official, and still gets pulled into daily work. People assume someone checked it recently, even when nobody has opened it for months.

The gap gets worse when work changes in small steps. A team adds one approval, drops one tool, changes who signs off, or rewrites a handoff. The old document stays put, so yesterday's process keeps acting like today's rule.

Assistants make this sharper, not smaller. They follow the written instruction in front of them. They cannot rely on hallway context, half-remembered Slack messages, or the fact that "everyone knows" the process changed last quarter.

That is how stale documentation turns into repeated mistakes. If the doc says invoices need finance review before upload, the assistant will wait for finance review every time, even if the team removed that step six weeks ago. One old sentence can slow dozens of tasks.

Then people waste time arguing about versions instead of doing the work. One teammate points to the doc. Another says the process changed. A third person digs through chat history to prove who said what. Ten minutes goes by, then twenty, and nobody feels sure which version is safe.

The cost is not just delay. Old rules create quiet errors that spread. An assistant files work in the wrong place, asks the wrong person for approval, uses an old naming format, or skips a new check because the document never mentioned it. Small misses pile up into avoidable rework.

Without review dates, teams keep treating old text like live policy. Written rules usually beat unwritten updates, especially when an assistant repeats the same action across many tasks.

That is why stale docs are not just messy admin. They shape decisions, create false certainty, and keep outdated process rules alive long after the team moved on.

What every live doc should include

If an assistant can read a document and use it in daily work, that document needs a short header with basic control points. Without it, old instructions linger for months and keep shaping decisions after the team has changed course.

Put the review date near the title, not buried at the bottom. People should be able to see it in seconds. Assistants need the same signal.

Name one owner. Use a real person, not "Ops team" or "Engineering." Team labels sound tidy, but they usually mean nobody feels responsible for fixing the doc when the process changes.

State the scope in plain language. A live document should say where the rule applies and where it does not. If a doc covers customer support refunds in one region, say that. If it does not apply to enterprise contracts or manual exceptions, say that too. That single note prevents a lot of bad assistant behavior.

Status matters too. Mark the document as draft, active, retired, or superseded. People skip this more often than they should, and that is where the mess starts.

A short header is enough:

• Owner: Nina Patel
• Review by: 15 July 2026
• Status: Active
• Applies to: standard refund requests under $500 in the self-serve product; not enterprise deals or chargeback disputes

That format works because it answers the first questions a person or assistant should ask. Can I trust this? Who updates it? Does it apply here?

This matters most in small teams that move fast. Tools change, roles shift, and approval paths get rewritten in weeks, not years. In that setting, review windows and clear ownership are not paperwork. They stop last month's shortcut from becoming this month's broken process.

How to choose a review window

Pick the review window by asking a simple question: what happens if this doc is wrong next week?

If the answer is "not much," review it later. If the answer is "customers get bad advice" or "the team ships the wrong thing," review it soon.

Fast-moving work needs short windows. Release steps, support replies, AI prompt rules, approval flows, and tool setup guides can drift in a few weeks. When assistants use those docs, even a small error spreads fast because the same bad rule gets reused again and again.

Stable policies can wait longer. A dress code, reimbursement rule, or office access note may only need a review every 6 or 12 months. That works only when the rule rarely changes and the cost of being wrong is low.

Risk should set the date. A stale note about file naming might waste ten minutes. A stale incident checklist might waste an hour during an outage. Those docs should not share the same window.

Keep the ranges simple:

• 30 days for fast-moving process docs tied to tools, prompts, or weekly team habits
• 60 to 90 days for standard operating procedures that change now and then
• 180 days for stable internal rules with moderate risk
• 365 days for policies that rarely change and cause little harm if wording drifts

A default matters more than most teams expect. Without one, new docs land in a folder and never get reviewed. For many teams, 90 days is a good starting point. It is short enough to catch drift, but not so short that reviews turn into busywork.

If you are unsure, ask how hard cleanup would be after a wrong answer. If cleanup takes minutes, the window can be longer. If cleanup means refunds, rework, or a security scramble, shorten it.

How to assign clear ownership

Review dates only work when a real person owns the decision. "Team Ops" is not an owner. Neither is "engineering" or "HR." Pick one person who can approve a change quickly, because assistants will keep following old instructions if nobody feels responsible.

The best owner is usually the person closest to the live process. Do not default to the original author. A writer may understand the document, but the current team lead, manager, or process owner usually knows what changed last week.

A good owner does four things. They use the process often enough to spot drift. They can approve edits without waiting on a long chain of signoff. They know when the doc should be retired, not just updated. And they can answer follow-up questions from the team.

Give every owner a backup. People take time off, switch roles, or get pulled into urgent work. Put both names in the header, not in comments or chat.

At each review date, ask the owner to do one clear action: confirm, update, or retire. "No changes" still needs an explicit confirmation. Silence should not count as approval. If the owner does not respond by the deadline, move the doc out of active use until someone checks it.

That sounds strict, but it prevents a common failure. A doc with no owner is not neutral. It still shapes answers, approvals, and daily work, even when it no longer matches reality. If nobody owns it, mark it inactive and keep assistants away from it.

A simple example makes the point. A product team keeps an internal doc about refund approvals. The finance lead leaves, but the assistant still uses that doc to answer support questions. Refunds slow down because the approval path no longer exists. One new owner and one backup fix that faster than another full rewrite.

How to set it up

Start with a list of every document an assistant can touch today. Include playbooks, SOPs, team notes, old migration guides, prompt libraries, and copied docs in shared folders. If nobody can say which version is current, you already found the first problem.

Next, sort the pile into three groups: active, outdated, and unknown. Active docs still match how the team works now. Outdated docs describe tools, approvals, or steps nobody uses anymore. Unknown docs sit in the gray area. People remember them, but nobody wants to claim them.

A plain tracker is enough. Keep one row per document with these fields:

• document name
• status
• owner name
• first review date
• what the assistant should do when the date passes

For active docs, assign owners right away. Use one real person, not a team name. If the owner leaves, replace them before the assistant keeps using the doc.

Set the first review date while the document is still open in front of you. A fast-changing support script may need 30 days. A stable security checklist may be fine at 90. Keep the rule simple so people follow it.

Then decide what happens after the date passes. Do not leave this vague. One rule works well: if the review date passes and the owner has not renewed the doc, the assistant stops using it for decisions and treats it as background only. For unknown docs, take a stricter path and block them until someone reviews them.

Last, tell the team which docs assistants may use right now. Put that approved list in one place and keep it short enough that people will actually read it. A messy wiki with five versions of the same rule will beat your system every time.

Small teams can do this in an afternoon. The hard part is not setup. The hard part is saying no to stale documentation once people notice how much of it still shapes daily work.

A simple example from daily work

A support team uses an assistant to answer refund questions. Months ago, someone added a short refund script to the prompt pack: "Customers can request a refund within 30 days of purchase." It worked at the time, so nobody touched it again.

Then the product team changed the policy. Annual plans moved to a 14-day refund window, while monthly plans kept 30 days. The public help center changed, the billing team changed its macros, and human agents learned the new rule. But the old script stayed where the assistant could still read it.

The problem shows up in a normal ticket. A customer with an annual plan asks for a refund on day 20. The assistant replies with the old 30-day window and tells the agent the refund should go through. The agent trusts the answer, sends the same message to the customer, and billing has to step in later to correct it.

That one stale line creates more work than people expect. The customer gets mixed messages. The agent loses time. Billing cleans up the mistake. If this happens ten times in a week, the team wastes hours on a rule that should have been fixed in five minutes.

The repair is simple. One person owns the doc. Their name sits at the top, along with the last review date and the next check date. When the support lead sees the mismatch, they update the script so it says:

• Monthly plans: 30 days
• Annual plans: 14 days
• If the plan type is unclear, send the case to billing

They also remove the old version from the prompt pack and set the next review for 60 days later, or sooner if pricing or billing changes again.

That is the practical value of review dates. The assistant does not guess which rule is current. It uses a live rule with a review window and a named owner. When the policy changes again, the team knows exactly who checks the text and when.

Mistakes that keep stale rules alive

A stale doc usually survives because the team built a weak routine around it, not because the content looked convincing. One bad rule can sit untouched for months and still shape live work if assistants keep finding it first.

The first mistake is fake shared ownership. When three people "own" one process doc, each assumes someone else will review it after a policy change, a tool update, or a product shift. The result is silence. One doc needs one named owner, even if others can suggest edits.

Another mistake is treating review dates like decoration. Teams add "review every 90 days" to the header, then never create a calendar task, dashboard, or queue for expired pages. Dates only work when someone checks them and either renews, updates, or retires the page.

Copying old material into new folders causes a quieter problem. A writer duplicates last year's onboarding guide, changes the title, and forgets to mark the old one as replaced. Now both versions look current. If neither page has a clear status label, humans and assistants both guess.

A few habits cause most of the damage:

• keeping retired docs searchable beside active ones
• leaving drafts and meeting notes in the same index as approved guidance
• moving files without carrying over owner names and review windows
• renaming a doc instead of marking it "superseded"
• assuming assistants can tell the difference between a rule and a rough note

Search makes this worse. If a retired checklist ranks well in internal search, people will use it even after the team stopped following it. Assistants do the same, only faster. They pull from whatever looks relevant unless you filter the source set.

Suppose support updates its refund steps in the official playbook, but an older version still sits in a shared folder, and a Slack summary from six months ago says something different. If the assistant can read all three with no status filter, it may answer with the wrong rule and sound certain while doing it.

The fix is boring, which is why teams skip it. Mark every doc as active, draft, retired, or superseded. Remove retired material from the assistant's search path. Give one person the doc. Put review checks on a real schedule. If a page has no owner, no status, or no review date, the assistant should treat it as untrusted.

Quick checks before an assistant uses a doc

An assistant can follow a bad instruction with perfect confidence, so start with one basic question: who owns this page right now? If the document shows no owner name, treat it as risky. A team label is too vague. One real person should be able to say, "I keep this current."

Then check the review date. If there is no next review date, or the date passed a while ago, do not let the doc guide live work on its own. Old process notes often stay around because nobody planned to keep them. They just never got removed.

A quick scan catches most problems:

• one named owner, not just a department
• a review date that is still current
• steps that match the product or process people use now
• a clear note about which older version this page replaced
• wording a new teammate could read once and act on

The third check trips teams up all the time. A doc can show a recent date and still be wrong if the product changed last week. If the page mentions screens, tools, approvals, or roles that no longer exist, the assistant should stop and ask instead of guessing.

Version clarity matters for the same reason. When two similar docs sit side by side, assistants often mix them. A good page says what it replaced and tells readers to stop using the older one.

Clarity is the last test. If a new teammate needs to ask three people what step two means, the assistant will struggle too. Plain language, current names, and a short path from start to finish make a huge difference.

A simple rule works well: if two of these checks fail, the assistant should not use the document without human review. Five minutes up front is usually cheaper than fixing a week of work shaped by an old rule.

What to do next

Start small. Pick the five documents that shape the most assistant behavior today. In most teams, that means docs behind approvals, support replies, pricing notes, escalation rules, and release checklists. If a document changes daily work or customer output, move it to the top.

Do not buy another tool yet. A spreadsheet or shared table is enough for the first pass. Give each live doc five fields: document name, owner name, last reviewed date, next review date, and a short note on where the assistant uses it.

Set a 30-minute working session this week. Open those five docs, add names and dates, and mark anything overdue if nobody remembers the last review. That one session usually exposes weak spots faster than a long policy meeting.

Each month, check which documents actually drive assistant outputs. You can do this with prompt logs, linked references, or a quick review of common tasks. Most teams find that a small set of docs shapes most answers. Those pages need shorter review windows than archive material nobody uses.

If a rule has no owner, it will sit untouched until the assistant repeats it as if it were still true. Put a real name on each document, not a department. "Operations" cannot review a page. One person can.

If your assistant drafts refund replies from a policy written nine months ago, one outdated sentence can create dozens of bad answers in a week. A monthly check on that policy takes less effort than fixing the fallout.

Keep the system light. Start with a tracker, review the docs that affect real decisions each month, and shorten the window only where mistakes cost time or trust. That is enough to stop stale documentation from shaping live work.

For teams building heavier AI workflows, this is the kind of operating cleanup Oleg Sotnikov often helps with through oleg.is. The useful part is not more process. It is a simple setup with clear ownership, current source material, and rules people will actually keep using.