Core terms

Use this index for the nouns that show up throughout ota and the payoff each one gives you.

Repo readiness

The state of a repo being runnable and diagnosable, so the next safe step is obvious.

Contract

The explicit ota.yaml that defines repo readiness, so teams stop guessing.

Repo signals

The files and conventions ota inspects to infer the contract without hand-writing it.

Inference

What ota concludes from repo signals when it helps you bootstrap faster.

`ota.yaml`

The repo-local source of truth for readiness, execution, and safe AI-agent guidance.

Doctor

The command that explains blockers and the next safe action, so you know what to fix first.

Build identity

The machine-readable ota binary identity, so CI and automation can distinguish release builds, source builds, and supported contract capabilities.

Pressure evidence registry

The Core-owned record of bounded real-repository pressure cases, so proven controls and explicit limits stay together instead of becoming a green-matrix claim.

Execution governance

The discipline of making repository execution explicit, policy-aware, and evidence-backed, so humans, CI, and AI agents can determine what can run and what each result proves.

Execution contract

The machine-readable ota.yaml interface that defines readiness, verification, execution, and proof for a software repository.

Execution governance loop

The separation between contract declaration, execution selection, proof and receipt evidence, semantic comparison, and policy constraint.

Execution topology

The resolved relationship between contexts, tasks, services, endpoints, requirements, and execution boundaries for one selected lane.

Execution context

A named runtime boundary that supplies backend, lifecycle, requirements, attachments, and platform truth to selected tasks.

Execution closure

The complete ordered set of dependencies, hooks, services, observers, and assertions that a selected task or workflow may execute.

Commands

Detect

The command that infers a contract from repo signals, so you can compare reality to the current contract.

Init

The command that writes a starter ota.yaml, so you can bootstrap quickly from repo signals.

Validate

The command that checks contract structure and semantics, so edits fail early instead of in use.

Check

The command that runs readiness checks without execution, so you can verify readiness without side effects.

Diff

The command that compares two contracts, so change impact is obvious before merge.

Explain

The command that turns findings into a remediation plan, so the next action is obvious.

Receipt

The read-only receipt artifact from ota receipt or ota workspace receipt, so CI and humans can archive the same readiness state without mutating the repo.

Proof runtime

The evidence command that proves one selected workflow really starts and reaches readiness, so CI or reviewers do not rely on a verbal claim.

Policy review

The ota policy review command that shows the policy-authority boundary, so repo truth and org approval do not get conflated.

Tasks use view

The capability-oriented task view that shows runnable modes, agent access, effects, requirements, and the next dry-run or receipt command.

Workflow

A named contract flow that composes preparation, setup, run, services, proof, and teardown into one selectable execution lane.

Execution plan

The resolved pre-execution plan showing the selected backend, mode, lifecycle, requirements, and task closure before work starts.

Execution topology command

The machine-readable view of contexts, services, endpoints, and bindings that make a selected runtime addressable.

Proof lifecycle

The service-oriented proof transaction that starts a declared lifecycle, verifies readiness, runs an optional assertion, and records teardown.

Baseline record and promote

The explicit two-step flow that records a generated baseline, then promotes that exact reviewed attestation as replay authority.

CI projection

The provider-neutral governance projection and adapter output that lets CI consume contract truth without becoming a second contract.

`ota up`

The command that prepares the repo and re-checks readiness; service workflow run tasks use proof-owned readiness by default (prepare + verify + teardown + return) unless --detach is selected.

`ota run`

The command that executes a named task, so humans, CI, and agents follow the same path.

Doctor output

Primary Blocker

The headline issue when readiness is blocked, so you fix the right thing first.

Primary Finding

The headline issue when readiness is risky or advisory, so you know what still needs attention.

Finding groups

Grouped summaries with a stable action key, so repeated fixes stay readable.

Contract fields

Tasks

The named repo actions ota can run from the contract, so execution stays explicit.

Checks

The contract-defined checks ota can run to prove readiness, so validation stays repeatable.

Execution

The part of the contract that says how work should run, so the environment boundary stays clear.

Effects

Declared task side effects such as repo writes, network use, or external state mutation, so safety and review are explicit before a task runs.

Toolchain

A managed ecosystem environment, so ota can diagnose and fulfill capabilities like Rust components without hiding them in shell setup.

Runtime

A required runtime version, so toolchain drift is visible early.

Tool

A required command-line dependency version, so local setup matches the contract.

Minimum Ota version

The metadata.ota.minimum_version gate that prevents an older ota binary from pretending it understands a newer contract.

A provider-neutral declaration of which exact task or workflow needs secret material at a bounded destination. In the current v1.6.28 implementation Ota consumes it for fail-closed admission, but does not store, resolve, contact a provider for, or deliver secret material.

Artifact lineage

The declared producer, inputs, outputs, and consumer relationship for generated or replayed repository artifacts.

Generated source

An artifact whose declared producer creates source or other files that a selected consumer must explicitly require.

Replay baseline

A generated artifact consumed from explicitly promoted authority rather than regenerated as part of the replay consumer closure.

Replay input

