docs deterministic-units.md

Deterministic computational units

An agent is good at interpreting intent. A LEMC recipe is good at doing a known thing the same governed way. Put them together without asking the agent to recreate the operational procedure on every turn.

Unhinged, Accelerated DevOps for Agents & Users means both callers cross the same explicit contract boundary before work begins.

The unit

A useful computational unit has a stable identity and enough declared structure to invoke safely.

Identity: A cookbook/app UUID, page, scope, recipe, and stable action ID.
Inputs: Named form fields with values supplied by the caller, plus server-owned job context.
Implementation: Ordered recipe steps from authorized, digest-pinned managed images.
Policy: Authentication, authorization, queue locks, timeouts, runtime isolation, networking, and quotas.
Observability: Task ID, system steps, recipe steps, live events, status, terminal reason, and bounded diagnostics.
Outputs: Rendered content, logs, artifacts, cache, and workspace data synchronized to durable storage.

What “deterministic” means here

The claim is about the invocation and execution contract:

the caller selects a published action rather than generating a new procedure;
the server validates the same declared inputs before admission;
the recipe points at authorized, immutable image content;
the server chooses and records execution policy;
events and terminal state use one durable job model;
retries can carry an idempotency key for exactly-once admission.

Exactly-once admission does not make every external side effect exactly once. Recipe authors still design idempotent operations, validate remote state, and expose useful failure reasons.

What it does not mean

An agent's reasoning and underlying LLM are not made deterministic.
A changing API, clock, network, database, or user input is not frozen.
A recipe is not safe merely because it is containerized.
A successful public-egress test is not proof that host and private networks are denied.
Rich output is not permission to bypass server authorization or execute on the host.

LEMC makes nondeterministic dependencies visible and puts execution behind an operator-controlled boundary. The recipe remains responsible for its own domain invariants.

A discoverable contract

An agent first asks the server what actions exist. A simplified action record looks like this:

{
  "id": "run-page-1-individual-check-release-readiness",
  "kind": "run_recipe",
  "page": 1,
  "scope": "individual",
  "recipe": "check release readiness",
  "form": [
    { "variable": "environment", "type": "select", "required": true }
  ]
}

The model chooses from the returned surface, fills the declared values, and passes the stable ID back to jobs run. It does not need to infer page numbers or reconstruct recipe names from prose.

Why models benefit

Without the unit	With a LEMC recipe
Generate commands from partial context.	Select a named action from server discovery.
Guess required parameters.	Fill declared fields and receive validation errors.
Run through an agent-specific shell path.	Submit to the same server path as a human click.
Parse unstructured terminal noise.	Follow structured steps, LEMC verbs, status, logs, and artifacts.
Lose the result with the agent session.	Reference durable output by task ID later.

Invocation sequence

lemcli jobs surface app \
  --uuid "$APP_UUID" \
  --scope individual \
  --format=json

lemcli jobs run app \
  --uuid "$APP_UUID" \
  --action "$ACTION_ID" \
  --set environment=production \
  --follow \
  --render html

Continue with one unit, two callers for the surface-parity contract.

# Deterministic computational units

## The unit

## What “deterministic” means here

## What it does not mean

## A discoverable contract

## Why models benefit