Executive ops systems

What to send before an executive knowledge-base build

A practical intake packet for teams that want an AI-ready executive knowledge base without dumping private context into a tool and hoping it sorts itself out.

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

The first intake packet should show what the system needs to help with, what material is safe to inspect, who owns truth, and which boundaries the agent must not cross. Without that, the project becomes document compost: lots of inputs, weak current truth, and a confident assistant making guesses from stale context.

Send less material than you think. Send the right material.

1. The operating jobs

List the recurring jobs the knowledge base must support.

Good examples:

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

Bad examples:

  • “make the AI know everything”;
  • “summarize all our docs”;
  • “build a company brain”;
  • “replace the chief of staff.”

Those are slogans, not operating jobs. The first build needs two or three workflows that are painful enough to maintain and narrow enough to test.

2. A source map, not a data dump

Prepare a short source map before sending files.

For each source area, note:

  • where it lives;
  • what it contains;
  • who owns it;
  • how current it is;
  • whether it can be used for internal briefing only or also for external copy;
  • what should be excluded.

Example source areas:

  • meeting notes and transcripts;
  • project trackers;
  • decision records;
  • public positioning docs;
  • partner or investor materials;
  • operating runbooks;
  • approved service descriptions;
  • private notes that require special handling.

Do not send raw inbox exports, private relationship notes, customer data, contracts, HR material, financial records, or credential-bearing files unless the scope explicitly needs them and the handling rule is approved first.

3. Current-truth priorities

Name the domains where stale context costs the most.

Usually that means:

  • people and relationship context;
  • active projects;
  • products and services;
  • partner or investor conversations;
  • operating decisions;
  • public positioning;
  • sensitive approval boundaries.

For each domain, answer one question: what would be expensive if the assistant got it wrong?

That answer determines what gets canonicalized first. A clean knowledge base is not built by volume. It is built by risk and usage.

4. Decision records and open loops

Bring recent decisions, but include the rejected options and revisit triggers.

A useful decision packet says:

  • what was decided;
  • when;
  • by whom;
  • what alternatives were rejected;
  • why the chosen path won;
  • what is still uncertain;
  • what would trigger a revisit.

The revisit trigger matters. It lets the system say, “this condition changed,” instead of preserving an old decision as if it were permanent law.

Also bring unresolved decisions. Those are often the best first briefing workflows because they expose missing source material, unclear authority, and competing priorities.

5. Approval boundaries

Write the boundaries before the agent sees the material.

At minimum, define:

  • what can be summarized internally;
  • what can appear in public or client-facing copy;
  • what requires approval from the principal;
  • what requires legal, finance, HR, security, or partner review;
  • what should never be stored;
  • what should never be sent to another tool;
  • who can approve external commitments.

This is where many AI knowledge projects get sloppy. They treat access as permission. It is not. A document may be safe to read for internal context and still unsafe to quote, summarize externally, or use in sales copy.

6. A sample briefing request

Send one real briefing request that the system should eventually handle.

Good format:

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 approved internal sources.
Flag anything older than 30 days or missing a citation.
Do not draft external messages.

Adjust the wording to fit your team. The point is to show the desired output, the allowed source boundary, and the approval rule.

7. The maintenance owner

Name the person who will keep truth current.

This 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 does not have to write every page. They do need authority to mark what is current, what is stale, what is private, and what needs escalation.

A clean first packet

A practical intake packet can fit in one folder or shared doc:

  1. two or three operating jobs;
  2. a source map with owners and sensitivity notes;
  3. the five to ten domains where stale context is expensive;
  4. recent decisions and open decisions;
  5. approval boundaries and sensitive areas;
  6. one sample briefing request;
  7. the maintenance owner and review cadence.

That is enough to scope the first build without pretending the model can infer the company from a messy archive.

Copy this one-page template

Use this as the first shared doc before sending files. Keep it blunt. Empty fields are useful because they show what the build cannot safely assume yet.

Executive knowledge-base intake packet

1. Operating jobs
- Job 1:
- Job 2:
- Job 3:

2. Source map
- Source area:
- Location:
- Owner:
- Current through:
- Allowed use: internal briefing / external copy / do not use externally
- Exclusions:

3. Current-truth priorities
- Domain where stale context is expensive:
- What breaks if the assistant gets it wrong:
- Source that should win when notes conflict:

4. Decisions and open loops
- Recent decision:
- Rejected options:
- Revisit trigger:
- Open decision needing a brief:

5. Approval boundaries
- Safe to summarize internally:
- Requires principal approval:
- Requires legal/finance/HR/security/partner review:
- Should never be stored or sent to another tool:

6. Sample briefing request
- Request:
- Allowed sources:
- Required citations or freshness rule:
- External-message rule:

7. Maintenance owner
- Owner:
- Review cadence:
- Stale-context escalation rule:

Do not make the template pretty before it is honest. The point is to expose the operating job, source authority, approval boundary, and owner quickly enough that a first build can be scoped without a private archive dump.

If your team wants an executive AI knowledge base, do not start by sending every file. Start by defining the operating jobs, source boundaries, current-truth priorities, and approval rules. The archive can wait. Bad context is not made safer by being searchable.