---
title: Glossary
description: >-
  A list of terms that appear in this documentation, grouped into five areas —
  product, backlog, implementation/review, infrastructure, and mechanics.
seo:
  image: /ogp.png
---
This page collects the terms explained throughout this documentation.
Come back here whenever you read something in the body text and can't recall what a term means.

It mixes general software-development terms with terms specific to NexusArchitect.
Terms specific to NexusArchitect are marked **NexusArchitect-specific**.

## Product terms

| Term | Meaning |
|---|---|
| Vision | A statement of what this product wants to achieve. It's the starting point of the pipeline, and every later decision traces back to it |
| Scope | What's in and out of scope for this round. Decided using constraint classification, MoSCoW, and RICE scoring |
| North Star Metric (NSM) | The single metric the business cares about most as a measure of success. Defined together with 3–5 supporting input metrics and guardrail metrics that prevent drift |
| TAM / SAM / SOM | A three-tier measure of the addressable market: the total market size (TAM), the portion your company can target (SAM), and the share you can realistically capture (SOM) |
| MoSCoW | A method for splitting priority into four tiers: Must / Should / Could / Won't |
| RICE score | A method for scoring priority numerically from Reach, Impact, Confidence, and Effort |
| Persona / proto-persona | A concretization of the intended user as a single person. A provisional one not based on actual research is explicitly labeled a proto-persona |
| JTBD (Jobs-to-be-Done) | A way of thinking about features that starts from "what job is the user really trying to get done" |
| SLI / SLO / SLA | How service quality is measured (SLI), targeted (SLO), and promised to customers (SLA) |
| NFR | Non-functional requirements: performance, reliability, security, and other requirements beyond "what it can do." Derived from SLOs into a measurable form |
| Bounded context | The boundary within which the same word means the same thing. A term from DDD (Domain-Driven Design) |
| Profile | **NexusArchitect-specific.** A setting that determines which phases run. One of four kinds: `mvp` / `core-only` / `ux-to-spec` / `full` ([details](/concepts/dependency-graph)) |
| Validation gate | **NexusArchitect-specific.** A check right after Phase 1 that decides whether to proceed. A "Go" doesn't mean "proof this will be profitable" — it means "the plan for how to find out is in place" ([details](/concepts/validation-gate)) |

## Backlog terms

| Term | Meaning |
|---|---|
| Epic | The largest unit of work, grouping multiple issues. Describes "what" and "why" |
| Sub-Epic | A further breakdown of an Epic, split by feature grouping or area of ownership, with a measurable KR of its own |
| Issue | The smallest unit of work that's actually carried out. Split by, for example, one feature, one endpoint, or one schema change |
| Acceptance Criteria | Verifiable conditions used to judge that an issue is complete |
| Sub-task list | **NexusArchitect-specific.** A checklist of child items (`- [ ] #<iid>`) embedded in the parent's description |
| Delivery Status | **NexusArchitect-specific.** A checklist showing each item's progress stage (`Implemented` / `Reviewed` / `Merged`) ([details](/concepts/checklist-contract)) |
| Status label | **NexusArchitect-specific.** `status::todo` / `doing` / `review` / `done` / `blocked`. Who can trigger which transition is fixed ([details](/concepts/status-labels)) |
| `backlog-manifest.json` | **NexusArchitect-specific.** Backlog data meant to be read by the program. On resume, state is read from here and from the `status::*` labels |
| Roll-up | **NexusArchitect-specific.** The chain of updates by which a child's completion propagates up to its parent (Sub-Epic → Epic) |
| Fallback | In environments where GitLab's Epic feature isn't available, switching to plain Issues plus `type::*` labels plus a task list ([details](/getting-started/prerequisites)) |

## Implementation and review terms

| Term | Meaning |
|---|---|
| Branch | A forked line of code history. NexusArchitect creates branches named `feature/<issue-id>-<slug>` |
| PR / MR | Pull Request / Merge Request. A submission for review before changes are merged in. Created by `review-issue` |
| Merge | Incorporating a PR/MR's changes. An operation that's hard to undo once done |
| Preflight check | **NexusArchitect-specific.** A set of checks that must always pass before a merge. If even one fails, the merge doesn't happen |
| Confirmation gate | **NexusArchitect-specific.** A confirmation that always appears right before merging. Only `--yes-merge` can skip it |
| Auto-fix loop | **NexusArchitect-specific.** A mechanism that repeats "fix → re-review" whenever a blocker appears. Stops after 3 tries by default and sets `status::blocked` |
| severity | How serious a found issue is: `[B]` blocker (stops the merge) / `[S]` important (recorded only) / `[Q]` question (open question) |
| Blocker | An issue that stops the merge — a finding marked `[B]` |
| finding | A recorded issue found during review |
| SAST | Static analysis that scans source code for vulnerabilities without running it |
| Quality gate | **NexusArchitect-specific.** An 8-stage checkpoint covering build, tests, SAST, dependency scanning, and more. Any FAIL blocks progress |

## Infrastructure terms

| Term | Meaning |
|---|---|
| OKF (Open Knowledge Format) | A documentation format that structures technical knowledge into three tiers: confirmed facts, design recommendations, and unresolved open questions. Answers from the infra plugin (`okf-k8s-tf`) and the ScalarDB-related skills (`OKF-ScalarDB-ScalarDL`) are grounded in a knowledge bundle written in this format |
| ADR (Architecture Decision Record) | A document that records why a given design was chosen and why alternatives were rejected. Assumptions that haven't been implemented yet (e.g., a production environment) are recorded as ADRs rather than as facts |
| Layer (L1–L4) | **NexusArchitect-specific.** A four-tier classification the infra plugin uses to divide infrastructure. L1 is cloud-specific (VPC/IAM, etc.; not unified), L2 is Kubernetes abstraction (Deployment/Service, etc.; fully common), L3 is platform components (Argo CD/Vault, etc.; only values differ), L4 is the application (fully common) |
| Image digest | A fixed hash value computed from a container image's contents. Using the same digest across environments guarantees that the binary that was tested is identical to the one running in production (immutable deploy) |
| Ownership map | **NexusArchitect-specific.** A table listing which of Terraform, Argo CD, CI, or manual operations manages each resource. Infra reviews create this first |

## Mechanics terms

| Term | Meaning |
|---|---|
| Skill | A unit of extension for Claude Code. Each NexusArchitect command is implemented as one Skill |
| Sub-agent | A small AI split out to handle one role. The parent only receives its result |
| Model tiering | **NexusArchitect-specific.** A design that uses haiku/sonnet/opus depending on task difficulty to control cost ([details](/concepts/token-cost)) |
| `disable-model-invocation` | A setting that forbids Claude itself from invoking that Skill. Attached to operations that are hard to undo ([details](/getting-started/installation)) |
| Shared-Context pack | **NexusArchitect-specific.** A bundle of shared knowledge loaded on every implementation ([details](/concepts/shared-context)) |
| Append-only log | A log that's only ever appended to, never erased or rewritten. `decisions.md` and `review-knowledge.md` are examples |
| Traceability ID | **NexusArchitect-specific.** An identifier issued per decision, such as `VIS-`, `NSM-`, `SCP-`, `FEAT-`, `ENT-`, `CTX-`, `API-`, `NFR-`, or `KN-` |
| `reports/` | **NexusArchitect-specific.** The single source of truth where every artifact is collected ([details](/getting-started/output-structure)) |
| Prompt caching | A mechanism for handling repeated identical input cheaply. Input read from the cache is billed at 0.1x the normal rate |