Glossary

An independent, second LLM agent that checks a generated plan against the organization’s compliance rules after a generate round. Failing findings — and, optionally, a high-impact verdict — lock the session until a panel editor unlocks it or a later generate round passes clean.

See Session locks.

Infrastructure changes made outside Terraform — for example a console edit or a hotfix — that no longer match the code. Kumoss can detect drift and generate code that reconciles it.

See Remediate drift.

The phase where a small-model agent classifies a request: a change request proceeds, a question is answered in the conversation, and an out-of-scope, prohibited, or ambiguous request is declined with an explanation.

See Make a request.

The phase where the main-model agent edits Terraform files through tools to satisfy the request, committing and pushing the result to the session branch.

See Follow a session.

The command-line tool — OpenTofu by default, or HashiCorp Terraform — that the iac sidecar runs to initialize, validate, plan, and apply infrastructure code.

See Deployment view.

The operating mode chosen in the web application header: Generate Infrastructure, Partial Drift Remediation, Full Drift Remediation, Partial Import, or Full Import. The drift and import modes require the devops operation role.

See Operating modes.

The bundled, verified default IaC engine (MPL-2.0). HashiCorp Terraform (BUSL-1.1) is also bundled and selectable with IAC_BINARY.

See Deployment view.

developer or devops, assigned per user and checked by the API on every IaC route; devops is above developer and is required for drift remediation.

See Roles and permissions.

An optional, hierarchical role — viewer, editor, or admin — that gates the admin panel: viewer reads cross-user sessions, editor also toggles a session lock, and admin also manages users and roles.

See Roles and permissions.

The plan file and validated workspace that a successful generate round renames into the session’s pinned directory, replacing any earlier pin, and that POST /api/v1/iac/apply executes without re-planning. Only generate rounds pin — drift rounds never do — and apply consumes and discards it whatever the outcome.

See Merge and apply.

Kumoss’s readable summary of the plan: what is created, updated, deleted, or recreated, the potential impact, and an estimated cost.

See Follow a session.

The natural-language text a user submits describing the infrastructure change, the drift to reconcile, or the question to ask. Each request within a session opens a round.

See Make a request.

One request-and-response cycle inside a session, with its own statuses, report, plan, code changes, and pull requests. The first API call creates round 1 with status started and the handler immediately opens round 2 for the actual work; the API exposes both a round’s database id and its per-session number, and the web application labels rounds by number.

See Follow a session.

One conversation with Kumoss about one repository. A session owns a Git branch named Kumoss/YYYY-MM-DD_HHMMSS (UTC) and a directory on the shared volume, and each user request within it opens a round.

See Follow a session.

A flag on the session that blocks apply and pull-request merge. It is set automatically when the compliance audit fails or, where the deployment enables it, when the impact is High, and cleared either by an admin-panel editor or by a later generate round whose audit passes without a high-impact verdict. Some internal material calls this a plan lock.

See Session locks.

An integration point between Kumoss and an organization’s systems, implementing an OpenAPI contract. Any implementation of the contract can replace the bundled reference by pointing services.<name>.endpoint in config.yaml at it.

See HTTP APIs.

The phase where the iac sidecar runs init, validate, and plan against the shared workspace to check that the generated code is sound and preview its effect.

See Follow a session.

The per-run directory, shared with the iac sidecar, where Kumoss clones the repository and the IaC engine runs its commands. Each run gets its own directory under the session’s path; only the pinned plan is per session.

See Deployment view.