What the documents look like
Store counts and loss control work from the gap between recorded and physical stock and from shrinkage. The materials are count sheets, variance analyses, write-off approval forms and monitoring access records. These materials do not settle supplier payables, which is the main difference from supplier entry and settlement work. Data comes from POS inventory, WMS, monitoring systems and the SB/T count specification. The typical roles are the loss prevention department, store warehouse keepers and finance auditors.
These materials change hands during operations handover. A closing count is performed by one group; variance investigation is picked up by another; write-off approval and monitoring access pass across departments. The access controls step has to answer one question for each material and each request: what authorization state applies at the moment of handover. A retrieval result and a completed form are not authorization. A relevance score is not a category, entity or permission filter, and retrieval is not authorization.
Constraints at the access controls step
Count variances touch inventory value and employee conduct, so the materials are sensitive and handover requires account-by-account checks of the visible scope. In FastGPT v4.17.2, file-level permission for a knowledge base is a commercial-edition feature. In the default closed state, collection readability matches the knowledge base and the system queries no collection permission records. In the open state, each file or folder gets a full permission snapshot, and lists, details and retrieval recall are authorized item by item against that snapshot. Knowledge base permission remains the threshold; collection permission cannot bypass it. The team administrator does not bypass file-level permission. The team owner and system root are treated as holding all permissions on all files. Retrieval recall filters by the files the current member can read, and this applies only when authorization runs under the current member identity. A workflow that preselects a knowledge base without member-identity authorization does not perform file-level filtering.
Hypothetical paper exercise sample. Source text for checking: "March 2025 count sheet (Store A, count date 31 March 2025, status is pending review); variance analysis draft marks SKU-4471 book-to-physical variance of -12 units; write-off approval form (number BS-2025-0312, status is pending approval); monitoring access record (requesting person: Loss Prevention A, access window 31 March 2025 22:00 to 23:00)." Draft sentence to be judged: "The count variance is confirmed, the write-off is approved, and the monitoring access has completed authorization." The draft merges a pending review, a pending approval and an access record into completed facts, and it supplies no approval outcome and no authorization boundary evidence.
Configuration and implementation checks
| Configuration item | Documented setting or implementation check | Relation to this page's sample |
|---|---|---|
| File-level permission switch | Entered from the target row menu in the knowledge base file list; requires knowledge base manage permission; the switch is set only after materialization succeeds | Determines whether the count sheet can be authorized per file |
| Collection collaborator roles | Read, write, administrator, creator; the creator cannot be granted or modified through collaborator configuration | Checks the read and write boundary for the variance analysis and write-off form |
| Full-overwrite semantics | The submitted collaborator list is the final result and must contain the current creator | Prevents a handover from overwriting the creator record |
| Inherited and independent states | Inherited follows the parent; independent is not overwritten by the parent; restoring inheritance keeps node-specific permissions | Judges whether permissions follow a folder after handover |
| Retrieval recall filtering | After file-level permission is enabled, filtering is by files the current member can read; applies only under member-identity authorization | Checks whether the monitoring access record can be recalled without authorization |
| Special identities | System root and team owner are treated as holding all permissions on all files; team administrator does not bypass file-level permission | Checks the actual visible scope of Loss Prevention A |
Hypothetical starting point for this exercise: set the folder holding the count sheet to the independent state and grant Loss Prevention A read permission. This starting point is chosen because the count sheet in the sample is pending review and write operations should be restricted. The comparison object is the variance analysis file in the same knowledge base with no individual configuration. Observe the difference in visibility between the two in lists and retrieval. This starting point is a hypothetical setting, not an official default value.
Three common errors
- Treating pending approval as approved. In the sample the write-off approval form has status pending approval, while the draft sentence says the write-off is approved. The input is the approval form status field; the comparison object is the approval outcome record; the observable result is that the status field remains pending approval and no completed approval record exists. The sentence is unsupported.
- Treating an access record as completed authorization. In the sample the monitoring access record states only the requesting person and the time window, while the draft sentence says monitoring access has completed authorization. The input is the content of the access record; the comparison object is an authorization boundary statement; the observable result is that the record contains no authorization scope and no approver field. The sentence remains to be verified.
- Replacing a permission judgment with retrieval relevance. If a high similarity score is used to conclude that Loss Prevention A can view all count files, the input is the retrieval score; the comparison object is that member's file-level permission snapshot; the observable result is that the score does not change the readable file set in the snapshot. The inference does not hold.
How to verify the setup
- Input the sample source text and the draft sentence. Compare the field values "pending review" and "pending approval" against "confirmed" and "approved". The observable result is that the draft sentence is judged unsupported when the status fields have not changed to completed and no approval record exists.
- Input the account of Loss Prevention A and the folder holding the count sheet. Compare that folder's permission snapshot against the knowledge base threshold permission. The observable result is that isolation is in effect when the list shows only files readable in the snapshot and retrieval recall contains no file beyond authorization. If a file that is not readable appears in recall, record it as an abnormal observation.
- Input write-off approval form BS-2025-0312 and a handover request. Compare the authorization subject, the object and the approval status stated in the request. The observable result is that the request remains to be verified when it states no approver and no approval time, and it is not treated as an executed authorization. For the empty-result check, a paper input of [] can be used to check the downstream design, without claiming that a fictional rule retrieval necessarily returns an empty result.