What to send before an executive knowledge-base build

A useful executive knowledge-base build starts before anyone migrates a folder.

The intake packet should show what the system must help with, which material may be inspected, who owns current truth, what uncertainty must remain visible, and which actions stay with a person. Without that contract, the project becomes document compost: many inputs, weak authority, and a confident assistant making guesses from stale context.

Send less material than you think. Send the right material, with enough context to decide whether a build should happen at all.

This page owns preparation. The scope guide decides what belongs in the system; the first 30 days guide covers implementation; the maintenance rulebook covers recurring review.

Define the intake contract before collecting files

Write one paragraph that fixes the boundary of the proposed system:

• the two or three recurring operating jobs it should support;
• the people who will use and review its output;
• the source areas it may inspect;
• the artifact it should prepare;
• the actions it must not take;
• the failure that would make the first build unacceptable;
• the person responsible for current truth after launch.

A workable contract might say:

Prepare a weekly leadership brief from the approved project tracker, decision register, and current service pages. Show source dates, conflicts, stale claims, and open decisions. The chief of staff reviews the packet. Do not send messages, change external records, or state a commitment as approved unless the principal has approved it.

“Build a company brain” is not a contract. Neither is “put all our files into AI.” Those phrases avoid the hard questions about purpose, source authority, privacy, review, and upkeep.

Name the operating jobs

List the recurring jobs the knowledge base must support.

Good candidates include:

• prepare a pre-meeting brief for a weekly leadership call;
• recover decision history before a partner or investor conversation;
• summarize project status from approved current sources;
• prepare follow-up tasks after a meeting, with approval before anything external happens;
• onboard a trusted operator without repeating the same company context every week.

Poor candidates include:

• “make the AI know everything”;
• “summarize all our docs”;
• “replace the chief of staff”;
• “answer any question about the company.”

The first build needs a small number of jobs that are frequent enough to maintain and narrow enough to test. For each job, name the trigger, expected artifact, reviewer, decision supported, and worst plausible mistake.

Build an evidence register, not a confidence theater

The packet should label what is known and how it is known. Use a small evidence register rather than blending polished sources, private recollections, and old drafts into one story.

Use these states:

• verified — backed by the declared authoritative source and current enough for the intended use;
• reported — stated by a named person but not yet confirmed against the source that should win;
• inferred — a reasonable interpretation that must not be presented as fact;
• conflicting — credible sources disagree and a named owner must resolve the conflict;
• stale — once useful, but now outside its freshness window or superseded by a later decision;
• unavailable — required evidence is missing, inaccessible, or not approved for this use.

For every important item, capture the claim, evidence state, source, source date, owner, allowed use, and next review. Unknown and unavailable are valid states. A useful intake packet exposes them before a model turns them into plausible filler.

Do not treat a polished deck as verified because it looks final. Do not treat the latest file as authoritative because its timestamp is newer. Do not turn one executive’s recollection into canonical company history without recording who reported it and who can confirm it.

Map source areas and exclusions

Prepare a short source map before sending files. For each source area, note:

• where it lives;
• what it contains;
• who owns it;
• the current or authoritative version;
• how quickly it becomes stale;
• whether it may support internal briefing, external copy, or neither;
• what must be excluded.

Typical source areas include meeting notes and transcripts, project trackers, decision records, approved public positioning, partner or investor materials, operating runbooks, and current service descriptions.

Do not send raw inbox exports, private relationship notes, customer data, contracts, HR material, financial records, credential-bearing files, or whole drives merely because they are available. If the first operating job does not need a source area, leave it out.

Raw public-form submissions are untrusted intake. They should not enter an executive knowledge base, an agent prompt, a public proof artifact, or an autonomous workflow merely because a form delivered them to an inbox.

Write source precedence before the first import

For every high-risk domain, say which source wins when material conflicts.

Many weak intake processes make the same mistake. They treat access as permission. It is not. Access is not authority, and authority is not permission to disclose. A source may be authoritative for internal briefing and still be prohibited in public, client-facing, or partner-facing copy.

If no source wins, record the conflict and its resolver. Do not let the system average two incompatible versions or choose whichever one produces the neatest answer.

Prioritize current truth by consequence

Name the domains where stale context would hurt most: active projects, product or service scope, partner conversations, public positioning, operating decisions, people context, and sensitive approval boundaries.

For each domain, answer:

1. What would break if this were wrong?
2. How current must it be for the operating job?
3. Who can mark it current?
4. What should the assistant do when the freshness window expires?

The consequence determines what gets canonicalized first. A registration number and an active partner commitment do not need the same review cadence. The intake packet should say so rather than promising that one archive is “up to date.”

Bring decisions with their rejected paths

A useful decision record includes:

• what was decided and when;
• who had authority to decide;
• the evidence used;
• options rejected and why;
• unresolved assumptions;
• what would trigger a revisit;
• which later record supersedes it, if any.

Also include one unresolved decision that the proposed briefing workflow should help prepare. This exposes missing sources and unclear authority faster than a demo built around an easy, settled question.

A transcript records discussion. It does not automatically record approval. A draft memo can show the thinking. It does not become policy until the person with authority accepts it.

Make approval and privacy boundaries operational

Write the boundary before the material is transferred:

• safe to summarize internally;
• usable for external copy only after named approval;
• restricted to legal, finance, HR, security, or partner review;
• prohibited from storage or model access;
• prohibited from transfer to another tool;
• prohibited from quotation, screenshots, or public proof;
• retained only for a stated period or operating purpose.

