Skip to main content
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 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: 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

Once you have this mental model, the rest of the product is just tooling to make each of these things faster, cleaner, and safer.

Ready for the first walkthrough?

Walk through a real failure report, step by step.