> For the complete documentation index, see [llms.txt](https://govplane.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://govplane.gitbook.io/docs/documentation/resources/7-runtime-decisions-that-should-not-be-hardcoded.md). # 7 Runtime Decisions That Should NOT Be Hardcoded Hardcoded conditionals tend to look harmless at first. ```js if (user.plan === 'free') { ... } if (country === 'RU') { ... } if (requests > 100) { ... } ``` They are often perfectly acceptable in the early stages of a project, when the system is small, the number of scenarios is limited, and changes are infrequent. The problem emerges as the system grows. What starts as a few simple checks gradually turns into a web of hardcoded rules, magic values, and implicit assumptions spread across multiple services. At that point, even small changes require careful code updates, coordination between teams, and deployments that introduce unnecessary risk. This becomes even more problematic when those rules depend on an evolving context — fraud patterns, traffic behaviour, regulatory constraints, or business strategy — where decisions need to be adjusted quickly and sometimes under pressure. They are easy to write, easy to understand, and easy to forget about.\ Until they become the reason why changing behavior in production requires a deployment. This article outlines seven categories of decisions that should not live in code, along with ready-to-import policy templates. *** ### 1. Feature Kill Switches When something fails, the priority is containment, not deployment. Hardcoded logic assumes recovery depends on shipping code. A kill switch shifts that control to runtime. **Why externalise it:** * Immediate containment without redeploying\\ * Scoped impact (region, tenant, traffic type)\\ * Safe rollback once the issue is resolved ```json { "policyKey": "kill-payments-stripe", "env": "prod", "friendlyName": "Kill Switch – Stripe Payments", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "allow" }, "rules": [ { "id": "ks-stripe-global", "priority": 100, "target": { "service": "payments-api", "resource": "payment", "action": "create" }, "when": { "op": "eq", "path": "provider", "value": "stripe" }, "thenEffect": { "type": "kill_switch" }, "effect": { "type": "allow" } } ] } } ``` *** ### 2. Rate Limiting & Abuse Control Static thresholds rarely survive contact with real traffic. **Why externalize it:** * Adjust limits without redeployments * Apply different strategies per endpoint or identity * Respond quickly to abuse patterns ```json { "policyKey": "api-throttle-dynamic", "env": "prod", "friendlyName": "Dynamic API Throttling", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "allow" }, "rules": [ { "id": "throttle-ip", "priority": 90, "target": { "service": "public-api", "resource": "*", "action": "*" }, "thenEffect": { "type": "throttle", "throttle": { "limit": 200, "windowSeconds": 60, "key": "ip" } } } ] } } ``` *** ### 3. Geo Restrictions & Compliance Rules Country-based restrictions evolve over time. Keeping them in code guarantees drift. **Why externalize it** * Fast updates for regulatory changes * Centralized visibility * Reduced risk of inconsistencies across services ```json { "policyKey": "geo-blocking", "env": "prod", "friendlyName": "Geo Restrictions", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "allow" }, "rules": [ { "id": "deny-high-risk-countries", "priority": 100, "target": { "service": "platform", "resource": "*", "action": "*" }, "when": { "op": "in", "path": "country", "values": ["RU", "KP", "IR"] }, "effect": { "type": "deny" } } ] } } ``` *** ### 4. Plan-Based Access Control Tying features to plans directly in code makes pricing changes expensive. **Why externalize it:** * Decouple pricing from deployments. * Enable fast iteration on packaging. * Support temporary overrides and experiments. ```json { "policyKey": "plan-feature-access", "env": "prod", "friendlyName": "Feature Access by Plan", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "deny" }, "rules": [ { "id": "allow-pro-feature", "priority": 100, "target": { "service": "analytics", "resource": "advanced-dashboard", "action": "view" }, "when": { "op": "in", "path": "plan", "values": ["pro", "enterprise"] }, "effect": { "type": "allow" } } ] } } ``` *** ### 5. Traffic Shaping & Rollouts Embedding rollout logic across services leads to fragmentation. **Why externalize it:** * Centralized rollout control * Instant rollback * Consistent behavior across services ```json { "policyKey": "feature-rollout", "env": "prod", "friendlyName": "Gradual Feature Rollout", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "deny" }, "rules": [ { "id": "rollout-20-percent", "priority": 100, "target": { "service": "frontend", "resource": "new-ui", "action": "render" }, "when": { "op": "lt", "path": "userHash", "value": 20 }, "effect": { "type": "allow" } } ] } } ``` *** ### 6. Risk-Based Decisions Risk thresholds should evolve with observed behaviour. **Why externalize it:** * Adjust sensitivity without redeployments * Combine multiple signals * Apply targeted controls ```json { "policyKey": "risk-control", "env": "prod", "friendlyName": "Risk-Based Blocking", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "allow" }, "rules": [ { "id": "deny-high-risk", "priority": 100, "target": { "service": "payments-api", "resource": "transaction", "action": "create" }, "when": { "op": "gt", "path": "riskScore", "value": 80 }, "effect": { "type": "deny" } } ] } } ``` *** ### 7. Time-Based Logic Time-based conditions tend to be scattered and difficult to maintain. **Why externalize it:** * Update windows without deployments * Ensure consistency across systems * Avoid timezone-related issues ```json { "policyKey": "promo-window", "env": "prod", "friendlyName": "Promotion Window Control", "status": "active", "activeVersion": 1, "snapshot": { "defaults": { "effect": "deny" }, "rules": [ { "id": "allow-promo-period", "priority": 100, "target": { "service": "checkout", "resource": "discount", "action": "apply" }, "when": { "op": "and", "conditions": [ { "op": "gte", "path": "now", "value": "2026-03-01T00:00:00Z" }, { "op": "lte", "path": "now", "value": "2026-03-31T23:59:59Z" } ] }, "effect": { "type": "allow" } } ] } } ``` *** ### Key Takeaways – Moving Decisions Out of Code In this article we covered seven situations where hardcoded conditionals introduce unnecessary friction. Individually, they may seem manageable. But as they accumulate, they turn runtime decisions into deployment problems. What should be a quick adjustment becomes a coordinated effort involving code changes, testing cycles, and production releases. **The underlying issue is not the conditionals themselves — it’s where they live.** **When decisions depend on context that changes over time — traffic patterns, risk signals, business rules, or operational incidents — they need to be controlled at runtime, not embedded in code.** **Govplane addresses this directly.** Instead of relying on the usual patch → test → deploy workflow, you can define and update policies that are evaluated locally at runtime. This allows you to adapt system behaviour instantly, without introducing latency, external dependencies, or operational overhead. All changes remain: * deterministic in execution * auditable over time * collaborative across teams So decisions stop being hidden inside services and become something you can manage explicitly. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://govplane.gitbook.io/docs/documentation/resources/7-runtime-decisions-that-should-not-be-hardcoded.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.