Glossary

When a page uses a word you have not met yet, this is where you settle it. Every term Disco Parrot uses is here, defined in a sentence or two, with a link to the guide that covers it in full. The list is alphabetical so you can find a word fast. Use your browser's find to jump straight to a term, or skim a band if you are not sure of the exact word. If you would rather see the same terms grouped by how they relate, core concepts at a glance lays them out by neighborhood.

A few words carry two meanings in different parts of the product, and those are split into separate entries so the distinction is on the page rather than in your head. Plan is both a work record and a subscription tier. Session is both a single run and the index that lists them. Owner is both a record's accountable person and the name of the top workspace role. Workflow is a status machine, which is not the same thing as a Flow. Where one term is just another name for another, the entry points you to the full one.

A to C

• Action launcher. The drawer that starts a manual skill, a chat, or a flow from any record, with the right options already in context. See action launcher.
• Activity feed. The chronological record of changes across the workspace, shown at a friendly altitude. It reads the same trail as the audit log and is gated by the same audit.read scope. See activity feed.
• Agent. The AI runtime plus the Agent Instructions you write for it. The runtime is the engine; the instructions are how it behaves on your team's work.
• Agent Instructions. The versioned, scoped instructions that shape how the agent works. They apply globally or to a single sandbox profile, and every change is a new version. See agents and Agent Instructions.
• AI model. The runtime an agent runs on. The runtimes Disco Parrot supports are Claude, Codex, Google Gemini, and GitHub Copilot; a workspace picks a default, and users or skills can override it. See AI models.
• Approved actions. The mechanisms that bound what an agent can reach: tool allowlists on connected servers, propose-only environment policies, and credentials the agent never holds. See approved actions.
• Ask. The read-only, cited question-and-answer surface over your workspace. Ask reads your records and answers with citations; it does not change anything. See Ask.
• Assignee. The person doing the work on a record, as distinct from its owner, who is accountable for it. See plans.
• Audit log. The tenant-wide record of who did what, retained for a year and gated by the audit.read scope. You cannot edit or delete an individual entry; only retention removes aged rows. See audit and evidence.
• Azure DevOps. A work-tracking integration. Disco Parrot maps its records to Azure DevOps work items and reaches the service through a connected MCP connection during a run. See Azure DevOps.
• Background task. Agent work that runs without you watching it, created by sending a chat to the background, running a flow in the background, or fanning out sub-tasks from a step. See background tasks.
• Board (Kanban). Your records arranged by status in columns. The sprint board is the first board that mixes plans and bugs in the same columns. See boards.
• Bug. An issue record that lives alongside plans, rolls up against an initiative, and can be assigned to a sprint. See bugs.
• Built for query. Every record is structured data with a stable URL, so the records you filter and share are the same ones the agent reads and writes. See built for query.
• Capacity. The hours or points a sprint budgets per member across its window, set against the committed estimate so you can see whether the sprint is over or under filled. See sprints.
• Chat. The multi-turn agent surface with tool calls, attachments, a status-scoped slash menu, and the ability to start a flow or send the work to the background. See Chat.
• Checkpoint. A point where a flow pauses for a person to Approve, Reject, or Skip before the run continues. Also called a human checkpoint. See human checkpoints.
• Clarification. A question the agent raises against an initiative before it commits to a spec, answered by a person so the spec reflects real intent. See initiatives.
• Command Center. The live panel of every chat, flow run, and background task you have in flight. See Command Center.
• Credential lease. A short-lived, scoped grant of a credential to a single operation. The agent receives an opaque handle and an expiry, never the secret value itself. See credential leases.

D to G

• Danger level. The risk tier marked on every scope: low, elevated, destructive, or platform-only. The role builder uses it to show the weight of each permission. See the scope catalog.
• Data grid. The filterable, sortable, inline-editable grid every entity gets, with a filter panel, bulk edit, and shareable URL-encoded views. Also called a list view. See list views and the data grid.
• Document. A file or page attached to your work. Uploaded files are stored as blobs; the per-repository wiki is kept in the platform's document store. See documents.
• Document provider. Google Drive or OneDrive, connected per person as a read-only source you import from. Distinct from a repository provider. See document providers.
• Documentation health review. The scheduled review that keeps a repository's wiki current by proposing edits a person approves. See documentation health reviews.
• Entitlement. A capability a commercial plan turns on, such as email or Microsoft Teams notifications, GitHub Enterprise, custom MCP tools, or audit export.
• Environment. The change-policy and capability layer a sandbox profile runs under. Its policies can park flow steps that depend on a part of the system the agent is told not to touch. See environments.
• Estimate. A record's sized effort, recorded in hours or in story points. Estimates sum into sprint capacity and roll up against an initiative, and they are what the estimate-accuracy reporting measures against the real outcome. See plans and sprints.
• Evidence package. A sealed bundle of security events with a verifiable hash, built to hand to an auditor. Distinct from the audit log, which is the operational record. See audit and evidence.
• Fan-out. A flow step or agent spawning sub-tasks that run in parallel in the same container, up to a fixed ceiling. The sub-tasks inherit the parent's surface and approval gate. See background tasks.
• Field. A named attribute on a record, such as a status, an owner, an estimate, or a due date. The work items reference lists every field on every entity.
• Flow. An orchestration of agent work: ordered steps, parameters, per-step checkpoints, and a choice of running interactively or in the background. A flow is not a workflow. See flows.
• GitHub. Both a repository provider and a code-aware chat integration, and the merge authority for every change a ship produces. See GitHub code integration and repository providers.
• GitHub Enterprise. Enterprise Managed Users on github.com, available as a repository provider when you supply an enterprise slug. See repository providers.
• Goal. An outcome the work supports, with key results that tie back to the initiatives contributing to them. Also covers OKRs. See goals and OKRs.

