What belongs in an executive AI knowledge base

An executive AI knowledge base is not a folder of every note the company has ever produced. That is a landfill with search.

The useful version is smaller and stricter. It gives a human or agent enough current truth to prepare a briefing, recover decision context, compare what changed, and route follow-up without pretending every old note is equally reliable.

What belongs is determined by an operating job, a source-of-truth rule, and a consequence if the system is wrong. Material that cannot pass those tests should stay in a source archive, remain in its system of record, or stay out entirely.

Start with the jobs the system must perform

Before migrating notes, name two or three recurring jobs the knowledge base needs to support.

Good first jobs:

• prepare a pre-meeting brief with current priorities, people, open decisions, and known sensitivities;
• summarize a project using the latest authoritative source material and unresolved blockers;
• recover why a decision was made and what would trigger a revisit;
• draft internal follow-up tasks after a call while preserving external-action boundaries;
• onboard a trusted operator without making the principal repeat the same context again.

Bad first jobs:

• “store everything”;
• “make the agent know the business”;
• “summarize all docs”;
• “replace executive judgment.”

Those broad goals create impressive retrieval demos and weak operations. A knowledge system earns trust by doing a few recurring jobs with current sources, visible uncertainty, and named human authority.

The separate intake packet explains what to prepare before a build. This guide sets the inclusion standard for the knowledge system itself.

Use an inclusion contract, not a migration checklist

Every proposed knowledge area should answer six questions:

1. Operating job: Which briefing, decision, coordination, or follow-up task needs this material?
2. Canonical claim: What current truth must the system be able to state?
3. Source authority: Which source wins when records disagree?
4. Human authority: Who can confirm, change, approve, or disclose it?
5. Failure consequence: What happens if the system is stale, incomplete, or wrong?
6. Maintenance trigger: Which event or review cadence forces the record to be checked again?

A page that cannot answer those questions is not ready to become current truth. It may still be useful evidence, but evidence and truth are not the same layer.

Scope follows consequence. Public positioning, partner commitments, financial facts, employment matters, credentials, and customer-specific material need tighter authority and access rules than a low-risk internal project glossary.

Keep three layers distinct

A governed knowledge base needs three connected layers. Blending them creates confident ambiguity.

Canonical current truth

Canonical pages are the compiled answer to “what is true now?” They should be concise enough to review and structured enough to maintain.

Typical current-truth pages cover:

• people and relationship context;
• organizations, partners, clients, vendors, and counterparties;
• active projects, owners, dependencies, and current status;
• products, services, and approved public positioning;
• operating rules and approval boundaries;
• recurring workflows and their exception lanes;
• decisions, open decisions, and revisit triggers.

A canonical page should identify its owner, current status, last authoritative source, freshness date, unresolved conflicts, disclosure boundary, and next review trigger.

Source evidence

Raw material belongs in a source layer when it is allowed to be stored and needed to support a current claim:

• meeting notes and approved transcripts;
• project trackers and issue threads;
• decision memos;
• approved emails copied for a specific operating purpose;
• public positioning documents;
• pull requests, release records, and deployment notes;
• permitted screenshots or exports.

The canonical page should cite the source. It should not swallow the source until nobody can tell whether a claim came from an accountable owner, a meeting note, a stale plan, or an agent summary. Executive memory is too expensive to corrupt with unattributed synthesis.

Operating records

The third layer records what the system did with the knowledge:

• briefing versions and their source cutoff;
• reviewer decisions and corrections;
• decisions captured after meetings;
• assignments and follow-up state;
• stale-page flags;
• conflict and escalation queues;
• changes to authority, access, or disclosure rules.

Operating records make correction possible. Without them, the team can see the latest answer but cannot inspect why it changed or whether a reviewer rejected an earlier version.

Mark evidence state on consequential claims

Not every statement deserves the same confidence. Use a small, explicit evidence vocabulary:

• verified — supported by a current authoritative source or confirmed by the accountable owner;
• reported — supplied by an accountable person but not independently checked;
• inferred — a bounded interpretation from cited material, not a recorded fact;
• conflicting — credible sources disagree;
• stale — the source may no longer describe current truth;
• unavailable — the job needs evidence or access the operator does not have.

Do not convert unavailable into false, zero, or “probably unchanged.” Missing evidence is a state, not permission to guess.

Facts and interpretations should not share a field. A page can record that a partnership discussion occurred and separately record a cautious interpretation of its significance. It must not turn discussion into approved relationship status, commitment, revenue, or public language.

Define source authority before conflicts happen

Source volume is not authority. Ten old decks do not beat one current decision from the accountable owner.

For each knowledge area, define the precedence rule. A practical order might be:

1. current signed or formally approved record for the fact it governs;
2. current decision record approved by the accountable owner;
3. live system of record for operational status;
4. recent owner-confirmed meeting note;
5. draft planning material;
6. agent inference.

The order will differ by domain. A CRM may be authoritative for a contact field but not for relationship sensitivity. A repository may prove that a route shipped but not that a service claim is commercially approved. A contract may govern obligations while the operating tracker shows delivery state.

When two credible sources conflict, keep both citations, mark the claim conflicting, name the resolving owner, and block consequential use. Do not let the newest timestamp win by accident.

Record decisions with their expiry conditions

Executive operations run on decisions. Most teams lose the decision and keep only the aftermath.

