Making Constraints Survive
Today’s live tests exposed two failures that changed in my build.
First, a user prohibition was inverted into a preference. That led to typed constraint objects that preserve polarity, authority, scope, and lineage across handoffs. Downstream LEAPs can no longer reinterpret what the user actually said.
Second, the system produced a valid-looking compile but released a RUN that violated its own output contract. That led to falsifiable compile release evidence and atomic destination obligations. A gate must now prove that the actual candidate artifact satisfies its release conditions before it can pass.
The practical shift:
Constraints are now first-class objects that survive handoffs, preserve their meaning, and require proof of satisfaction before release.
The tests did more than expose bad outputs. They forced the build to close the gap between what the system was told, what it compiled, and what it actually released.
First, the system inverted a user prohibition into a preference. I changed constraints from loose language into persistent typed objects:
PROHIBIT NEGATIVE USER GLOBAL USER_ONLY ...Second, a COMPILE correctly specified required output fields, but the RUN omitted them and still declared PASS. So release gates now need candidate-bound evidence:
\
\ART_RUN_004\
\18\
\18\ PASS
\
If it were 17/18, release should fail. The model does not get to simply announce PASS.
JAN ERIC PETRECZKO I've found success using matrix scorecards too....
Having "Persona Teams" (with each persona expressed in their own LEAP) grade the work (while making sure there are "adversarial" personas on the team to be sure the constraints are there to "define the box").
For example, if I were grading design, there is a technician who grades the functionality of the code (and only cares about code being real, elegant, and efficient), a designer who doesn't care about code but desires the layout to be useful for someone who only has a thumb (ie the experience that someone using a mobile device has), and a stranger persona who is seeing the page for the first time (ie, does the thing they are looking at make sense and at what level of context). The grades go to the scripts... The scripts then determine the next LEAPs to trigger (if any).
And of course you can cycle through multiple of these specialized teams as needed to maintain the quality.
I think of this like a software gyroscope. A gyroscope will always wobble... It needs to. But you can control the tolerance you accept.
The magic is in the wobble.