Keep an executive AI knowledge base up to date

Keep the knowledge base current by assigning an owner to each important claim, tying it to an approved source, and recording when it was last confirmed. Review the claim when that source changes or before the next consequential use. A disputed or expired claim should block a confident answer until an owner resolves it; uploading a new document is not that resolution.

Use this maintenance sequence

1. Name the owner and approved source. Someone must be able to decide which source wins for the claim and its intended use.
2. Mark the claim state. Use current, historical, draft or disputed, or excluded. Do not leave conflicting versions equally usable.
3. Review on a real trigger. A source change, decision, external use, or expired owner-set review date should open the check.
4. Resolve before use. The owner confirms the current claim and its use boundary before the next briefing, follow-up, or public draft.
5. Keep the old version as history. Superseded guidance can explain a decision, but it should not compete with current truth.
6. Verify the next artifact. Test that the briefing cites the current source, labels uncertainty, and treats the prior version as historical.

The knowledge-base scope guide decides what belongs in the system. The first-month guide covers implementation. The synthetic executive briefing sample shows the downstream artifact. This page owns the recurring maintenance job.

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, 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.

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.

The windows below are examples, not universal policy. The owner should shorten or extend them based on the cost of being wrong, how quickly the source changes, and when the claim will next be used.

Example freshness rules:

• 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.

Completed example: one claim changes

Fictional maintenance example. This shows the record shape and approval path. It is not customer data or an observed outcome.

Claim: approved scope of the example service
Previous source: historical scope note, revision A
New source: approved scope decision, revision B
Trigger: owner approves a scope change
Affected artifact: next executive briefing
State while unresolved: disputed; do not repeat as current
Resolution: owner confirms revision B for the stated purpose
Historical handling: retain revision A as history, not current guidance
Next check: before external use or the owner's defined review date
Verification: briefing cites revision B; a test question about revision A is answered as historical

The briefing stays blocked while the claim is disputed. Uploading revision B does not resolve the conflict by itself. The owner must confirm that revision B is current for the stated purpose, then the briefing test must cite B and describe A as history.

Use event triggers and periodic sweeps for different jobs

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

Event-triggered review handles a known change or consequential use:

• after a partner call where commitments changed;
• when a service page or offer changes;
• when a project moves from planning to delivery;
• before an investor, board, client, or public artifact uses the claim.

Periodic sweep catches decay with no obvious event:

• confirm owners and last-confirmed dates for the high-risk domain;
• inspect claims approaching their owner-set review date;
• resolve or escalate open conflicts;
• verify that superseded sources remain historical rather than current;
• test one upcoming briefing or follow-up against the current source.

Do not wait for the sweep when a source or decision changes. Do not invent a trigger for every stable background fact. The two review modes have different jobs.

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.