Action and capability contract

Distinguish action discovery, installed capability reports, preflight, execution, and server authority.

Overview

The CLI provides an action manifest, offline preflight, installed capability discovery, and explicit native commands. The 0.1.9 bootstrap creates the signed installed layout needed for capabilities. These outputs answer different questions; none should be treated as proof of the others.

Customer Action Manifest

The versioned manifest contains 25 actions:

  • 22 actions are marked executes=true;

  • altifigence.analyze.run, altifigence.evolve.launch, and altifigence.verify.run are the three plan-only actions.

executes=true means the action is defined as executable. The actual command can still need a local engine, account permission, or remote service. A plan-only action validates and returns a plan without running a job.

Use alti commands to inspect the manifest shipped with the current binary. Do not copy a command list from a different release.

Offline Preflight Receipt

The offline job validate workflow verifies one bounded CPU RTL envelope and a safe workspace-relative source. A successful receipt explicitly states submitted: false and server_authority_verified: false. It does not run a local engine or contact a hosted service. See CLI First Success.

Installed Engine Capability Contract

The capability schema defines these states for a correctly installed, receipt-backed release:

State

Meaning

real

The installed release provides the documented local surface

partial

Only the reported subset is available

unavailable

The installed release cannot provide the surface

default-off

The surface requires an explicit, documented opt-in

plan-only

The action returns a plan rather than evidence of execution

Follow Verify Downloads and Install on Linux before using alti capabilities. The embedded bootstrap creates the authenticated catalog/receipt layout; do not copy a binary elsewhere or fabricate that state. Installed readiness reports available capabilities. Evidence that a design or GPU job ran comes from its execution result.

Question

Answered by

Did this command run here, and with what result?

The command’s own exit status and the receipt line naming the binary, the resolution, and the status

Does this installed release report the capability as available?

A successful alti capabilities report on an installed release

A successful local command reports what ran on that machine. Automation that depends on an installed product capability should also require the capability report.

Source Upload Is Opt-In

In its default customer mode, the packaged stdio MCP server hides the three plan actions that can include source files. They require separate environment credentials and use the Cloud client. The current public release does not provide a complete remote execution workflow for them.

The separate ALTI_MCP_MODE=local-xls mode exposes fixed local XLS tools without Cloud dispatch. Native ide cloud operations use their own sign-in and explicit upload rules; the plan-only customer action state does not describe all Cloud workspace operations.

An opt-in permits transmission; it does not turn a plan-only action into a real run or make a remote service available.

Handle Each Result Separately

When automating the CLI, handle these results as different states:

  • a local capability is available;

  • a request was validated;

  • a plan was returned without execution;

  • work was accepted by an explicitly enabled authority;

  • work completed and produced evidence;

  • a capability or authority was unavailable.

Collapsing these states into a single success value can make a plan or preview look like completed engineering work.

Select the right result contract

For a local run, record the selected engine, input digest, native exit status and full result. For a saved-file mutation, retain the plan and apply receipt and reread the file. For a remote job, follow its ID until a terminal state, then retrieve and verify the actual result. An action manifest entry only describes the callable interface.

Keep local engine request envelopes, customer plan actions and saved Cloud RTL jobs separate in automation. They differ in input schema, source location, authentication, submission and result handling even when their names contain “analyze” or “evolve”.