There was a time when I changed my phone number, and the bank asked me to verify it through a security question. I answered correctly, but I was still rejected because the system matched what I entered against data from ten years ago. Back then, I misspelled one letter, and I don’t remember it. Correct in meaning, wrong in formatting—and the system can’t tell the difference between those two kinds of mistakes.
DeFi has the same kind of confusion too—an address written in uppercase vs lowercase, a rounded number vs a number with more decimal places. Even if the condition is logically correct in essence, it may be considered not matched, simply because it compares strings exactly instead of understanding the intent.
@NewtonProtocol nIf the policy engine could understand the meaning of conditions rather than only doing rigid string matching, it would reduce many cases of unfair rejections like this.
Self-refutation: but the more you make the system “flexible enough to understand meaning,” the more complex data normalization you need, and every added layer becomes another place where new errors can be introduced. Over-normalization can make two truly different values seem the same, creating the opposite—and even more dangerous—risk: accepting a wrong answer because it’s assumed to be right.
The challenge of @NewtonProtocol isn’t making the system smarter; it’s finding the right boundary of flexibility—enough to avoid unfairly rejecting harmless format differences, but not enough to blur real, truly important differences.
$NEWT nSo it should be evaluated by where it can find that boundary, not only by whether it uses semantic-understanding technology.
#newt $LAB $SAROS
DeFi has the same kind of confusion too—an address written in uppercase vs lowercase, a rounded number vs a number with more decimal places. Even if the condition is logically correct in essence, it may be considered not matched, simply because it compares strings exactly instead of understanding the intent.
@NewtonProtocol nIf the policy engine could understand the meaning of conditions rather than only doing rigid string matching, it would reduce many cases of unfair rejections like this.
Self-refutation: but the more you make the system “flexible enough to understand meaning,” the more complex data normalization you need, and every added layer becomes another place where new errors can be introduced. Over-normalization can make two truly different values seem the same, creating the opposite—and even more dangerous—risk: accepting a wrong answer because it’s assumed to be right.
The challenge of @NewtonProtocol isn’t making the system smarter; it’s finding the right boundary of flexibility—enough to avoid unfairly rejecting harmless format differences, but not enough to blur real, truly important differences.
$NEWT nSo it should be evaluated by where it can find that boundary, not only by whether it uses semantic-understanding technology.
#newt $LAB $SAROS
