# Assumptions weaken properties

DevFeed: [Assumptions weaken properties](<https://devfeed.tech/articles/assumptions-weaken-properties-25481.md>)

Original publisher: [Read original article](<https://buttondown.com/hillelwayne/archive/assumptions-weaken-properties/>)

Author: Hillel Wayne

Published: 2026-05-20T15:13:16Z

Content type: tutorial

Language: en

Sources: [Newsletter feed for Hillel Wayne's Newsletter](<https://devfeed.tech/sources/newsletter-feed-for-hillel-wayne-s-newsletter.md>)

Topics: [Formal methods](<https://devfeed.tech/topics/formal-methods.md>), [Math and Logic](<https://devfeed.tech/topics/math-and-logic.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [JSON](<https://devfeed.tech/topics/json.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [formal-methods](<https://devfeed.tech/tags/formal-methods.md>), [json](<https://devfeed.tech/tags/json.md>), [math](<https://devfeed.tech/tags/math.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

The article explains, using logical implication, why adding assumptions weakens a formal property. It illustrates the idea with tests, formal specifications, fairness constraints, and a JSON parser verified only for ASCII input.

## Source excerpt

In some tests are stronger than others, I defined STRONG => WEAK to mean "any system passing test STRONG is also guaranteed to pass WEAK". This uses the logical implication operator, defined as P => Q = !P || (P && Q). Implication may be the most overworked operator in logic. Among other things, it's also used in formal specification, where Spec => Prop means "any system satisfying Spec has property Prop" and ASSUME => Spec means "The assumption ASSUME must hold in order for the system to satisfy Spec." Now let's mush these all together and do some math. To start, "the system has property Prop" is the same as "the system passes the test that checks Prop", so test strength is also property strength. Now let "ASSUME => Prop" mean "the system passes Prop assuming ASSUME is true." In classic logic, if P is true, then obviously !Q || P is true. Further, that is equivalent (just draw the truth table!) to !Q || (P && Q). So for any propositions P and Q, P => (Q => P). In other words, Prop => (ASSUME => Prop). In other other words, "the system passes Prop" is a stronger property than "the system passes Prop whenever our assumptions hold." In other other other words, any assumption added makes a property weaker. This makes intuitive sense to me. A JSON parser that's only been verified with ASCII strings has the property "input only uses ASCII && is valid json => correctly parsed". A better JSON parser that works for all Unicode will have the property "is valid json => correctly parsed", which has fewer assumptions, meaning it's guaranteed to work in a strict superset of cases. It also matches the intuition that "more assumptions means more likely to go wrong". We have a bug whenever Prop is false. The only way for Spec => Prop to be true and Prop be false is if Spec is false, eg our system doesn't satisfy the specification we intended to implement. On the other hand, Spec => (ASSUME => Prop) && !Prop is true whenever Spec and/or ASSUME is false, meaning a correctly-implement