Applicable

Podcast 2 — In conversation

Speaker A: I was filling in a grant application last week and it had the instruction delete as applicable throughout the form. I always find that phrase oddly satisfying — it is doing a lot of work in three words. It acknowledges that the form is a template covering many situations, and it invites you to make it fit yours.

Speaker B: Delete as applicable is one of those brilliant pieces of bureaucratic shorthand that has been in use since at least the Victorian era. The full logic it contains is: this form anticipates multiple possible answers; strike through the words that do not apply to your specific situation; retain only those that do. The phrase applicable is doing the heavy lifting — it tells you that the criterion for deletion is not preference or convenience but relevance to your actual circumstances. You are not choosing what to keep; you are identifying what is true for your case.

Speaker A: How does applicable differ from relevant? They seem very close in meaning.

Speaker B: Relevant is broader — it means connected to or pertinent to. Something can be relevant to a discussion without being applicable to it. Applicable is stronger and more specific: it means the thing can actually be applied, put into effect, or claimed in the given situation. A piece of case law might be relevant to your legal argument — it touches on the same area of law — but not applicable to your case — because the facts are different enough that the ruling does not directly govern your situation. In tax and law particularly, this distinction is crucial. Relevant information is background context; applicable law is what you are legally bound by or entitled to invoke.

Speaker A: Is there a common mistake with applicable, like a pronunciation issue?

Speaker B: There is indeed a very common one. The standard British pronunciation stresses the first syllable: APP-lih-kuh-bul. However, many speakers — particularly in legal and business contexts — stress the second syllable: app-LIK-uh-bul. This has become so widespread that many dictionaries now accept both, but the traditional and formally preferred pronunciation in British English remains APP-lih-kuh-bul. It is one of those words where the unstressed variant sounds authoritative to some ears because it mimics the stress pattern of apply — and the association with legal weight makes people gravitate toward a more emphatic stress pattern even when it is technically non-standard.

Podcast 3 — Prompt engineering

Speaker B: Applicable is an enormously precise word in prompt engineering because it specifies the scope and condition of a rule, feature, validation, or piece of logic. When you tell an AI that something is applicable under specific conditions, you are defining the exact branch logic, the eligibility criteria, the field visibility rules, or the business rules that govern when something applies and when it does not. This is the language of conditional logic, form validation, compliance systems, and policy engines. Let me show you the most immediately useful prompt patterns.

Speaker A: The eligibility and conditional logic angle is the one I reach for most often — defining when a discount, a feature, or a rule is applicable to a specific user type.

Speaker B: Here is the pricing eligibility prompt:

Speaker B: PROMPT:

Speaker A: Returning the full list of applicable discounts rather than just the largest one — that is the design that enables the UI to explain to the customer which discounts they are receiving and why. Customers who understand why a price is what it is have much higher satisfaction with the pricing than those who just see a number.

Speaker B: Now a form field visibility prompt:

Speaker B: PROMPT:

Speaker A: Deriving applicability rules from a JSON configuration object rather than hardcoded conditions — that is the architecture that makes the form maintainable when insurance regulations change. You update the JSON configuration, not the component code, which means a business analyst can update the rules without a developer deployment.

Speaker B: Now a compliance check prompt:

Speaker B: PROMPT:

Speaker A: Hiding inapplicable items rather than showing them as inapplicable — that is the UX decision that scales the complexity to the user's actual situation. A system that only processes internal employee records has a very different compliance checklist from one that processes customer payment data; showing the full list with most items greyed out for the first system is confusing and demoralising.

Speaker B: Now a database schema for policy rules:

Speaker B: PROMPT:

Speaker A: Storing applicability rules as structured JSON rather than as separate Boolean columns — that is the flexible design that handles new criteria without schema migrations. If a new applicability criterion is introduced — such as remote versus office-based — you add it to the JSON structure and update the query logic rather than adding a new column to the applicability rules table.

Speaker B: Use applicable in prompts wherever you need to define the conditions under which a rule, feature, discount, validation, or policy takes effect. The word forces the AI to model eligibility and conditionality explicitly rather than producing one-size-fits-all logic. Systems designed around applicable conditions are more accurate, more maintainable, and more honest about the complexity of the business rules they are implementing.