Glossary

This glossary defines the key terms and concepts used throughout IAS. Terms are listed alphabetically. For a narrative introduction to the core concepts, see Core Concepts.

---

Agent (Worker)

A local process that executes jobs on behalf of the IAS system. Agents run on developer machines or CI environments and communicate with the Console via the control plane API. IAS provides two agent components: the CLI worker (handles setup and scaffolding jobs like bootstrap, create run, and apply decision) and the hybrid runner (handles AI-driven execution via the Codex SDK for work and PR review jobs). Start both with ias agent start. See Execution Modes.

Apply Decision

A job type that commits a decision request answer into the repository. When a human answers a decision request in the Console, IAS creates an apply_decision job. The CLI worker claims this job, writes the decision into docs/ias/runs/<run>/decisions.md (or the relevant decision file), and commits the result. The commit links back to the decision record for full traceability.

Bootstrap

The process of adding the IAS scaffold to a target repository. Bootstrap copies documentation structure, agent configuration files, CLI tooling, and optionally the hybrid runner into the repo. It creates the docs/ias/ directory with initial project context, base goal, and configuration templates. The primary command is ias install <path>. The bootstrap typically creates files on a dedicated branch (default: ias/bootstrap) that can be merged via PR. See Install & Bootstrap.

Briefing

A periodic health summary generated for a workspace. Briefings surface key metrics, attention items, and opportunities across repositories and agent activity. They provide a high-level view of workspace health -- what is progressing well, what needs attention, and where opportunities for improvement exist -- without requiring you to review every individual job or decision request. Briefings are available in the Console UI.

Build Context

A job type that reads repository content and populates project context artifacts. The Build Context job analyzes the codebase -- architecture, dependencies, file structure, and patterns -- and writes structured context that agents can use for future work. It populates docs/ias/project-context.md and related context files. Build Context can be triggered from the Console or via the CLI after bootstrap.

Command Center (Console)

The IAS Console web application. It provides a browser-based interface for workspace management, goal creation, decision request review, agent monitoring, context management, and repository onboarding. Built with Next.js and Convex. The Console coordinates work but never executes code -- all execution happens locally via agents. Also referred to as the "Console" throughout this documentation. See Architecture.

Context Architect

A job type that reads the repository and upserts project context into the control plane. The Context Architect analyzes the codebase structure and metadata, then syncs relevant information to the Console's Context Lake so that it is available for context pack assembly and workspace-level visibility.

Context Lake

IAS's unified knowledge layer. The Context Lake aggregates project context from multiple sources -- repository documentation, tickets, conversations, integration events, and code metadata -- into a single, queryable layer. Agents read from the Context Lake to understand project constraints and prior decisions. Humans use it (via the Console) to review what agents know and fill gaps. Data storage respects the workspace's data policy mode. See Context Lake.

Context Pack

A bundled set of context assembled from the Context Lake for a specific run or job. Context packs include relevant project context items, knowledge artifacts, and optionally live-fetched content from integrations. They are built on demand via the control plane API and provided to agents during job execution.

Data Policy

A workspace-level configuration that controls what content is stored in the cloud. Two modes are available: internal_ok (full content may be stored) and metadata_only (only identifiers, hashes, and structural metadata are stored unless explicitly allowlisted). The data policy is enforced at write time and read time. See Architecture.

Decision Request

A human-in-the-loop question raised by an agent when it encounters uncertainty during execution. Decision requests appear in the Console Inbox, where a human can review the question, consider the agent's assumed answer, and provide a resolution. Agents continue working with best-effort defaults while waiting for answers, so decision requests do not block progress unless configured as a hard stop. When answered, an Apply Decision job commits the resolution to the repository.

Goal (Run)

A goal-scoped unit of work tracked under docs/ias/runs/ in the repository. Each goal has its own directory containing a run log, run state, implementation plan, task breakdowns, decision records, and execution artifacts. Goals are created from intakes after refinement and approval. In the Console UI, goals are the primary unit of work that agents execute against. The terms "goal" and "run" are used interchangeably. See Create Goals.

Heartbeat

