Your conditionals are a database with no schema, and "premium" is the proof

A post on dev.to makes a claim worth taking seriously: the conditionals that encode business decisions in your code are not code at all, they are rows of data stored in the worst available place ^[2]. The reason that matters to anyone running a system is the example the author leads with, a condition like `user.plan === 'enterprise' || user.tenantId === 'acme-corp'` that nobody remembers writing, that has been in place for two years, and that is almost certainly still load-bearing ^[1].

The strongest part of the argument is the drift case. According to the author, one service decides a customer is premium by checking `plan === 'premium'`, a second checks `subscription.tier > 2`, and a third checks a flag that was set during a migration in 2023 ^[3]. All three are the same rule until the day they are not, and there is nothing in the system that would notice ^[3]. That is the correct framing. If those three checks were columns in a table you would have a constraint, or at minimum a query that returns the disagreement. As conditionals they are three independent implementations of a business concept with no canonical definition anywhere, which is a structural gap rather than a code-review miss.

The post enumerates five failure modes ^[14]. No schema, per the premium example ^[3]. No query path: you cannot list what rules are live in production, and grep does not rescue you because the interesting conditions are compound, spread across guard clauses, and half of them are expressed as an early return rather than an `if` ^[4]. No migrations: changing a rate limit from 100 to 200 costs a pull request, a review, a CI run and a deploy window ^[5]. No audit log: git blame gives you an author and a timestamp, not who decided the rule, when it was meant to expire, or whether the customer it was written for is still a customer ^[6]. No access control: the person accountable for pricing policy cannot read the pricing policy without asking an engineer, and the change then routes through a sprint ^[7].

The author is fair about the usual remedy. Pulling rules into remote config, a feature flag platform or a policy server does deliver a UI, an audit trail and changes without a deploy ^[8]. The cost is that the application now makes a network call in the request path to decide whether a user can read a document, which brings a latency budget, a failure mode and a dependency on somebody else's uptime ^[9]. The sharpest line in the piece concerns the kill switch: the rule you most want to flip at 3 a.m. now requires a third-party service to be available during exactly the kind of incident in which things are not available ^[10].

From those five problems the author derives five requirements: a declarative format with a schema, one artifact, changeable without a deploy, verifiable enough to be worth signing, and evaluated locally ^[11]. That is also a product description. The piece ends by introducing Govplane, built by the author's team, in which rules compile into a signed JSON bundle shipped like any other config artifact and evaluated in memory after a signature check ^[12][13]. Read the diagnosis on its merits and the prescription as a vendor's.

Worth noting what local evaluation does not fix. A signed bundle answers the availability objection ^[10][12]. It does not by itself reconcile three services that already disagree about premium; something still has to define the term once and prove the definitions match. Watch whether teams adopting bundle-style policy artifacts build that reconciliation check, or whether they ship the same three definitions in a new file format.