01
Use the inputs you already have
Collect change, identity, ownership, and runtime context from CI/CD, cloud audit, Kubernetes, OpenTelemetry, catalogs, and security tools.
Vartio by False Systems
What caused production to behave differently?
Vartio reconciles production changes with normalized runtime behavior, preserving the evidence behind each conclusion and refusing to guess when the evidence is insufficient.
01 / the missing layer
Production change and production behavior live in different systems.
Git, CI, cloud APIs, and Kubernetes record what changed. Runtime sensors and observability systems record what happened next. Neither side normally explains the other.
Vartio does not compare everything that changed. It explains which changes caused production to behave differently.
As automation becomes more autonomous, a human-authored deployment trail is no longer enough to describe production. We need a searchable memory of what existed, how it behaved, which automation patterns changed it, and how those patterns changed over time. That memory must preserve history rather than overwrite it with the latest snapshot.
02 / the operational mirror
A mirror of production that includes the limits of the mirror
Vartio is the product. False Agent, Kide, Ruuma, and Ahti are the systems inside it; external tools provide evidence and context.
External systems
cloud · CI/CD · security · Kubernetes · OpenTelemetry
Vartio product
Evidence intake
connectors · webhooks · APIs · OTLP
False Agent
runtime witness · processes · identity · network · capture quality
Kide
reconcile meaning · preserve provenance and conflict
Ruuma
normalize and compare runtime behavior
Product surface
operational mirror · status · diff · why · blame · bisect · accept
Ahti
immutable evidence · stores versioned interpretations · searchable history
02
Witness production directly
False Agent adds independent process lifecycle, ancestry, workload identity, network relationships, and observer-state evidence.
03
Record the quality of knowledge
Coverage, capture loss, missing or withheld evidence, attribution degradation, and ordering limits travel with everything Vartio claims.
The mirror contains both the state of production and the epistemic state of what Vartio knows about it.
03 / adoption
Start with existing evidence. Add production access only where it earns its keep.
The footprint depends on the questions and coverage you need. Vartio can begin outside your workloads and make the resulting runtime gaps explicit.
01
Connect existing sources
Use webhooks, audit feeds, APIs, and existing OpenTelemetry exports. SaaS and control-plane use can begin without installing an application agent or sidecar.
02
Add a runtime witness when needed
For independent Linux runtime evidence, deploy False Agent at the node level. On Kubernetes, the intended footprint is one privileged DaemonSet instance per covered worker—not one sidecar per pod.
03
Keep telemetry scoped
eBPF is a runtime-capture implementation choice, not a Vartio platform requirement. Vartio consumes selected operational evidence; it does not require every log, metric, trace, or application payload.
A smaller footprint means less coverage—not permission to turn missing evidence into absence.
04 / mechanism
The semantics behind the simple surface
01
Kide reconciles meaning
Preserve source truth and derive small typed claims, recording whether each relationship was carried, witnessed, derived, or inferred.
02
Ruuma compares behavior
Normalize causally meaningful runtime structure and establish same, changed, or indeterminate only when observation integrity allows it.
03
Vartio makes it operable
Turn claims and comparison witnesses into status, diff, why, blame, bisect, and explicit acceptance—while Ahti preserves the history.
05 / refusal
Missing evidence is not evidence of sameness
A healthy collector does not prove a trustworthy observation interval. Capture loss, ordering degradation, attribution failure, or an unsupported dimension may prevent comparison.
Uncertainty is data. The epistemic state of the observer is data.
Vartio does not convert those conditions into a lower confidence percentage merely to force an answer.
06 / audience
Built for people and software changing production
- Production engineering
- Teams asking which release or configuration change altered runtime behavior.
- Platform and SRE
- Teams tracing changes across CI, cloud, Kubernetes, services, and runtime execution.
- Security and incident response
- Teams that need provenance and evidence quality to travel with a conclusion.
- Software agents
- Operational agents that need the same evidence-backed production memory as human engineers.
07 / workflow
Six operations, not another dashboard
The semantic system is deep so the user workflow can remain small: status, diff, why, blame, bisect, and accept.
| Before Vartio | With Vartio |
|---|---|
| Change records and runtime telemetry searched separately. | status and diff show what can be compared and what changed. |
| Engineers manually guess which deployment caused a symptom. | why, blame, and bisect preserve the evidence behind attribution. |
| Historically common behavior silently becomes normal. | accept records an explicit trust decision. |
08 / boundaries
Use the systems you already have
Vartio begins after evidence exists.
Vartio does not replace observability, OpenTelemetry, security products, service catalogs, runtime enforcement, application logs, or a SIEM. Those systems make Vartio stronger by supplying evidence and context.
09 / deeper view
What the operational mirror must preserve
The mirror is useful only when a technical reader can distinguish production state from the quality of Vartio’s knowledge about it.
- What exists?
- The relevant services, workloads, executions, identities, resources, and relationships over time.
- What was observed?
- The immutable source evidence, including capture-session state, gaps, and redaction.
- How does it behave?
- The normalized runtime structure and recurring patterns Ruuma can establish from the supported evidence.
- What changed it?
- The production changes and typed Kide claims that connect delivery, configuration, identity, and runtime behavior.
- How is it known?
- Whether provenance was carried, independently witnessed, derived, or inferred.
- How good is the evidence?
- Coverage, capture integrity, loss, attribution quality, ordering limits, redaction, and observer state.
- What remains unknown?
- The explicit gaps, conflicts, unsupported dimensions, and unresolved relationships that limit the mirror.
Kide preserves how shared meaning was established. Ruuma defines when two executions are behaviorally equivalent. Vartio gives both operational meaning and preserves observations and versioned interpretations in Ahti. Ahti stores structure; Vartio interprets behavior.
bring the change
Bring us one production change you could not explain
Show us the change record, the runtime evidence, and the question engineers still had to answer by hand. We will map what a trustworthy comparison would require.
Discuss the change →