<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Data-Integrity on Brian Faust</title><link>https://wimdy.works/tags/data-integrity/</link><description>Recent content in Data-Integrity on Brian Faust</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate><atom:link href="https://wimdy.works/tags/data-integrity/rss.xml" rel="self" type="application/rss+xml"/><item><title>A Valid Pricing Row Can Still Be Wrong</title><link>https://wimdy.works/thoughts/a-valid-pricing-row-can-still-be-wrong/</link><pubDate>Sun, 15 Feb 2026 00:00:00 +0000</pubDate><guid>https://wimdy.works/thoughts/a-valid-pricing-row-can-still-be-wrong/</guid><description>&lt;p&gt;One row charges EUR 12 from zero through five kilograms. Another charges
EUR 18 from four through ten. Give them different names and sequence numbers,
attach them to the right tariff book, and both rows can be perfectly valid
database records. At 4.5 kilograms, they still disagree about the base price.
Adding them gives EUR 30, which nobody specified as the base rate.&lt;/p&gt;
&lt;p&gt;Moving my private rating engine from
&lt;a href="https://wimdy.works/thoughts/not-every-pricing-rule-belongs-in-a-formula/"&gt;expression definitions to explicit rows&lt;/a&gt;

made this problem easier to inspect. It didn&amp;rsquo;t solve it by itself. I needed
to decide which combinations should be impossible, which should remain valid
drafts, and which should stop a ruleset from becoming executable.&lt;/p&gt;</description></item></channel></rss>