The first 30 days of an executive AI knowledge-base build

The first month of an executive AI knowledge-base build should not be a heroic migration. It should answer a narrower question: can this system keep one important operating loop current enough to produce a briefing or follow-up artifact that an executive will trust and a reviewer can correct?

If the plan is “connect every folder and see what the model knows,” the project is already drifting. That produces a searchable archive with a confident narrator, not a maintained knowledge system.

A useful first month has one loop, one primary artifact, one authority map, and one maintenance owner. It ends with a decision to build the next slice, repair the current one, or stop.

Choose a loop with entry criteria

Pick a recurring moment where missing context causes repeated explanation, slow preparation, or avoidable uncertainty. Useful candidates include:

• a weekly leadership briefing;
• partner or investor conversation preparation;
• a project-status review;
• post-meeting follow-up preparation;
• decision-history recovery before a commercial call.

The candidate should meet five entry criteria:

1. Named reader: one person or role uses the output for a real operating decision.
2. Repeated trigger: the briefing, review, or follow-up happens often enough to maintain as a workflow.
3. Knowable sources: the team can identify where current facts, decisions, and open questions live.
4. Review authority: someone can correct the artifact and decide what may leave the company.
5. Bounded failure: a weak output can be held, corrected, and rerun without making an irreversible commitment.

If the loop has no source owner, no reviewer, or no stable output, do not start by adding a model. Repair the operating process or prepare the source-preparation packet first.

Write a one-paragraph contract before week one:

When [trigger] occurs, the system prepares [artifact] for [reader] using [approved sources]. [reviewer] checks the output before [external action]. Missing, stale, or conflicting material is shown, not guessed.

That contract is the scope boundary for the month. New folders, teams, and use cases wait unless they are required to make the chosen loop work.

Week one: publish source and authority rules

The first work is not bulk ingestion. It is deciding what the system is allowed to believe.

Create a source register with these fields:

Do not treat access as authority. Source access is not source authority. A meeting note may explain why a decision happened without overriding the signed agreement or approved decision record. A CRM entry may be current for contact details and useless for partner terms. A slide deck may be approved for one audience and stale for the next.

Add a conflict register for cases where two sources disagree. Each item needs the disputed claim, both source references, the last known decision, and the person who can resolve it. Until that happens, the knowledge base should show the conflict.

Unknown is a valid output. “No approved current answer” is more useful than a polished synthesis built from stale fragments.

Publish the authority map for the workflow as well:

• the system may find, compare, summarize, and draft from approved sources;
• the reviewer may accept, correct, reject, or request missing evidence;
• the principal or named owner controls sensitive facts, commitments, and external wording;
• the system may not send messages, update external records, or make commitments on its own.

External action stays human-owned. That rule should appear in the workflow instructions and in the review artifact, not just in a setup document nobody reads again.

Week-one deliverable: a source register, conflict register, authority map, and a small set of excluded material. If the team cannot agree on those, stop the build and resolve ownership first.

Week two: build current truth and conflict handling

Build only the canonical pages needed by the chosen loop. For a leadership briefing, that might be:

• active priorities;
• open decisions;
• recent decisions with source links;
• project status;
• key people and organizations;
• approval boundaries;
• stale, disputed, or missing context.

Each important statement should have a simple operating contract:

• claim: what the page currently says;
• status: current, provisional, disputed, stale, or unknown;
• source: where the statement came from;
• as-of point: when it was last confirmed;
• owner: who can correct it;
• external-use rule: whether it may appear in an outward-facing draft.

This is deliberately less elegant than a long narrative summary. The structure makes errors visible. A page can say:

The delivery sequence is current as of the last operating review. Commercial terms remain disputed between the proposal and meeting notes. Principal approval is required before either is repeated externally.

That statement helps a briefing workflow. A generic paragraph about “strategic alignment” does not.

Test correction while the scope is still small. Change one source fact, retire one stale claim, and resolve one conflict. Confirm that the canonical page changes, the old state remains traceable where needed, and the next artifact uses the corrected version. If correction is awkward in week two, a larger content migration will only bury the defect.