External action stays human-owned. The first system may prepare a brief, proposed task list, draft follow-up, or issue summary. A named person still decides whether to send a message, update an external record, make a commitment, disclose private context, or approve commercial wording.

If the reviewer cannot see which artifact revision they approved, the approval is weak. If the content changes, the prior approval is stale.

Use a safe transfer manifest

Do not begin with an unlabeled archive link. Prepare a manifest before sharing files or granting access.

For each transfer, record:

• file or source-area name;
• owner and transfer date;
• intended operating job;
• evidence state and source date;
• allowed use;
• sensitivity class;
• exclusions or redactions;
• retention or deletion rule;
• person who approved the transfer.

Do not include credentials, access tokens, private keys, recovery codes, production environment files, or unrestricted database exports. Do not use public links for private material merely to make ingestion easier. If a sensitive source is necessary, agree on the minimum subset and handling path first.

The manifest gives reviewers something concrete to reject. That is useful. “We shared the folder” is not an auditable handoff.

Send one real briefing request and expected artifact

A sample request should declare the task, allowed sources, freshness rule, and prohibited action:

Prepare me for the weekly operating review.
Include current priorities, unresolved blockers, decisions needed,
relationship sensitivities, and follow-up items from the last review.
Use only the approved tracker, decision register, and current service pages.
Flag anything outside its freshness window or missing a source.
Do not draft or send external messages.

Attach the output shape you expect: sections, citations, evidence labels, open decisions, reviewer status, and next-action owners. The synthetic executive briefing sample shows an artifact shape without pretending to contain private client context or production results.

Test the packet against representative cases

A packet is not ready merely because the happy-path documents are tidy. Use fixed cases to test whether the proposed source and authority rules survive ordinary mess.

Also test unavailable evidence. If the desired operating job depends on a source the team cannot access or approve, the honest result is defer or redesign, not “we will connect it later.”

Name the maintenance owner and review moment

The owner can be a founder, chief of staff, operator, EA, project lead, or trusted agent operator. It cannot be “everyone.” Everyone means nobody, and nobody means the knowledge base starts lying by neglect.

The owner must be able to:

• confirm which source wins;
• mark material current, stale, conflicting, excluded, or unavailable;
• approve promotion into canonical current truth;
• keep external-use boundaries visible;
• pause the workflow when the source contract breaks;
• schedule review around the operating job.

Tie review to a real moment: before the weekly leadership brief, after a partner call, before an investor update, or when public positioning changes. “Quarterly cleanup” is weak if the knowledge is used every Monday.

Copy this one-page intake template

Use this as the first shared doc before transferring files. Keep it blunt. Empty fields are evidence that the build cannot safely assume an answer yet.

Executive knowledge-base intake packet

1. Intake contract
- Operating jobs:
- Primary users:
- Reviewers:
- Expected artifacts:
- Prohibited actions:
- Worst plausible mistake:
- Maintenance owner:

2. Evidence register
- Claim or knowledge item:
- State: verified / reported / inferred / conflicting / stale / unavailable
- Source and source date:
- Source owner:
- Allowed use:
- Next review or resolution:

3. Source map and precedence
- Source area and location:
- What it contains:
- Source that wins when records conflict:
- Freshness window:
- Allowed use: internal briefing / external copy / do not use externally
- Exclusions:

4. Current-truth priorities
- Domain where stale context is expensive:
- What breaks if wrong:
- Person who can confirm current truth:
- Assistant stop rule:

5. Decisions and open loops
- Recent decision and decision owner:
- Evidence used:
- Rejected options:
- Revisit trigger:
- Open decision needing a brief:

6. Approval and privacy boundaries
- Safe for internal briefing:
- Requires principal approval:
- Requires legal / finance / HR / security / partner review:
- Never store, quote, screenshot, or send to another tool:
- External actions that stay human-owned:

7. Safe transfer manifest
- Source transferred:
- Intended operating job:
- Sensitivity and redactions:
- Transfer approver:
- Retention or deletion rule:

8. Representative cases
- Normal:
- Conflict:
- Stale:
- Privacy:
- Refusal:
- Recovery:

9. Sample briefing
- Request:
- Allowed sources:
- Required citations and freshness rule:
- Expected artifact:
- Reviewer:

10. Operating ownership
- Maintenance owner:
- Review moment and cadence:
- Pause condition:
- Correction path:

Do not make the template pretty before it is honest. Its job is to expose source, authority, privacy, and ownership gaps early enough to avoid building around them.

Choose build, repair, defer, or stop

End the intake with a decision, not a folder count.

• Build — the operating job, source precedence, evidence states, representative cases, reviewer, prohibited actions, transfer rules, and maintainer are clear enough for one bounded workflow.
• Repair — the job matters, but sources, ownership, privacy rules, or the expected artifact need work before implementation.
• Defer — the necessary source, reviewer, or approval is not available yet, but a specific condition could change that.
• Stop — the proposal depends on unrestricted private-data ingestion, invisible authority, unsupported external action, or a vague goal that cannot be tested.

If the verdict is build, take the packet into a scoped Knowledge Base & Executive Ops Systems engagement. If it is repair, fix the operating source and owner first. If it is defer or stop, keep the archive where it is. Bad context is not made safer by being searchable.