Start with the handoff
Imagine a supplier sending a product file every morning. It contains product_id, price, currency and updated_at. The receiving system accepts the file because all four columns exist. Later, a report treats a negative price as valid, an empty identifier creates duplicates and an unsupported currency slips into a total.
None of those failures is solved by the presence of a column alone. A contract begins at the handoff: what does the receiving team need to trust, and what can the producing team actually promise?
Separate structure from business expectations
A structural check asks whether price is numeric. A business rule asks whether it may be negative, whether zero is meaningful and whether the value includes tax. These are different questions, and both deserve an explicit answer.
For this example, the agreement could say: every product has a nonempty identifier; prices are numeric and nonnegative; currency belongs to an agreed list; and the timestamp uses an agreed timezone. Those expectations should be reviewed by someone who understands the supplier relationship, rather than inferred from a handful of sample rows.
Write down the failure policy
“Validate the file” leaves a surprisingly large decision unresolved. If one row is wrong, should the receiver reject the whole delivery, quarantine that row or load the data with a warning? Each choice changes the downstream meaning of a report.
Record the rule’s severity, the action on failure and the owner who can approve an exception. Preserve the original input alongside the diagnostic. If you transform a value, distinguish that deliberate transformation from a validation that only reports a problem. Silent repairs make later investigations harder.
Keep the rule readable
A short, declarative rule can make a review more concrete. In the historical RuleScript notation, a price constraint looks like this:
validate "price": number, min 0, max 10000,
on error "Price must be between 0 and 10000";This is a documentation example from the legacy language, not an installation instruction for an available runtime. Its value here is readability: the limit and the error message are visible together. The upper limit is an example business decision, not a universal rule about product prices.
Ask the domain owner to explain that limit. If there is no source for it, the contract has exposed a missing decision before it becomes hidden logic.
Version the agreement, not just the file
Suppose the supplier starts supporting another currency. Adding a value to the accepted list can be a small code edit with a large business consequence. Tie the change to a contract version and record when it becomes effective. Identify which producers and consumers must move together.
A useful review includes examples that pass, examples that fail and boundary cases such as zero, an empty string and a missing value. Keep the sample data synthetic. This turns the agreement into something both teams can discuss without sharing production records.
A small checklist for the first contract
- Name the producer, consumer and responsible owner.
- Describe the fields and their business meaning.
- List constraints, exceptions and the source of each decision.
- Specify delivery expectations and failure handling.
- Assign a version and an effective date.
- Agree on representative passing and failing examples.
You do not need a large platform to start. A reviewed document and a versioned set of checks can already improve a fragile handoff. The next challenge is keeping that agreement connected to the implementations that enforce it.
Where RuleGenius fits
RuleGenius started with readable data validation and transformation. The project also asks a wider question: how do we keep a rule’s meaning, source, review and version attached as it moves toward execution?
The project is in development. Explore the preserved RuleScript reference for the earlier language, or read about the current product direction. If you manage a real supplier handoff, that is exactly the sort of workflow we want to learn from.