Files
Every file the platform holds — an uploaded image, a mail attachment, a generated PDF, a documentation asset — lives in one tree, per organization.
Back office → Content → Files.
Why one tree
Because the alternative is five stores with five sets of rules, and the question "who can see this file?" then has five answers that eventually disagree. One tree means one answer.
Folders
Folders are yours to arrange. Files can be moved, renamed and organised without breaking anything that references them, because a reference points at the file rather than at its path.
A folder belongs to an organization
A file cannot be filed into another firm's folder. The platform refuses it — not as a validation nicety, but because a folder is the boundary as much as anything else is.
Public and private
A file is public or private, and the difference is enforced when it is served, not merely hidden in the interface.
| Kind | Example |
|---|---|
| Public | Product photographs, published documentation assets |
| Private | Mail attachments, contracts, documentation sources, anything under review |
A private file is served only to somebody entitled to it. An unpublished record's attachment is not reachable by guessing its address.
Deduplication
Identical bytes are stored once — within an organization.
Never across organizations
Two firms holding the same file byte for byte still have two stored files. Sharing the storage would have been cheaper and would have been a leak: the existence of a file is information, and one firm must not learn anything about another's.
Quotas
Storage is limited per organization, and personal mailboxes have their own per-user limit. A quota that is reached is reported clearly, and the operation is refused rather than half-completed.
Documentation files
Sourcebook stores each documentation set under a folder named after it, in a tree mirroring the git repository. Identical bytes are stored once, at the path git showed first, and every page pointing at them links the same file.