An immutable file a selected lane consumes and Ota observes before execution; its identity narrows evidence but does not prove runtime state.

Expected identity

An optional independently declared SHA-256 pin for a replay input; Ota refuses before execution when the observed file differs.

Service lifecycle

The start, readiness, assertion, and teardown behavior of a declared service, including what Ota can and cannot prove about existing state.

Readiness probe

A bounded observation of a declared service or endpoint used to decide whether the selected runtime path is ready.

Runtime surface

A reusable named endpoint or application surface attached to tasks that publish it, so bind and host projection stay canonical.

Typed effect

A contract-declared effect with a specific action, resource, bounds, and realization identity, rather than a broad shell-side-effect label.

Effect refusal canary

A negative control that asks the real runner to prove a declared typed effect remains unavailable before execution begins.

Execution modes

Native vs container vs remote

native runs commands on the host. container uses a container backend, and remote forwards execution to the declared remote transport target.

Lifecycle

The selected persistence boundary for a run: persistent, ephemeral, or a proof-owned lifecycle transaction.

OCI sandbox

The Ota-managed container enforcement boundary for repository root, writable paths, network posture, and cleanup evidence.

Isolated path

A declared dependency or artifact path mounted into Ota-managed storage so host-native state does not leak into container execution.

Policy and agent fields

Policy

The org-level rules that constrain readiness and provisioning, so shared standards stay consistent.

Policy Pack

The shared .ota/org-policy.yaml rules above repo contracts, so many repos can share guardrails.

Effect governance

The policies.effects rules that decide whether selected task-path side effects are allowed, warned, or denied before execution starts.

Effect override

The --effect-override <effect>=<allow|warn|deny> one-invocation override for ota run and ota up when a reviewed temporary policy decision is needed.

Typed effect policy

Org policy that evaluates exact typed effects and their resource bounds before a selected task or workflow can execute.

Policy decision

The evaluated allow, warn, or deny result for one selected closure, retaining the policy identity and decision basis.

Policy overlay

A deterministic, more restrictive policy layer applied above contract truth without rewriting the repository contract.

Refusal canary

A contract-owned negative test that verifies an agent execution surface refuses a task or workflow that must remain unavailable.

Audited crossing

A heavier execution boundary that requires an explicit, single-use operator decision and records what crossed, why, and under which authority.

Crossing authority

Contract-bound authority for an audited crossing; a reusable grant is valid only when it is narrow, expiring, revocable, issuer-bound, and checked at crossing time.

Sandbox policy

The compiled boundary posture for filesystem writes, network access, runtime sockets, and provider capabilities in a selected execution.

`OTA_POLICY`

An explicit override for a local policy file or hosted policy URL, so ota uses the right source.

Workspace policy

A workspace-level policy source declared in ota.workspace.yaml, so one rule set can cover several repos.

Environment Variables

How ota decides which environment values apply, so the result is explainable.

Provisioning

The contract-driven path that installs or selects required runtimes and tools, so setup is repeatable.

Provisioning source

The effective approved source ota resolves for one runtime or tool on the current target, so installs stay auditable.

Adapter bootstrap

The separate policy layer that tells ota how it may install a missing adapter such as brew, choco, or sdkman before repo provisioning retries.

Provenance

The evidence about where a value, inference, or policy decision came from, so receipts, detect, and explain output stay trustworthy.

Safe tasks

The tasks an AI agent may run safely, so automation has a default path.

Agent posture

The declared authority model for agent edits, so strict readiness slices and broader authoring slices stay distinct.

Verify after changes

The tasks to rerun after edits, so the review loop stays obvious.

Writable paths

The paths an AI agent may edit, so the edit boundary is explicit.

Protected paths

The paths an AI agent should avoid changing casually, so sensitive files stay protected.

Container backend

The execution mode that runs setup and provisioning inside a container, so host setup stays isolated.

Agent admission

The pre-execution decision that determines whether an agent may run the selected task or workflow closure under the declared safety boundary.

Evidence and identity

Proof scope

The exact selected runtime boundary a proof covers; it prevents a green lane from being read as repo-global success.

Not proved

A machine-readable boundary for material behavior the selected proof did not exercise or independently establish.

Evidence class

The ownership label explaining whether a value is declared, runner-observed, attested by a boundary, derived, or still unknown.

Claim assurance

The evaluator that compares a contract claim with scope-matching proof evidence and reports supported, contradicted, or unknown.

Semantic snapshot

The canonical normalized contract identity used to compare execution evidence against the contract that was actually selected.

Execution receipt

The structured record of one selected execution or readiness result, including contract identity, evidence, boundaries, and terminal status.

Runtime proof

An archive-backed, selected-lane evidence record for starting a workflow, reaching readiness, and preserving explicit unproved boundaries.

Replay authority

The one explicitly promoted attestation a replay-baseline consumer is allowed to consume; Ota never selects the newest record automatically.

Source identity

The content or revision identity used to bind evidence to the source state that produced it, so later drift cannot silently acquire old proof.

Boundary identity

The identity of the exact managed execution boundary, such as an Ota-created container session, that produced or enforced evidence.