Docs Product

Reusable operational domains

A domain is the thing you build once with KIFF: the state, the valid actions, the authority and approvals, the outcomes, and the evidence that an agentic system would otherwise rebuild around every new agent. A domain is the operational contract your software runs against, and the unit you reuse.

That is the apex idea. The decision boundary, the controls, the receipts, and Govern are all things a domain has. Start here, and the rest of these pages are detail.

What a domain holds

A domain gathers, in one place, the operational facts about a slice of your business:

  • State: what counts as the current status of an entity (an invoice is PENDING or PAID; a refund is REQUESTED or SETTLED), derived from the events KIFF has seen.
  • Actions: the consequential operations that can be taken (ISSUE_REFUND, CREATE_PAYOUT, PAY_INVOICE) and the states each is allowed in.
  • Authority and approvals: who may propose what, what needs a human sign-off, and the thresholds that trigger it.
  • Outcomes and evidence: the terminal result of each proposal and the signed receipt that proves what was decided, before execution.

A Protected Control is how you express one consequential action inside a domain. It is the natural starting point - pick the one action you’d least like taken unsupervised, but it is a part of the domain, not the foundation everything sits on. The domain is.

Reuse is the point

The reason a domain is worth building is that it outlives any single agent. Once the operational contract exists, you can:

  • connect a new agent, or replace the one you have, without rewriting what “a legitimate refund” means;
  • put a human, a scheduled job, or a service through the same boundary the agent uses;
  • change the framework underneath without changing the contract above.

You build the refund domain, the payout domain, the access-change domain once. The agents that act through them are interchangeable. That is the difference between governing an agent and owning an operational domain.

How you build one

A domain is a kiff.yaml: a versioned artifact that lives in your own repository, like a docker-compose.yml: committed, diffed, and reviewed in git alongside the code it governs. You don’t hand-edit it in a browser form. You author it with your own coding agent, two on-ramps:

  • Derive from what your agent already does. Attach the guard to an agent you run, in observe mode, and it derives a starter domain from real traffic, the actions your agent actually calls, ready to review. This removes the blank page. See connect an existing agent.
  • Author it with your coding agent. Install the kiff-domains skill in Cursor, Claude Code, Codex, or Gemini and let your agent write and extend the kiff.yaml against the real grammar, states, actions, approvals, permissions, executors, then kiff verify it locally.

You bring the finished kiff.yaml to KIFF Cloud to validate and activate it. The dashboard’s Build view is a read-only render of the running version, the mirror of what you have deployed, not an editor. The source of truth stays in your repo. See the quickstart and how the guard works.

The Cloud unit: a governed operation

When you run a domain on KIFF Cloud, the thing that’s counted is a governed operation: one unique authenticated proposal that KIFF evaluates against current state and the active domain contract and records with a terminal outcome. Idempotent retries of the same proposal do not create another governed operation, the duplicate that state refuses is not a second billed event.

Domains, actions, agents, integrations, and development environments are not metered, and there is no cap on how many you create: build as many as you want. They expand what the platform is worth; only governed operations are counted.

The model is usage-based, analogous to how Twilio meters messages or Stripe meters payments: what you pay for is a continuous, verifiable evidence stream: every governed operation records a signed, tamper-evident receipt, and spend stays predictable through budgets and alerts, not through limits on the objects you model. See the pricing page for how Cloud operation is bought.

Running more than one domain

A workspace is not limited to one domain, and each domain has its own lifecycle. The all-domains view is the portfolio: one row per domain with its state, the freshness of the runtime backing it, its recent governed-operation count, and the single next action to take.

  • Independent posture. Governance posture (shadow / enforce) is per domain, one domain can be enforcing while another is still observing in shadow. You flip a domain’s posture from its home page; it takes effect on the next decision. See Govern.
  • Independent lifecycle. A domain you’re still building appears as a draft: in the switcher and the portfolio, while your other domains keep operating. Adding or drafting a domain never puts the whole workspace back into setup.
  • Finish a draft with your agent. A draft’s home shows a status checklist (runtime observed → action derived → finish with your agent → activate in shadow → first decision). The milestones reflect observed progress; the only deliberate actions are finishing the contract with your coding agent and activating the verified kiff.yaml.

Honest boundaries

  • A domain is yours. KIFF decides whether a proposed action conforms to the contract you declared; it does not invent authority you didn’t set, and it never becomes your executor.
  • Reuse is a property you build toward, not a marketplace claim. KIFF does not yet offer a public exchange of domains authored by other customers; reuse here means reuse across your own agents, humans, and services.

Next

← Quickstart kiff-guard on GitHub ↗