Run a clean document library

Document intake

A file is useful because it is authoritative—not because it is long.

The file area is for approved knowledge that does not fit naturally into a published WordPress page. A concise current handbook can be excellent. A folder of overlapping presentations, scans, and old price sheets can make answers less reliable.

Decide whether a file belongs here

Upload a document when it contains stable information the public assistant should be able to explain, an accountable owner can keep it current, and a WordPress page is not the right publishing format. Typical candidates are product manuals, program handbooks, specification sheets, or a carefully sanitized operational guide.

Do not upload a file merely because it exists. Exclude customer records, employee material, contracts with confidential terms, exports containing personal data, private network details, credentials, internal incident reports, and licensed documents you are not allowed to process. A vector store is a retrieval service, not a private staff drive.

The four-signature testContent owner: current and correctPrivacy owner: approved for OpenAI processingCustomer owner: appropriate for a public answerMaintainer: knows when and how to replace it

Supported formats and what “supported” means

Accepted document formats

Format	Accepted upload	How the admin opens it	Preparation advice
PDF	Yes	Browser preview is available.	Prefer searchable text. Scanned pages or complex columns may not yield clean retrieval; test unique facts after indexing.
DOCX	Yes	Open with a compatible local application.	Remove comments, tracked changes, hidden revisions, and internal notes before creating the approved copy.
PPTX	Yes	Open with a compatible local application.	Slides often omit context. Make units, conditions, and speaker-note-only facts explicit in visible content.
TXT	Yes	Browser preview is available.	Use descriptive headings and readable sections; a large unstructured dump is difficult to govern.

Each file must be nonempty and must fit within the WordPress upload limit reported by wp_max_upload_size(). That limit belongs to the WordPress/PHP environment, so it can differ between Local, staging, and production. Passing the extension and size check only means the upload is acceptable; it does not prove that the document’s text will retrieve well.

The file’s journey through two systems

When you upload, SmartSite processes files one at a time:

1. WordPress validates the type and size and writes a local copy to the uploads area.
2. The plugin uploads the document to OpenAI for assistant use.
3. It attaches that OpenAI file to the site’s vector store with file attributes.
4. OpenAI indexes it asynchronously.
5. SmartSite stores the local record and refreshes the remote indexing status.

This explains why a successful browser upload is not the same as completed knowledge. Between upload and completion, the file can still be processing. A failure during setup is cleaned up where possible so an incomplete local or remote copy is not knowingly left as a valid record.

Files and pages share one library, not one lifecycle

WordPress pages become Current through the page synchronization process. Uploaded documents attach and index through the file process. The same vector store can therefore contain Current pages, a completed PDF, and a TXT file still processing at the same time.

Read file states as operational facts

What a file status allows you to conclude

State	What it means	What to do
Processing or indexing	The file has not reached a ready terminal state.	Wait and refresh. Do not sign off the knowledge test yet.
Completed	OpenAI reports indexing complete.	Ask targeted questions whose answers are unique to the document; completion is readiness, not a quality score.
Failed	The remote indexing process ended unsuccessfully.	Record the error, inspect the source, remove the failed record, and upload a corrected approved copy.
Cancelled	Processing ended without completion.	Treat it as unavailable. Remove or replace it deliberately.

A document marked Completed can still be poor knowledge: it may be an image-only scan, contain tables without context, contradict another source, or answer with obsolete values. Indexing success is technical evidence, not editorial approval.

Prepare a document for retrieval

1. Create an approved copy. Flatten comments and tracked changes; remove hidden sheets, notes, personal data, and internal annotations.
2. Give it a useful filename. Returns-policy-EU-2026.pdf is governable; final_v7_REAL.pdf is not.
3. Make the document self-explanatory. Put product, audience, market, units, version, and effective date in the visible text.
4. Check for duplicates. Search selected pages and existing files for an older version of the same facts.
5. Upload in Knowledge Files. Keep the page open until the local and remote setup completes.
6. Wait for Completed. Processing is not a pass.
7. Test distinctive facts. Ask for a specification or rule found only in this file, then phrase the question differently.
8. Record ownership. Outside the chat plugin, keep an owner and review date so the source is not forgotten.

Replacement is a small release, not a casual upload

There is no reason to keep “old” and “new” copies live while deciding which one retrieval should prefer. Prepare and approve the replacement, upload it, wait for Completed, test it, then remove the obsolete file. If continuous accuracy matters, perform this during a controlled maintenance window and test immediately.

When filenames, headings, and version statements make the effective document obvious, future administrators can understand the library without opening every file. Do not rely only on a date hidden in a footer.

Removal means removal in both places

Removing a knowledge file is deliberately destructive. The operation removes its vector-store attachment/OpenAI file, deletes the local uploaded copy, and removes the WordPress record. This is different from deselecting a WordPress page and waiting for the next page sync.

Keep an archive outside the plugin if policy requires one

The Knowledge Files area is not a records archive. If the organization must retain a source, store the approved original in its proper document-management system before removing it here. Do not keep obsolete knowledge attached merely for retention.

After removal, test a question that previously depended on the file. The assistant may still answer from another source or from general model knowledge, so review retrieved-source evidence rather than assuming any plausible answer proves the file remains.

A practical intake record

For each production document, keep five facts in your content operations process: public purpose, owner, approval date, effective market/audience, and replacement trigger. SmartSite does not turn those governance decisions into truth automatically. The discipline is what prevents a two-year-old slide deck from quietly winning retrieval over the current policy page.

See the file desk

knowledge-files

Screenshot capture pending /images/screenshots/knowledge/files.webp

Upload and Remove Knowledge Files

Capture

Show the Knowledge Files area with one completed fictional PDF and one indexing TXT file; filenames must not reveal clients.

Show

Upload control, accepted types/limit, filenames, state badges, Preview/Open, Remove

Viewport

Desktop, 1440 × 900

Annotate

Use numbered callouts only for controls referenced in the procedure.

Redact

OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text

Continue the library work

• Learn where files sit in the full knowledge journey.
• Interpret page and vector-store state in the sync control room.
• Investigate a completed file that still does not answer well with the troubleshooting field guide.