Custom GPT Knowledge Base: Add, Test, and Maintain Sources

A custom GPT knowledge base is the reference material you attach for the GPT to use when answering. Start with a small, current set of documents, separate source facts from behavior instructions, and test answers against known passages before other people rely on it.

Use fenbs for changing project decisions and progress that should remain available beyond one GPT’s uploaded files. First check whether you can edit the GPT at all: OpenAI’s creation and editing guide↗ (opens in a new tab) says personal accounts cannot create or publish new GPTs, while eligible existing GPTs can still be edited.

How do you get a useful first version?

1. Define one job, such as answering questions about an approved onboarding handbook. List the questions users need answered before collecting files.
2. Choose the current source for each subject. Remove superseded copies and label the document with its owner, scope, and effective date.
3. In an editable GPT, add reference documents as knowledge and put response behavior in instructions. Ask for source names and sections when an answer depends on them.
4. Test the result in Preview with questions whose answers you already know, then with a question the files cannot answer.
5. Apply the reviewed update and keep the source files, expected answers, and maintenance owner outside the GPT as well.

Suppose a small design studio wants an assistant for employee onboarding. Start with the approved handbook and a concise directory of current procedures. Do not upload every draft, meeting transcript, and abandoned policy. The first version should answer a narrow set of real questions well enough for the handbook owner to verify.

The general AI knowledge base guide covers the broader approach. Here the job is maintaining a reliable source set for an editable GPT, including the tests and ownership that stop an upload from becoming an unattended archive.

What belongs in the documents and what belongs in instructions?

OpenAI distinguishes knowledge as reference material from instructions that guide behavior. Its editing guide recommends clear, text-forward documents and testing the result after upload. Use that distinction to organize your material: the handbook explains the procedure; the instructions explain how the assistant should answer questions about it.

Give each document a clear title and purpose. Keep headings meaningful, expand uncommon abbreviations, and write table headings so their meaning survives outside the visual layout. If an important answer exists only in a diagram, add a plain-language explanation you can compare with the diagram.

Mark uncertainty explicitly. “Draft awaiting approval” is different from “current procedure.” When two documents disagree, resolve the conflict with the responsible person before treating either as authoritative. More content does not fix a disagreement about what the organization actually decided.

How should you check upload limits without overfilling the GPT?

Use the file-limit and accepted-format sections of OpenAI’s linked editing guide for the current custom GPT knowledge base limit. Check the live guidance before reorganizing files around a number from an old tutorial. A successful upload shows that a file was accepted; it does not show that every important question will be answered correctly.

Make an inventory before uploading: title, owner, current version, topic, and why the assistant needs it. If two files cover the same question, decide which is authoritative. Combine related material when that makes the source easier for a person to maintain, rather than creating one enormous file solely to avoid a file count.

Keep the original editable sources in their normal home. The GPT’s copy is one delivery of that material, and the owner needs a practical way to update it again. A short source inventory also makes it easier to move the workflow later without reconstructing what was attached.

Which questions reveal whether the sources are working?

Write the expected answer before running the test. Include the source passage, acceptable paraphrases, and any caveat the answer must preserve. You are checking whether the assistant uses the intended evidence, not whether it produces confident prose.

• A direct lookup: ask for a documented step and check the source section it names.
• A paraphrased question: use everyday wording that differs from the heading in the document.
• A boundary case: ask whether a rule applies to a group the document excludes or never mentions.
• A missing answer: ask something outside the source set and check that the assistant identifies the gap.
• A revision check: after replacing an old procedure, ask a question that distinguishes the old and new answers.

For the studio example, ask what a new hire should do first, then ask about an exception for a contractor. If the files do not settle the exception, the useful answer says so and points to the handbook owner. An invented exception should fail the test even if it sounds reasonable.

Save failed questions as well as passing ones. After a revision, repeat the same checks in a fresh conversation. Record whether the failure came from an unclear source, a contradictory instruction, or an answer that did not follow the available evidence. Fix the smallest identifiable problem before adding more material.

Keep the maintenance decision and remaining tests with the work. fenbs project context lets the next supported connected assistant read which source revision was approved and which checks still need attention.

How do you keep the sources useful through changes?

Name one person responsible for each important source. When a procedure changes, update the source, replace the attached copy where editing is available, and rerun the questions it affects. Record the revision and what you checked so another person can distinguish “uploaded” from “verified.”

Also check the product’s direction before investing in a new setup. OpenAI’s GPT migration guide↗ (opens in a new tab) describes moving affected workflows to plugins, with instructions becoming a skill and knowledge files becoming reference resources. Follow the notice for your account or workspace, and test the replacement before switching.

Keep your source inventory and expected answers usable outside the GPT. They give you a portable acceptance check when the delivery changes. OpenAI’s plugin-building guide↗ (opens in a new tab) describes adding reference material and retesting updates; the same source-quality discipline remains useful.

If you are still choosing the container for the work, read ChatGPT projects versus custom GPTs. For the cross-product choice, see Claude Projects versus custom GPTs. Keep those choices separate from the immediate question of whether your own sources answer accurately.

How to maintain this with fenbs

1. Create a free account and add a project for the reference workflow. Give it a clear goal, such as accurate answers from the approved employee handbook.
2. Add tasks for document cleanup, answer testing, and the next source revision. Record the plan and the actual test results on each task.
3. Use Decisions and rules to record the source owner’s approved choices. Keep unresolved exceptions open for a person to decide.
4. Add source locations to Links and listings, then connect a supported assistant through Integrations if you want it to help maintain the work.
5. Ask the connected assistant to read the project context at the start and save progress before stopping. Include the current source revision and the next question to test.

fenbs is free for one person, no credit card. It does not upload files into your GPT, import its knowledge, or provide a document-answering engine. It is not the right fit if you only need one static handbook answered inside ChatGPT; it helps when source maintenance creates continuing work across assistants.

Your first useful milestone is small: one approved source set, a handful of checked answers, a named owner, and a known next review. The AI memory topic hub covers how that reviewed work can remain useful beyond one conversation.