Verified against ChatGPT · 2026-08-12
Turn a description of business logic into a checkable list of data validation rules
Converts a plain-language description of how a business process should work into explicit, testable validation rules for a dataset, with each rule stated so a failing row can actually be identified.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Convert the business logic described below into a set of explicit, testable data validation rules — every rule needs to be something a query could actually check against real rows, not a restated version of the business description.
BUSINESS PROCESS DESCRIPTION
A refund can be issued for up to 30 days after purchase, can't exceed the original order amount, and requires a reason code. Partial refunds are allowed.
TABLE(S) INVOLVED
orders table (order_id, order_amount, purchase_date) joined to refunds table (refund_id, order_id, refund_amount, refund_date, reason_code)
KNOWN EDGE CASES ALREADY SEEN
Occasionally a single order gets two partial refunds that together approach the full order amount — this is legitimate, not a violation
SEVERITY THIS MATTERS FOR
This feeds a finance reconciliation report — a refund exceeding the order amount is a hard data-integrity problem, but a missing reason code is just sloppy entry
Read the business logic and extract every implicit rule it depends on — not just the rules explicitly stated, but the ones the description assumes without saying (if the description says "a refund can't exceed the original order amount," that implies a rule about what happens when a refund exactly equals it, and a rule about what "original order amount" means if the order itself was later modified). For every rule, write it in a checkable form: the field(s) involved, the condition that should hold, and what a violation looks like concretely (e.g., "refund_amount should never exceed order_amount for the same order_id; a violation is any row where refund_amount > order_amount"). Classify each rule's severity based on This feeds a finance reconciliation report — a refund exceeding the order amount is a hard data-integrity problem, but a missing reason code is just sloppy entry — a hard constraint that should block a record from loading at all versus a soft warning that should be flagged for review but not block anything, since treating every rule as equally blocking will stop good data from loading over a rule that was only ever meant to be advisory. For any known edge case, write the rule so it explicitly accounts for that case rather than flagging every instance of it as a false-positive violation forever. Where the business description is ambiguous about what should actually happen in a genuinely unclear scenario (what if a refund is issued after the order was itself edited), state the ambiguity plainly and ask which behavior is intended rather than picking one silently.
WHAT NOT TO DO
Do not write a rule as a restatement of the business sentence ("refunds should be reasonable") — every rule must be phrased as a concrete, evaluable condition. Do not mark every rule as a hard blocker by default; that's a business decision requiring input from whoever owns This feeds a finance reconciliation report — a refund exceeding the order amount is a hard data-integrity problem, but a missing reason code is just sloppy entry, not a default to assume.
OUTPUT FORMAT
Table: rule # | fields involved | condition | what a violation looks like | severity (hard block / soft warning, with why) | edge case handled (if any).
Followed by: any ambiguous scenario in the business description that needs a decision before the rule can be finalized.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Business logic as described in plain language is almost never a complete specification — it states the intended happy path and leaves the edge cases and boundary conditions implicit, and a model asked to "write validation rules from this" will, by default, restate the explicit sentence as a rule without doing the harder work of surfacing what the sentence assumes but doesn't say, which is exactly the gap this prompt closes by explicitly instructing extraction of implicit rules, not just stated ones. Requiring every rule to specify concretely what a violation looks like, rather than a restated business sentence, is what actually makes a rule testable — "refunds should be reasonable" cannot be checked by any query, while "refund_amount > order_amount" can be run against the table today, and the difference between those two forms is the entire value of turning business logic into validation logic in the first place. Forcing an explicit hard-block versus soft-warning classification addresses a specific and costly failure mode in real data pipelines: a validation layer that treats every rule as equally blocking will eventually halt a legitimate load over a rule that was only ever meant to flag something for human review, and that classification is a business risk-tolerance decision that the model has no basis to make silently — surfacing it as a decision to confirm, tied to the stated severity context, keeps that judgment with the person who actually owns the consequences. Handling the known edge case explicitly (two partial refunds that together approach the order total) rather than leaving the rule naive prevents the common operational annoyance of a validation system that cries wolf on legitimate transactions constantly, which is how teams end up ignoring their own validation alerts entirely after enough false positives erode trust in them.
What you get back
Rule 3 | refund_amount, order_amount, order_id | Sum of all refund_amounts for a given order_id should never exceed that order's order_amount | Violation: SUM(refund_amount) GROUP BY order_id > order_amount | Hard block (finance reconciliation integrity) | Edge case handled: rule sums across multiple partial refunds per order rather than checking each refund row independently, so two legitimate partial refunds don't falsely trigger. Ambiguity flagged: description doesn't say what "original order amount" means if the order was edited after purchase — confirm whether refund rules should check against the current order_amount or the amount at time of purchase.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
