opscompose

A minimal Go model for Ops as composable transformations from intent to execution.

---

The Category of Ops

I’ve been thinking lately about all the “-Ops” disciplines we see around us —
DevOps, FinOps, MLOps, SecOps, AgentOps — and how they might fit together if we looked at them through a more abstract lens.

What if each “Ops” is not a suffix, but a transformation?

Ops : Intent → Execution

Each Ops discipline preserves a different kind of truth:

• DevOps → reliability
• FinOps → cost-truth
• MLOps → learning-truth
• SecOps → safety
• AgentOps → autonomy

In this view, Ops is the morphism between thought and action — the process that keeps abstractions alive in the real world.

This repository explores that idea in executable form.

---

What this is

opscompose is a small Go library that models Ops pipelines as composable transformations:

• typed steps (A → B)
• explicit composition
• explicit fan-out and combination
• no infrastructure
• no orchestration engine
• no YAML

Just structure.

---

The core idea

A pipeline step is a typed transformation:

type Step[A any, B any] struct {
	Name string
	Run  func(ctx context.Context, a A) (B, error)
}

Steps compose:

Then : (A → B) × (B → C) → (A → C)

Independent paths can be combined:

Fanout : (A → B) × (A → C) → (A → (B × C))

From these primitives, you can model DevOps, MLOps, FinOps, or any other “Ops” flow as a sequence of transformations between typed states.

---

An example: the Ops loop

The example in examples/opsloop models a simple feedback loop:

Intent → Plan → Execution → Observation → Intent′

Where learning happens by feeding execution back into intent.

This mirrors how real systems evolve:

• we act,
• we observe,
• we adjust our intent.

Run it with:

go run ./examples/opsloop

---

Why Go?

Go forces explicitness:

• no hidden control flow,
• no implicit effects,
• clear data movement.

That makes it a good medium for modelling structure rather than platforms.

---

What this is not

• Not a workflow engine
• Not a pipeline runner
• Not an Ops framework
• Not production infrastructure

This is a thinking tool, expressed in code.

---

Where this could go

Possible future extensions (not implemented yet):

• tracing and evidence for diagram chasing
• equivalence checks between alternative paths
• visualisation of composed pipelines
• applying the same algebra to DevOps, MLOps, and beyond

All without changing the core model.

---

Status

Early, intentionally small, and complete enough to be useful.

Contributions, critiques, and counterexamples are welcome.