Week-two deliverable: the minimum current-truth set for the chosen loop, with source references, status fields, correction ownership, and visible uncertainty.

Week three: test the briefing workflow against fixed cases

Now build the workflow around the current-truth layer. It should produce a reviewable artifact, not merely fluent prose. A useful packet may contain:

• the decision or meeting context;
• current facts with source references;
• interpretation kept separate from facts;
• open decisions and missing inputs;
• stale or conflicting context;
• a draft follow-up section that cannot send itself;
• the named reviewer and required approval.

A briefing that cannot show its sources is a liability. A polished paragraph cannot compensate for missing evidence, hidden uncertainty, or unclear approval authority.

Use a fixed evaluation set before trying the workflow on live executive work. Include:

• a routine case with complete current sources;
• a case with one stale source;
• a direct source conflict;
• a missing decision owner;
• sensitive material that must stay internal;
• an external follow-up request that must remain a draft.

Review each output for evidence, not style. Ask:

1. Did every important factual statement point to an approved source?
2. Did the artifact separate fact, interpretation, and missing information?
3. Did stale and disputed material stay visible?
4. Did the workflow hold the output when authority was missing?
5. Could the reviewer correct the underlying truth instead of editing the same mistake repeatedly?
6. Did external action remain blocked until human approval?

Keep the failed cases. A corrected output without the original failure tells the next operator almost nothing about what changed.

The synthetic executive briefing sample shows the shape of a cited decision packet without pretending to be private client work or an outcome benchmark.

Week-three deliverable: a fixed test set, reviewed outputs, a failure log, and updated workflow instructions for the errors that matter.

Week four: run the operating review

Use the system in the real recurring loop, with the same review boundary as the test cases. Do not widen the source set during the run unless a missing source blocks the agreed artifact.

Record what happened:

• which source gaps stopped preparation;
• which claims reviewers corrected;
• which conflicts remained unresolved;
• whether the artifact arrived at the point it was needed;
• whether the reader used, rejected, or bypassed it;
• which page or rule needs maintenance before the next run.

Then assign the maintenance cadence. High-risk pages may need event-driven review when a decision changes. Lower-risk entity or background pages may tolerate a periodic check. The useful rule is not “review everything monthly.” It is “review each truth before its staleness can damage the operating loop.”

Name one maintenance owner. They do not need to write every update, but they must own source additions, conflicts, stale-page review, and changes to what the system may do. The maintenance rulebook provides a practical review packet for that job.

Week-four deliverable: one live reviewed artifact, a correction record, source and page maintenance rules, and a named owner for the next cycle.

Day-30 decision: build, repair, or stop

Do not end the month with a demo and a vague promise to “scale the knowledge base.” End it with one of three decisions.

Build the next slice

Continue when:

• the source hierarchy is understood;
• important statements are cited and correctable;
• the artifact serves a real recurring decision;
• reviewers can see why the system produced each section;
• external authority remains human-controlled;
• a maintenance owner accepts the operating burden.

The next slice should extend the same proven loop or add one adjacent artifact. It should not become a company-wide migration by reflex.

Repair the current slice

Repair when the operating loop is useful but source ownership, current-truth structure, review instructions, or maintenance behavior is unreliable. Keep the scope fixed and correct the failure. Adding more content to a system that cannot handle one conflict is dumb.

Stop

Stop when there is no recurring reader, no authority to settle conflicts, no reliable source set, no reviewer, or no willingness to maintain the pages. A search interface over unmanaged files may still be useful, but call it that. Do not market it internally as executive current truth.

What the first month should leave behind

A useful first build produces:

1. a one-loop workflow contract;
2. a source register and conflict register;
3. a small current-truth set with citations and status;
4. a briefing or follow-up workflow with human approval checkpoints;
5. a fixed evaluation set and failure record;
6. a maintenance cadence with a named owner;
7. a build, repair, or stop verdict.

That is enough to decide whether the knowledge system has earned a second slice. It is not a complete company brain, a substitute for executive judgment, or permission for an agent to act externally.

If the loop is ready for a bounded implementation, Knowledge Base & Executive Ops Systems scopes the source rules, current-truth layer, briefing artifact, approval boundary, and maintenance path around one operating job.