Complete a knowledge-library document¶

When every part of a file has arrived, Zerohive still needs to check the complete document and hand it to the selected knowledge-library entry. This acceptance stage is called admission. It protects the connection between the original upload, its document version and the file that the library will use.

The document checks described here are implemented. The complete connected library experience is still being verified. This page explains preparation, results and recovery; step-by-step screen guidance will follow the verified library journey. Start with knowledge-library file uploads for transfer and recovery.

Prepare a document that can be accepted¶

Use a document that your organization permits every current member to access. The supported declaration is Normal, with confirmation that the document is suitable for all members. A restricted or confidential declaration is rejected by this admission flow. Do not change a classification simply to get a file accepted; use the organization's appropriate handling process for restricted information.

The system checks this declaration against the identity and contents of the submitted file. It does not read the prose and independently determine whether it contains sensitive information. The person managing the library remains responsible for making the correct declaration. A clean malware scan is also not a review of accuracy, confidentiality or suitability.

Upload creation currently accepts filenames up to 256 characters, while full validation accepts only 180. Keep the filename within the stricter limit from the start. Transferring a file successfully does not mean its name or contents have passed final validation.

Some otherwise readable documents can fail structural checks. PDF forms, scripts, embedded files and links represented by unsupported PDF actions are not accepted by this parser. Word documents with macros, external relationships, embedded objects or unsupported fields can also fail. Large or unusually complex documents may exceed structural limits even when their visible page count and file size fit.

Word's page count is based on the server's rendered output, which can differ from a local editor's layout. If a document is near the limit, simplify or divide it into suitable documents through the library's normal versioning process. Keep the original and review any revised copy before submitting it. Plain text must use valid UTF-8 and must not contain unsupported control characters.

What completion checks¶

Completion rebuilds the file from its saved parts and checks their order, lengths and fingerprints against the expected file. It then validates the document structure, requires a clean malware-scan result and, for Word files, checks the rendered page count. An unavailable scanner, failed rendering or inconclusive scan prevents fresh admission.

Only after those checks and the audience declaration pass can the final file be stored and reserved for the library entry. The reservation protects the handoff from ordinary temporary-upload expiry cleanup. The library still has to accept that exact file and version through its own authorization and version rules.

Completion itself does not publish a manual, make it appear in AI answers or deduct processing credits. It refreshes storage accounting, which is separate from paid knowledge processing. See the HiveAI overview for the broader capability and commercial controls.

Recover an uncertain completion¶

Keep the same organization, library entry, version, original uploader and original file. Check the entry's current result before starting another upload. If the file was already admitted, a matching completion retry verifies the stored file and the declaration without scanning and storing a second copy. It is not a way to replace that version with changed content or obtain a new malware-scan certificate.

Fresh admission requires an unexpired upload. Recovery of an already admitted result follows a different path; the old transfer expiry alone does not tell you whether the library accepted it. Ordinary personal upload recovery and temporary-upload discard are not substitutes for the knowledge-library flow.

A timeout or conflict can occur after storage changed but before the final result was recorded or returned. Cleanup handles some of those cases, but it is not a universal rollback guarantee. Support should reconcile the saved upload, library version and remaining file before advising another attempt. Do not repeatedly resubmit a large file merely because one completion response was lost.

Understand cleanup after acceptance¶

After the library confirms the exact document, the upload is marked as used and its temporary parts are removed. The accepted final document remains available under the library's own lifecycle. Removing temporary parts is not deleting the manual from the library.

If cleanup fails partway through, a matching confirmation retry can continue removing the remaining parts and refresh storage usage. Earlier parts may already have been removed. A successful library acceptance and a completed storage cleanup are therefore separate outcomes; a temporary accounting delay does not by itself mean the manual was rejected.

Managers and executives should distinguish transfer volume, accepted documents, published knowledge and useful answers. These are different measures. Support should capture the selected library entry and version, the original attempt, visible outcome, time and error, while keeping credentials and document contents out of ordinary support messages.

The private engineering reference describes the precise protocol and recovery limits. Source verification and initial reader review continue; this draft does not claim a successful live scan, connected library walkthrough or deployment acceptance.