JSON DSLs Are Not No-Code: Four Things That Make Rule Engines Safe

A popular engineering pattern involves expressing business logic as JSON so non-engineers can edit rules without triggering code deployments. However, a JSON DSL is effectively a second programming language, lacking the linter, type checker, test runner, and version history of a proper development environment. Simply moving logic from Python into JSON does not make it safe for non-technical users unless four safeguards are in place: a schema, validation, a safe evaluator, and versioning. A strict schema using tools like Pydantic can catch structural errors at entry, but semantic issues — such as misspelled field names silently returning null values — require an additional validation layer checking rule fields against known data sources. Teams that treat JSON rule expression as the finish line rather than the starting point risk silent failures in production that can go unnoticed until real users are affected.