A periodic signal sent by a worker to the control plane. Worker heartbeats indicate that the worker is online and available for jobs. Job heartbeats extend the lease on a running job, preventing it from being reclaimed. If heartbeats stop (due to a crash or network issue), the worker is marked offline and job leases expire, allowing recovery.

Hybrid Runner

The automated execution component that uses the Codex SDK to run bounded agent turns without manual interaction. The hybrid runner claims work and pr_review jobs from the queue, executes them using an AI agent, stores results, and enqueues follow-up jobs. It supports features like auto-commit, PR creation, review loops, and PR chains. The runner can operate standalone with a local file-based queue or in Console-managed mode. See Execution Modes.

Inbox

The Console UI surface for viewing and answering decision requests. The Inbox shows pending questions from agents across all repositories in a workspace, with filters for workstream and priority. Humans review the agent's context and assumed answer, provide their own answer, and approve the resolution. See Inbox.

Intake

A raw intent input that starts the refinement process toward a goal. Intakes capture the initial problem statement, requirements, and context. They go through a refinement workflow -- intent review, quality gates, readiness checks -- before being promoted to a goal with an implementation plan. Intakes can include attached documents, links, and structured context.

Goal Proposal

A reviewable proposal generated during the intake-to-goal refinement process. Proposals include a structured summary, scope definition, acceptance criteria, a readiness scorecard, and identified gaps. A human reviews the proposal and either approves it (creating a goal) or requests changes. The readiness scorecard highlights missing information and potential risks before any code is written.

Job (Task)

A unit of work claimed and executed by an agent. Jobs have a kind (e.g., install_ias, create_run, work, pr_review, context_architect, apply_decision, update_git_policy, git_repair), a status (pending, running, done, failed, blocked, canceled), and are scoped to a specific repository and workspace. Jobs carry a prompt (what the agent should do), evidence (what it accomplished), and metadata (timing, lease state, retry state). Jobs are managed through the control plane API and visible in the Console UI.

Lease

A time-limited claim on a job, typically lasting 10 to 30 minutes. When a worker claims a job, it receives a lease that prevents other workers from claiming the same job. The worker must send periodic heartbeats to extend the lease. If the worker crashes or disconnects, the lease expires and the job returns to the pending state for another worker to claim. This mechanism ensures exactly-once execution and automatic recovery.

Project Context

The structured knowledge about a project that agents use to understand the codebase, constraints, and goals. Project context is stored in the repository under docs/ias/ (including project-context.md, context/base-goal.md, and context/inputs.md) and synced to the Context Lake in the Console. It includes information about the tech stack, architecture patterns, production status, stakeholders, and development constraints. Project context is built automatically via the Build Context and Context Architect jobs, or populated manually.

Space

A view within a workspace that scopes the Console UI to a subset of repositories, goals, and activity. Spaces support three visibility tiers: internal (visible to the workspace team), shared (visible to collaborators), and client (visible to external stakeholders). Spaces help team members focus on what matters to them without seeing unrelated noise. They are an organizational layer on top of the workspace, not a security boundary. See Spaces & Visibility.

Uncertainty

An internal knowledge gap, assumption, or risk identified by an agent during execution. Uncertainties are tracked within the system and can be resolved autonomously (through research, inference, or reasonable defaults) or escalated to a decision request when human input is needed. This two-tier model means humans only see the decisions that genuinely require their judgment. Uncertainties are also tracked in the repository at docs/ias/gaps.md.

Workboard

The Console UI surface for managing and monitoring jobs across a workspace. The Workboard provides a kanban-style view of job status, allowing team members to see what is pending, running, done, or blocked at a glance. See Workboard.

Workspace

A team-level container in IAS, analogous to a GitHub organization. A workspace groups together repositories, team members, integrations, goals, agents, and configuration. Each workspace has a unique slug, its own member list with roles (owner, admin, member, viewer), its own data policy, and its own authentication scope. All IAS operations are scoped to a workspace. Most teams need only one workspace; create additional workspaces for hard isolation between projects or clients.

Workstream

A scoping mechanism within a workspace. Workstreams allow teams to organize work into logical streams -- for example, by project, product area, client engagement, or sprint theme. Goals, decision requests, jobs, and context can be associated with a workstream for filtering and focus. Workstreams are used throughout the Console UI to help team members concentrate on relevant work.