Skip to main content
Library is the controlled home for working files, approved material, and service evidence. It gives teams a place to organize folders and files without turning email attachments or chat uploads into the only copy of an important document. It is not an unrestricted public file store: what a member can see, open, change, share, or remove depends on the space and the member’s assigned scope. In the Citizen Services Directorate scenario, the inspection report and approved response template for CSR-2026-00042 are stored in the designated service space. The request record contains the service facts and links to the required evidence; Library retains the files in a location that the correct team can govern.

​
Goal

Choose the right Library space, create a clear evidence path, use only the file actions your scope allows, and understand the difference between moving a file to the recycle bin and permanently deleting it.

​
Choose the right space before upload

Library supports personal and shared spaces. A personal space is appropriate for a member’s working material that does not need a team-maintained location. A shared space is appropriate for material the approved team must locate, review, and manage together. Do not use a personal space to hide evidence that the service team must retain or review. Do not place unrelated citizens’ records in a broad shared folder simply because it is convenient. Follow the organization’s retention, classification, and file-naming rules in addition to the KayanOS access model.

​
Build a controlled evidence path

For the Citizen Services Directorate scenario, use a predictable structure that matches the service model:
  1. Open Library and select the approved shared service space.
  2. Create a folder only when the organization’s structure calls for it. Use a meaningful name, such as Citizen Service Requests / 2026 / CSR-2026-00042.
  3. Upload the approved evidence or move it from an authorized location. Confirm the file name, type, content, and relationship to the request before completing the upload.
  4. Open or preview the uploaded file to confirm it is the intended version and readable.
  5. Link or reference the evidence from the request or inspection record through the approved field/workflow. The record should tell reviewers why the file matters; the file name alone is not a service decision.
  6. Assign or verify the appropriate shared-space access. Do not use a copied link as a way to bypass a scope that should limit viewing.
  7. When a file is superseded, follow the retention policy and use a clear replacement/move process. Do not assume that every file has version-history, public-link, or universal online-editing behavior.
Expected result: the authorized team can find the correct evidence from the relevant request, while members outside the approved space do not gain access through convenience copies.

​
File and folder actions

Depending on the selected item and your permissions, Library can provide actions such as open, preview, download, copy link, share, rename, move, replace, send to recycle bin, restore, or permanently delete. The presence of an item in a folder does not guarantee every action is available. Use these boundaries:
  • Open/preview/download to inspect a file you are allowed to access. Check that the file is the right version before relying on it in a decision.
  • Rename/move/replace to maintain the approved organization. Preserve a meaningful relationship to the request and do not move evidence into a broader space merely to make it easier to find.
  • Share/copy link only when the recipient already has a legitimate need and the organization’s sharing rule permits the action. A link should not substitute for a scoped access decision.
  • Edit only when the file type and your files:update scope support editing. Do not promise that every file can be edited in place.
  • Recycle when the item may need to be restored or is awaiting the organization’s retention decision.
  • Permanently delete/purge only when deletion is authorized and irreversible removal is intended. Treat this as a distinct, higher-risk action.

​
Recycle bin versus permanent deletion

Sending an item to the recycle bin is a non-destructive step: it removes the item from the active location but allows a permitted recovery workflow. Restoring returns the item to active use according to the product’s available restore behavior. Purging or permanently deleting is destructive and should be used only after the organization confirms that retention, legal hold, service audit, and access implications are satisfied. Before permanent deletion, ask:
  1. Is the file evidence for an open request, inspection, decision, or complaint?
  2. Does the organization require a retention period, review, or legal hold?
  3. Is there an approved replacement linked from the record?
  4. Does the person performing the action have the scoped permanent-delete authority?
  5. Would moving to the recycle bin meet the immediate need more safely?

​
Availability and permissions

Library operations are scope-aware. A member may be able to see a shared space but not upload to it, open a file but not share it, move a file but not permanently delete it, or edit a supported document only when files:update applies in the relevant scope. Check the requested action at the file/folder and service-record levels rather than granting broad access because a team needs one document. If a file action is missing, verify:
  1. the current organization and selected personal/shared space;
  2. access to the file/folder itself and its parent location;
  3. the required verb for open, update, share, recycle, restore, or permanent delete;
  4. the member’s assigned scope; and
  5. whether the file type supports the intended action.

​
Safe testing

Use synthetic material that contains no citizen data. In an approved non-production space, create a folder, upload a harmless file, preview it, rename or move it within the allowed space, and confirm that a non-authorized member cannot access it. Send the file to the recycle bin and restore it. Do not test permanent deletion unless the organization explicitly authorizes the test and the item is disposable.

​
Troubleshooting

KayanOS Library with controlled material for a representative service team.