The Principles of Modulo

Modulo is built on nine engineering principles that shape how the system works. Schema seams, immutable snapshots, deterministic gates (with guardrails at the ingestion edge), audit as a first-class output, humans in the loop where it matters, secret hygiene, dispatch-not-run, correction-never-rewrites-history, and self-hosted-no-telemetry.

Schema seams

Every boundary in a pipeline is a typed contract. Inputs validate against input_schema, outputs against output_schema, before anything moves. An agent cannot pass garbage downstream without a record of it. Typed seams make automation auditable and failures loud. What you see is what runs; mismatches fail loudly at the seam.

Immutability of runs

When a run starts, we freeze the whole pipeline definition into a snapshot before anything executes - every agent version, schema pin, connector binding, model backend, and prompt hash. Nothing resolves live. Pause for a human review and resume a week later, and the run behaves exactly the same. This is what makes the audit trail trustworthy: the run you inspect is the run that happened, not a reconstruction. (See all first-class versioned entities for the full list of what gets frozen in each snapshot.)

Audit as a first-class output

Every state-changing action produces an immutable audit event, timestamped and org-scoped, so the history you inspect is exactly what happened. Governance requires a record you can trust after the fact, and the trail is a product output, not an afterthought.

Deterministic gates

Gates produce a clear pass or fail result. A regex, a schema check, a custom function, or a scored eval either passes or it doesn't, and the run history shows which gate caught what. Regex and schema gates are deterministic; scored eval gates use an LLM judge with a pass threshold. Both produce the same outcome: the run either proceeds or pauses for review.

Deterministic gates catch failures before they reach a human reviewer. Audit records what the gate decided and why. Together they mean a reviewer never sees a decision without its evidence.

Guardrails at the ingestion edge

Deterministic gates check what leaves a node; guardrails check what enters a run. A guardrail is evaluated at run creation, before the run's input payload is persisted - deterministic only, regex or JSON Schema, no LLM judge on the input side. Its actions are observe, warn, block, or redact. A block is terminal: the run never dispatches and there is no human-in-the-loop gate on it. Redaction masks matched values before the payload is persisted, so raw secrets never reach the audit log. Remediation is the guardrail-override endpoint, which re-runs the guardrail pass on the operator-supplied input rather than resuming on the blocked payload - re-blocking is always safe.

The speed-bump logic applies on the way in: the agent definition is the driver's manual, but boundary controls are the enforcement. A credential or a disallowed string in a webhook payload is stopped at the entrance, before any node sees it.

Humans in the loop where it matters

Humans are in the loop where it matters. Every gate is atomic - one claim, one decision, an audit record either way - and an agent can never approve its own work. Governance is permissions plus gates plus audit; automation never gets a blank check.

Secret hygiene

Credentials are decrypted once, at run start, into a run-scoped context. They never touch agent state, checkpoints, or logs. Secrets in agent-visible state are a liability; one-decrypt-per-run bounds exposure.

We dispatch, we don't run agents

We dispatch work to the runtimes you already use, and we own everything around the work: auth, audit, cost, eval gates, and human review. Established agent runtimes do tool-use better than a platform can, so we dispatch to them instead of competing with them. Swap runtimes without changing governance; your stack stays yours.

Correction never rewrites history

Correction never rewrites history. A failed output produces a new run with the feedback attached, and the original stays as it was - which is what makes the trail trustworthy. The correction loop is a first-class pipeline that produces a new run, not an in-place edit of the original.

Self-hosted, no telemetry

Your infra, your data, no cloud dependency. Runs on Docker Compose, Fly, or standalone SQLite mode; no telemetry by default. For regulated and IP-sensitive teams, governance without data ownership is not a viable option.

What it adds up to

These nine principles are the answer to a single question: what does it take to trust automation at scale? Schema seams, immutability, audit, gates (with guardrails at the ingestion edge), HITL, secret hygiene, dispatch, correction, and self-hosting - each one closes a gap that would otherwise make the system untrustworthy.