FTS: Why Developers Need an Executable Specification

FTS is not a replacement for TypeScript, React, Node.js, or a database. It is a small language for that part of the system that the team usually writes three times: human business rule in the task, implementation in the code, and examples in the tests.

категория «Продажи»

  объект Покупка
    сумма является деньгами

  утилита «Рассчитать скидку»
    принимает Покупка
    возвращает деньги
    начинает с 0

    правило «Большая покупка»
      если сумма не меньше 10000
      то добавить 10 процентов от поля сумма

    пример «Покупка на двадцать тысяч»
      дано сумма равна 20000
      ожидается результат равен 2000

Such a file can be:

• check with fts check;
• execute as a clean utility through fts run;
• use as a set of new subject unit tests through fts test;
• convert to TypeScript and node:test through fts generate;
• compile into canonical JSON for React, Python, Go, or an agent;
• link to the actual snapshot and obtain a verifiable certificate.

Where Value Emerges

Imagine a regular task: “a regular customer gets an additional 5%, but the discount cannot exceed 15 000 ₽”. The analyst writes the text, the middle developer — the branching, QA — the test cases, the frontend — similar logic for the preview. After half a year, four versions diverge.

In FTS the rule, postcondition, and test cases are located together. The backend can execute it directly, the frontend can read the structure, CI can run the examples, and the agent can suggest a change and pass it to the same compiler. The value is not in the syntax being shorter than TypeScript. The value is in one verifiable source of the domain solution.

Where FTS is not needed

Don’t move the entire application into FTS. React loop, SQL query, retry HTTP client, transaction and sending email remain regular code. A good boundary looks like this:

1. the application reads data;
2. FTS takes a scalar snapshot and computes a solution;
3. the application checks the result;
4. only then does the application perform an external effect.

If a rule cannot be made deterministic or it is easier to express it in three lines that are never duplicated, FTS may be redundant.

And what lies beyond the boundary: FTS has grown into a language

The boundaries of FTS are narrow by design: no loops, no recursion, no lists, no computations over strings. Precisely because of this, the utility is guaranteed to terminate, which means it can be executed in CI, in access checks, and inside the agent, without fear of hanging. The entire course is about how to extract benefit from this limitation.

But the boundary has a second side, and it is already present in the same repository. From FTS emerged flang — a full-fledged language for which the specification turned out to be a subset. The relationship between them is not “similar,” but strict and verifiable: any existing model .fts — is a valid flang program, entirely lying within its total class, that is, within that subset of the language where computation termination is proven by the compiler. This is verified not by declaration, but by comparing two engines on all models in the repository: 19,593 inputs, zero discrepancies.

This practically means that your model is already understood by the second tool — it accepts .fts without any conversion:

$ node flang/bin/flang.mjs test examples/utilities/discount.fts
{"valid":true,"total":3,"passed":3,"failed":0,"results":[…]}

There is no and was never intended to be a return path: flang adds exactly what is absent in FTS on purpose — recursion, lists, sum types, strings as data. The model remains the model; the language is needed where the specification ends and the tool that serves it begins. Below, in modules about tooling and cross-language integration, this boundary is shown with concrete commands, and the track «flang» walks through the language as a whole.

Everything Can Be Done Without Installing Anything

The FTS compiler is built for the browser and runs on the course page: a rule from any module opens in the sandbox, where the walkthrough, results of examples, utility execution, and generated TypeScript are immediately visible. No installation is needed for the first introduction.

When it comes to integration, the course repository contains four working projects: an HTTP service for calculating discounts, team access for the agent via proof, TypeScript generation with divergence checking in CI, and a form schema for React. All of them are launched with a single npm run fts:examples command and are covered by tests.

Course Track

The course moves from language mechanics to production issues.

Language and Model

1. Model and language boundaries.
2. Installation and canonical JSON.
3. Russian and English notation.
4. Structures and types.
5. Utilities, rules, and properties.
6. Examples as a new kind of unit test.
7. Reading compiler errors.

Integration

8. Node.js and HTTP.
9. React and Forms.
10. Integration with Any Language.
11. Single Run and Visualization.
12. Generation and CI.

Architecture and Team Workflow

13. DDD and command guards.
14. Antipatterns: what should not be expressed in the specification.
15. Migration: from nested if to specification.
16. Rule versions, snapshots, and retroactive audit.
17. You don’t need lodash — but not where you think.

Verifiability and boundaries

18. AI agents, Digit and MCP.
19. Proofs and certificates.
20. Requirements checked before implementation: spec corpus, constitution, and ftspec.
21. Performance.

Cross-cutting project

22. Order execution: from model to service and form.

Practical success criterion: after the course you can choose one real rule of your project, formulate it in .fts, check with examples and integrate the result, without dragging effects into the specification language.

Cases in the catalog on this topic

Next: model and language boundaries