Short version: Triage Logic is a set of rules by which a LegalTech service (an online tool that automates part of legal services) sorts incoming requests and decides whether to answer on its own, ask for more data or hand the case to a lawyer.
The word comes from medicine, where triage means sorting patients by the severity of their condition. A legal service applies this idea to requests: it ranks them by urgency and by the cost of a mistake.
An everyday example: a hospital emergency room. The doctor looks at the severity of the condition, and arrival time does not matter: a patient with an injury is seen before a patient with a cold who arrived an hour earlier.
Triage Logic gives the service the same intake rules.
How is triage different from a questionnaire?
A questionnaire collects data and produces a result. Triage decides after every answer what to do next: continue, clarify or stop. The same answer leads to different routes in different circumstances.
Three routes
Three outcomes are enough to start with:
- The service resolves it. A typical case with no risk: the service answers on its own.
- Clarification needed. Data is missing: the service asks the next question.
- Hand to a lawyer. The case is dangerous, urgent or needs a lawyer’s decision: the service stops and sends a specialist a case file with a priority level.
Clarification returns the case to the input step, while the other two routes end the triage. The number of repeat questions is limited, so the user does not get stuck: when the attempts run out, the case goes to a lawyer marked “data incomplete.” The service owner sets the limit.
Example: first-pass assessment of a labor dispute
Take a fictional service that tells an employee, based on their account, how much time is left to go to court. Only the service is invented. The deadlines are real: Art. 392 of the Labor Code of the Russian Federation.
| Type of dispute | Deadline to go to court | Counted from | Basis |
|---|---|---|---|
| Dismissal | 1 month | The day the copy of the dismissal order is handed over, the work record book is issued, or information on employment activity is provided | part 1, Art. 392 of the Labor Code |
| Non-payment or incomplete payment of wages and other payments | 1 year | The day the payment was due, including on dismissal | part 2, Art. 392 of the Labor Code |
| Other disputes of an employee | 3 months | The day the employee learned or should have learned of the violation of their right | part 1, Art. 392 of the Labor Code |
A court may restore a missed deadline for good reasons (part 5, Art. 392 of the Labor Code). But the court controls that exception, so the service works with the ordinary deadlines. A missed deadline is taken into account only if the employer raises it (para. 5 of Supreme Court Plenum Resolution No. 2 of March 17, 2004).
Where to count the deadline from
The hardest part for a program is determining the date from which the deadline runs. The service does not guess that date: it asks about a specific event.
For a dismissal dispute, that is the day the copy of the order is handed over, the day the work record book is issued, or the day information on employment activity is provided. The date the order was signed plays no part in counting the deadline.
If the employee was handed neither a copy of the order nor the work record book and did not refuse to receive them, the one-month deadline, under Supreme Court Ruling of December 7, 2020, No. 5-KG20-101, has not been missed. The service does not declare such a deadline expired and passes the case to a lawyer.
If the employee refused to receive the order or the work record book, the deadline runs from the day of refusal (para. 3 of Supreme Court Plenum Resolution No. 2 of March 17, 2004).
For wages, it is the day the payment was due. The specific payment date is set by the internal labor regulations, a collective agreement or the employment contract (Art. 136 of the Labor Code), so the service asks: on what date should you have been paid?
If that day falls on a weekend or a holiday, payment is made the day before, and the service accounts for that shift.
If the employee keeps working and accrued wages have not been paid, the violation is treated as continuing. According to the Supreme Court Plenum’s clarification (para. 56 of Resolution No. 2 of March 17, 2004), the deadline to go to court has not been missed while the employment relationship lasts. The service does not calculate the remaining time from the payment calendar in this situation.
For final settlement on dismissal, the payment deadline is set by Art. 140 of the Labor Code: all amounts are paid on the day of dismissal, and if the employee did not work that day, no later than the day after the employee’s request for settlement. In that case the service confirms the day of dismissal and finds out whether the person worked that day. The payment calendar from the internal labor regulations does not apply here.
A person may have worked under a contractor or services agreement and ask to have the relationship recognized as employment. In that case the deadlines under Art. 392 of the Labor Code apply to it only after a court recognizes the relationship as employment (Supreme Court Ruling No. 64-KG24-4-K9, Review of Case Law No. 3 for 2025). The service does not calculate deadlines for such a case and passes it to a lawyer.
Urgency rule
The service calculates how much time is left until the deadline and assigns a priority based on what remains. The service owner sets the urgency threshold. The threshold value is stored in a settings file (a separate file from which the program takes deadlines and thresholds), as described in the article How to Write a LegalTech Spec.
The priority determines the response time: for urgent cases it is shorter, and the service notifies the lawyer immediately.
If the deadline is far off and the data is sufficient, the service answers on its own: it states the deadline date and the time remaining. It does not assess the prospects of the case.
The technical specification (spec) also records the behavior at the threshold boundary: whether a value equal to the threshold counts as urgent (“strictly less than the threshold” or “less than or equal to the threshold”). A one-day difference can change the route.
What to do when a request contains several claims
An employee was dismissed and not paid. These are two claims with different deadlines: one month for the dismissal dispute and one year for the wages.
The priority rule. The service splits the request into separate claims and calculates the deadline for each. A missed deadline on one claim does not close the others, and the service reports each claim separately. The urgency of the whole case is set by the claim with the shortest remaining time among those not yet missed.
A missed deadline on any claim is, by itself, a reason to pass the case to a lawyer: the lawyer assesses whether the court can be asked to restore the deadline and whether going to court makes sense.
The priority rule is written down in advance, otherwise the result depends on the order in which the program checks the conditions.
When data is missing
The answer “I don’t remember” differs from the answer “no.” If the employee cannot state the date the order was handed over, the service asks for it and does not substitute today’s date.
For a dismissal dispute, the law names three starting points: handing over the copy of the order, issuing the work record book, and providing information on employment activity. If the employee mentions several dates, the service counts from the earliest. When the dates produce different results (the deadline has already passed by one date and is still running by another), the case goes to a lawyer.
The earliest date is chosen only within a single claim. Dates from different claims, such as the dismissal and the unpaid wages, are never compared with each other.
Decision log
The service records each decision in a log: the answers received, the rule that fired and the route chosen. A lawyer uses the log to review disputed cases and to check that the rules are configured correctly.
How to test the triage
Each rule needs at least one test situation with a known route (calibration dataset).
Here are seven for our example:
- The employee reports a dismissal but does not give the date the order was handed over. Expected route: clarification needed.
- The employee was dismissed and not paid; two months have passed since the order was handed over and the work record book was issued. Expected route: hand to a lawyer in the ordinary way, because the dismissal deadline has been missed while the wage deadline is still running.
- The employee gives two dates: receipt of the copy of the order and issue of the work record book; plenty of time remains by both. Expected route: the deadline is counted from the earlier date, and the service answers on its own.
- The time remaining equals the urgency threshold. Expected route: hand to a lawyer with urgent priority, because in our spec the boundary counts as urgent.
- The employee was not handed a copy of the order or the work record book and did not refuse to receive them. Expected route: the deadline is not declared expired, and the case goes to a lawyer.
- The employee keeps working, and accrued wages have not been paid. Expected route: the remaining time is not calculated, the deadline is not declared expired, and the case goes to a lawyer.
- The person worked under services agreements and considers the relationship to be employment. Expected route: no deadline is calculated, and the case goes to a lawyer.
In test 2 the case goes to a lawyer because of the missed dismissal deadline, while the priority is set by the wage claim: its deadline is still running, so the case is not urgent.
What the lawyer writes into the spec for triage
The package for the developer has six parts:
- The routes and the conditions for moving to each of them.
- The deadline and threshold parameters for the settings file, including the rule for boundary values.
- The priority rule for a request with several claims.
- The “insufficient data” branch and the limit on repeat questions.
- The contents of the log entries.
- Test situations with the expected route.
Four mistakes in designing triage
- An opaque overall risk score. Scoring (rating by points) works when the lawyer sees the weight of each factor and the conditions that fired. A bare total gives a number but does not explain the decision.
- No “insufficient data” branch. The service substitutes a default value and makes mistakes silently.
- No priority rule. With several claims in one request, the result depends on the order in which the program checks the conditions.
- A lawyer route for any doubt. The lawyer receives too many cases, and automation loses its point: only cases with a high cost of error should reach a lawyer.
Frequently asked questions
How does Triage Logic differ from an AI chatbot? A chatbot holds a conversation, while triage chooses a route. A model can help understand the user’s account, but the rules determine the route.
How many routes are needed? Three are enough to start: “the service resolves it,” “clarification needed,” “hand to a lawyer.” Add new routes when the log shows recurring cases.
How often should the rules be reviewed? Whenever a provision a rule relies on changes, and after reviewing the errors from the log. For regular monitoring of provisions, the service page offers a support format (Legal Maintenance).
Read Also
- Red Flags in LegalTech: When a Legal AI Service Hands the Case to a Human: which conditions stop a service before any other rule
- How to Write a LegalTech Spec: six steps from a parameter table to test scenarios
- Where’s the Line Between a Glitch and a Refusal?: what a service does when a register stays silent
- Prompt Engineer vs Legal Architect: who sets the framework for the AI model
- Client API Verification: What a Legal Service May Check: on what ground a service obtains the data a route is built from
Designing a LegalTech service and want it to tell urgent cases from ordinary ones by itself? Write to me: I will describe the routes, the priority rules and the test situations for your product. Details on the service page.