> **Source:** https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule > **Site:** Leegality Knowledge Base — https://knowledge.leegality.com > **About:** Leegality is a document execution platform covering eSigning, stamps, NeSL, workflows, and REST API integration. > **Navigation:** Every article on this site has a plain-text version at `.txt` (this format). To get an index of all articles with their `.txt` links, read: https://knowledge.leegality.com/llms.txt > **AI Guide:** For instructions on how to navigate this knowledge base as an AI agent, read: https://knowledge.leegality.com/ai-readable.txt --- # Turn a requirement into a rule Requirements arrive as goals: *"auto-calculate the premium"*, *"big loans need a reviewer"*, *"NRI customers must fill FATCA"*. The Rule Engine needs those goals expressed as precise logic. The bridge between the two is a **six-line rule spec** — plain English, no syntax, but exact. A working rule is written in Leegality's **rule language** — but the spec comes first, and it isn't paperwork. Think of it as the rule's **intake form**: each of its six lines answers a question the rule-writer must answer anyway, whether that writer is you (once you know the language) or Leegality Support. Write the spec well and writing the rule is mechanical. Write it vaguely and the wrong rule gets built. The whole game is precision. ## Before you write: two quick checks 1. **Is it a rule at all?** Run the requirement through the [three-question test](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/what-is-a-rule). If it's time-based, signer-triggered, template-swapping, or cross-workflow, stop — it needs a different solution, and the same page tells you which. 2. **Which category is it?** Identify which property changes — Mandatory, Visibility, Editable, or Value — or whether it's a validation or assignment rule. [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) makes this a 10-second habit. ## The six-line spec Every rule spec has the same six lines: ``` TARGET field: ACTION: SUBJECT field: CONDITION: OUTCOME: Workflow: ``` A filled-in spec looks like this: ``` TARGET field: Reviewer (1st invitee) step ACTION: Set Mandatory = true SUBJECT field: Loan Amount CONDITION: Loan Amount > ₹10,00,000 OUTCOME: Reviewer step is Mandatory; below ₹10L, Reviewer step is Optional Workflow: Personal Loan Workflow (workflow_id: pl_v4_01) ``` Six lines. Unambiguous. Anyone reading it — you next month, a colleague, Leegality Support — builds exactly the same rule. ## Worked translations Three real customer asks, three specs. Notice the pattern: the customer speaks in goals; the spec pins down fields, thresholds, and both sides of the behaviour. ### "Big home loans need a credit officer" > *"For home loans above ₹1 crore, we want an internal credit officer to review and approve the agreement before the borrower can sign. Below ₹1 Cr, no credit officer needed."* ``` TARGET field: Credit Officer reviewer invitee · Name field ACTION: Set Mandatory = true SUBJECT field: Loan Amount CONDITION: Loan Amount > ₹1,00,00,000 OUTCOME: Credit Officer review required above ₹1 Cr; optional otherwise Workflow: HDFC Home Loan (workflow_id: hdfc_hl_v4_01) ``` A **Mandatory** rule. The customer's phrase "before the borrower can sign" is captured by making the reviewer invitee mandatory — the signing order does the rest. ### "The premium should auto-calculate" > *"The annual premium should auto-calculate from the customer's age, sum assured, and policy term — and show up on the policy document the customer is signing."* ``` TARGET field: Premium Amount template field on Policy Document ACTION: Set Value = lookup(Age, Sum Assured, Policy Term) SUBJECT field: Age, Sum Assured, Policy Term CONDITION: All three fields filled OUTCOME: Premium appears printed on the policy document before signing Workflow: Term Life Policy (workflow_id: tl_v4_01) ``` A **Value** rule with multiple subject fields. "Show up on the document" tells you the target is a *template field* — the computed value prints into the document itself. ### "Only NRIs should see FATCA" > *"For NRI customers, we need them to fill the FATCA Declaration field. For resident Indians, the FATCA field shouldn't even appear in the workflow."* ``` TARGET field: FATCA Declaration field ACTION: Set Visibility = true (for NRI); false (for Resident) SUBJECT field: Customer Type CONDITION: Customer Type = NRI OUTCOME: NRI customers see and fill FATCA; residents do not see the field at all Workflow: PMS Customer Onboarding (workflow_id: pms_v4_01) ``` A **Visibility** rule. "Shouldn't even appear" is the giveaway — this is about the field existing in the journey, not about it being optional. ## What makes a spec precise The difference between a spec that builds right the first time and one that bounces back with questions: - **Exact field names, not descriptions.** "Loan Amount" (the field as named in the workflow), not "the loan value". If the field is a [custom field](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview), name it exactly as created. - **Exact thresholds and values.** ₹10,00,000, not "around ten lakh". `NRI`, spelled as the dropdown option spells it. - **Both sides of the behaviour.** The OUTCOME line states what happens when the condition is met *and* when it is not. "Below ₹10L, Reviewer is Optional" prevents the classic ambiguity: should the rule also *undo* its effect, or only ever apply it? - **One workflow, named.** Include the workflow name and ID. A rule lives inside exactly one workflow — the spec should leave no doubt which. - **Error message text, if it's a validation rule.** The message shown to the user is part of the spec, word for word. ## From spec to working rule: two paths The spec is the form; the rule itself is written in the rule language and configured in the Rule Engine panel — title, logic, trigger method. With a finished spec, pick whichever path fits: 1. **Write the rule yourself.** [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) walks the full configuration with ready-made rule logic to paste and adapt. When you're ready to write your own, Advanced: the LEEQL rule language teaches the language, and the use-case gallery is full of adaptable patterns. 2. **Send it to Support.** Mail the spec to [support@leegality.com](mailto:support@leegality.com) and Leegality writes and configures the rule for you. A clear six-line spec is everything Support needs. > **Tip — Not sure it's buildable?** > > Borderline requirement? Spec it anyway and send it in. The spec format makes it easy to confirm whether something is a rule — and if it isn't, [What counts as a rule?](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/what-is-a-rule) usually points to the alternative.