Infrastructure as Behavior
From desired state to desired response.
Your infrastructure lives in a world of static descriptions
Kubernetes and Terraform revolutionized infrastructure by letting you describe what you want. But the logic that maintains that state remains opaque. Controllers, operators, reconciliation loops: you can see what the system should look like, but not why it makes the decisions it makes.
The visibility gap. Controllers make decisions constantly, but you can't see why. Logs show what happened, not what logic applied. When scaling kicks in at 3am, you reconstruct the reasoning after the fact.
Controller sprawl. Every new automation scenario means another controller. Cert-manager for certificates, external-dns for records, Karpenter for nodes, separate operators for Postgres, Redis, Kafka. Each with its own reconciliation logic, its own failure modes, its own way of expressing intent.
Implicit behaviors. Scaling logic, failover rules, resource priorities: all buried in imperative code across multiple operators. The behavior exists, but it's not declared anywhere you can read it.
State-centric blindness. You describe what the system should look like, but not how it should respond when conditions change. "Three replicas" says nothing about when to scale, what signals matter, or how to prioritize competing demands.
You can describe what you want. You can't describe how to react.
What if infrastructure could express intent, not just state?
Inferal inverts the model. Instead of writing controllers that poll and decide, you write rules that declare behavior. The rules live alongside your infrastructure definitions: visible, versionable, changeable without redeployment.
- When deployment completes and error rate stays flat for five minutes → promote canary to production
- When certificate expires within 30 days and no renewal is pending → trigger rotation
- When upstream dependency reports degraded while failover region is healthy → reroute traffic
- When maintenance window opens and active connections drain below threshold → begin rolling update
- When agent workload exceeds threshold and autoscaling would violate budget constraint → queue requests and alert
Rules evaluate continuously against events, state, and signals. When conditions align, actions activate. The rule is the logic, not a description of logic buried in controller code.
Change the rule, not the controller.
From 'Desired State' to 'Desired Behavior'
This isn't just a different syntax for the same automation. It's a different way of thinking about infrastructure management.
Logic becomes visible. Rules are readable, auditable, diffable. Review behavior changes in pull requests. No more digging through controller source to understand why scaling behaves the way it does.
Timing becomes explicit. "When error rate stays flat for five minutes after deployment" is a declaration you can read. Not timing logic hidden in a reconciliation loop with hardcoded intervals.
Operators become executors. Generic rule engines replace bespoke controllers. Same execution engine, different rules. Add new behavior by adding rules, not by writing and deploying new code.
Every action, traceable. Rule evaluations produce an audit trail. Why did this scale event happen? Which rule matched? What data triggered it? The answer is in the evaluation log, not reconstructed from metrics after the fact.
Agent-aware orchestration. Agents that manage infrastructure insert their own rules. An agent provisioning a cluster can set conditions for its own cleanup. The infrastructure adapts to agent intent, not just human configuration.
The logic is the documentation.
Infrastructure that anticipates, not just reacts
Reactive rules are powerful, but they still wait for conditions to occur. What if infrastructure could anticipate needs based on patterns it has observed?
Predictive scaling. Traffic patterns learned over weeks. Pre-scale before the Monday morning spike, not after latency climbs and alerts fire.
Self-scheduling maintenance. A database that schedules its own backup window based on observed query load patterns, not a fixed cron that hopes for the best.
Adaptive thresholds. A latency threshold starts conservative, then adjusts based on observed correlation with actual user-facing errors. The rule learns what matters.
Agent-driven adaptation. An SRE agent observes system behavior and proposes new rules. Human approves, rule activates. The agent learns, the human governs.
Dormant rules aren't idle. They're accumulating context, refining their understanding, waiting for the right moment to act.
Proactive isn't magic. It's rules with memory.
Declare once, adapt forever
Rules aren't one-time queries. They're standing orders. Write the behavior once; the system applies it continuously as data flows, as conditions change, as new telemetry sources connect.
Your infrastructure doesn't just converge to a desired state. It behaves according to declared intent. The gap between "what should exist" and "how it should respond" closes.