Glossary

Generated 2026-05-17 18:05. 278 term(s). Source: REQQA's definitions table.

This page is generated by the help-build pipeline. Edit definitions in REQQA's glossary UI; changes appear here at the next release.

Index

• A (35)
• B (23)
• C (27)
• D (20)
• E (3)
• F (9)
• G (5)
• H (6)
• I (15)
• K (1)
• L (5)
• M (10)
• N (3)
• O (7)
• P (19)
• Q (1)
• R (26)
• S (27)
• Symbols (1)
• T (23)
• U (6)
• V (2)
• W (4)

Symbols

32-byte value

A sequence of 32 bytes (256 bits) of data, typically represented as 64 hexadecimal characters or 43 base64 characters (with padding). In the context of API tokens, this refers to the raw random data generated before encoding into a human-readable token string format.

A

acceptance criteria

A set of verifiable conditions that must be satisfied to confirm successful implementation of a feature, requirement, or system component. These criteria establish measurable thresholds for functionality, performance, security, and compliance, providing an objective basis for validating that delivered capabilities meet stakeholder expectations and operational needs.

acceptance-criteria coverage

A measure of the extent to which a user story's acceptance criteria comprehensively specify all testable conditions and scenarios required to verify the story's functionality, including normal flows, edge cases, error conditions, and non-functional requirements.

accepted

A developer confirmation status indicating that the developer has tested the build deliverables, verified they meet the scope requirements, and formally accepted the build as complete and ready for closure. ACCEPTED status is a prerequisite for executing the /close-build skill and represents the developer's sign-off that the build phase is successfully concluded.

access control

A security mechanism that regulates which users, systems, or API clients can access specific resources, operations, or data within the platform. In the context of API integration, it provides granular permission management through custom API keys, ensuring that external systems can only perform authorized actions and access permitted information while maintaining audit trails of all access attempts.

accurate

Conforming to the true state of disruption events, passenger data, and policy rules without error or distortion. In the context of this platform, accuracy ensures that detected irregularities, executed decisions, and communicated information faithfully represent actual operational conditions and regulatory requirements, enabling reliable re-accommodation and compliance outcomes.

acting user

The user identity resolved from the API token used to authenticate a write request, representing the person or system performing the operation. The acting user is recorded in audit logs and as the created_by or updated_by value for all write operations, enabling traceability of who made each change.

action bar

A user interface component displayed in the backlog list view that presents available batch operations (such as 'Attach to Scope' or 'Create New Scope') that can be performed on the currently selected backlog items. The action bar typically appears when one or more items are selected and provides buttons or menu options for bulk actions.

action menu

A contextual menu or dropdown control displayed in association with a list item or entity that presents available operations (such as 'Attach to Scope', 'Edit', 'Delete') that can be performed on that item. Action menus typically appear on hover, click, or through a dedicated button (often represented by three dots or similar icon).

action option

A user interface element (button, link, or menu item) displayed on the triage page that represents an available operation the analyst can perform on the backlog item, such as 'Promote to requirement' or 'Decline'. Action options are enabled for open backlog items and trigger specific triage workflows when selected.

advisory criteria

A set of quality or completeness checks that are evaluated when transitioning a scope to handover_ready status, including conditions such as 'all stories analysed' and 'no HIGH issues'. Advisory criteria provide guidance and warnings to developers but do not block status transitions in v1, allowing developers to proceed with handover despite unmet criteria while being informed of potential quality concerns.

age

A computed display value representing the elapsed time since a backlog item was created, calculated as the difference between the current timestamp and the item's created_at timestamp, and rendered in human-readable relative time format (e.g., '2 days ago', '3 weeks ago', '1 month ago') to help analysts quickly assess item recency.

analyser

A software component or module within REQQA that executes a specific type of analysis (such as R-D Definitions, R-F Functional, R-C Completeness) on a requirement or story, applying predefined rubrics to identify issues, assess quality, and generate structured feedback. Each analyser corresponds to a step-code and produces analysis results stored in the analyses and analysis_issues tables.

analyser step-code

A short alphanumeric identifier (e.g., 'R-D', 'R-F', 'R-C') that uniquely identifies a specific requirement analysis step or procedure within the REQQA analysis framework. Step-codes follow a consistent naming convention and are registered in the system's analyser registry, enabling references to analysis types in templates, requirements, and audit trails.

analysis engine

The core REQQA subsystem responsible for executing requirement analyses by orchestrating AI calls, managing analysis workflows, detecting issues, tracking progress, and persisting results to the analyses and analysis_issues database tables. Located in the modules/ and harness/ directories, it implements the step-code taxonomy (R-D, R-F, R-C, etc.) and coordinates worker processes to perform asynchronous analysis operations.

analyst

A user role in REQQA with permissions to create and manage requirements, stories, scopes, and backlog items within their organization. Analysts are responsible for requirements specification, scope definition, and responding to builder feedback during the Dark Factory lifecycle.

analyst repository

A version-controlled file system directory structure (typically a Git repository) where analysts store requirements documentation, review artifacts, and legacy backlog files. The repository follows a standardized directory structure including 'documentation/reviews/YYYYMMDD-Review/' paths for organizing review-dated content. The migration script reads markdown backlog files from this repository to populate the backlog_items database table.

api

Application Programming Interface - a set of defined methods, protocols, and tools that allow different software applications to communicate and exchange data. In this context, REST APIs expose HTTP endpoints that accept requests in a specified format (typically JSON) and return structured responses, enabling integration between the order management system and external services (payment gateway, fulfillment system, carrier tracking).

api endpoints

Specific URLs or URI paths exposed by the REST API that represent distinct resources or operations, each supporting one or more HTTP methods (GET, POST, PUT, DELETE). Each endpoint defines a contract specifying request parameters, payload structure, response format, status codes, and error conditions for a particular API function.

api token

A unique, cryptographically secure string issued to a user that serves as a credential for authenticating API requests. API tokens are scoped to the user's organisation, inherit the user's permissions, and are used in place of session-based authentication for programmatic access. Tokens can be generated, regenerated, and revoked by the user, and each token is associated with metadata including creation timestamp, last usage timestamp, and active status.

application

A software system or product being specified and developed, serving as the top-level organizational container for requirements, stories, and scopes. Each application represents a distinct development effort with its own set of specifications, and scopes cannot span multiple applications. Applications provide the context within which requirements are authored and scopes are defined.

appropriate indexing

Database index structures strategically applied to columns frequently used in query WHERE clauses, JOIN conditions, or ORDER BY operations to optimize query performance. Appropriateness is determined by query patterns, data volume, update frequency, and the trade-off between read performance and write overhead.

archived

A data state where records are moved from active operational storage to long-term retention storage, remaining accessible for authorized queries and reporting but excluded from routine transactional processing. Archived data maintains integrity and auditability while optimizing active system performance.

aria

Accessible Rich Internet Applications - a set of attributes that can be added to HTML elements to improve accessibility for users of assistive technologies (such as screen readers). ARIA attributes provide semantic information about UI components, their states, and their relationships, enabling assistive technologies to convey the purpose and behavior of interactive elements to users with disabilities. Examples include aria-label, aria-describedby, and role attributes.

aria labels

Accessible Rich Internet Applications (ARIA) label attributes that provide accessible names for UI components, enabling assistive technologies like screen readers to announce the purpose and function of interactive elements to users with disabilities. ARIA labels include attributes such as aria-label, aria-labelledby, and aria-describedby that supplement or override visible text labels for accessibility purposes.

artifact

