Glossary
A list of terms that appear in this documentation, grouped into five areas — product, backlog, implementation/review, infrastructure, and mechanics.
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) |
| 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) |
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) |
| Status label | NexusArchitect-specific. status::todo / doing / review / done / blocked. Who can trigger which transition is fixed (details) |
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) |
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) |
disable-model-invocation |
A setting that forbids Claude itself from invoking that Skill. Attached to operations that are hard to undo (details) |
| Shared-Context pack | NexusArchitect-specific. A bundle of shared knowledge loaded on every implementation (details) |
| 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) |
| Prompt caching | A mechanism for handling repeated identical input cheaply. Input read from the cache is billed at 0.1x the normal rate |