H to O

• Host. Where the work runs. Managed hosts (Azure Container Apps and Docker) need no setup; bring-your-own hosts (a Kubernetes operator or a Local Docker operator) run on your own compute. See sandbox hosts.
• Inbox. The notifications page in Settings, with search and unread, read, and archived filters. The top-bar bell shows the unseen count, and opening it clears the count. See notifications.
• Initiative. The captured intent at the top of the work model. An initiative holds the spec that decomposes into plans. See initiatives.
• Integration. A connected external work-tracking system. Azure DevOps and GitHub are the two integrations; tools like Jira, Linear, or Slack reach the agent as MCP tools, not as integrations. See integrations and providers.
• Isolation key. The tag on every sandbox that names the kind of work and the record it is for. One key maps to one container at a time, and it is how a request reaches the right sandbox. See sandboxed execution.
• Key Vault. Where your workspace's secrets are held. Values are never returned over the wire; a run receives one through a credential lease. See Secret.
• Lease. See credential lease.
• Materialize. The step that writes your in-scope records, the focal item plus its plans, bugs, attachments, and test cases, into the agent's sandbox as files at the start of a run, so the agent reads your work the way you query it. See built for query.
• MCP. The Model Context Protocol, the open standard for connecting external tools the agent can call. A workspace configures MCP connections and the agent calls those tools at runtime. See MCP tools.
• Member. A person with a membership in a workspace. A membership can hold several roles at once. See members and invitations.
• Modular monolith. Disco Parrot's architecture: one service and one app deployed as a single unit, with the parts that vary swappable behind interfaces. See system overview.
• Navigation and search. The app shell, the three areas (Planning, Platform, and Settings), the project switcher, and cross-workspace search. See navigation, workspaces, and search.
• Notification. An alert driven by rules, delivered in-app and, where your plan allows, by email or Microsoft Teams. See notifications.
• OKR. See goal.
• Owner. On a record, the person accountable for it, always in its notification recipients and distinct from the assignee. As a workspace role, the top built-in role. See roles and permissions.

P to R

• Plan (work record). A reviewable piece an initiative decomposes into. Seven plan types cover implementation, design, spec, review, research, chore, and verification. See plans.
• Plan (subscription). A commercial tier: Free, Team, Business, or Enterprise, plus a 14-day Pilot. It sets your entitlements and quotas. See plans and usage.
• Plan type. One of the seven kinds a work plan can be. The type shapes what the plan is for and which skills it offers. See plans.
• Point scale. A team's story-points option, set to off, fibonacci, or linear, which fixes the point values allowed on estimates when the team estimates in points. See teams.
• Portfolio. The rollup container above projects, with team-based membership and a privacy switch, for looking across several projects at once. See portfolios.
• PR review loop. The cycle where pull-request comments and reviews become findings on a plan the agent picks up and addresses. Comments are read one way; the platform never writes back to the request. See PR review loop.
• Profile. A sandbox profile: the configuration that decides how a sandbox runs, covering its runtime, image, resource class, allowed commands, and connected tools. See sandbox profiles.
• Project. The container a team's work lives in. A project holds initiatives, binds to a repository, and sets the default sandbox profile. See projects.
• Provider. A repository provider (GitHub or GitHub Enterprise) or a document provider (Google Drive or OneDrive). Distinct from an integration. See integrations and providers.
• Pull request. An ordinary GitHub pull request a ship produces, opened under your connected GitHub identity against the repository's default branch. GitHub holds the merge; the platform never writes back to the request. See ship code.
• Quick View. A modal that lets you peek any record over your current list without losing your place. See Quick View.
• Quota. An enforced numeric cap, such as flow runs per day or active projects. A quota that is absent means uncapped; a quota set to zero means the capability is turned off. See usage metering and quotas.
• Repository. A connected git repository the agent reads, branches from, and opens pull requests against. See connect a repository.
• Repository documentation. The wiki the platform keeps for each repository, generated by the agent and kept current by documentation health reviews you approve. See repository documentation and wiki.
• Resolution. How a bug was settled when it leaves the open states. The work items reference lists the bug states and resolutions in full. See bugs.
• Reviewable autonomy. The operating model: agents do the work, people review it, and every action is visible and reversible. See reviewable autonomy.
• Revise Spec. The agent action that folds answered clarifications into an initiative's spec in a single pass. The edit lands marked as agent-made. See initiatives.
• Roadmap and timelines. Initiatives and plans drawn on a time axis, with drag-to-reschedule, dependency arrows, and sub-task rollups. See roadmap and timelines.
• Role. A named bundle of scopes. Eleven roles ship and cannot be edited; you can build custom roles from the scope catalog. A membership can hold several roles. See built-in roles.
• Rollup. A derived aggregate that climbs the work hierarchy, so progress and counts on a child add up on its parent. See rollups.

