> ## Documentation Index > Fetch the complete documentation index at: https://docs.ferrufino-tech-solutions.com/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > Workspaces, cases, evidence, reviews, taxonomy, and roles — the six ideas you need to understand FTS. Understanding these six concepts is enough to be productive in FTS. Every feature in the product is built on top of them. ## 1. Organisation and workspace An **organisation** represents your company in FTS. It owns the subscription, the billing relationship, and the global settings. A **workspace** is a container inside an organisation. It holds cases, members, and a taxonomy. Think of it as a project, a plant, a product line, or a department — whatever scope makes sense for your team. The boundary is the **organisation**, not the workspace. Data in one organisation is strictly separated from every other organisation. **Inside** an organisation it is not: anyone who is a member of the organisation sees **all** of its workspaces — there is no per-workspace invitation, invitations always apply to the whole organisation. An earlier version of this note promised the opposite ("cannot see anything in Workspace B unless they are explicitly invited"); that was wrong. ## 2. Case A **case** is the atomic unit of knowledge in FTS. Each case has: * A **title**. There is no separate summary field * Three plain-text fields — **Observation / Symptoms**, **Root cause** and **Resolution**. Only the first is mandatory. They are **plain text, not rich text**: no Markdown is rendered, and there are no code blocks, tables or inline images. Pictures are attached as evidence instead * A **severity** and a **category** from the taxonomy * A **state** (`Draft`, `In Review`, `Verified`, `Published`, `Deprecated`) * **Tags** from a single list shared by the **whole organisation** — until 06.08.2026, this read "from the workspace taxonomy"; there is no per-workspace taxonomy (`TaxonomyConfig` is keyed by organisation, and `model Tag` carries no scope at all) * Attached **evidence** * A complete **audit trail** (who did what and when) * Optional **links** to other cases (for patterns, dependencies, follow-ups) A case is never hard-deleted by the delete action: deleting it sets its status to Deprecated and it stays readable, with its history intact. **There is no "move" function** — a case cannot be moved to another workspace, and archiving is not a third thing beside deprecating, it is the same one under the button's name. This is critical for regulated industries and for long-term knowledge preservation. ## 3. Evidence **Evidence** is a file attached to a case that supports the claims inside it. Two kinds are accepted: **images** (JPEG, PNG, GIF, WebP) up to 5 MB, and **PDFs** up to 20 MB — so a CAD screenshot or a scanned report is fine, a video clip or a spreadsheet is not. Evidence is stored in a secure EU-hosted object store and linked to the case by reference, not embedded — so the case record stays small and fast. On the Team plan and above, FTS automatically runs OCR on image and PDF evidence, and you can read the extracted text at the evidence itself. **It is not searchable.** An earlier version of this page said the extracted text was indexed alongside the case body and that you could search for a word that only ever appeared inside a photo of a handwritten note — neither is true. The keyword index is built from exactly four fields (title, observation, root cause, resolution), and the text behind semantic search adds only category, severity and tags to those four. If you need to find a case by something that is only in a picture, write it into the case text. ## 4. Review workflow Cases go through a lightweight but strict review before becoming "truth": ``` Draft → In Review → Verified → Published → (Deprecated) ``` * **Draft** is where you write. **You are not alone in it:** a draft is visible to every member of your organisation and findable in search. There is no per-case visibility setting. * **In Review** means the case is waiting for a decision. **This status does not block editing** — no status does. Saving an edit sends the case back to Draft, and it has to be reviewed again. * **Verified** means a second pair of eyes has confirmed the facts. * **Published** is the released, canonical version. The case was visible before this too; what the status changes is how binding it is. * **Deprecated** is how you retire a case without deleting it. It leaves the list and search results and stays in the history. The button that puts it there is labelled **Archive**. Every state transition is captured in the audit log with a timestamp and the responsible user. ## 5. Taxonomy A **taxonomy** is the structured vocabulary your organisation uses to classify cases. It has exactly three lists, and every workspace in the organisation shares them: * **Workspace Types** — what kind of place a workspace stands for (`testbed`, `production_line`, `lab`, `field`) * **Severity Levels** — how serious the case is (`critical`, `high`, `medium`, `low`) * **Categories** — the nature of the problem (`hardware`, `software`, `process`, `configuration`, `other`) Admins edit these three lists under **Settings → Taxonomy Config** — which additionally requires the **Team** or **Enterprise** plan; on Starter the shipped values above apply. **You add and remove values. You cannot rename, merge or retire one.** An earlier version of this page listed four dimensions — component, failure mode, site and severity — and promised that renaming a tag updates every case that uses it. Neither is true. Removing a value from a list does not touch cases that already carry it: the value they stored stays exactly as it is and simply stops being offered in the dropdown. Tags are a separate, flat list and have no rename either — a tag is added to or removed from one case at a time. ## 6. Roles and permissions FTS uses three roles, and they are held at the organisation level: | Role | Can do | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | **Operator** | Create and edit their own cases, attach evidence, send cases for review. | | **Reviewer** | Everything an operator can do, plus decide any case in the organisation — **Verify ✓** or **Request Changes**. There is no *Reject*. | | **Admin** | Everything a reviewer can do, plus manage members, taxonomy, templates and settings. | Roles are **per organisation**, not per workspace: a person holds one role, and it applies to every workspace of that organisation. Someone cannot be an Admin in one workspace and only an Operator in another. ## How it all fits together ``` Organisation (your company, billing) └─ Workspace (project/team/site) ├─ Members (with roles) ├─ Taxonomy (tags) └─ Cases ├─ Body + state ├─ Evidence ├─ Tags ├─ Reviews └─ Audit log ``` Once you have this mental model, the rest of the product is just tooling to make each of these things faster, cleaner, and safer. Walk through a real failure report, step by step.