Glossary

Term	Meaning
Scenario	A durable, evidence-grounded behavioral fact about a piece of software. The primary object in ArtlessDev — never “test case” or “ticket.”
Feature	A group of related Scenarios within a Project.
Place	A standing surface where someone can check a fact, named within a Project (The product, Web app, API, …) — perspective, not hierarchy.
Vantage	A Place’s closed classification: Product, Client, or Service. A nested child’s vantage must be the same as or deeper than its parent’s; Product-vantage Scenarios are never nested children.
Path	A Scenario’s Conditions and Results as one ordered sequence — the order the behavior runs in, not two separate lists. A Scenario encodes exactly one execution path.
Step	One entry on the path: either a Condition or a Result.
Input	A step describing something the behavior reads, including environmental reads like SQL or HTTP calls. Labeled Condition everywhere a person sees it.
Output	A step describing something the behavior writes or causes. Labeled Result everywhere a person sees it.
Mid-path Condition	A Condition sitting after a Result — a checkpoint that must hold at that point in the path, not an opening precondition.
Evidence	A concrete artifact (HTTP response, SQL row, screenshot, HTML snippet) attached to a step. Concrete values live only here, never in a step’s summary text.
Issued / Observed	The two sides a Result’s evidence can take: what the system sent (the INSERT, the request, the event) versus what the world looks like afterwards (the row, the page, the inbox). Two kinds of evidence for one Result, not two Results.
Parent	The broader-boundary Scenario a Scenario is nested under — set from the editor’s Parent picker. See Scenario Relationships.
Grounding	How a Condition gets its evidence: Own evidence, or Chain from result — a direct link to another Scenario’s Result.
Chain reference	That direct link from a Condition to another Scenario’s Result. Also how a fork is written: each alternative outcome is its own Scenario chained from the Result where the paths diverge.
Lifecycle status	One of a Scenario’s two independent status axes: Draft, Published, or Deprecated — whether the team stands behind this spec. An app-only overlay, never part of the Scenario’s content.
Verification status	The other axis: Not attempted, Fit, or Gap — whether reality has been checked against the Scenario, and what happened. Independent of lifecycle; neither gates the other.
Draft	The lifecycle status every Scenario starts in. Not a separate staged object: a Draft Scenario is a real, immediately queryable row, human- or AI-proposed alike.
Published	The team stands behind the Scenario as written. Says nothing about whether anyone has checked it.
Deprecated	A retired Scenario. Stays queryable, and deliberately stays editable and verifiable. A Published Scenario can never be deleted — it is deprecated instead; only a Draft can be deleted (and restored from Deleted scenarios in Project settings).
Fit	Reality was checked and matched the Scenario as written.
Gap	Reality was checked and diverged. How a bug shows up — there is no separate bug object. States the fact of divergence, not who is at fault.
Drift note	The plain text field describing how reality currently differs, meaningful only on a Scenario whose verification is a gap.
Verification pass	One attempt at checking a Scenario against reality. Findings and their evidence attach to the individual path steps they are about. A Scenario has at most one open pass at a time; closing a pass is what moves its verification status.
Verify all	The cascade action that records a fit for a Scenario and its nested descendants (and optionally chain successors) in one go. Also called a rollup. Only ever records a fit.
Asset	Supplementary, non-checkable notes, links, or diagrams attached to a Feature or Scenario. Carries no status — an asset is context, never a checkable claim.
Work item	Non-Scenario-shaped work — a refactor, an infrastructure change, a migration. A work item’s status (open / in_progress / done) answers “is this chore done,” never “is this true,” which is a third vocabulary, separate from both Scenario axes.
API key	A project-scoped machine credential (adk_live_…) carrying its own scopes. How MCP and the REST API authenticate — never a stand-in for a user, and never spanning two Projects.
Activity log	A Workspace-wide audit trail (members, Projects, Places, subscription changes) visible only to Workspace owners/admins. Not the same as a Scenario’s own Activity history. See Account & Navigation.
Workspace	The top-level container for a team: members and seats.
Project	Lives inside a Workspace; holds Features and Scenarios, and is the boundary an API key acts within.