How to keep an executive AI knowledge base current

An executive AI knowledge base does not fail all at once. It decays quietly.

A decision changes, a partner note gets superseded, a product page is revised, a pricing assumption expires, and the assistant still has the old version in reach. The output looks polished. The source is stale. That is the dangerous version of wrong.

The fix is not a bigger archive. The fix is a maintenance loop that makes freshness, source authority, and escalation visible.

Start with source authority

Every important knowledge area needs a source-of-truth rule.

Write down which source wins when material conflicts:

This table is not bureaucracy. It gives the system a way to answer, “which source should I trust?” instead of blending everything into one confident summary.

Put freshness windows on claims

Not all facts age at the same speed.

A company registration number may stay stable for years. A sales pipeline note may be stale next week. A partner-positioning assumption may be safe for internal context but unsafe for external copy after one meeting.

Useful freshness rules look like this:

• project status: flag anything older than seven days;
• active commercial discussions: flag anything older than the last confirmed follow-up;
• public positioning: use the published page unless an approved messaging note says otherwise;
• people and relationship context: flag old notes and separate private context from external wording;
• legal, finance, HR, security, and credential material: do not ingest or summarize unless the handling rule is explicit.

The system should not pretend a fact is current because it exists in the archive. It should show the last confirmed date and the owner who can update it.

Keep a stale-context register

A useful executive knowledge base needs a small list of known weak spots.

The stale-context register can be simple:

Stale-context register

Area:
Current risk:
Source currently used:
Last confirmed:
Owner:
What would break if wrong:
Next review date:
Escalation rule:

The goal is not to catalogue every old note. The goal is to name the places where old context would cause operational damage: wrong commercial wording, mistaken commitments, obsolete priorities, exposed private relationship context, or a briefing that points the principal at yesterday’s decision.

Separate current truth from useful history

Old material is not useless. It just needs to be labeled.

A rejected option, earlier pricing model, old campaign brief, or previous partner position can explain why a decision changed. That is useful history. It should not sit beside current truth without a label.

Use four simple states:

1. Current — safe to use for the defined purpose.
2. Historical — useful background, not current guidance.
3. Draft or disputed — may inform questions, not decisions.
4. Excluded — should not be stored, summarized, quoted, or sent to another tool.

If the knowledge base cannot represent those states, it will treat everything as equally usable. That is how a private note becomes public copy, or a rejected plan comes back as a recommendation.

Review by operating cadence

Maintenance should follow the work, not an arbitrary cleanup ritual.

Tie review to the moments where the knowledge base is actually used:

• before a weekly leadership review;
• after a partner call where commitments changed;
• before an investor or board update;
• when a service page or offer changes;
• when a project moves from planning to delivery;
• before any external message uses internal context.

This keeps the system smaller and more useful. You are not asking someone to “maintain the knowledge base.” You are asking them to update the few pages that will be used in the next decision.

Give the assistant stop rules

The assistant should know when to refuse a confident answer.

Good stop rules:

• if sources conflict, name the conflict and ask the owner to resolve it;
• if the last confirmed date is outside the freshness window, mark the claim stale;
• if the use boundary is internal-only, do not draft public or client-facing copy from it;
• if a commitment is implied but not approved, treat it as an open loop;
• if the source contains sensitive material, summarize only under the approved handling rule;
• if no owner exists, do not promote the note to current truth.

A knowledge system earns trust when it can say, “I do not have a current approved source for that.” Annoying? Slightly. Cheaper than sending a polished lie.

Use a monthly maintenance packet

The review should produce a short packet, not a vague “knowledge base updated” note.

Copy this into the next review agenda:

Executive knowledge-base maintenance packet

Review window:
Knowledge area:
Owner:

1. Current-truth pages checked
- Page:
- Last confirmed date:
- Source that won:
- State after review: current / historical / draft / disputed / excluded

2. Source conflicts found
- Conflict:
- Sources involved:
- Decision owner:
- Resolution or open loop:

3. Stale-context risks
- Risk:
- What would break if used:
- Next review date:
- Assistant stop rule:

4. External-use boundary
- Safe for internal briefing? yes / no / only with caveat
- Safe for external copy? yes / no / needs approval
- Sensitive material excluded:

5. Next operating use
- Briefing, follow-up, page update, or decision this knowledge will support:
- Person accountable before use:

If the packet is empty every month, the domain is probably too broad or nobody is using it. Narrow the scope until the review catches real conflicts, stale claims, or approval boundaries before they hit a briefing.

What the maintenance owner actually does

The maintenance owner does not need to rewrite every page.

Their job is to:

• confirm which source wins when notes conflict;
• mark pages current, stale, historical, draft, disputed, or excluded;
• approve or reject promotion from source notes into canonical pages;
• keep approval boundaries visible;
• schedule reviews around real operating moments;
• escalate when a briefing would rely on weak or missing source material.

Without that owner, the system becomes a searchable attic. Useful for nostalgia, bad for decisions.

The operating rule

Build the first executive knowledge-base maintenance loop around one high-risk domain.

Do not start with the whole company. Start with the area where stale context would hurt: partner commitments, investor materials, service scope, current projects, or executive briefing preparation.

Define the source that wins, the freshness window, the owner, the stale-context register, and the stop rules. Then use the system in one recurring briefing or follow-up workflow.

A maintained knowledge base is not a place where every note goes. It is where current truth survives long enough to be useful, and stale context is forced to wear a warning label.