A generic term for any primary entity in the REQQA system that can have associated analyses and issues, including requirements, stories, scopes, and applications. Artifacts are identified by a combination of artifact_type (e.g., 'requirement', 'story', 'scope') and artifact_id (the entity's unique identifier), enabling polymorphic querying of analyses and issues across different entity types.

as-built snapshot

A JSON-serialized, immutable record of all stories and requirements in a scope at the moment it transitions to 'accepted' status. The snapshot captures the final state of artifacts after implementation, including any changes made during the build phase, enabling comparison with the as-scoped snapshot to identify scope drift, measure change impact, and provide an auditable record of what was actually delivered versus what was originally specified.

as-planned vs as-built delta

A comparison report showing the differences between the original scope plan (as-planned snapshot taken at scope creation or approval) and the final delivered state (as-built snapshot taken at build closure). The delta identifies: artifacts added or removed from scope, artifacts with changed revisions or status, work items deferred to backlog, and any other deviations from the original plan. This delta provides transparency into scope changes and helps stakeholders understand what was delivered versus what was originally committed.

as-scoped

The original planned state of a scope as defined at scope creation or approval, capturing the initial set of artifacts, requirements, and work items intended for delivery. The as-scoped state serves as the baseline for comparison with the as-built state to identify scope changes, additions, deferrals, or deviations during the build phase.

as-scoped snapshot

A JSON-serialized, immutable record of all stories and requirements included in a scope at the moment it transitions to 'handover_ready' status. The snapshot captures the exact content, structure, and revision numbers of all artifacts as they were specified, providing the baseline against which the builder will work and enabling comparison with the as-built snapshot to measure scope drift or changes during implementation.

attach

The action of linking an open backlog item to a scope by populating the backlog_items.scope_id field with the target scope's identifier, indicating that the item is planned for inclusion in that scope's delivery. Attaching does not change the backlog item's status and is reversible while the scope remains in draft state.

attaching user

The authenticated analyst who performed the action of linking a backlog item to a scope, recorded for audit trail purposes. The attaching user is captured from the current session context and stored immutably with the attachment record to support accountability and change tracking.

attachment timestamp

The date and time (with timezone) when a backlog item was linked to a scope, recorded in UTC format with microsecond precision to support audit trails and chronological ordering of scope composition changes. This timestamp is immutable once recorded and is used to track when items were added to scope planning.

authorization header

An HTTP request header field (as defined in RFC 7235) that contains credentials for authenticating the client with the server. In this system, it carries the Bearer token in the format 'Authorization: Bearer <token>', where the token is the API authentication credential.

auto-increment

A database column attribute that automatically generates sequential integer values for new records, typically used for primary keys. The database management system increments the value by 1 for each new insert, ensuring uniqueness without requiring application-level value generation.

available

A book status indicating that the item is not currently on loan, not on hold for another member, and is physically present in the library or digitally accessible for immediate borrowing. An available book can be checked out by any eligible member or allocated to the first member in the reservation queue.

B

backlog item

A structured work item representing a future task, enhancement, defect, or change that has been identified during scope review, design, or build phases but falls outside the current scope. Backlog items are stored per organization and application, linked to source artifacts, prioritized for future implementation, and may be promoted to requirements or stories in subsequent scopes through manual workflow.

backlog items

Work items stored in the project backlog that represent future work to be prioritized, planned, and executed in subsequent iterations or phases. Backlog items include a description, priority, origin (source of the item), status, and any relevant metadata. Items can be created from various sources including deferred work from closed scopes, new feature requests, or identified technical debt.

backlog list view

A tabular or list-based user interface displaying multiple backlog items with key attributes (title, status, priority, scope attachment) in a scannable format, supporting sorting, filtering, bulk selection, and access to item-level actions through action menus or inline controls. The list view serves as the primary interface for browsing and managing multiple backlog items simultaneously.

badge

A small visual indicator (typically a colored label or tag) displayed alongside or within a UI element to convey status, category, or other metadata at a glance. In the context of backlog items, a priority badge would visually represent the priority level (mvp, dependency, valuable, nice-to-have) using color coding or iconography.

batch

A collection of related builder feedback issues submitted together in a single API request or transaction, typically representing all feedback identified during a single builder review of a scope. Batches enable atomic submission and efficient processing of multiple related issues.

bearer scheme

An HTTP authentication scheme defined in RFC 6750 where the client includes an access token in the Authorization header using the format 'Authorization: Bearer <token>', indicating that the bearer (holder) of the token is authorized to access the requested resource without additional proof of identity.

blocker issue

An issue with severity or priority classification indicating that it prevents progress on a scope and must be resolved before the scope can transition to the next lifecycle state. Blocker issues typically represent critical defects, missing information, or unresolved conflicts that would make it impossible or inadvisable to proceed with handover, review, or acceptance.

blocker issues

Critical problems or unresolved questions identified during scope review that prevent the design phase from proceeding. Blocker issues represent gaps in requirements, unresolved stakeholder conflicts, or missing information that must be addressed before technical design decisions can be made. The system tracks blocker status and warns users when attempting to design a scope with unresolved blockers.

blockers

Critical issues identified during builder's review that prevent the scope from proceeding to design and implementation, such as missing essential requirements, fundamental contradictions, or undefined critical terms. Blockers must be resolved by the analyst before the scope can exit in_review status and continue through the Dark Factory pipeline.

body hash

A cryptographic hash (such as SHA-256) computed from the JSON request payload body, used in conjunction with the Idempotency-Key header to detect when the same idempotency key is reused with different request content. The body hash enables the system to distinguish between legitimate retries (same key, same body) and conflicting requests (same key, different body), with the latter returning a 409 Conflict error.

brand

The manufacturer or trademark name associated with a tennis ball product (e.g., Wilson, Penn, Dunlop, Babolat). Brand is a primary organizational dimension in the catalogue and a filterable/sortable attribute used for product discovery and comparison.

browser sessions

Independent instances of user interaction with the web application, typically corresponding to separate browser tabs, windows, or devices, each maintaining its own authentication state, cookies, and local storage. Browser sessions may share authentication if using the same browser profile, or be completely isolated if using different browsers or incognito/private modes.

build phase

The active code generation and implementation stage where the builder creates executable artifacts based on approved requirements and scope definitions. Feedback issues with source 'build_phase' are raised during actual code generation when the builder encounters implementation blockers, discovers runtime constraints, or identifies issues not visible during earlier review phases.

build plan

A versioned document or structured record created by the builder that outlines the technical approach, implementation sequence, dependencies, and estimated effort for delivering the stories in a scope. Build plans are stored against the scope and may be updated as implementation progresses, providing visibility into the builder's strategy and enabling tracking of plan vs actual execution.

build report

A structured document summarizing completed implementation work for a scope, including deliverables produced, test results, deviations from the build plan, issues encountered and resolved, and confirmation that acceptance criteria have been met. The build report is posted to REQQA as part of scope closure and serves as the final artifact of the build phase.

builder

The AI-powered system (Claude Code) or human development team responsible for implementing the stories and requirements defined in a scope. The builder receives the formal handover package, creates build plans, implements the specified functionality, and provides feedback through the issue mechanism. In the Dark Factory context, the builder is expected to operate with high autonomy, guided by structured specifications and automated quality gates.

builder feedback

Structured comments, questions, or issue reports submitted by external AI tools or developers during the implementation process, typically including references to specific requirements, proposed changes, identified ambiguities, or implementation challenges. Builder feedback is posted via the API and stored as part of the requirement audit trail, enabling asynchronous communication between automated builders and human stakeholders.

builder review

A systematic evaluation phase where the builder (AI code generation agent) analyzes a defined scope to identify specification gaps, implementation risks, ambiguities, and missing requirements before code generation begins. The review produces a batch of feedback issues that are submitted to the issue management system for analyst resolution.

builder token

An API authentication token issued to automated builder systems (such as Claude Code agents) that grants permission to create backlog items and submit builder feedback, distinguished from regular user tokens by having builder-specific permissions and rate limits. Builder tokens are scoped to an organization and application, and are used to authenticate API requests from automated build processes.

builder's review

A structured evaluation performed by a builder (automated agent or human developer) during the handover stage, assessing whether a scope's requirements are complete, clear, testable, and ready for design and implementation. The review produces findings, questions, and a readiness assessment that determines whether the scope can proceed to the design phase.

bulk select

A user interface capability that allows the analyst to select multiple backlog items simultaneously from the list view using checkboxes or similar selection controls, enabling batch operations (such as attach to scope or create new scope) to be performed on all selected items in a single action. The system supports up to 100 items per bulk selection.

bulk-propagation admin action

An administrative operation that applies template changes (specifically recommended_analyses updates) to multiple existing requirements in a single transaction, typically performed by system administrators when a template's analysis recommendations are updated and need to be synchronized across all requirements using that template.

business hours

The designated time periods during which the e-commerce platform is expected to provide full service availability for order placement and tracking, typically defined as specific hours in a specific timezone (e.g., 06:00-23:00 UTC). Business hours may vary by region or be defined as 24/7 for global e-commerce operations.

C

caller context

The set of authentication and authorization metadata associated with an API request or user action, including the authenticated user identity, authentication method (UI session, builder token, AI system credentials), user role, organization membership, and permissions, used by the system to determine access rights and automatically populate audit fields.

canonical master

The authoritative, reference version of a data entity (such as a template) that serves as the source of truth for replication or inheritance across multiple instances. A canonical master defines the standard structure and content that derivative instances should follow, and changes to the canonical master may propagate to dependent instances according to system rules.

carried forward

The action of including a story from a previous scope (typically one that was deferred or not completed) into a new scope, allowing work to continue on the story in a subsequent delivery cycle. Carried forward stories may appear in multiple scopes over time, with each scope capturing the story at a different revision.

cascade deletion

A database referential integrity behavior where deleting a parent record automatically triggers deletion of all related child records in dependent tables. Cascade deletion is typically configured through foreign key constraints with ON DELETE CASCADE, ensuring that orphaned records are not left in the database when their parent entity is removed. This maintains referential integrity but carries data loss risk if not carefully managed.

category

A hierarchical classification scheme used to organize library materials by subject area, genre, or topic (e.g., Fiction > Science Fiction, Non-Fiction > History > Ancient History). Categories follow a controlled vocabulary or standard classification system (such as Dewey Decimal or Library of Congress) and allow members to browse related materials systematically.

checkout

The multi-step process where a user finalizes their purchase by providing delivery information, selecting payment method, reviewing order details, and submitting payment authorization. Checkout converts a shopping basket into a confirmed order and initiates fulfillment workflows.

circuit breaker

A design pattern that prevents cascading failures in distributed systems by detecting when a downstream service is failing and temporarily stopping requests to that service (opening the circuit). After a timeout, the circuit breaker allows test requests (half-open state) and closes the circuit if the service has recovered, restoring normal operation.

claude code conversation

An interactive dialogue session between a user and the Claude AI assistant within the Claude Code interface, used for collaborative design work. The conversation maintains context across multiple exchanges, allowing iterative refinement of design decisions through natural language discussion. In this system, Claude Code conversations serve as the primary interface for generating and refining design records.

client

The user-facing application or interface (such as a web browser, mobile app, or desktop application) that initiates requests to the server and presents information to the end user. The client runs on the user's device and communicates with the server over a network.

clock skew

The difference in time between two or more system clocks that should theoretically be synchronized. Clock skew can occur due to network latency, system time drift, or misconfigured time synchronization services (NTP). In distributed systems, clock skew can cause timestamps to appear out of order, with events appearing to occur before their actual time or in the future relative to other system components.

closable state

A scope status that indicates all required build phase activities have been completed and the scope is eligible for closure. A closable state typically requires that the build plan has been executed, acceptance criteria have been met, a build report has been generated, and no blocking issues remain open.

comprehensive

In the context of audit trails, capturing all relevant details necessary to reconstruct the complete state and history of a transaction or change, including who performed the action, when it occurred, what was changed (before and after values), why it was changed (if applicable), and the context in which it occurred.

computed hash

The hash value generated by applying the system's hashing algorithm to a provided plaintext token during authentication. The computed hash is created on-demand for each authentication request and compared against stored token_hash values to verify token authenticity. The computed hash is never stored and exists only in memory during the authentication process.

concurrent users

The number of authenticated users actively interacting with the system simultaneously within a defined time window (typically measured as users with active sessions performing transactions within a 1-minute interval). This differs from total logged-in users, as it counts only those actively generating system load through requests or operations.

conditional fields

Database entity attributes whose validity, requirement status, or allowed values depend on the state of other fields in the same record. In the context of backlog items, conditional field validation ensures that linked_requirement_id must be null when status is 'declined', and that declined_reason is required when status is 'declined'. Conditional field rules are enforced during create and update operations.

confidence

A numeric score (typically 0.0 to 1.0) assigned to an inbound disruption signal indicating the reliability or certainty of the event data, used to determine whether automatic correlation should proceed or the event should be routed to the Unmatched Queue for manual review. Confidence thresholds are configurable, and the score is stored with the normalized event to support explainable correlation decisions and audit trails.

configured token

An authentication credential (API key or bearer token) stored in the Dark Factory's configuration that grants the handover skill permission to access REQQA API endpoints. The token is obtained through REQQA's authentication mechanism and must be securely stored and rotated according to security policies.

confirmation dialog

A modal dialog or UI overlay that appears when an analyst initiates a promotion action, requiring explicit user confirmation before proceeding with the operation. The dialog typically displays a summary of the action to be performed, provides 'Confirm' and 'Cancel' buttons, and blocks interaction with the underlying page until the user makes a selection.

confirmation message

No definition yet.

conflict

No definition yet.

constraint violation

A database error condition that occurs when an INSERT or UPDATE operation attempts to violate a defined database constraint such as primary key uniqueness, foreign key referential integrity, NOT NULL requirements, CHECK constraints, or UNIQUE constraints. In the context of backlog migration, this typically refers to violations of the backlog_items table's constraints during bulk insert operations.

conversation context

The ephemeral state and history of an interactive session between a user (typically a developer) and the builder system, including messages exchanged, decisions made, and intermediate artifacts generated. Conversation context is maintained during active sessions but is not persisted as permanent records in REQQA.

cookies

Small text files stored by a web browser on the user's device, containing data sent by the web server. Cookies are used to maintain session state, store user preferences, and track user behavior. In this context, cookies are used to persist guest user baskets for a minimum of 24 hours, subject to browser settings and user privacy controls.

copy to clipboard

A user interface action that programmatically copies text or data to the operating system's clipboard memory, making it available for pasting into other applications or fields. Implemented using browser APIs (navigator.clipboard.writeText() or document.execCommand('copy')), this feature requires user interaction or permission in modern browsers for security reasons.

correlation

No definition yet.

create

The action of adding a new investment holding record to the user's portfolio by specifying all required attributes (asset identifier, quantity, acquisition date, cost basis). Creation establishes a new holding that did not previously exist in the system and immediately affects portfolio calculations.

cryptographically secure

A property of random number generation or cryptographic operations where the output is computationally infeasible to predict or reproduce without knowledge of the secret key or seed, meeting standards for cryptographic applications such as token generation, encryption, or digital signatures. Typically implemented using cryptographically secure pseudo-random number generators (CSPRNGs) that pass statistical randomness tests and resist cryptanalysis.

D

dark factory

A software development methodology or process framework that defines a structured workflow from specification through to acceptance, consisting of the phases: specify → scope → review → design → plan → build → accept. The term suggests an automated or lights-out approach to requirement processing and delivery.

dark factory lifecycle

The end-to-end process by which requirements are formally specified, handed over to an AI builder, reviewed, designed, planned, built, and accepted with full traceability. The lifecycle operates with minimal human intervention ('dark factory' metaphor from manufacturing), relying on structured handovers, automated quality gates, and versioned snapshots to ensure repeatable, auditable delivery from specification to working software.

decision

A discrete technical choice made during the design, review, planning, or build phase that addresses a specific aspect of system implementation. Each decision documents: (1) the decision made, (2) alternative options considered, (3) rationale for the chosen approach, (4) requirements affected, and (5) current status (proposed, accepted, rejected). Decisions are logged individually within a scope and require developer approval before being considered final.

declined

A terminal status for a backlog item indicating that the analyst has decided not to act on the item, with a documented reason for rejection. Declined items remain in the backlog for audit purposes but are excluded from active consideration. Once declined, the item cannot be reopened; if reconsideration is needed, a new backlog item must be created.

decline_note

A mandatory text field (maximum 2,000 characters) that captures the analyst's explanation for declining a backlog item, documenting the business rationale for not pursuing the proposed work. The note is required when transitioning an item to 'declined' status and becomes part of the permanent audit record, providing context for future reference and stakeholder communication.

default filtered list view

The backlog list view displayed when no explicit filter parameters are applied, configured to show only backlog items with status 'open', excluding items with terminal statuses ('promoted' or 'declined'). This is the primary view analysts use to identify pending work requiring triage decisions.

default value

A pre-populated value automatically inserted into a form field when the form is first displayed, derived from system logic, user context, or related data. Default values can be accepted as-is or modified by the user before submission. In the context of scope creation, the default scope name may be generated from patterns like 'New Scope [timestamp]' or derived from selected backlog item titles.

default values

Pre-populated or system-assigned values automatically applied to form fields when creating a new entity, based on business rules, user preferences, or system configuration. Default values reduce data entry effort and ensure consistency, but can be overridden by the user before submission.

deferred scope

A scope that was planned for delivery but postponed to a later time, typically due to resource constraints, priority changes, or dependencies on other work. Deferred scopes may have stories carried forward to new scopes, and the deferral decision is typically recorded in the scope's audit trail or status history.

deferred work

Work items, features, or requirements that were originally included in a scope's plan but were not completed during the build phase and have been postponed for future implementation. Deferred work is explicitly identified during build closure, documented with a reason for deferral, and converted into backlog items to ensure it is not lost. Deferral may occur due to time constraints, priority changes, technical blockers, or scope adjustments agreed with stakeholders.

delete

The action of removing an investment holding record from the user's active portfolio, making it no longer visible in current holdings or included in portfolio calculations. Deletion may be logical (marking as inactive while preserving historical data) or physical (permanent removal), depending on audit and tax reporting requirements.

delivered

An order status indicating that the package has been successfully handed over to the customer or an authorized recipient at the delivery address, or left in a secure location according to delivery instructions. This status is typically confirmed by carrier delivery confirmation (signature, photo, or GPS verification) and represents the terminal successful state of an order.

dependency

A priority classification for backlog items indicating that the item is required as a prerequisite for other planned work or represents technical infrastructure needed to support future features. Dependency items may not deliver direct user value but are necessary to unblock or enable other development efforts. This is the second-highest priority classification in the product backlog taxonomy.

derived requirements

Requirements that are generated or decomposed from user stories, representing the formal specification of functionality described in story format. The term suggests a bidirectional relationship where stories can produce requirements, complementing the more common pattern of requirements producing stories.

design decision

A discrete technical choice made during the design phase that addresses a specific aspect of the system implementation. Each design decision documents: (1) the decision made, (2) alternative options considered, (3) rationale for the chosen approach, and (4) current status (proposed, approved, rejected, superseded). Design decisions are logged individually within the design record and require developer approval before being considered final.

design record

A structured document capturing design decisions, architectural choices, implementation approach, and technical rationale for a scope. The design record includes individual design decisions with their context and alternatives considered, and serves as the authoritative design artifact for the scope, posted to REQQA via API for traceability and audit purposes.

detach

The action of removing the linkage between a backlog item and a scope by setting the backlog_items.scope_id field to null, indicating that the item is no longer planned for that scope's delivery. Detaching is only permitted while the scope is in draft status and does not change the backlog item's status.

developer

In the context of scope management, the user role responsible for creating and defining scopes, analyzing requirements, and preparing scopes for handover to builders. The developer (scope creator or organization member with appropriate permissions) has exclusive authority to transition scope status and revise scopes based on builder feedback. This role is distinct from software developers who write code.

discounts

Price reductions applied to products or orders based on promotional rules, coupon codes, customer loyalty status, or other business logic. Discounts may be percentage-based or fixed amounts, and can apply to individual items, categories, or entire orders. The system must track which discounts are applied and ensure they combine correctly according to business rules.

draft status

A scope state indicating that the scope definition is incomplete or under construction, typically occurring when a scope has been created but contains no stories. Draft status allows scopes to be saved and edited before they are ready for use in development planning or implementation, with a warning displayed to indicate incompleteness.

E

empty array

A JSON array with zero elements, represented as [], returned in API responses when a query matches no records. An empty array indicates successful query execution with no results, distinct from null (which indicates absence of data) or error responses.

error message

A user-facing notification displayed when an operation fails or encounters an invalid state, providing a clear explanation of what went wrong and actionable guidance for resolution. Error messages must be non-technical, specific to the failure context (e.g., 'Basket storage limit reached. Please remove items or proceed to checkout.'), and include an error code for support reference where applicable.

exponential backoff

A retry strategy where the wait time between retry attempts increases exponentially (e.g., 1s, 2s, 4s, 8s) to avoid overwhelming a failing service while giving it time to recover. Often combined with jitter (random variation) to prevent synchronized retry storms from multiple clients.

F

feeder

A source system or data repository that provides input to another system without replacing its functionality. In this context, the backlog serves as a feeder to project management tools by supplying prioritized work items that can be imported, synchronized, or referenced, while the project management tool retains responsibility for sprint planning, team assignment, and execution tracking.

field-level detail

Error response information that identifies which specific input fields failed validation and provides a descriptive error message for each field, enabling API clients to present targeted error feedback to users. Field-level detail typically includes the field name, the invalid value provided, and a human-readable explanation of why the value was rejected.

filtered list view

A display mode of the backlog list that shows only items matching specified filter criteria, such as status (open, promoted, declined), priority level, or source. The filtered view dynamically updates to exclude items that no longer match the active filter criteria, providing analysts with a focused view of relevant backlog items.

final housekeeping

The last set of administrative and cleanup tasks performed after a scope transitions to 'accepted' status, including: archiving artifacts, cleaning up temporary resources, finalizing audit logs, sending closure notifications, and updating project metrics. Final housekeeping ensures the scope is fully closed and all related data is properly stored or disposed of according to retention policies.

fk

Foreign Key - a database constraint that establishes a relationship between two tables by requiring that values in one table's column must exist in another table's primary key column, enforcing referential integrity and preventing orphaned records.

flash message

A temporary notification message displayed to users on the next page load, typically stored in session state and automatically cleared after being shown once. Flash messages are commonly used to communicate the result of an action (success, error, warning) across HTTP redirects, such as displaying 'Session expired. Please log in again.' after redirecting to the login page.

foreign key constraints

Database integrity rules that enforce referential relationships between tables by requiring that values in a foreign key column must exist in the referenced table's primary key column. Foreign key constraints prevent orphaned records and maintain data consistency by rejecting operations that would violate the relationship (e.g., inserting a record with a non-existent parent ID) or by cascading changes (deletes/updates) to dependent records.

form-level error

An error message displayed at the top or bottom of a form (rather than adjacent to a specific field) that indicates a validation failure affecting the entire form submission or multiple fields. Form-level errors typically appear in a distinct visual container (error banner or alert box) and remain visible until the user corrects the issue and resubmits the form.

fully in scope

A status indicating that all stories derived from a particular requirement have been included in the scope. When a requirement is fully in scope, every story linked to that requirement appears in the scope's story collection, providing complete coverage of the requirement's functionality within the scope definition.

G

gate check

A validation checkpoint executed during a scope status transition that evaluates whether specific preconditions are satisfied before allowing the transition to proceed. Gate checks enforce business rules (such as ensuring all attached backlog items are triaged) and reject transitions that fail validation, returning the scope to its previous state with an explanatory error message.

gherkin content

The structured text content of a user story written in Gherkin syntax, a business-readable domain-specific language used for behavior-driven development (BDD). Gherkin content consists of scenarios with Given-When-Then steps that describe system behavior in a format that can be understood by both business stakeholders and automated testing tools.

given/when/then

A structured format for writing user story acceptance criteria or scenarios, where 'Given' establishes preconditions or context, 'When' describes the action or event, and 'Then' specifies the expected outcome or result. This format is part of Behavior-Driven Development (BDD) and Gherkin syntax, enabling clear, testable specifications.

gold template

A canonical, authoritative template record that serves as the master reference for a particular requirement type across all organizations in the system. Gold templates define the standard structure, recommended analyses, and metadata that should be replicated when organizations create their own template instances. In the current system, the REQQA org's template set (orgid = 1) serves as the de-facto Gold template collection.

gptlog

A logging and accounting subsystem within REQQA that records all calls made to OpenAI's API, capturing request parameters, response data, token consumption (prompt tokens, completion tokens, total tokens), timestamps, costs, and call outcomes. The gptlog provides an audit trail of AI interactions, enables token usage monitoring and cost tracking, and supports debugging of analysis quality issues by preserving the full context of each AI invocation.

H

handover

The formal transfer of a scope from the specification phase (REQQA) to the build phase (Claude Code builder), occurring when a scope transitions to 'handover_ready' status. The handover includes the as-scoped snapshot of all included stories and requirements, establishing the baseline against which the builder will work and creating an auditable record of what was specified at the point of transfer.

handover_ready

A scope status indicating that the developer has completed initial scoping work and the scope is ready to be handed over to builders for review and implementation planning. At this transition, an as-scoped JSON snapshot is captured to preserve the scope definition at handover. This status represents the completion of the 'scope' phase in the Dark Factory process.

hash collision

An event where two different input values produce the same hash output when processed by a hash function. For cryptographic hash functions like SHA-256, collisions are computationally infeasible to find intentionally, but the possibility exists due to the pigeonhole principle (infinite possible inputs mapping to finite hash space). Collision resistance is a key security property of cryptographic hash functions.

hashed comparison

A secure authentication technique where a provided plaintext credential is hashed using the same algorithm used for storage, and the computed hash is compared against the stored hash value to verify authenticity. This approach ensures that plaintext credentials are never stored in the database and cannot be recovered even if the database is compromised. The comparison is performed using constant-time comparison functions to prevent timing attacks.

highlighted

A visual emphasis applied to a UI element to draw user attention, typically implemented through distinctive background color, border styling, icon, or text formatting that differentiates the element from surrounding content. In the context of backlog items, highlighting indicates items requiring user action or attention.

holding

A record representing a specific quantity of a financial asset owned by a user in their investment portfolio, including the asset identifier, quantity held, acquisition date, and cost basis per unit. Holdings are the fundamental unit of portfolio composition and are used to calculate total portfolio value, performance metrics, and tax implications.

I

i18n

Internationalization (abbreviated as i18n, where 18 represents the number of letters between 'i' and 'n') - the process of designing software to support multiple languages, locales, and cultural conventions without requiring code changes. i18n includes support for translated text, date/time formats, number formats, currency, and text direction.

idempotency

A property of an operation where executing it multiple times with the same input produces the same result as executing it once, with no additional side effects. In the context of basket operations, idempotency ensures that duplicate API requests (e.g., due to network retries) do not create duplicate basket items or apply duplicate discounts. Implemented using idempotency keys or request deduplication mechanisms.

idempotency key

A unique identifier used to ensure that duplicate requests or events do not result in duplicate processing or side effects. In the context of notifications, it is computed from Case ID, channel, and template to prevent sending the same notification multiple times.

idempotency-key header

An HTTP request header field that contains a unique client-generated identifier used to ensure idempotent processing of API requests. When the same Idempotency-Key is provided with identical request body content, the API returns the cached response from the original request without creating duplicate resources. If the same key is reused with different request content, the API returns a 409 Conflict error. The header enables safe retry of failed requests without risk of duplicate operations.

immutable

A data attribute or record that cannot be modified after creation. Immutable fields are write-once, ensuring data integrity and supporting audit requirements by preventing tampering with historical records. Attempts to update immutable fields should be rejected by the system with an error.

immutable fields

Database entity attributes that cannot be modified after the record is created, ensuring data integrity and supporting audit requirements by preventing tampering with historical records. In the context of backlog items, immutable fields include source, orgid, and appid. Attempts to update immutable fields are rejected with a 422 status code.

inactivity

A period during which no basket-related events occur for a registered user, measured as the absence of basket view, item add, item remove, quantity modification, or checkout initiation events. Used to determine when a basket transitions to 'abandoned' status after 30 days. Does not include non-basket activities such as browsing products or account management.

indexed

A database optimization where a separate data structure is created to enable fast lookup of records based on the indexed column's values. Indexed columns support efficient WHERE clause filtering, JOIN operations, and sorting, reducing query execution time from linear scans to logarithmic lookups. Indexes incur storage overhead and slow down write operations.

indicator

A UI element that displays status, state, or metadata information to users, typically through visual cues such as icons, colors, text labels, or symbols. In the context of backlog items, a source indicator would show whether the item originated from an analyst, builder, or AI system.

inline actions

Action buttons or links displayed directly within a list item row, allowing users to perform operations on that specific item without navigating away from the list view. Inline actions provide quick access to common operations (view, edit, delete, triage) and are typically represented as buttons, icon buttons, or dropdown menus positioned at the end of each row. The availability of inline actions may vary based on item state, user permissions, or business rules.

inline error

A validation error message displayed directly adjacent to or below the form field that failed validation, providing immediate contextual feedback to the user without requiring navigation to a separate error summary. Inline errors appear in real-time (on blur or submit) and remain visible until the field is corrected.

invest

An acronym representing six quality criteria for well-formed user stories: Independent (can be developed separately), Negotiable (details can be discussed), Valuable (delivers user/business value), Estimable (size can be estimated), Small (fits within an iteration), and Testable (can be verified). INVEST is an industry-standard framework for evaluating story quality.

in_review

A scope status in REQQA indicating that the Dark Factory builder's review has been completed and feedback issues have been posted, awaiting analyst resolution before the scope can proceed to design. This status prevents duplicate handover attempts and signals that the scope is in a feedback-remediation cycle.

issue detection pipeline

The sequence of processing stages within the analysis engine that identifies, classifies, and records requirement quality issues. The pipeline includes: (1) AI-based analysis of requirement text against step-specific criteria, (2) parsing of AI responses to extract issue records, (3) application of severity and confidence scoring models, (4) deduplication and consolidation of similar issues, (5) validation of issue structure and content, and (6) persistence to the analysis_issues table. The pipeline ensures consistent issue detection and recording across all analysis types.

item count

The total number of items in a basket, calculated as the sum of BasketItem.quantity for all items in the basket. Item count is displayed in the basket badge, used for capacity validation (maximum 9,999 per BR-08), and included in basket summary displays. Distinct from product count (number of unique products).

K

kickoff ui

The user interface component or page where an analyst initiates an analysis run by selecting which requirements or artifacts to analyze, choosing which analysis steps to execute (via checkboxes or similar controls), and configuring analysis parameters. The kickoff UI is the entry point for triggering the analysis workflow and consumes recommended-analyses metadata to pre-select applicable analysis checkboxes.

L

last write wins

A conflict resolution strategy for concurrent modifications where the most recent update (based on timestamp) overwrites any previous changes, without attempting to merge or reconcile conflicting edits. In the context of basket management, when the same basket is modified simultaneously from multiple sessions or devices, the last modification to be committed to the database becomes the authoritative state, and earlier modifications are discarded.

lifecycle transitions

The valid state changes that a scope can undergo as it progresses through its workflow, defined as a state machine with permitted transitions between status values. Invalid transitions are rejected with a 400 error listing the valid next states from the current state. The lifecycle ensures scopes follow a controlled progression through analysis, planning, implementation, and completion phases.

linked to scope

The state where a backlog item has an active association with a scope, represented by a non-null scope_id foreign key reference in the backlog_items table. A linked item appears in the scope's backlog item collection and is considered part of the scope's planned work, though it remains in 'open' status until triaged. The link can be removed (detached) while the scope is in draft status.

linked_requirement

A foreign key field on a backlog item that references the requirement to which the item has been promoted, establishing a formal relationship between the backlog item and the requirement it has been incorporated into. This field is populated when a backlog item transitions to 'promoted' status and enables traceability from backlog items to their corresponding requirements in the formal requirements model.

logged

Recorded in a persistent audit trail or transaction history for compliance, security monitoring, or troubleshooting purposes. In the context of payment transactions, this refers to capturing transaction details, timestamps, and associated metadata in a traceable format. For access control, it refers to recording all attempts to access sensitive member data, creating an audit trail that documents who accessed what information and when.

M

markdown backlog file

A text file in Markdown format stored in the analyst repository following the naming convention 'Backlog_vN.md' (where N is a version number) within a review-dated directory structure 'documentation/reviews/YYYYMMDD-Review/'. Each file contains backlog items structured as level-2 headings with priority tags in square brackets (e.g., '## [MVP] Item title') followed by multiline description text. These files represent the legacy storage format for backlog items prior to the introduction of the backlog_items database table.

metadata

A section of an API response containing supplementary information about the result set rather than the data itself, including pagination details (page, page_size, total_count, total_pages), query parameters applied, and response generation timestamp. Metadata is typically returned in a separate JSON object alongside the data array.

microsecond precision

A timestamp format that includes time measurement down to one millionth of a second (microseconds), typically represented as YYYY-MM-DD HH:MM:SS.mmmmmm in databases. Microsecond precision enables accurate ordering of events that occur in rapid succession and supports high-resolution audit trails for systems processing multiple transactions per second.

migration report

A structured summary document generated by the migration script upon completion (successful or failed) that contains execution metrics including files_processed count, items_created count, duplicates_skipped count, validation_errors count, execution_time_ms, and detailed listings of any duplicate items skipped or validation errors encountered. The report format (JSON, text, log file) and delivery mechanism (console output, file, database record) are implementation-specific.

migration script

A one-time executable program or database script that reads legacy markdown backlog files from the analyst repository, parses their content, validates the extracted data, and inserts backlog items into the backlog_items database table while enforcing transactional semantics and duplicate detection rules. The script is invoked manually by a system administrator with specified application_id and organisation_id parameters, and produces a migration report summarizing execution results.

mission

The overarching purpose and strategic objective of the disruption operations platform: to detect journey irregularities in near real time, orchestrate passenger communications, and execute policy-compliant re-accommodation and compensation workflows with full auditability. It defines the system's core value proposition of translating carrier policies and consumer-rights regimes into deterministic, explainable outcomes for affected passengers.

modal

A modal window or dialog box - a UI overlay that appears on top of the main application content, requiring user interaction before they can return to the underlying page. Modals typically dim or disable the background content, focus user attention on a specific task or message, and are dismissed through explicit user action (clicking a button, pressing ESC, or clicking outside the modal area).

modal dialog

A UI overlay window that appears on top of the main application content, requiring user interaction before they can return to the underlying page. Modal dialogs block interaction with the rest of the application until the user makes a choice or dismisses the dialog, ensuring critical decisions are not overlooked.

mutable fields

Database entity attributes that can be modified after the record is created, as opposed to immutable fields which are write-once. In the context of backlog items, mutable fields include title, description, priority, and scope_id, which can be updated while the item is in open status.

mvp

Minimum Viable Product - a priority classification for backlog items indicating that the item represents core functionality required for the initial product release. MVP items are essential features that must be delivered to meet the minimum threshold for product viability and user value. This is the highest priority classification in the product backlog taxonomy.

N

negotiation round

A structured exchange cycle in the builder feedback workflow where: Round 1 consists of the builder posting a batch of feedback issues and the analyst resolving or rejecting each issue; Round 2 allows the builder one follow-up response to unclear rejections. After two rounds, the analyst's decision is final, and unresolved disagreements are moved to Accepted status with a risk-acknowledgement comment.

nice-to-have

A priority classification for backlog items indicating that the item represents optional functionality that would be pleasant to have but provides minimal business value or user impact. Nice-to-have items are the lowest priority and are typically implemented only if time and resources permit after higher-priority work is complete. This is the lowest priority classification in the product backlog taxonomy.

no-op updates

Update requests that specify field values identical to the current stored values, resulting in no actual data modification. No-op updates are rejected with a 422 status code and 'No changes detected' error message to prevent unnecessary database writes, audit log entries, and timestamp updates when no meaningful change has occurred.

O

oauth2

An authorization framework (RFC 6749) that enables applications to obtain limited access to user accounts or API resources without exposing credentials. OAuth2 uses access tokens with defined scopes and expiration times, supporting various grant types for different use cases (authorization code, client credentials, etc.).

optimistic locking

A concurrency control strategy that assumes conflicts are rare and allows multiple transactions to proceed without locking resources. Before committing a write operation, the system checks whether the data has been modified by another transaction since it was read (typically by comparing a version number or timestamp). If a conflict is detected, the transaction is rolled back and the user is prompted to retry with the latest data.

order status

The current state of an order in its fulfillment lifecycle, represented as a discrete value from a defined set of possible states (e.g., confirmed, processing, dispatched, out for delivery, delivered, cancelled, returned). Each status represents a milestone in order processing, has defined entry/exit conditions, determines which operations are permitted, and triggers specific customer notifications. Status transitions follow a defined state machine with validation rules.

order status

No definition yet.

organization context

The set of organization-specific metadata (primarily orgid) loaded from an authenticated API token that determines the scope of data access for the current request. The organization context is derived exclusively from the token's stored orgid value and is automatically applied as a filter to all database queries, ensuring tenant isolation. The organization context cannot be overridden by request parameters and remains constant for the duration of the request.

orgid

Organisation Identifier - a unique identifier assigned to each organisation (tenant) in the REQQA system, used to scope database queries and enforce tenant isolation. The orgid is derived from the authenticated user's token and is automatically applied as a filter to all API queries to ensure users can only access data belonging to their organisation.

overselling

The condition where the system accepts and confirms orders for a quantity of product that exceeds available physical inventory, resulting in an inability to fulfill all confirmed orders. Overselling occurs when inventory tracking fails to account for concurrent order placement, basket reservations are not enforced, or stock quantities are not decremented atomically with order confirmation. Preventing overselling requires real-time stock reservation, transactional inventory updates, and enforcement of stock availability checks before order confirmation.

P

page

A query parameter specifying which page of results to return in a paginated API response, using 1-based indexing where page=1 returns the first set of results. Used in conjunction with 'page_size' to calculate the offset into the result set (offset = (page - 1) * page_size).

page_size

A query parameter specifying the maximum number of records to return in a single API response page. Valid values range from 1 to a system-defined maximum (typically 100), with a default value (typically 50) applied when not specified. Used in conjunction with 'page' parameter to implement pagination.

pagination

A technique for dividing large result sets into smaller, manageable pages that can be retrieved incrementally through sequential API requests. Pagination is implemented using limit (maximum number of records per page) and offset (number of records to skip) query parameters, allowing clients to retrieve data in chunks and improving API performance and user experience when dealing with large datasets.

pagination controls

UI elements that enable users to navigate between pages of a paginated result set, typically including buttons or links for next/previous page, first/last page, direct page number selection, and display of current page position. Pagination controls provide the interface for interacting with paginated data.

panel

A distinct section or container within a web page user interface that groups related information or functionality, typically with a visible border, heading, and consistent styling. Panels organize content into logical units and may be collapsible, scrollable, or fixed depending on design requirements.

partially in scope

A status indicating that only some stories derived from a particular requirement have been included in the scope, while others have been excluded. A partially in-scope requirement provides incomplete coverage of the requirement's functionality within the scope definition, signaling that selective story inclusion has occurred.

payment gateway

A third-party service that processes payment transactions by securely transmitting payment information between the merchant, customer's bank, and payment networks. The gateway validates payment credentials, authorizes transactions, and returns success/failure responses with transaction identifiers. Examples include Stripe, PayPal, Authorize.Net.

pci dss

Payment Card Industry Data Security Standard - a set of security requirements designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. PCI DSS prohibits storing sensitive authentication data (e.g., full magnetic stripe, CVV2, PIN) after authorization and requires encryption, access controls, and regular security testing.

phase closure protocol

A standardized sequence of housekeeping and finalization steps executed when closing any project phase, including: validating all phase exit criteria are met, archiving phase artifacts, updating project status and metrics, notifying stakeholders, releasing resources, and transitioning to the next phase or terminal state. The protocol ensures consistent and complete phase closure across all project types and phases.

pinned

The action of creating an immutable reference to a specific revision of a story at the time it is added to a scope. A pinned story maintains its association with that exact revision number, ensuring that subsequent modifications to the story do not automatically update the scope's definition. The scope continues to reference the original revision unless explicitly updated.

plain text

Unformatted text content stored and displayed exactly as entered, without interpretation or rendering of markup languages (HTML, Markdown, BBCode, etc.). Plain text preserves special characters and formatting syntax as literal characters rather than converting them to styled output, ensuring that user input is stored safely without risk of code injection and displayed predictably without formatting transformations.

plaintext

The original, unhashed, human-readable form of the API token as generated by the system, displayed to the user only once at creation time before being irreversibly hashed for storage. The plaintext token is the actual credential that must be included in API requests and cannot be recovered from the stored hash.

plaintext token

The original, unhashed, human-readable form of an API token as generated by the system and provided to the user. The plaintext token is the actual credential that must be included in API requests (in the Authorization header) and is hashed before storage in the database. It is displayed to the user only once at creation time and cannot be recovered from the stored hash.

platform skills

Claude Code skills that interact with a specific development platform or technology stack (e.g., /pydal-migrate for database migrations, /py4web-shell for framework console access). Platform skills are environment-specific, operate on local development resources, and are defined by the customer or development team rather than being part of REQQA's core skill set.

pre-handover gate

A validation checkpoint that must be satisfied before a scope can transition from draft to handover_ready status, enforcing business rules and quality criteria. In the context of backlog item attachment, the pre-handover gate checks that all attached backlog items have been triaged (promoted to requirements or detached), blocking the transition if any attached items remain in open status.

process skills

Platform-agnostic Claude Code skills that implement lifecycle stages by interacting with REQQA's API rather than with local development environments. Process skills (such as /handover, /design, /submit-plan) are provided by REQQA and work consistently across different technology stacks, focusing on workflow automation and artifact management rather than code generation or platform-specific operations.

profile page

A dedicated user interface within the library system where members can view and modify their personal information, including contact details, communication preferences, and account settings, accessible after authentication.

promoted

A terminal status for a backlog item indicating that the analyst has decided to act on the item by linking it to a formal requirement or incorporating it into a release scope. Promotion represents acceptance of the backlog item's value and commitment to address it in the requirements model. Once promoted, the item cannot be reopened or modified.

provenance

No definition yet.

Q

quality gate

A set of criteria or checks that must be satisfied before a scope can transition from one lifecycle state to another. Quality gates may include validation of completeness (all required fields populated), consistency (no unresolved blocker issues), or compliance (all stories have acceptance criteria). In v1, quality gates are advisory only, providing warnings but not preventing transitions.

R

rate limit

A restriction on the number of API requests a client can make within a specified time window (e.g., requests per minute or per hour), enforced to prevent abuse, ensure fair resource allocation, and protect system stability. When exceeded, the API returns HTTP 429 Too Many Requests with a Retry-After header indicating when the client can resume requests.

rate limiting

A throttling mechanism that restricts the number of API requests a client can make within a specified time window (e.g., 100 requests per minute, 1000 requests per hour) to prevent abuse, ensure fair resource allocation, and protect system stability. Rate limits may be enforced per API token, per user, or per organisation, and exceeded limits result in HTTP 429 Too Many Requests responses with headers indicating when the client can retry.

rbac

Role-Based Access Control - a security model that restricts system access based on a user's role within an organization. Users are assigned roles (e.g., agent, supervisor, auditor), and each role has defined permissions for specific operations or data. RBAC simplifies permission management and supports separation of duties.

read-only access

A restricted permission level that allows a user to view resources within an organisation and application but prevents them from creating, modifying, or deleting those resources. Users with read-only access can view backlog items, requirements, and other artifacts but cannot perform triage operations or make changes to the system state.

real-time

A system response characteristic where inventory updates, availability status changes, and stock level modifications are reflected across all system components and user-facing interfaces within milliseconds to low seconds of the triggering event, without perceptible delay from the user's perspective. In the context of inventory management, real-time means that stock decrements from order confirmation, stock reservations from basket additions, and availability status updates are immediately visible to all concurrent users and system processes, preventing race conditions and ensuring data consistency.

recommended-analyses metadata

A structured field stored on each requirement entity that contains a list of analysis step codes (e.g., R-D, R-F, R-C) indicating which analyses are most applicable to that requirement based on its format, content type, or domain. This metadata is used to pre-populate analysis selection checkboxes in the kickoff UI, providing guidance to operators while remaining advisory rather than prescriptive.

reject

To refuse or decline a requested operation, transaction, or state change due to validation failure, business rule violation, or system constraint. The system returns an error code and message explaining the reason for refusal, logs the attempt to the audit trail, and leaves the entity's state unchanged.

relative time

A human-readable time format that expresses elapsed duration from a reference point (typically 'now') using natural language units such as 'just now', 'X minutes ago', 'X hours ago', 'X days ago', 'X weeks ago', 'X months ago', or 'X years ago'. Relative time provides intuitive temporal context without requiring users to calculate elapsed time from absolute timestamps.

release scope

A scope that represents a planned release or delivery increment, containing a collection of requirements, stories, and optionally backlog items that will be implemented together. Release scopes can be created by attaching backlog items to an existing scope or by combining multiple backlog items to form a new scope. Release scopes follow the standard scope lifecycle defined in FR-13.

requirement grouping

A user interface organization pattern in the story selector where stories are visually grouped and labeled by their parent requirement, allowing users to see which stories belong to which requirement and facilitating bulk selection of all stories from a single requirement.

requirement template

A reusable structural pattern that defines the format, sections, and default metadata for creating requirements of a specific type (e.g., 29148-full, user story, technical specification). Each template specifies which analyser steps are recommended by default for requirements created from it, and serves as a blueprint ensuring consistency in requirement structure across the organization.

requirements picker

A user interface component (typically a modal dialog, dropdown, or searchable list) that allows analysts to browse, search, and select an existing requirement from the current application when promoting a backlog item. The picker displays requirement reference, title, and status, supports text search by reference or title, implements pagination for large result sets, and filters to show only requirements in active or draft status within the current application context.

requirements_affected

A comma-separated list of requirement identifiers (requirement refs) that are impacted by or related to a design decision. This field documents which requirements' implementation approach is influenced by the decision, enabling traceability between design choices and functional specifications. The format and validation rules for requirement refs should align with the requirement identification scheme used in REQQA.

response body

The main content payload of an HTTP response, typically containing JSON-formatted data, error messages, or other structured information. The response body is distinct from HTTP headers and status codes, and its structure varies based on the endpoint and response status.

retention period

The duration for which a basket is preserved in the system before being eligible for automatic deletion, measured from the last_modified_at timestamp. Retention periods vary by user type: 72 hours for guest baskets (from last modification), 90 days for registered user baskets (from last modification), and 30 days for abandoned baskets (from abandonment detection). After the retention period expires, baskets are marked for purge and deleted by the scheduled purge process.

retro-placeholder

A requirement record origin classification (origin='retro-placeholder') indicating that the requirement serves as an anchor point for existing functionality that has not yet been formally documented to current standards. Retro-placeholder requirements have intentionally thin bodies and are excluded from default analyses, reports, and exports until they are retrofitted with complete documentation. They enable tracking of known-existing features awaiting formal specification.

retro-placeholder requirements

Requirements created retrospectively to document functionality that was already implemented without formal specification, serving as placeholders in the requirements model to maintain traceability and completeness. These requirements typically have minimal content, reference existing implementation artifacts, and are marked to indicate their retrospective nature. They are generally excluded from quality analysis runs since they document past decisions rather than specify future work.

retrofit

The process of creating or updating formal requirement documentation for existing functionality that was previously implemented without complete specification. Retrofitting involves analyzing the implemented system, extracting its behavior and rules, and documenting them as properly structured requirements that meet current documentation standards. Retrofitted requirements replace retro-placeholder records and enable full analysis coverage.

retry logic

An automated error-handling mechanism that re-attempts failed email delivery operations after temporary failures (such as network timeouts, rate limiting, or recipient server unavailability). Retry logic includes configurable parameters for maximum retry attempts, backoff intervals between attempts (e.g., exponential backoff), and criteria for distinguishing temporary failures (retryable) from permanent failures (non-retryable).

retry policy

A set of rules governing how the analysis engine handles transient failures when calling the OpenAI API, including: maximum number of retry attempts, backoff strategy (linear, exponential, or exponential with jitter), conditions that trigger retries (network timeouts, rate limits, server errors), conditions that abort retries (authentication failures, invalid requests), and timeout thresholds. The retry policy balances reliability (completing analyses despite transient failures) against resource consumption and latency.

retry-after header

An HTTP response header (defined in RFC 7231) that indicates how long the client should wait before making a follow-up request, typically returned with 429 Too Many Requests or 503 Service Unavailable responses. The value can be expressed as either a number of seconds (integer) or an HTTP-date timestamp, informing clients when rate limits will reset or when a temporarily unavailable service is expected to recover.

revision number

A sequential integer identifier assigned to each version of a story, incrementing with each modification. The revision number enables point-in-time references to specific versions of a story, allowing scopes to pin to a particular revision at the time of inclusion, ensuring that subsequent story changes do not automatically affect the scope's definition.

risk-acknowledgement comment

A mandatory comment added by the analyst when moving an unresolved builder feedback issue to Accepted status after the negotiation period expires. The comment documents that the analyst acknowledges the builder's concern as a valid risk but has decided to proceed with implementation despite the unresolved disagreement, accepting the identified risk.

risks

Potential problems identified during builder's review that could cause implementation difficulties, quality issues, or project delays if not addressed, but do not completely prevent progress. Risks are advisory findings that should be considered by analysts and may be accepted, mitigated, or resolved before proceeding to design.

rq workers

Background worker processes based on the Python RQ (Redis Queue) library that execute asynchronous analysis jobs from a Redis-backed job queue. RQ workers run as systemd services (defospam-worker@*.service) and process analysis tasks independently of the main web application, enabling concurrent analysis execution, improved responsiveness, and horizontal scaling. Each worker polls the job queue, executes assigned analysis tasks, updates progress, and handles failures according to configured retry policies.

rubrics

Structured evaluation criteria and scoring guidelines used by analysers to assess requirements or stories against quality standards. Rubrics define what to check, how to score findings, and what constitutes pass/fail conditions for each analysis type. In the context of FR-18.3.3, template-heading-specific rubrics would provide tailored evaluation criteria based on the requirement template section being analyzed.

S

sca

Strong Customer Authentication - a security requirement under PSD2 that mandates two-factor authentication for electronic payments using at least two of three elements: something the customer knows (password/PIN), something the customer has (phone/token), or something the customer is (biometric). SCA aims to reduce payment fraud while maintaining user experience.

scope

A named collection of user stories and their derived requirements that form a cohesive unit of work for development purposes. A scope belongs to exactly one application and serves as the bridge between specification (REQQA) and implementation (Claude Code), capturing what will be built in a particular development effort along with constraints and exclusions.

scope closure

The formal completion phase of a defined scope where all planned work items have been delivered, reviewed, and accepted. During scope closure, any identified out-of-scope work, technical debt, or deferred items are captured as backlog items for future consideration. Scope closure triggers the generation of backlog items from build-phase outputs and marks the scope as complete in the system.

scope form

A user interface component (modal dialog, page, or panel) that collects scope metadata during scope creation, including required fields (scope name) and optional fields (scope description). The form validates input, displays pre-filled values derived from selected backlog items, and provides save/cancel actions. The form is presented after the 'Create Scope from Selection' action is invoked and dismissed upon successful save or explicit cancellation.

scope package

A collection of related requirements, acceptance criteria, business rules, and supporting documentation that defines a discrete unit of work to be implemented. Scope packages are fetched by external tools (such as Claude Code) via the API to understand what needs to be built, and may include metadata such as priority, dependencies, and current status. The package format and structure are defined by the Scope Management feature (FR-13).

scope picker

A user interface component (typically a dropdown, modal dialog, or searchable list) that allows the analyst to select an existing scope from the current application when attaching backlog items. The scope picker displays only scopes in draft or handover_ready status and provides search/filter capabilities to help locate the target scope.

scope reference

An identifier used to locate a specific scope in REQQA, which may be either a scope ID (unique numeric or alphanumeric identifier) or a scope name (human-readable string). Scope references are provided as parameters to slash commands to specify which scope the command should operate on.

scope-id

A unique identifier for a scope in REQQA, used as a parameter to the /handover skill to specify which scope should be fetched and reviewed. The identifier format, uniqueness guarantees, and validation rules are defined by the REQQA API specification.

serializable isolation level

The highest transaction isolation level in SQL databases that ensures complete isolation between concurrent transactions by preventing dirty reads, non-repeatable reads, and phantom reads. SERIALIZABLE transactions execute as if they were run sequentially, one after another, preventing any concurrent modifications to data being read or written. This level provides the strongest consistency guarantees but may impact performance due to increased locking and potential for transaction conflicts.

session

A server-side or client-side state management mechanism that maintains user authentication and context across multiple HTTP requests. A session is created upon successful login, identified by a session token (typically stored in a cookie or local storage), and expires after a defined period of inactivity or when explicitly terminated by logout. The session stores the authenticated user's identity and may cache user preferences to avoid repeated database queries.

sessions

A period of continuous interaction between a user and the system, typically bounded by login/logout events for authenticated users or by browser session lifecycle for guest users. Sessions maintain user state and context across multiple requests, and may expire after a period of inactivity or when explicitly terminated.

severity

No definition yet.

sha-256

Secure Hash Algorithm 256-bit - a cryptographic hash function that produces a fixed 256-bit (32-byte) hash value from input data of any size. SHA-256 is part of the SHA-2 family, designed by the NSA, and is widely used for data integrity verification, password hashing, and digital signatures. The algorithm is deterministic (same input always produces same output) and computationally infeasible to reverse or find collisions.

skill

A reusable, configurable capability in Claude Code that encapsulates a specific workflow or operation, invoked via slash commands and defined in .claude/commands/*.md files. Skills can be process skills (platform-agnostic, interacting with external APIs) or platform skills (specific to a development environment).

slash command

A command-line style instruction prefixed with a forward slash (/) that triggers specific functionality within Claude Code's conversational interface, enabling programmatic actions such as API calls, file operations, or workflow automation without leaving the conversation context.

soft-close

A scope closure operation that marks the scope as closed without physically deleting the scope record or its associated data from the database. Soft-closed scopes remain in the system for audit and historical reference but are excluded from active scope lists and cannot be reopened or modified. This preserves traceability while indicating the scope is no longer active.

source

A classification attribute on issues indicating the origin or context in which the issue was identified, with valid values including 'builder_review' (identified during automated analysis) and 'build_phase' (identified during implementation). The source is specified by the API caller during issue creation and is used for reporting and filtering.

step-code taxonomy

A classification system for requirement analysis steps using alphanumeric codes (e.g., R-D for Definitions, R-F for Functional completeness, R-C for Consistency) that categorizes different types of analysis performed by the REQQA analysis engine. Each step-code represents a distinct analysis dimension with specific evaluation criteria, AI prompts, and issue detection rules. The taxonomy defines the complete set of analysis types the system can perform and governs the structure of analysis results.

step-codes

Short alphanumeric identifiers (such as R-D, R-F, R-C, S-A) that uniquely identify specific analysis types within REQQA. Step-codes are used to reference analysers in metadata, UI selections, and database records, providing a compact notation for analysis types. The 'R-' prefix typically denotes requirement analyses, while 'S-' denotes story analyses.

stock

The total quantity of a product SKU physically present in the warehouse or fulfillment center, including units that are available for sale, reserved for baskets, committed to confirmed orders, and held as safety stock. Stock is the gross inventory count before any allocations or reservations are subtracted.

story

A user story or functional specification unit that describes a discrete piece of functionality from an end-user perspective. Stories are derived from requirements, can be versioned through revisions, and represent the atomic units of work that can be included in or excluded from a scope. Each story belongs to a parent requirement and can appear in multiple scopes simultaneously.

story analyser

A software component or module within REQQA that evaluates user stories against quality criteria, applying specific rubrics to assess completeness, clarity, testability, and adherence to story-writing standards such as INVEST principles and Given/When/Then format.

story-staleness

A state indicator for user stories that have not been updated or reviewed within a defined time period, or whose parent requirement has been modified since the story was last generated, suggesting the story may no longer accurately reflect current requirements and may need regeneration or review.

structured outputs

Data produced by slash commands in a defined format (such as JSON, YAML, or a specific document schema) that can be programmatically parsed, validated, and posted to REQQA's API. Structured outputs ensure consistency, enable automation, and support audit trails by providing machine-readable artifacts of skill execution.

suggestions

Recommendations for improvement identified during builder's review that would enhance requirement quality, clarity, or testability but are not essential for proceeding to implementation. Suggestions are optional enhancements that analysts may choose to incorporate based on time, priority, and value considerations.

superseded

A status indicating that a design record or design decision has been replaced by a newer version and is no longer the current authoritative reference. Superseded records are retained for audit and history purposes but are not used for active development. When a new design version is created, the previous version's status automatically transitions to 'superseded'.

system administrator

A user role with elevated privileges responsible for performing system maintenance tasks including database migrations, configuration changes, and operational procedures that affect multiple organizations or the entire platform. System administrators have access to administrative tools and scripts not available to regular users or analysts, and their actions are logged for audit purposes.

T

template administrator

A user role with permissions to create, modify, and delete requirement templates within their organization, including the ability to configure template structure, default metadata, and recommended analyses. Template administrators manage the reusable patterns that other users employ when creating requirements, ensuring organizational consistency in requirement formats.

tenant isolation

A security mechanism that ensures users can only access data belonging to their own organisation (tenant), preventing cross-organisation data leakage. Implemented by automatically filtering all database queries with the authenticated user's orgid, validating that all referenced entities belong to the same organisation, and rejecting any attempt to access resources from a different tenant with a 403 Forbidden response.

terminal items

Backlog items that have reached a final, non-reversible status ('promoted' or 'declined') from which no further state transitions are permitted. Terminal items represent completed decision points in the backlog lifecycle and cannot be reopened or returned to 'open' status.

terminal state

An order status representing the final, completed state of an order lifecycle from which no further forward transitions are expected. Terminal states include: delivered (successful completion), cancelled (order voided before fulfillment), returned (order completed but product returned), and failed (fulfillment could not be completed). Orders in terminal states are excluded from 'current orders' and may be subject to different retention and archival policies.

timeline

No definition yet.

token accounting

The process of tracking and recording OpenAI API token consumption for each analysis operation, including prompt tokens (input), completion tokens (output), and total tokens used. Token accounting captures usage per analysis, per requirement, per organization, and per time period, enabling cost allocation, budget monitoring, usage trend analysis, and identification of expensive operations. Token counts are stored in the gptlog and aggregated for reporting and billing purposes.

token hash

A one-way cryptographic hash of the API token plaintext, computed using a secure hashing algorithm (such as bcrypt or SHA-256), stored in the database to enable token validation without storing the plaintext token itself, protecting against credential exposure in the event of database compromise.

token metadata

The set of attributes stored with an API token record in the api_tokens table, including: user_id (owner of the token), orgid (organization scope), is_active (revocation status), created (creation timestamp), last_used (most recent authentication timestamp), and expires_at (expiration timestamp). Token metadata is loaded during authentication and used for authorization, audit logging, and token lifecycle management.

token usage tracking

The system capability that records metadata about API token usage, including the timestamp of the most recent successful authentication (last_used field). This tracking enables monitoring of token activity, identification of unused tokens for security audits, and detection of suspicious access patterns.

token validation

The process of verifying that a provided API token is authentic, active, and not expired by: (1) hashing the provided plaintext token, (2) comparing the computed hash against stored token_hash values in the api_tokens table, (3) checking that is_active is true, (4) verifying that expires_at is in the future, and (5) loading the associated user_id and orgid for authorization. Token validation occurs on every API request before processing.

token_hash

A cryptographically hashed representation of an API token stored in the database, generated using a secure one-way hashing algorithm (such as bcrypt, Argon2, or PBKDF2). The token_hash allows the system to verify token authenticity during API requests without storing the plaintext token, which would pose a security risk if the database were compromised. The original token is shown to the user only once at generation time and cannot be recovered from the hash.

tooltip

A small pop-up text box that appears when a user hovers over or focuses on a UI element, providing additional context, explanation, or help text. Tooltips are typically displayed after a short delay (e.g., 500ms) and disappear when the user moves away from the element. They are used to explain truncated text, provide definitions for icons or abbreviations, or offer guidance without cluttering the main interface.

total_count

A metadata field in paginated API responses indicating the total number of records matching the query criteria across all pages, regardless of pagination parameters. Used by clients to calculate total_pages and determine whether additional pages exist.

total_pages

A metadata field in paginated API responses indicating the total number of pages available for the current query, calculated as ceiling(total_count / page_size). Used by clients to determine the last available page number and implement pagination controls.

triage

The process of evaluating and categorizing backlog items to determine their priority, feasibility, and disposition (promote to requirement, decline, or defer). Triage involves analyst review of item details, assessment of business value and technical complexity, and a decision to either promote the item (linking it to a requirement) or decline it (with a documented reason).

triage action link

A clickable hyperlink displayed alongside a backlog item in the attached items panel that navigates the user to the triage page for that specific item, enabling the analyst to promote or decline the item. The link is only displayed for items in 'open' status and is hidden for items already in terminal states (promoted, declined).

triage page

A dedicated user interface page where analysts review individual backlog items and make triage decisions (promote to requirement or decline with reason). The page displays the backlog item's details (title, description, priority, source, creation date) and provides form controls for entering a decline reason, confirmation dialogs for triage actions, and navigation back to the backlog list view.

triage workflow

A structured process for reviewing and categorizing open backlog items, where analysts assess each item's priority, feasibility, and disposition (promote to requirement, decline, or defer), ensuring systematic evaluation of all incoming work items before they enter active development planning.

triaged independently

The capability for a backlog item to undergo the triage workflow (evaluation, prioritization, and disposition decision to promote or decline) without being constrained by its attachment to one or more scopes. Independent triage means that attaching an item to a scope does not automatically promote it to a requirement or change its status, and the triage decision can be made separately from scope planning activities.

triaged_at

A timestamp field recording the exact date and time (in UTC with microsecond precision) when a backlog item's triage decision was finalized, marking the moment the item transitioned from 'open' status to either 'promoted' or 'declined' status. This field is immutable once set and serves as part of the audit trail for backlog item lifecycle tracking.

triaged_by

A foreign key field referencing the user (auth_user.id) who performed the triage action on a backlog item, recording which analyst made the decision to promote or decline the item. This field is immutable once set and serves as part of the audit trail, enabling accountability and traceability of triage decisions.

type (verified)

A classification of tennis balls based on their construction and performance characteristics, with defined values including 'pressurised' (balls with internal air pressure), 'pressureless' (balls without internal pressure), 'training' (designed for practice and coaching), and 'competition' (meeting official tournament standards). Type is a primary filterable attribute in the catalogue.

typical load

The expected normal operating conditions for system performance testing, representing the average concurrent user activity and transaction volume during regular business operations. Typical load is used as a baseline for performance benchmarks and capacity planning, excluding peak periods or stress test scenarios.

U

ui session

An authenticated user session initiated through the web-based user interface (as opposed to API-based programmatic access), typically maintained via browser cookies or session tokens and associated with interactive user actions in the graphical interface.

unique constraint

A database integrity rule that ensures no two rows in a table can have the same value for a specified column or combination of columns. Unique constraints are enforced by the database management system, which rejects INSERT or UPDATE operations that would create duplicate values, typically returning a constraint violation error.

units

No definition yet.

update

The action of modifying one or more attributes of an existing investment holding record, including quantity held or cost basis per unit. Updates preserve the holding's identity and history while changing current values, and take effect immediately in portfolio calculations.

utc

Coordinated Universal Time - the primary time standard by which the world regulates clocks and time, not subject to daylight saving time adjustments. UTC is used as a timezone-neutral reference for storing timestamps in databases and logs, enabling consistent time-based calculations and comparisons across different geographic regions. Display times are typically converted from UTC to the user's local timezone.

utf-8 encoding

A variable-width character encoding standard that can represent every character in the Unicode character set using one to four 8-bit bytes. UTF-8 is backward compatible with ASCII and supports international characters, symbols, and emoji, making it the standard encoding for web applications and databases storing multilingual text.

V

valuable

A priority classification for backlog items indicating that the item would provide meaningful user or business value but is not essential for the initial product release. Valuable items represent enhancements, optimizations, or additional features that improve the product but can be deferred if necessary. This is the third-highest priority classification in the product backlog taxonomy.

version

A numbered or timestamped edition of a plan document that represents a distinct state of the implementation plan at a specific point in time. Each version is immutable once created, with new versions superseding (but not deleting) previous versions, maintaining a complete audit trail of plan evolution. Version numbers typically follow sequential integer numbering (1, 2, 3...) or semantic versioning schemes.

W

wcag

Web Content Accessibility Guidelines - an international standard published by the World Wide Web Consortium (W3C) that defines how to make web content more accessible to people with disabilities. WCAG provides testable success criteria organized into three conformance levels (A, AA, AAA) covering perceivability, operability, understandability, and robustness. WCAG 2.1 Level AA is the most commonly adopted standard for web accessibility compliance.

webhook

An HTTP callback mechanism where an external system sends real-time event notifications to a specified URL endpoint when specific events occur. The webhook payload contains event data in a structured format (typically JSON), enabling the receiving system to react to external state changes without polling. Webhooks require the receiving system to expose a publicly accessible HTTP endpoint and implement authentication/verification to prevent unauthorized requests.

worker orchestration

The coordination and management of background worker processes (RQ workers running as defospam-worker@*.service systemd units) that execute asynchronous analysis tasks. Worker orchestration includes job queue management, task distribution across available workers, progress tracking, error handling, retry logic, and resource allocation to ensure analyses complete reliably and efficiently without blocking the main application thread.

write access

A permission level granted to users that allows them to create, modify, or delete data within a specific organizational context or application scope. Write access is distinct from read-only access and is required for operations that change system state, such as creating requirements, updating backlog items, or triaging work items.