Rules as Data: Decoupling Logic from Code

The Hardcoded Nightmare

In traditional development, business rules are often scattered like landmines throughout the code.

if user.subscription == "pro" and date.month != 12:

const TAX_RATE = 0.05;

These magic numbers and conditional checks are buried deep in functions. When the business changes the rule—"Pro users now get 2 months off"—you have to hunt through the code, find the line, change it, run tests, and redeploy.

For an AI Agent, this is even worse. Agents struggle to find these "implicit" rules buried in syntax. They tend to hardcode new rules on top of old ones, creating logic conflicts.

We solved this with a pattern called Rules as Data.

The rules.yaml Artifact

We stripped all "magic numbers" and "business policies" out of the Python code entirely.

We moved them into a single, central artifact: rules.yaml.

```yaml

subscriptions:

pro:

discount_months: [12]

rate: 29.99

features: [analytics, exports]

race_logic:

min_laps: 5

pit_stop_avg_time: 22.5

```

This file became the Single Source of Truth for the behavior of the application.

The Agent's Bible

The Business Analyst Agent owned this file. When the user said, "Change the pit stop time to 24 seconds," the BA didn't touch the Python code. It just updated the YAML.

The Coding Agent was taught to treat this file as a dependency.

The components didn't have if x > 22.5.

They had if x > rules.race_logic.pit_stop_avg_time.

This means the application logic remained Generic. The Python code described how to process rules, but the YAML described what the rules were.

Dynamic Governance without Deployment

This separation allowed us to do something powerful: Change behavior without writing code.

We could tweak the rules.yaml and the application would instantly behave differently, without a single line of Python changing.

This reduced the risk of regression bugs. Touching Python scripts creates bugs. Touching a YAML config is much safer.

Self-Validating Rules

But what if the Agent puts a typo in the YAML?

We introduced Schema Validation for the rules.

The rules.yaml itself was checked against a rules_schema.py (Pydantic model).

If the Agent tried to set min_laps: "five" (string instead of int), the pipeline exploded immediately. "INVALID RULE CONFIGURATION."

This effectively gave us "Type Safety for Business Logic."

We could ensure that the business rules were not only centralized but strictly formatted.

Use Case: Feature Toggles

We also used this for "Evolutionary Architecture."

When we were building a complex feature, we’d put it behind a toggle in rules.yaml.

```yaml

features:

new_dashboard: false

```

The Coding Agent would wrap the new code in if rules.features.new_dashboard:.

This allowed us to merge code safely without breaking the main app. The AI understood this pattern perfectly. "Oh, this is a feature flag. I will respect it."

Conclusion

Rules as Data is a profound shift for AI development.

It treats logic as content, not syntax.

It allows the "Business" (the Human + BA Agent) to control the application behavior directly, while the "Engineering" (Coding Agent) focuses on the machinery that executes those rules.

It made our system flexible, transparent, and—most importantly—easy for an LLM to manage without breaking the build.