S

• Sandbox. The disposable container the agent runs in, one per run, with the agent and a sidecar inside and all input and output passing through the sidecar. The container is the boundary. See also Profile and Host, and sandboxed execution.
• Sandbox profile. See Profile.
• Scope. The unit of permission. Disco Parrot ships over 140, each in the form area.subject.action and marked with a danger level. Roles are bundles of scopes. See roles and permissions and the scope catalog.
• SDK config. The named runtime configuration, covering the provider, model, and credentials, that a chat or skill runs under. See AI models and SDK configs.
• Secret. A credential value held in your workspace's Key Vault. Secrets are never returned over the wire; a run receives one through a credential lease. See secrets.
• Session (a run). A single chat, flow run, or background task, with its full transcript. See sessions.
• Session (the index). The unified page that lists every chat and flow run in the workspace so the team can see what is running. See the Sessions page.
• Ship code. Turning approved work into a pull request: the agent commits its change on a branch and opens a PR under your GitHub identity. See ship code.
• Sidecar. The process that runs beside the agent inside a sandbox and mediates all of its input and output, so the agent never talks to the outside world directly. See how sandboxed execution isolates agents.
• Sign-in. How a person authenticates: Microsoft Entra or Google. GitHub is used to authenticate repositories and integrations, not as a way to sign in. See authentication and identity.
• Skill. A named, reusable set of instructions for one kind of work, runnable on its own from the action launcher or as a step inside a flow. Skill sources are built-in and tenant-authored, with a private marker for skills only their author sees. See skills.
• Snapshot. A full point-in-time copy of a record's body and fields. Version history is a stack of snapshots, not diffs, which is why a restore brings back an exact past state. Not to be confused with the reporting metric snapshot. See entity versioning and history.
• Sprint. A team-scoped delivery window that groups plans and bugs. See sprints.
• SSE. Server-sent events, the unified real-time channel the browser holds open. The platform sends signals over it and the app refetches the named record, so a missed signal never means lost data. See real-time architecture.
• Status. The state a record currently holds in its workflow, such as a plan in review or a bug that is triaged. The statuses reference lists every status for every kind of record.
• Status-scoped skill. A binding that decides which skills appear on which records at which statuses, so the right action is offered at the right moment. See status-scoped skills.
• Story points. A unitless way to size a record's effort, as an alternative to hours. The allowed values come from the team's point scale. See Estimate and Point scale.

T to W

• Team. A membership group that carries access to the portfolios and projects it is linked to. See teams.
• Tenant. See Workspace.
• Test case. A verification record that captures what should be true and the status of checking it. See test cases.
• Transition. A permitted move from one status to the next in a workflow. The platform enforces them, so a record cannot jump to a status its workflow does not allow. See workflows.
• Trigger. What starts a flow without a person launching it: a schedule, a pull-request comment, or a pull-request review. See build a flow.
• Velocity. A team's completed-versus-committed work read across several recent sprints, a measure of how much it reliably finishes in a window. See sprints.
• Version history. The non-destructive snapshots kept on every initiative, plan, skill, and agent instruction, with an AI badge on agent-made versions and a restore that creates a new version rather than overwriting. See entity versioning and history.
• Warm pool. A small inventory of ready containers kept per sandbox profile, so a launch attaches to a waiting one instead of building from scratch. See sandboxed execution.
• Watcher. A person on a record's notification recipient set, added automatically by participation or by hand with the Watch toggle. A notification reaches the watchers plus the owner, minus whoever made the change. See notifications.
• Workflow. The status machine a record moves through. Five ship, one each for initiatives, plans, bugs, flows, and test cases, and you can customize the statuses and transitions. A workflow is not a flow. See workflows.
• Workspace. The top-level boundary that holds your organization's work, members, and settings. Also called a tenant. One workspace stays one workspace; data does not cross between them. See workspaces and tenancy.

Keep going