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.
Data in one workspace is strictly isolated from another workspace, even within the same organisation. A user with access to Workspace A cannot see anything in Workspace B unless they are explicitly invited.

​
2. Case

A case is the atomic unit of knowledge in FTS. Each case has:
  • A title and summary
  • A rich-text body with Markdown, code blocks, tables, and inline images
  • A state (Draft, In Review, Verified, Published, Deprecated)
  • Tags from the workspace taxonomy
  • 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 deleted. It can be deprecated, archived, or moved, but the history is permanent. This is critical for regulated industries and for long-term knowledge preservation.

​
3. Evidence

Evidence is any file attached to a case that supports the claims inside it: photos, PDFs, measurements, CAD screenshots, video clips, or reports. 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. FTS automatically runs OCR on image and PDF evidence. The text extracted is indexed alongside the case body, which means you can search for a word that only ever appeared inside a photo of a handwritten note.

​
4. Review workflow

Cases go through a lightweight but strict review before becoming “truth”: 
Draft → In Review → Verified → Published → (Deprecated)
  • Draft is where you work alone.
  • In Review blocks edits except for the reviewer’s comments.
  • Verified means a second pair of eyes has confirmed the facts.
  • Published makes the case visible to the wider workspace and eligible for AI indexing.
  • Deprecated is how you retire a case without deleting it.
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 workspace uses to classify cases. Out of the box, each workspace gets a starter taxonomy with four dimensions:
  • Component / part — what physical thing the case is about
  • Failure mode — the nature of the problem
  • Site / asset — where it happened
  • Severity — how serious it is
Workspace admins can add, rename, merge, or retire taxonomy entries from Settings → Taxonomy. Tags are references, not copies — renaming a tag updates every case that uses it.

​
6. Roles and permissions

FTS uses three roles at the workspace level:
RoleCan do
OperatorCreate and edit their own cases, attach evidence, send cases for review.
ReviewerEverything an operator can do, plus approve or reject any case in the workspace.
AdminEverything a reviewer can do, plus manage members, taxonomy, integrations, and workspace settings.
Roles are per-workspace — someone can be an Admin in one workspace and just 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.

Ready for the first walkthrough?

Walk through a real failure report, step by step.