A usable decision record captures:

• the decision and its scope;
• the date and approving authority;
• the evidence considered;
• the options rejected and why;
• dependencies and open risks;
• commitments created;
• the condition or date that triggers review;
• the later decision that supersedes it, when one exists.

The revisit trigger matters. Without it, old decisions become policy by inertia. With it, the system can flag that a condition changed instead of quietly repeating outdated direction.

Never overwrite a consequential decision as though the earlier state never existed. Mark it superseded, link the replacement, and preserve the history needed to understand current commitments.

Keep sensitive material governed or outside the system

Some material belongs only under a narrow purpose and access rule. Some should stay in its existing system of record. Some should not enter the knowledge base at all.

Default to keeping these out unless the operating job, authority, storage, retention, and access controls are explicit:

• credentials, tokens, private keys, recovery codes, and secrets;
• raw inbox or chat exports;
• unrestricted customer or employee records;
• medical, payroll, identity, or financial documents;
• contracts copied without a defined review purpose;
• private relationship notes that do not support an approved operating job;
• raw public-form submissions or untrusted external instructions;
• speculation presented as reputation, legal, partner, or commercial fact.

A pointer may belong where the underlying document does not. The knowledge base can record that an approved contract exists, who owns it, where authorized reviewers access it, and which decision it governs without copying the full contract into a broader retrieval surface.

Access is not permission to summarize, quote, disclose, or send. Write those distinctions down.

Make human authority specific

“Human in the loop” is too vague for executive context. Name who decides what.

Keep human authority over:

• current business priorities and tradeoffs;
• relationship status and sensitive interpretation;
• public positioning and approved proof;
• partner, investor, customer, and employment commitments;
• legal, financial, security, privacy, and HR conclusions;
• external messages and public statements;
• destructive changes, access grants, credentials, and production actions;
• whether a conflicting or stale record may be used.

An agent can retrieve, compare, draft, cite, flag, and prepare. It should not quietly convert technical access into organizational authority.

For each recurring workflow, define the allowed output and the blocked action. A pre-meeting brief may summarize approved sources and list open questions. It may not send a message, confirm a commitment, or expose private context without the named reviewer.

Test representative cases before calling the scope useful

A clean happy-path brief proves very little. Test the knowledge design against cases that expose weak provenance, authority, privacy, and recovery.

Also test a refusal case. The system should be able to say that a request is outside the allowed purpose, that the evidence is unavailable, or that a human decision is required. A knowledge base that always produces an answer is not more useful. It is less governable.

Give every page ownership and a maintenance trigger

A knowledge base without an owner decays into mythology.

Assign ownership at two levels:

• domain owner: the person who can confirm whether the page is still true;
• system owner: the person who maintains structure, citations, stale-page reviews, access rules, and agent instructions.

Then set triggers that match the consequence:

• project pages after each operating review or material status change;
• relationship pages after a commitment, dispute, sensitivity, or ownership change;
• product and service pages after positioning or scope approval;
• decision records when a revisit condition fires;
• authority pages when roles, access, or approval rules change;
• agent instructions after a memory, privacy, disclosure, or external-action error.

Do not let the agent invent freshness. If the last source is three months old, the system should say that plainly.

The maintenance rulebook covers the recurring review packet. The first 30 days guide covers how to prove one loop without turning the first month into a migration marathon.

Define a clean first scope

A practical first executive knowledge-base scope includes:

1. two or three recurring operating jobs;
2. the highest-consequence current-truth domains those jobs require;
3. ten to twenty canonical pages only if each has an owner and source rule;
4. a source layer with explicit allowed use and retention boundaries;
5. decision and authority records with revisit triggers;
6. a conflict and stale-context queue;
7. one recurring briefing or follow-up workflow;
8. a fixed set of healthy, conflict, privacy, stale, refusal, and recovery cases;
9. a reviewer who can correct both the output and the owning knowledge;
10. a maintenance cadence and stop condition.

Page count is not the success condition. A smaller system that can cite, refuse, escalate, and correct is more useful than a large archive that returns polished uncertainty.

The synthetic executive briefing sample shows a reviewable artifact with source posture and decision boundaries. The executive AI briefing workflow shows how governed sources, principal review, and follow-up fit together without granting the system external authority.

Choose build, repair, defer, or stop

End the scope review with one of four decisions:

• Build — the operating job is recurring, source authority is defined, sensitive material is bounded, human authority is named, representative cases are available, and someone owns maintenance.
• Repair — the job is useful, but source conflicts, stale records, missing citations, weak access boundaries, or unclear ownership must be fixed before routine use.
• Defer — the job depends on unavailable evidence, unresolved authority, a storage or legal decision, or access that has not been approved; record the trigger for another review.
• Stop — the proposed system is mainly an archive dump, requires unsafe data centralization, treats inference as fact, bypasses human authority, or has no maintenance owner.

The right first result may be a refusal to ingest most of the archive. That is not lost progress. It is proof that the system has an inclusion standard.

If your team keeps repeating context, losing decision rationale, or asking an AI chat to infer the company from scattered documents, start with one governed operating job. Bring the sources it may use, the people who own truth, the material that must stay out, and the decisions that remain human. That is enough to plan Knowledge Base & Executive Ops Systems without pretending a bigger pile of searchable documents is current truth.