Short version: in a technical specification (spec) for a LegalTech service (an online tool that automates part of legal services), a developer needs rules that can be expressed as numbers and conditions. The phrase “the system must give a legally correct answer” is not one of them.
An ordinary spec for a legal service describes screens, buttons and connections to other systems. The legal logic fits into one line: “the answer must comply with the law.”
The developer reads that line and fills in the rest. Deadlines, thresholds and exceptions are chosen by the developer alone, and the mistake surfaces once clients are already using the service.
How does a legal spec differ from an ordinary one?
An ordinary spec answers the question of what the system does. A legal spec adds two layers: the limits of permitted decisions, and the conditions under which the system stops and hands the case to a person.
An everyday example: renovating an apartment. It is pointless to tell a contractor “make it look nice”: they need a floor plan, a design project, a cost estimate and a list of materials, otherwise they will interpret “nice” in their own way.
Legal logic works the same way: the developer needs a blueprint.
One example for all the steps
Take a fictional service that tells a buyer whether they can cancel an order placed on an online store’s website. Only the service is invented. The rules are real: paras. 3 and 4 of Art. 26.1 of the Consumer Protection Law (Law of the Russian Federation No. 2300-1 of February 7, 1992).
The example has clear-cut rules so the whole scheme is visible at once. In complex disputes the same scheme works as a router: what the service decides, and what the lawyer decides.
Step 1. The parameter table
Each rule becomes a parameter: a number, a deadline or a condition, plus a reference to the provision. The developer gets a table instead of a paragraph of text.
| Parameter | Value | Basis |
|---|---|---|
| Cancellation period after the order is received | 7 days | para. 4, Art. 26.1 |
| Cancellation period if the seller did not hand over written return instructions at delivery | 3 months | paras. 3 and 4, Art. 26.1 |
| Condition for return | marketable appearance and consumer properties preserved | para. 4, Art. 26.1 |
| Method of return | any method the buyer chooses, provided the seller can check the condition of the goods; the buyer bears delivery costs and the risk of damage in transit | Constitutional Court Resolution No. 7-P of February 17, 2026 |
| Refund period after the request | 10 days, minus the seller’s costs of delivering the returned goods | para. 4, Art. 26.1 |
| Exception | goods of proper quality with individually defined properties that only this buyer can use | para. 4, Art. 26.1 |
The three-month row describes the case where the store gave the buyer no written return rules at delivery. The cancellation period then grows from seven days to three months.
The rule on the method of return appeared in February 2026. The Constitutional Court held that paras. 3 and 4 of Art. 26.1 do not comply with the Constitution, because the law made no provision for returning remotely purchased goods by remote means. Until the law is changed, returns are allowed by any method the buyer chooses, as long as the seller can check the condition of the goods on receipt.
Step 2. A settings file instead of numbers in the code
The parameters from the table go into a separate settings file connected to the administration panel (admin panel). Numbers hard-coded into the program become outdated at the first change in the law, and every update turns into a task for a programmer.
The settings file stores the values of the rule, and the decision scheme stores its structure. When a deadline or threshold changes, the file is edited. When the set of conditions changes, the scheme is edited and the test set is run again.
The rule on the method of return from our table shows why the settings file is needed: the Constitutional Court instructed the legislature to amend the law, and this row of the table will have to be updated.
Step 3. The decision tree
The rules are arranged into an “if, then, otherwise” scheme. This is Triage Logic: automatic sorting of situations by predefined rules. In our example the scheme looks like this:
| No. | Question | If yes | If no |
|---|---|---|---|
| 1 | Do goods of proper quality have individually defined properties and suit only this buyer (for example, furniture made to the buyer’s measurements)? | The service passes the case to a lawyer: the limits of this exception are judged by the circumstances. | It moves to the next question. |
| 2 | Have seven days passed since the order was received? | It moves to the next question. | The service prepares a cancellation request. |
| 3 | Was written information on the return procedure handed over at delivery? | The service passes the case to a lawyer. | If less than three months have passed since receipt, the service prepares a cancellation request, otherwise it passes the case to a lawyer. |
The last branch is needed because the buyer may have other grounds: for example, the goods turned out to be defective, and then Arts. 18 to 24 of the same law apply.
A buyer is unlikely to know what “individually defined properties” means, so questions to the buyer are about facts. The lawyer writes down which facts need to be established and how they are confirmed (receipt, packaging, signs of use, photos), and the product team sets the format and wording of the questions. The scheme then qualifies those facts.
How triage works on a different example, with priorities and missed deadlines, is covered in the article What Is Triage Logic in LegalTech?.
Step 4. Stop factors
Stop factors (Red Flags) are situations in which an automatic answer becomes dangerous: it would clearly contradict the law or lead to losses. For each one, the spec records the sign and the service’s action.
In our example there are four:
| Stop factor | Basis |
|---|---|
| The order was placed for a company or a sole proprietor | The consumer protection law applies to purchases made exclusively for personal needs (the preamble of the law and para. 1 of the Supreme Court Plenum Resolution No. 17 of June 28, 2012), so a lawyer checks the purpose of the purchase. |
| The goods arrived defective | A different set of rules applies (Arts. 18 to 24 of the law). |
| The order was placed on a marketplace | Federal Law No. 289-FZ of July 31, 2025 “On Certain Issues of Regulating the Platform Economy in the Russian Federation” has been in force since October 1, 2026, so a lawyer checks the return rules. |
| The buyer’s message mentions a court or a written claim | A sign of a possible dispute. |
In each of these cases the service stops the automatic answer, shows a warning and sends the case file to a lawyer.
The list of stop factors is short and precise: it includes only situations where the cost of an error is higher than the cost of a manual check.
I covered how to write such rules for different areas of law and test them in the article Red Flags in LegalTech: When a Legal AI Service Hands the Case to a Human.
Step 5. Checking data against external databases
If the service checks data against official registers (for example, the register of legal entities), the spec also describes the case when the register fails. The programming interface (API) for a register request can let the service down, and then the service has to repeat the request under a set rule and, once the attempts are exhausted, hand the case to a person.
An answer of “no data” must not be given without this procedure: silence from a register does not yet mean the fact is absent. More on this in the article Where’s the Line Between a Glitch and a Refusal?.
Step 6. Test scenarios and acceptance criteria
The last element is a set of test situations with a known correct answer (calibration dataset). The developer and the tester run the service through it before launch.
You need at least one situation for each rule and each stop factor.
Here are two of them for our example:
- The order was received yesterday, the goods are ordinary. Expected answer: the service prepares a cancellation request.
- The order was received 10 days ago, and written return information was handed over at delivery. Expected answer: the service passes the case to a lawyer.
The acceptance criterion, meaning the test by which the client decides the work is done, is simple: the service gives the expected answer in every situation of the set.
After launch the set is topped up with real client requests: every error found becomes a new test situation.
What the developer receives
The complete package consists of six documents:
- A parameter table with references to the provisions.
- A settings file for the admin panel.
- A decision scheme.
- A list of stop factors with an action for each.
- A description of the service’s behavior when external databases fail.
- A set of test situations with expected answers.
The developer carries all of this into the code without making any legal decisions independently.
Four mistakes that come up most often
- General wording. A “correct answer” cannot be checked, and the phrase turns into the developer’s guess.
- Numbers in the code. The law changed, and only a programmer can edit the number.
- No stopping point. Without stop factors the service answers with confidence even where the answer depends on circumstances it does not know.
- No acceptance criteria. The client accepts the work “by eye,” and the first users find the errors.
Who writes what?
A lawyer writes and checks the rules: the table, the scheme, the stop factors and the test situations. A developer carries them into the code and keeps them accurate. The product team designs how it all looks for the user and how the questions are worded. The service owner decides which cases the service closes on its own and which it passes to a lawyer.
I cover the boundary between these roles in the article Legal Architect vs Developer.
Frequently asked questions
Can a developer put this table together alone? A developer can write it down. The values should be chosen by a lawyer: the deadline, the threshold and the exception are set by the law together with how courts apply it, while a developer sees only the text of the provision.
What if the law changes after launch? If a deadline or threshold changes and the numbers sit in the settings file, the update takes minutes: a lawyer checks the provision, an employee edits the value in the admin panel. When the set of conditions changes, the decision scheme is updated and the test set is run again. Numbers hard-coded into the program can be changed only through a task for a developer. For regular monitoring of provisions, the service page offers a support format (Legal Maintenance).
Are such rules needed if the service runs on an AI model? They are. An AI model works well as an input interface: it understands the user’s free-form account and pulls the facts out of it. The decision on the law stays with the rules, and the rules also set the limits within which the model may answer on its own. I cover the difference between these tasks in the article Prompt Engineer vs Legal Architect.
Read Also
- Legal Architect vs Developer — where the line between the roles falls
- Prompt Engineer vs Legal Architect — who sets the framework for the AI model
- Where’s the Line Between a Glitch and a Refusal? — what a service does when a register stays silent
- Client API Verification: What a Legal Service May Check — how to record the ground for checking each source in the spec
Planning a LegalTech service and want to hand your developers a spec with ready-made legal logic? Write to me: I will review your product and prepare the parameter table, the decision scheme, the list of stop factors and the test situations. Details on the service page.