Glossary

Generated 2026-07-13 19:11. 482 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 (51)
• B (30)
• C (64)
• D (36)
• E (12)
• F (13)
• G (7)
• H (9)
• I (20)
• K (3)
• L (9)
• M (18)
• N (7)
• O (11)
• P (31)
• Q (2)
• R (52)
• S (49)
• Symbols (2)
• T (36)
• U (12)
• V (4)
• W (4)

Symbols

/release-close

A slash command or automated workflow step in the REQQA system that executes the release closure process, including final quality checks, artifact generation, and adoption ratchet status review. The command is invoked by analysts or release managers to formally complete a release cycle.

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.

account

No definition yet.

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.

active

A book status indicating that the item is currently part of the library's circulating collection and eligible to appear in search results and be borrowed by members. Active books exclude those that are withdrawn, in processing, or otherwise removed from circulation.

admin ui

An administrative user interface that allows authorized users (typically system administrators or policy managers) to view, create, update, and delete entries in the category catalogue, including modifying canonical identifiers, names, default tool assignments, default gates, default thresholds, and default severity floors. The admin UI enforces validation rules, records changes in policy decision history, and manages catalogue versioning.

administrative interface

A restricted-access user interface component or web page accessible only to users with administrative privileges, providing controls for system-wide configuration including API key management, provider settings, and operational parameters. The interface enforces role-based access control and logs all configuration changes for audit purposes.

adoption ratchet

A progressive enforcement mechanism that incrementally tightens quality or compliance requirements over successive releases, preventing regression to lower standards once a higher standard has been achieved. The term 'ratchet' refers to the one-way advancement property where standards can advance but should not normally retreat.

advance

The action of transitioning a category from its current lifecycle stage to the next stage in the sequence (e.g., from baseline to stop-the-bleed, or from triage to ratchet). Advancement represents a tightening of enforcement standards and is typically proposed by analysts and recorded in the policy decision-history.

advisory

A category enforcement level where analysis results are displayed to analysts but do not block scope transitions or require resolution. Advisory categories provide guidance and warnings without enforcing mandatory compliance, allowing analysts to proceed despite unresolved issues.

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.

aes-256

Advanced Encryption Standard with a 256-bit key length - a symmetric block cipher approved by NIST (FIPS 197) that encrypts data in 128-bit blocks using a 256-bit encryption key. AES-256 provides a high security margin (approximately 128 bits of security strength against brute force) and is widely approved for protecting classified information up to TOP SECRET level in US and UK government systems.

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.

ai provider rate limits

Restrictions imposed by external AI service providers (such as OpenAI) on the number of API requests, tokens processed, or concurrent operations that can be executed within a specified time period (e.g., requests per minute, tokens per day). Rate limits may include quotas, throttling thresholds, and associated HTTP status codes (e.g., 429 Too Many Requests) that indicate when limits are exceeded.

ai-generated versus manually authored

A provenance classification that distinguishes requirements created by AI-assisted generation workflows from those created through direct human authoring. AI-generated requirements originate from the mission statement generation process and are marked with metadata indicating their AI origin, while manually authored requirements are created directly by analysts through the standard requirement creation interface. This distinction supports audit trails, quality analysis, and understanding of requirement sources.

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 categories

Predefined classifications of static analysis checks or quality assessments (identified by alphanumeric codes such as A1, A2, B1, F5) that group related analysis rules or inspection types. Each category represents a distinct dimension of code quality, security, or compliance that can be evaluated by automated analysis tools. Categories are configured with default settings for tool selection, quality gates, thresholds, and severity levels.

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.

analysiscontextdocs

A database join table that records the provenance of context documents used in AI-powered requirement analyses, linking each AI call (via gptlog) to the specific documents that contributed to the prompt. Each row represents one document's inclusion in one analysis, capturing the document identifier, revision used, tier of attachment, and optionally chunk-level details (chunk_id, similarity_score) for RAG-based retrievals. This table enables tracing which standards, templates, or reference materials shaped a given analysis result.

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.

analyst-facing finding display

A user interface component or page in REQQA that presents code quality findings (issues, violations, or warnings) detected by analysis tools to analysts, displaying for each finding: the rule code, severity, location in code, description, and associated KB entry content (explanation, risk note, remediation hints). The finding display consumes KB entry data to provide context and guidance to analysts reviewing code quality issues, enabling them to understand and address findings effectively.

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.

association table

A database table that establishes many-to-many relationships between entities by storing foreign key pairs, enabling multiple documents to be attached to multiple targets (organizations, templates, or scopes). In this context, association tables join org_context_documents to organizations, requirement templates, or release scopes, recording which documents are attached at each tier.

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 tier

A classification level that determines the scope at which a context document is automatically included in LLM prompts. Three tiers are defined: org-wide (applies to all requirements in the organization), requirement-template-scoped (applies to all requirements using a specific template), and release-scope-scoped (applies to all requirements within a specific release scope). The tier determines which analyses receive the document's content in their prompt prefix.

attachment time

The moment when an org administrator associates a context document with an organisation by creating a record in the org_context_documents table, making the document available for retrieval during AI analysis operations. Attachment time is the point at which document indexing is initiated and threshold validation occurs.

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

background job

An asynchronous task executed by worker processes outside the main request-response cycle, allowing long-running operations to complete without blocking the user interface. Background jobs are queued for execution, tracked with progress indicators, and notify users upon completion. In REQQA, background jobs are typically implemented using the RQ (Redis Queue) worker system referenced in the glossary's 'rq workers' entry.

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.

baseline

The initial stage of the adoption ratchet lifecycle where a category is recognized and tracked but no enforcement or quality gates are applied. Baseline represents the starting point for measuring improvement and establishing current-state metrics before progressive tightening begins.

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.

blocker-severity

A classification level assigned to static analysis findings indicating that the issue must be resolved or formally waived before a release can proceed to acceptance. Blocker-severity findings represent critical defects, security vulnerabilities, or policy violations that pose unacceptable risk if left unaddressed. Distinguished from lower severity levels (high, medium, low) that may be accepted with justification or deferred to future releases.

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.

breakpoint

A specific viewport width threshold defined in CSS media queries at which the layout, styling, or behavior of a responsive web interface changes to optimize display for different device sizes. Common breakpoints correspond to phone (e.g., 360px-767px), tablet (768px-1023px), and desktop (1024px+) screen widths. Breakpoints enable adaptive layouts that reflow content appropriately for each device category.

breakpoint limit

The maximum number of cache_control markers that Anthropic's API allows per request. This limit constrains how many tier boundaries from FR-21.3's prompt structure can have ephemeral caching enabled. Exceeding this limit would cause API request rejection or undefined caching behavior.

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 lookup

An API operation that retrieves KB metadata for multiple (tool, rule_code) pairs in a single request, returning an array of KB entries corresponding to the requested rules. Bulk lookups optimize performance when enriching batches of findings by reducing the number of HTTP requests and database queries required, compared to individual lookups for each rule.

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.

byte-identical

A comparison criterion where two data structures or text blocks are considered identical if and only if their binary representations match exactly at the byte level, including whitespace, encoding, and ordering. Byte-identical comparison is stricter than semantic equivalence and is used to verify that cached content has not changed in any way.

C

cache breakpoint

A boundary point in an LLM prompt where cache_control markers divide the prompt into cacheable and non-cacheable segments. Content before a breakpoint is marked for caching and can be reused across API calls; content after the breakpoint is processed fresh each time. Breakpoints are strategically placed to separate stable organizational context (cacheable) from variable per-analysis content (non-cacheable), optimizing token costs.

cache frontier

The boundary point in an AI prompt structure that separates cacheable static content (above the frontier) from dynamic, per-request content (below the frontier). Content above the cache frontier is sent to the AI provider once and reused across multiple requests via prompt caching, while content below is sent fresh on every call. The frontier placement determines which prompt components benefit from caching cost savings and which remain request-specific.

cache hit rate

The percentage of LLM API calls that successfully reuse cached prompt content, calculated as (calls with cache_read_input_tokens > 0) / (total calls) × 100. A high cache hit rate indicates effective prompt structuring and stable context reuse, resulting in reduced token costs. Cache hit rate is tracked per organization and surfaced in FR-21.5's observability interface.

cache statistics

Metrics returned by the Anthropic API indicating cache performance for a given LLM call, including cache_creation_input_tokens (tokens newly cached), cache_read_input_tokens (tokens reused from cache), and standard token counts (prompt_tokens, completion_tokens). Cache statistics enable calculation of cache hit rate, cost savings, and prompt efficiency. These metrics are captured per analysis in the gptlog table and aggregated for organizational reporting in FR-21.5's observability interface.

cache ttl

Cache Time To Live - the duration for which cached data is considered valid before it must be refreshed from the authoritative source. After the TTL expires, the cache entry is either automatically purged or marked as stale, triggering a refresh on the next access. TTL values balance data freshness requirements against system performance and load on upstream services.

cache_control

An Anthropic API parameter that marks specific portions of a prompt for caching on the LLM provider's servers, enabling reuse of previously processed prompt segments across multiple API calls. When cache_control breakpoints are set, the provider stores the processed representation of marked content and returns cache statistics (cache_creation_input_tokens, cache_read_input_tokens) indicating which portions were cached and reused, reducing token costs for repeated content.

cache_read_input_tokens

A metric returned by the Anthropic API indicating the number of input tokens that were served from cache rather than processed fresh. A value greater than zero indicates a cache hit, where previously cached prompt segments were reused. This metric is captured in gptlog (FR-21.5) to track caching effectiveness and calculate cache hit rates.

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 identifier

The authoritative, unique code or key assigned to each analysis category (such as A1, A2, B1, F5) that serves as the primary reference for that category throughout the system. Canonical identifiers are immutable, human-readable codes that distinguish categories and are used in configuration files, API requests, database records, and user interfaces to refer to specific analysis categories.

canonical identifiers

The authoritative, unique codes or keys assigned to each analysis category (such as A1, A2, B1, F5) that serve as the primary reference for that category throughout the system. Canonical identifiers are immutable, human-readable codes that distinguish categories and are used in configuration files, API requests, database records, and user interfaces to refer to specific analysis categories.

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.

cap

A moderator-configured maximum number of teams that can work on a single topic during the steering phase. When a topic reaches the cap threshold and any topic remains below the minimum, that topic becomes unavailable for new team selections. The cap is lifted (no longer enforced) once all topics meet the minimum coverage threshold, allowing unlimited teams per topic.

caps

Commercial Product Assurance Scheme — an NCSC certification program that evaluates and approves commercial cryptographic products for use in UK government systems. CAPS provides assurance that products meet security requirements for protecting OFFICIAL-SENSITIVE and SECRET information. Products on the CAPS list have undergone security evaluation and are approved for use without additional accreditation for their cryptographic functionality.

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.

catalogue

A centralized, searchable repository of all book records maintained by the library system, containing bibliographic information, availability status, and copy-level details for each title held by the library. The catalogue serves as the authoritative source for book metadata and inventory tracking.

categories endpoint

A companion API endpoint that returns the list of static analysis categories or rule groupings available in the system, providing metadata about category names, descriptions, and associated rules. This endpoint supports the main static-analysis profile endpoint by providing reference data for category identifiers used in the profile payload.

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.

category catalogue

A master reference table or registry that stores the complete list of static analysis categories (identified by codes A1 through F5) along with their associated metadata including canonical identifiers, display names, default analysis tool assignments, default quality gate settings, default threshold values, and default severity floor levels. The catalogue serves as the authoritative source for category configuration data used throughout the analysis system.

category-in-release record

A database record or entity that represents the association between a specific category and a specific release, storing the category's status value for that release along with metadata such as status change history, review timestamps, and responsible parties. This record enables the same category to have different status values across different releases.

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.

chronological order

A sorting sequence where entries are arranged by their creation timestamp, with the earliest entry first and the most recent entry last (ascending order), or vice versa (descending order). In the context of team discussion views, chronological order enables team members to follow the progression of discussion contributions over time.

chunk

A discrete segment of a source document that has been divided for retrieval purposes in a RAG (Retrieval-Augmented Generation) system. Each chunk represents a portion of text with defined boundaries, typically sized to fit within AI model context windows, and is indexed separately to enable semantic search and retrieval based on relevance to a query.

chunk-level provenance

A detailed record of which specific text segments (chunks) from context documents were retrieved and included in an AI prompt, including the chunk identifier, similarity score (if retrieved via semantic search), source document, and document revision. Chunk-level provenance enables fine-grained tracing of how retrieved content influenced AI analysis results, supporting debugging, quality assessment, and understanding of RAG (Retrieval-Augmented Generation) system behavior.

chunks

Fixed-size or semantically-bounded segments of a source document created during the indexing process, each representing a coherent unit of content that can be independently embedded and retrieved. Chunks typically range from 200-1000 tokens and may overlap to preserve context at boundaries. Each chunk maintains metadata linking it to its source document, position, and revision for provenance tracking.

chunk_id

A unique identifier assigned to each chunk when a document is divided for RAG retrieval purposes. The chunk_id enables precise tracking of which specific text segment was retrieved and used in an analysis, supporting provenance and auditability. The identifier format and uniqueness scope (per document, globally unique, etc.) should be specified by the chunking implementation.

ci/cd

Continuous Integration/Continuous Deployment - an automated software development practice where code changes are frequently integrated into a shared repository (CI), automatically tested, and deployed to production or staging environments (CD) with minimal manual intervention. CI/CD pipelines execute build, test, and deployment steps in sequence, providing rapid feedback on code quality and enabling frequent, reliable releases.

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.

cognitive complexity

A code quality metric that measures how difficult code is for humans to understand, based on the number of decision points, nested control structures, and logical operators. Cognitive complexity differs from cyclomatic complexity by weighting nested structures more heavily and ignoring certain constructs that do not increase human comprehension difficulty. High cognitive complexity indicates code that is hard to maintain, test, and debug.

common interface

An abstraction layer or software contract (typically implemented as an abstract base class, interface, or protocol) that defines a standardized set of methods and data structures for interacting with AI providers, enabling the system to invoke AI operations (prompt submission, response retrieval, error handling) without coupling to provider-specific APIs. The common interface allows provider implementations to be swapped or extended without modifying business logic that consumes AI services.

companion endpoint

A related API endpoint that provides supporting or complementary functionality to a primary endpoint, typically sharing a common resource path prefix and serving a related use case. In this context, the /categories endpoint is a companion to the /static-analysis/{release_id} endpoint, providing reference data about available analysis categories.

complete first-draft set

A comprehensive collection of requirements generated by AI that covers all aspects of the mission statement, providing sufficient detail and breadth to serve as a starting point for further refinement. A complete first-draft set includes functional requirements, non-functional requirements, and technical requirements as appropriate, with each requirement structured according to system templates and containing sufficient detail to be understandable without requiring immediate editing.

compliance purposes

The set of regulatory, legal, and policy requirements that mandate retention and availability of audit records, including financial regulations, data protection laws, industry standards, and organizational governance policies. Defines retention periods, access controls, and audit trail completeness requirements.

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.

configuration files

Structured data files (such as JSON, YAML, XML, or INI format) stored separately from application code that contain environment-specific settings and parameters. These files are read by the application at startup or runtime to configure behavior, connections, and features without requiring code changes or recompilation.

configured ai providers

External AI services (such as OpenAI, Anthropic Claude, or other large language model APIs) that have been registered in the system configuration with authentication credentials, endpoint URLs, model selection parameters, and usage quotas. Configured providers are available for selection when initiating AI-assisted requirements generation, allowing organizations to choose their preferred AI service based on cost, performance, or policy requirements.

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.

conflict resolution

The process of determining the final quantity for a product that exists in both guest and registered baskets during a merge operation. Resolution options include: keep guest quantity, keep account quantity, or sum both quantities (default). The chosen resolution is recorded in the BasketMerge.conflict_resolution JSON field for audit purposes.

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.

context library

An organization-scoped repository of reference documents (standards, SOPs, style guides, regulatory excerpts) that are automatically included in LLM prompts during requirement generation and analysis. The library stores documents in multiple formats (PDF, DOCX, Markdown, plain text) and supports tiered attachment rules determining which documents apply to which requirements.

context provenance

A record of which Context Library documents (including specific document revisions) were included in the prompt for a given AI analysis call. Context provenance is captured per analysis and stored in a join table linking gptlog entries to context documents, enabling traceability of which organizational reference material influenced each AI-generated or analyzed requirement. Provenance supports audit requirements and helps analysts understand why the AI produced specific outputs.

contributor

A workshop participant who has submitted one or more entries during the session. Each contributor is identified by a unique nickname and their contributions are attributed to them in the export. Contributors are the authors of entries and are acknowledged in the workshop output.

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.

cost-awareness nudge

A non-blocking warning or notification displayed to administrators when a configurable threshold is exceeded, designed to make the cost implications of a decision visible without preventing the action. The nudge provides transparency into resource consumption (such as token usage) to inform decision-making while preserving administrator autonomy.

coverage

The extent to which KB entries exist for rules encountered in practice, measured as the percentage of (tool, rule_code) combinations that have been populated with metadata. Coverage starts thin (initially just upstream URLs) and deepens over time as the team encounters rules and adds detailed explanation, risk, and remediation content. Full coverage means every rule emitted by integrated tools has a corresponding KB entry.

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.

curated

The process of human review, validation, and enhancement of rule metadata by a subject matter expert or administrator. Curation involves verifying rule explanations, adding context-specific remediation guidance, assessing risk notes, and ensuring the knowledge base content is accurate, complete, and actionable. The curated_by and curated_at columns track who performed curation and when.

curator

A user role within REQQA (specifically REQQA admin personnel) with elevated permissions to manage the knowledge base, including the ability to create, read, update, and delete KB entries, perform batch imports of stub entries, configure rule metadata, and maintain the authoritative reference content that guides analysts in interpreting and responding to code quality findings. Curators are distinguished from regular analysts who consume KB content but cannot modify it.

cve

Common Vulnerabilities and Exposures - a standardized identifier system for publicly known cybersecurity vulnerabilities, maintained by the MITRE Corporation. Each CVE entry includes a unique ID (e.g., CVE-2023-12345), description of the vulnerability, affected software versions, severity score (CVSS), and references to patches or mitigations. CVE identifiers enable consistent vulnerability tracking and communication across security tools and databases.

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.

dashboard

A web-based user interface displaying aggregated metrics and status information in a consolidated, at-a-glance format, typically using visual elements such as charts, tables, and summary statistics to enable rapid assessment of system state or progress.

data access layer

A software abstraction layer that provides modules with standardized methods to read and write shared data entities (Candidate, Client/Home Requirement, Staff/User) without direct database access. The data access layer encapsulates database queries, enforces data validation rules, manages transactions, and provides a versioned API that isolates modules from database schema changes. Implemented as a shared library, microservice, or ORM framework.

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 gate

The pre-configured quality gate setting for an analysis category that determines whether violations in that category will block a build, generate warnings, or be informational only. The default gate represents the standard enforcement level for the category (e.g., 'blocking', 'warning', 'advisory') that applies unless overridden at the release-scope level.

default override

An analyst action that changes a system-provided default value (such as severity floor, threshold, tool selection, or required-state) to a different value when configuring or saving a release scope. The override replaces the default with an analyst-specified value and must be accompanied by a documented rationale explaining the business or technical justification for the deviation.

default profile

A configuration or settings template that defines the initial or recommended adoption ratchet status for each category in a new release, inherited from the previous release's final status. The default profile serves as the starting point for enforcement rules and can be customized per release if needed.

default severity floor

The pre-configured minimum severity level for an analysis category below which violations are ignored or excluded from quality gate evaluation. The default severity floor represents the standard filtering threshold for the category (e.g., 'ignore INFO and LOW, report MEDIUM and above') that applies unless overridden at the release-scope level. Severity levels typically include values like INFO, LOW, MEDIUM, HIGH, CRITICAL.

default threshold

The pre-configured numeric limit or boundary value for an analysis category that defines the maximum acceptable number or severity of violations before the quality gate is triggered. The default threshold represents the standard tolerance level for the category (e.g., 'maximum 5 critical issues', 'code coverage >= 80%') that applies unless overridden at the release-scope level.

default tool

The specific static-analysis software or service (such as SonarQube, ESLint, Pylint, or Coverity) that is pre-configured to execute analysis for a given category when no alternative tool is specified. Each category in the catalogue has a default tool that defines which analyzer will run and what metrics will be collected. The default tool can be overridden at the release scope level if alternative analyzers are available for the category.

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.

defaults

The pre-configured set of analysis categories that are enabled or required when no explicit profile selection has been made, or the baseline category settings that a profile modifies. Defaults may be system-wide, organization-specific, or template-specific.

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.

dependency pinning

The practice of specifying exact versions of software dependencies in build configuration files (e.g., requirements.txt, package.json) rather than using version ranges or 'latest' tags. Pinning ensures reproducible builds by preventing automatic updates to newer dependency versions that may introduce breaking changes, security vulnerabilities, or behavioral differences. Pinned dependencies must be explicitly updated through controlled processes.

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.

deterministically

In a manner that produces the same output given the same input, with no randomness or variability. Deterministic correlation ensures that re-processing the same event will always produce the same correlation result.

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.

dispatched

An order status indicating that the order has been picked, packed, and handed over to a shipping carrier for delivery to the customer. At this stage, the order has left the warehouse or fulfillment center and is in transit. A tracking number from the carrier is typically available at this point.

document revision

A versioned instance of a Context Library document, identified by a unique revision number or timestamp, representing the document's content at a specific point in time. Each time a document is re-uploaded or modified, a new revision is created. Context provenance records link AI analyses to specific document revisions, enabling traceability of which version of organizational reference material influenced each analysis. Revisions support audit requirements and allow rollback to previous document versions.

document_revision

A version identifier for a document that increments each time the document content is updated, enabling tracking of which version of a document was used to generate embeddings. Document revisions ensure that vector store entries can be invalidated or updated when source documents change, and support audit trails showing which document version was used for retrieval at any point in time.

domain

A high-level grouping of related analysis categories organized by functional area or quality dimension (e.g., Domain A might be 'Functional Completeness', Domain B 'Consistency', etc.). Domains provide a hierarchical organization above individual categories, enabling profile definitions to reference entire groups of related checks.

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.

drill-down

A user interface interaction pattern where clicking on a summary metric or aggregate value navigates to a detailed view showing the underlying individual records that comprise that aggregate. In the context of source effectiveness reporting, drill-down allows the Owner/Director to click on a candidate source and view the list of individual candidates and placements from that source.

E

embed

The process of converting text into a high-dimensional numerical vector (embedding) using a machine learning model, where semantically similar texts produce vectors that are close together in vector space. In this context, refers to transforming the requirement's title and content into a query vector that can be compared against document chunk vectors in the vector store using similarity metrics.

embeddings

Numerical vector representations of text chunks generated by a machine learning model that capture semantic meaning, enabling similarity-based retrieval. Embeddings map text into a high-dimensional vector space where semantically similar content has similar vector representations, typically produced by models like OpenAI's text-embedding-ada-002 or similar transformer-based encoders.

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.

enforcement level

A classification indicating how a static-analysis category's results are treated in the release pipeline, with three possible values: 'required' (analysis must pass or build fails), 'advisory' (analysis runs but failures are warnings only), or 'excluded' (analysis is not performed for this release scope). The enforcement level determines whether analysis failures block release progression or serve as informational feedback.

entry

A single contribution made by a participant under a specific heading within a topic. Each entry contains text content, is attributed to a contributor by their nickname, has a timestamp, and represents one unit of workshop output. Entries are the atomic data elements that are aggregated and exported in the structured markdown and CSV files.

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.

evidence bundles

Packaged collections of security scan results, compliance reports, and audit artifacts generated during the CI/CD pipeline that document security findings, rule violations, and remediation status. Evidence bundles serve as proof of security controls for compliance audits and security reviews.

expected completion windows

The anticipated time ranges within which AI operations should complete under normal conditions, defined as 30-120 seconds for mission statement and story analysis operations and 60-180 seconds for requirements generation operations. When actual execution time exceeds these windows, the system treats the operation as delayed and triggers user notification workflows.

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.

exponential backoff retry logic

A retry strategy where the wait time between retry attempts increases exponentially (e.g., 1s, 2s, 4s, 8s, 16s) 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. The strategy includes maximum retry attempts, backoff multiplier, and criteria for distinguishing retryable failures from permanent failures.

extracted_text

The plain text content extracted from an uploaded document (PDF, DOCX, Markdown, or plain text file) through automated text extraction processes, stored as a database column in org_context_documents. The extracted text represents the document's textual content in a format suitable for token counting, analysis attachment, and future retrieval operations, stripped of formatting, images, and non-text elements.

extraction failure

A condition where the text extraction process (using pdfminer or equivalent) is unable to successfully extract readable text from an uploaded document, typically due to corrupted files, password-protected PDFs, scanned images without OCR, or unsupported PDF features. Extraction failures are surfaced to the uploader with an error message, allowing them to substitute a cleaner source file or alternative format.

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.

filter parameters

Query string parameters passed to the GET /api/v1/static-analysis/rules endpoint that restrict the result set based on specified criteria. Filter parameters include 'tool' (to retrieve rules for a specific analysis tool) and 'severity' (to retrieve rules of a specific severity level). Multiple filter parameters can be combined to narrow results, and the API returns only KB entries matching all specified filters.

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.

finding record

A structured data record representing a single issue, violation, or observation detected by an analysis tool, containing at minimum the tool name, rule code, location in the analyzed artifact, and severity. Finding records are submitted via FR-19.3 and enriched with KB metadata (explanation, risk, remediation) before display to analysts. Each finding references a KB entry by (tool, rule_code) to provide actionable context.

fixture

A predefined data file or script used to populate database tables with initial or reference data during system deployment or testing. In the context of help content, a fixture contains the canonical set of help_pages table entries that are loaded at release time to establish the baseline help content structure.

fixture file

A version-controlled data file stored in the application repository (typically in JSON, YAML, or SQL format) that contains a canonical snapshot of demo organisation content including requirements, stories, personas, and analyses. The fixture serves as the authoritative source for re-seeding the demo application during release deployments, ensuring consistent and reproducible demo data across environments.

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

A quality checkpoint in the release pipeline that evaluates static-analysis results against configured thresholds and enforcement levels to determine whether code can proceed to the next stage. A gate 'passes' if all required categories meet their thresholds, and 'fails' if any required category exceeds its threshold, blocking release progression. Advisory categories do not affect gate pass/fail status but their results are reported.

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.

graceful degradation

A system design principle where functionality is reduced in a controlled manner when operating conditions exceed normal parameters, rather than failing completely. In the context of GNSS-denied operation, graceful degradation means the system continues to provide positioning information (albeit with reduced accuracy) using dead reckoning, rather than reporting no position at all.

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 acceptance

The stage in the Dark Factory lifecycle where the analyst reviews the builder's completed work (including static analysis results) and formally accepts the build as meeting requirements, transitioning the scope to accepted status. Handover acceptance is the point at which the analyst verifies that all quality gates, including static analysis verdicts, are satisfied.

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.

heading

A topic or section label within the workshop forum structure under which participants add contribution entries. Headings organize contributions thematically and serve as the grouping dimension for concurrent-write scenarios and export formatting.

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.

http 200

An HTTP status code indicating that a request has succeeded. In the context of web page rendering, HTTP 200 means the server successfully processed the request and returned the requested content (HTML page) to the client's browser. The status code is part of the HTTP response header and indicates successful completion of the request-response cycle.

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.

idempotent

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 plugin registration, idempotent means that registering the same OAuth provider plugin multiple times (e.g., across py4web restarts or repeated calls to the registration function) does not create duplicate registrations, does not cause errors, and leaves the system in the same state as a single registration would.

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.

indexing-state

A database column in org_context_documents (added in FR-23) that tracks the processing status of a document for RAG retrieval, with possible values such as 'pending' (document uploaded but not yet chunked/embedded), 'indexing' (chunking and embedding in progress), 'indexed' (ready for retrieval), or 'failed' (indexing encountered an error). This field is only relevant for documents with use_mode='retrieve-on-demand' and enables the system to determine whether a document is available for semantic search.

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.

instructions

Moderator-authored guidance associated with a topic that directs participants on how to approach the discussion, what type of contributions are expected, and what format or structure to follow. Instructions complement background text by providing actionable direction rather than contextual information, and may include markdown formatting.

interface

A formally defined contract specifying the methods, data structures, protocols, and behavioral expectations through which one module communicates with another, including API endpoints, message formats, data schemas, error handling conventions, and versioning rules. Interfaces are documented, versioned, and subject to stability requirements to enable independent module evolution.

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

No definition yet.

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

kb

Knowledge Base - a structured repository of static analysis rules, remediation guidance, and best practices that provides reference information for code quality findings. The KB stores rule definitions indexed by tool and rule_code, containing descriptions, severity levels, remediation steps, and examples for each rule violation detected by static analysis tools.

kb entry

A database record in the rule knowledge base table that stores metadata for a specific (tool, rule_code) combination, including explanation (what the rule checks), risk (consequences of violation), remediation (how to fix), upstream_url (link to official documentation), and severity_mapping (normalized severity level). Each KB entry provides the contextual information needed to make a tool finding actionable for analysts.

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 successful step

The most recent discrete operation or checkpoint within an AI operation workflow that completed successfully before a failure occurred, from which the operation can be resumed without repeating all prior work. The last successful step is identified by preserved partial results and enables incremental progress recovery.

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.

linter

An automated code analysis tool that examines source code, templates, or configuration files to detect potential errors, enforce coding standards, and identify deviations from established conventions. Linters typically run as part of the development workflow or CI/CD pipeline and report violations as warnings or errors. In this context, a linter would scan template files to detect non-sanctioned HTML title attributes that violate the inline help conventions.

locale

A language and regional formatting code (e.g., 'en-GB' for British English) that determines which message templates, quiet hours rules, and cultural conventions are applied when composing and dispatching passenger notifications. The locale ensures that communications are delivered in the appropriate language and format for the recipient's region, and is stored with each outbound message for audit and compliance purposes.

lock

The fifth and final stage of the adoption ratchet lifecycle where full enforcement is active for a category, blocking all violations (both new and existing) from release. Lock represents the mature state where the standard is permanently enforced and no exceptions are permitted.

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

mapping

The defined correspondence between a profile name (Strict, Standard, Minimum, Custom) and the specific set of category toggle states (required, optional, disabled) that should be applied when that profile is selected. The mapping is the lookup table or configuration that translates profile selection into concrete category settings.

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.

match

A proposed pairing of a candidate with a client requirement, created by matching staff when they identify a potentially suitable candidate for a requirement. Matches are tracked through a proposal and acceptance workflow before becoming placements. Also referred to as 'match proposal' or 'match record'.

message queue

A middleware component that enables asynchronous communication between system components by temporarily storing messages until they can be processed. Messages are added to the queue by producers and consumed by workers in FIFO order (or priority order). Message queues provide decoupling, load leveling, and reliability through features like persistence, acknowledgments, and dead-letter queues. Examples include RabbitMQ, Apache Kafka, AWS SQS.

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.

metrics

Quantitative measurements of system behavior, performance, or business activity that are collected, aggregated, and exposed in real-time or near-real-time for monitoring and analysis. Metrics include counters (e.g., candidates per stage), gauges (e.g., queue depths), histograms (e.g., time-in-stage percentiles), and rates (e.g., API response times), typically stored in a time-series database and visualized in dashboards.

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.

minimum

A moderator-configured threshold representing the target number of teams that should work on each topic to ensure adequate coverage. The minimum serves as the trigger for ending the steering phase: once all topics have at least this many teams, the cap is lifted and all topics become available. The minimum ensures every topic receives baseline attention before teams can freely revisit popular topics.

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.

mission statement

A concise, structured declaration of the system's purpose, goals, and scope that serves as the foundational input for AI-assisted requirements generation. The mission statement defines what the system should accomplish, who it serves, and the key problems it solves, providing the context and constraints that guide the generation of detailed functional and non-functional requirements.

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.

module

A discrete, independently deployable software component with defined interfaces that encapsulates a specific functional area (Screening, Verification, Interviewing, Matching, or Placement) and can be developed, tested, and deployed independently of other modules while maintaining integration through standardized interfaces.

monthly spend

The total monetary cost incurred by an organisation for AI analysis operations during a calendar month, including token costs for prompts, completions, and retrieval operations across all analyses performed. Monthly spend is calculated by aggregating per-analysis costs from the gptlog accounting system and is used for budget tracking, cost allocation, and usage trend analysis.

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.

normal ai api conditions

The expected operational state of external AI service providers where API endpoints are responsive, rate limits are not exceeded, network latency is within acceptable ranges, and no service degradation or outages are occurring. Normal conditions exclude scenarios such as provider outages, rate limit exhaustion, network failures, or degraded service performance.

normalization

No definition yet.

normalized severity

A standardized severity classification (HIGH, MEDIUM, LOW) applied consistently across all analysis tools, derived by mapping each tool's native severity scale to a common internal scale. Normalized severity enables analysts to prioritize findings from different tools on a consistent basis, regardless of whether the source tool uses numeric scales (1-10), categorical labels (critical/major/minor), or custom classifications.

notification

No definition yet.

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.).

operator

A user with permissions to initiate and configure analysis runs in REQQA, typically an analyst or quality assurance role who selects which analyses to execute on requirements or stories and reviews the resulting findings. The operator has discretion to override recommended analysis selections based on their judgment of what is appropriate for a given requirement.

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

No definition yet.

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.

org-wide attachment

An attachment tier configuration where a Context Library document is automatically included in the prompt prefix for all LLM analyses performed within the organization, regardless of requirement template or release scope. Org-wide attachments represent universal organizational standards or policies that apply to all requirements. This is the broadest attachment tier and takes precedence over more specific tiers when assembling the prompt prefix.

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.

org_context_documents

A database table that stores organisation-scoped reference documents (SOPs, standards, style guides) uploaded by organisation administrators, containing metadata including title, source type, extracted text content, token estimates, upload provenance, revision history, and status. Each document is scoped to a single organisation (orgid) and serves as the authoritative source for context documents that can be attached to requirements, templates, or scopes.

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.

partial results

Intermediate outputs or incomplete data structures produced during AI operation execution that represent progress toward the final result. Partial results may include partially analyzed stories, incomplete requirement text, or intermediate analysis findings that can be preserved and used as a starting point for retry operations, preventing complete loss of work when operations fail or are cancelled.

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.

pdfminer

A Python library (pdfminer.six or pdfminer3k) used for extracting text content from PDF files by parsing the PDF structure and converting it to plain text. The library handles various PDF encodings, fonts, and layouts to produce machine-readable text output. In this context, 'pdfminer or equivalent' indicates the preferred text extraction tool for PDF documents uploaded to the org context library.

per-category result payload

A structured data package submitted to the results ingestion API containing the analysis findings, metrics, and verdict for a single static analysis category (such as security, complexity, or test coverage). Each payload corresponds to one category's results and is submitted via a separate API call to the per-category endpoint.

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.

pipeline

An automated build and deployment workflow (typically implemented in a CI/CD system such as GitHub Actions, GitLab CI, or Jenkins) that executes a sequence of steps to compile, test, package, and deploy the application and its help documentation. In this context, the pipeline is responsible for writing version stamps to help artifacts and performing build assertions to validate version consistency.

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.

plugin

A modular software component in py4web that extends the authentication framework to support a specific OAuth2 identity provider. Each plugin (e.g., Google, GitHub, LinkedIn) implements the provider-specific OAuth2 flow including authorization URL construction, token exchange, user profile retrieval, and email extraction. Plugins are registered in settings.py and invoked by the py4web Auth system when users select a provider on the login page.

policy decision history

An audit trail or versioned record of all changes made to analysis policy configuration, including modifications to the category catalogue, default settings, and quality gate rules. Each history entry captures what was changed, when it was changed, who made the change, and the rationale or justification for the change. Policy decision history supports compliance, traceability, and understanding of how analysis standards have evolved over time.

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

A named configuration preset that defines which analysis categories are required, optional, or disabled for a release scope. Profiles provide predefined combinations of category settings (Strict, Standard, Minimum, Custom) to simplify analyst workflow and enforce organizational quality standards.

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.

progress tracking

A system capability that monitors and reports the status of long-running operations (such as AI-assisted requirements generation) by providing real-time or periodic updates on completion percentage, current step, elapsed time, and estimated time remaining. Progress tracking enables users to monitor background jobs without blocking their workflow and provides feedback that the system is actively processing their request.

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.

prompt

A modal dialog or inline UI element that interrupts the user's workflow to request a decision or input before proceeding with an operation. In the context of template changes, a prompt displays available merge options (Replace, Keep, Merge) and requires explicit user selection or dismissal before the template change is finalized.

prompt injection

A security vulnerability in AI systems where an attacker manipulates input prompts to cause the language model to ignore its instructions, leak sensitive information, generate harmful content, or execute unintended actions. Prompt injection exploits the model's inability to distinguish between system instructions and user input, similar to SQL injection in databases. Detection requires pattern matching for known attack vectors and validation of AI outputs.

prompt prefix

The initial portion of an LLM prompt that contains stable, reusable context (organizational reference documents, standards, style guides) assembled before the variable, per-analysis content. The prompt prefix is structured to align with cache_control breakpoints, placing org-stable content earliest to maximize cache reuse. The prefix is assembled from Context Library documents according to attachment tier rules and prepended to the analysis-specific prompt content.

provenance

No definition yet.

pydal

Python Database Abstraction Layer - an object-relational mapping (ORM) library included with the py4web framework that provides a database-agnostic API for defining schemas, executing queries, and managing database transactions. PyDAL supports multiple database backends including MySQL, PostgreSQL, and SQLite.

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.

quality gates

Predefined checkpoints in the software development lifecycle where specific quality criteria must be satisfied before work can proceed to the next phase. Quality gates enforce standards through automated checks (tests, static analysis, coverage thresholds) and manual reviews (code review, security assessment), blocking progression when criteria are not met. Gates provide objective go/no-go decisions based on measurable quality metrics.

R

ratchet

The fourth stage of the adoption ratchet lifecycle where active enforcement prevents any new violations in a category from being introduced, while existing violations are tolerated but tracked. This stage implements the one-way ratchet mechanism: quality cannot regress below the current baseline, but improvement is encouraged.

ratcheting status

A progressive quality or maturity indicator that can only advance forward through defined stages (baseline → stop-the-bleed → triage → ratchet → lock) and cannot regress to earlier stages, ensuring continuous improvement and preventing quality degradation. The term 'ratcheting' implies a one-way progression mechanism similar to a mechanical ratchet that prevents backward movement.

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.

rationale

A text explanation provided by the Release Analyst documenting the business or technical justification for deviating from default static-analysis settings, such as overriding a threshold value, excluding a category, or changing an enforcement level. Rationale entries are captured during profile configuration and stored with the static-analysis profile to provide audit trail and context for quality policy decisions.

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.

re-upload warning

A user-facing notification displayed when an organization administrator attempts to upload a new version of a Context Library document that is currently referenced by one or more existing AI analyses. The warning indicates how many analyses used the document (e.g., 'used by N analyses') and prompts the administrator to confirm the upload, acknowledging that the new version will be used for future analyses but will not trigger re-analysis of existing requirements. Re-upload warnings implement AR-21.P4's 'warn, do not block' principle.

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.

referential integrity

A database constraint mechanism that ensures relationships between tables remain consistent by preventing actions that would create orphaned records or invalid foreign key references. It enforces that a foreign key value must either match an existing primary key in the referenced table or be null, and defines cascading behaviors (CASCADE, SET NULL, RESTRICT) when parent records are updated or deleted.

regenerate

The action of invoking the AI generation process again for a specific requirement that was previously generated but deemed unsatisfactory during review. Regeneration uses the same mission statement input but may produce different output due to AI model variability or user-provided refinement prompts. Regenerated requirements replace the previous version in the staging area and can be regenerated multiple times until the user is satisfied with the result.

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

A scope that represents a planned production deployment or delivery increment, distinguished from development or experimental scopes by stricter quality requirements. Release scopes may trigger additional mandatory analysis categories (such as Domain C in the Standard profile) to ensure production-readiness.

release analyst

A user role in REQQA responsible for defining release scopes, configuring quality policies, and managing release-level requirements and constraints. Release Analysts have permissions to create and modify release scopes, configure static-analysis profiles, and make decisions about which quality gates apply to a release. This role is distinct from requirement analysts who focus on individual requirement specifications.

release closure

The formal completion phase of a release cycle where all planned work has been delivered, final quality gates have been passed, and administrative tasks (including adoption ratchet status review) are performed before the release is published. Release closure is the trigger point for evaluating whether categories should advance to the next lifecycle stage.

release record

A database entity or structured document that captures all configuration, metadata, and audit information for a release scope, including the scope definition, included artifacts, quality gate settings, overrides applied, rationale for overrides, approval history, and release status. The release record serves as the authoritative source for release configuration and provides traceability for all release decisions.

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.

release-scope ui

A user interface component or page (referenced as FR-19.1) that allows users to configure analysis settings for a specific release scope, including selecting which analysis categories to enable, overriding default tool assignments, adjusting quality gates, modifying thresholds, and setting severity floors. The release-scope UI consumes category catalogue data to populate available options and default values.

release_id

A unique identifier assigned to a specific release in the REQQA system, used to reference and retrieve release-specific configuration, policies, and artifacts. The identifier format, uniqueness guarantees, and lifecycle are defined by the release management subsystem.

remediation

Actionable guidance provided in a KB entry that instructs analysts or developers on how to fix or address a code quality finding, including specific code changes, refactoring steps, configuration adjustments, or alternative approaches that resolve the rule violation. Remediation content is one of the four core fields of a KB entry (alongside explanation, risk note, and severity mapping) and is displayed to analysts in the finding display to enable them to correct issues efficiently.

remediation guidance

Actionable instructions and recommendations stored in the Knowledge Base that explain how to fix or address a specific static analysis rule violation. Remediation guidance typically includes: description of the issue, why it matters, step-by-step fix instructions, code examples showing before/after corrections, links to relevant standards or documentation, and alternative approaches where applicable. This guidance is consumed by developers to resolve findings.

remediation_hints

Actionable guidance and recommendations for resolving or mitigating a security rule violation, stored as markdown-formatted text. Remediation hints may include code examples, configuration changes, alternative approaches, or references to secure coding practices. Multiple hints can be provided per rule, stored either as a JSON array or delimited list, to offer developers various options for addressing the identified issue.

required-state

A mandatory status or condition that artifacts, work items, or system components must achieve before a release scope can progress to the next lifecycle stage. Required-states may include 'all stories analyzed', 'all HIGH issues resolved', 'all tests passing', or 'all documentation complete'. The system enforces required-state checks as quality gates, and analysts may override defaults to relax or tighten these requirements for specific releases.

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 generation operations

AI-powered processes that create formal requirement specifications from source inputs such as user stories, stakeholder descriptions, or existing documentation. Requirements generation operations invoke AI models to produce structured requirement text, acceptance criteria, and metadata, typically taking longer than analysis operations due to the generative nature of the task.

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.

resolution rules

The algorithm and business logic that determines which context documents are included in an AI prompt for a given requirement, by combining documents from all applicable attachment tiers (org-wide, template, scope), de-duplicating by document ID, and ordering according to FR-21.3. Resolution rules ensure consistent and predictable document assembly across all AI analysis operations.

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.

rest api endpoint

A specific URL path exposed by the RESTful API that represents a resource or operation, supporting one or more HTTP methods (GET, POST, PUT, DELETE). Each endpoint defines a contract specifying request parameters, payload structure (JSON), response format, authentication requirements (API token), status codes, and error conditions. Endpoints enforce tenant isolation by automatically scoping queries to the authenticated user's organisation.

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.

retired

A state where a document or chunk has been removed from active use in the RAG system, typically due to obsolescence, replacement by a newer version, or administrative decision. Retired documents and chunks are no longer retrieved for new analyses but their provenance records are preserved to maintain historical analysis auditability.

retrieval-augmented generation

An AI technique where relevant context is dynamically retrieved from a large corpus (using embeddings, vector indices, or semantic search) and injected into the LLM prompt at query time, rather than including all context statically. RAG enables working with large knowledge bases by selecting only the most relevant documents for each query, reducing token costs and improving response relevance.

retrieve-on-demand

A document usage mode where the document content is indexed for semantic search and retrieved dynamically in response to user queries, as opposed to being directly displayed or downloaded. In retrieve-on-demand mode, the document serves as a knowledge base for answering questions rather than a static artifact for reading.

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

A sequential version number assigned to each upload of a document in the org_context_documents table, starting at 1 for the initial upload and incrementing by 1 for each subsequent re-upload of the same document. Revisions enable tracking of document changes over time, support provenance records that reference specific document versions, and allow administrators to understand which version of a document was used in historical analyses.

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.

rule code

A unique identifier assigned by an analysis tool to a specific rule or check within that tool's rule set, used in combination with the tool name to uniquely identify a rule across all integrated tools. Rule codes may be alphanumeric strings, numeric identifiers, or hierarchical codes depending on the tool's convention (e.g., 'E501' for a Python linting rule, 'SQL-001' for a database rule).

rule knowledge base

A repository of static analysis rule definitions, thresholds, and metadata (referenced as FR-19.4) that provides context for interpreting analysis results. The knowledge base is joined with submitted results during display to show rule descriptions, severity levels, and remediation guidance alongside raw findings.

rule_code

A unique identifier assigned by a security scanning tool to a specific rule or check within its rule set. Rule codes are tool-specific (e.g., Bandit's 'B201', 'B301') and serve as the primary key for looking up rule metadata, explanations, and remediation guidance in the knowledge base. The combination of tool and rule_code uniquely identifies a rule across the system.

S

sbom

Software Bill of Materials - a comprehensive inventory of all software components, libraries, dependencies, and their versions used in an application, including transitive dependencies. An SBOM provides transparency into the software supply chain, enabling vulnerability tracking, license compliance verification, and dependency risk assessment. Typically formatted as structured data (JSON, XML, SPDX, CycloneDX) and generated automatically during the build process.

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.

semgrep

A static analysis tool for code that uses pattern matching to find bugs, detect security vulnerabilities, and enforce code standards across multiple programming languages. Semgrep allows custom rule authoring using a YAML-based syntax to define code patterns that should be flagged or prevented.

sensitive content

Information in AI API requests or responses that should not be persisted in logs due to privacy, security, or compliance requirements, including but not limited to: personally identifiable information (PII) such as names, email addresses, and phone numbers; authentication credentials or API keys; proprietary business data; and any content classified as confidential by organizational policy. Sensitive content is identified through pattern matching, classification rules, or explicit tagging, and is redacted (replaced with placeholders like '[REDACTED]' or hash values) before log entries are written to persistent storage.

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.

settings_private.py

A Python configuration file that contains sensitive or environment-specific settings (such as OAuth client secrets, API keys, and database credentials) that should not be committed to version control. This file is excluded from Git via .gitignore and must be created manually in each deployment environment. The file is imported by settings.py and its values override or supplement the default configuration. In production environments, settings_private.py contains the actual OAuth2 client credentials for enabled providers.

severity

No definition yet.

severity floor

A minimum severity level threshold configured for a release scope that determines the lowest severity of issues or findings that will be included in quality gates, reports, or enforcement actions. Issues below the severity floor are excluded from consideration. The floor may be set to values such as LOW, MEDIUM, or HIGH, with higher floors filtering out lower-severity items.

severity mapping

A configuration field in a KB entry that defines how the severity level of a finding should be interpreted or translated within REQQA's severity classification scheme. Severity mapping may involve translating tool-specific severity levels (e.g., pylint's 'convention', 'refactor', 'warning', 'error', 'fatal') to REQQA's standardized severity scale (e.g., LOW, MEDIUM, HIGH, CRITICAL), or may involve curator-assigned severity overrides based on organizational risk assessment. The mapping ensures consistent severity treatment across findings from different tools.

severity tier

A classification level indicating the seriousness or risk level of a security rule violation, typically organized into categories such as CRITICAL, HIGH, MEDIUM, LOW, or INFO. Severity tiers are stored in a reference table and used to prioritize remediation efforts, with the severity_mapping column in the Rule Knowledge Base providing a foreign key reference to the appropriate tier for each rule.

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 warning

A non-blocking advisory notification displayed to users when a configurable threshold is exceeded, informing them of a potential issue or cost implication without preventing the operation from completing. Soft warnings allow users to acknowledge the condition and proceed, as opposed to hard errors that block the action entirely.

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.

source_type

A database column in org_context_documents that records the original file format of the uploaded document, with possible values including 'PDF', 'DOCX', 'Markdown', and 'plain text'. The source_type enables the system to select the appropriate text extraction method and provides metadata for display and audit purposes.

staging area

A temporary workspace or review interface where AI-generated requirements are held for human review and approval before being committed to the application's formal requirements repository. The staging area allows users to inspect, edit, accept, reject, or regenerate individual requirements without affecting the application's active requirement set, providing a quality gate between AI generation and formal acceptance.

static analysis

Automated examination of source code without executing it, using tools that parse and analyze code structure to detect potential defects, security vulnerabilities, coding standard violations, and complexity issues. Static analysis tools check for issues such as null pointer dereferences, buffer overflows, unused variables, cyclomatic complexity violations, and adherence to coding standards. Analysis is performed as part of the build process or code review workflow.

static-analysis category catalogue

A system-maintained registry of available static code analysis categories (such as code complexity, test coverage, security vulnerabilities, code style violations) that can be applied to a release scope, each with metadata including category name, default analysis tool, default enforcement level (required/advisory/excluded), and default threshold value. The catalogue serves as the authoritative source of analysis options presented to Release Analysts during scope configuration.

static-analysis profile

A configuration specification that defines the static code analysis rules, linters, formatters, and quality gates to be applied during a release build, including tool versions, rule sets, severity thresholds, and enforcement policies. The profile ensures consistent code quality checks across all components in a release.

statistics

Quantitative metrics about the static analysis run, such as total lines of code analyzed, number of files scanned, number of issues found per severity level, analysis execution time, and coverage percentages. Statistics provide summary information about the analysis scope and findings volume.

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.

stop-the-bleed

The second stage of the adoption ratchet lifecycle where critical or high-severity violations in a category are blocked from release, preventing the most serious quality regressions while allowing lower-severity issues to pass. This stage focuses on halting the worst problems before comprehensive enforcement.

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 analysis operations

AI-powered evaluation processes that assess user stories against quality criteria such as INVEST principles, Given/When/Then format compliance, completeness, clarity, and testability. Story analysis operations invoke the story analyser component and produce structured feedback including issues, recommendations, and readiness assessments.

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.

stub

A minimal help page record that reserves a template key in the help system but contains placeholder or incomplete content, indicating that full documentation has not yet been authored. Stub pages ensure every user-reachable template has a help entry (satisfying coverage requirements) while signaling that the content needs expansion or review.

stub entries

Minimal KB entry records created through batch import that contain only essential identifying information (rule code, tool name) and references to upstream documentation, but lack complete curator-authored content for explanation, risk note, and remediation hints. Stub entries serve as placeholders in the knowledge base, ensuring that all known rules have a KB presence while allowing curators to progressively enrich entries with detailed guidance over time. Stub entries are distinguished from complete entries and may be flagged for curator attention.

stub entry

Minimal KB entry records created through batch import that contain only essential identifying information (rule code, tool name) and references to upstream documentation, but lack complete curator-authored content for explanation, risk note, and remediation hints. Stub entries serve as placeholders in the knowledge base, ensuring that all known rules have a KB presence while allowing curators to progressively enrich entries with detailed guidance over time. Stub entries are distinguished from complete entries and may be flagged for curator attention.

suggested priorities

AI-generated priority classifications assigned to each generated requirement based on analysis of the mission statement, requirement type, and inferred business importance. Suggested priorities provide an initial prioritization that users can accept or override during review, helping to organize requirements for implementation planning. Priority values likely align with the system's existing priority taxonomy (such as mvp, dependency, valuable, nice-to-have as defined in the glossary).

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.

summary verdict

An overall pass/fail/warning assessment for the entire static analysis run, aggregating the per-category verdicts according to defined rules to determine whether the build meets minimum quality standards. The summary verdict is submitted via the summary endpoint and determines whether the build can proceed to acceptance.

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.

system-admin

A user role with elevated privileges responsible for managing access requests, performing system-wide configuration, and executing administrative operations that affect multiple organizations or the entire platform. System-admins have exclusive access to the access request triage interface and can view, update, and process requests from all organizations.

T

technical debt

The implied cost of additional rework caused by choosing a quick or expedient solution now instead of a better approach that would take longer. Technical debt accumulates when code quality issues, architectural shortcuts, incomplete implementations, or deferred refactoring are accepted to meet deadlines, creating future maintenance burden, increased defect risk, and reduced development velocity. Like financial debt, technical debt incurs 'interest' in the form of ongoing maintenance costs.

template

A predefined structure that defines the set of headings under which participants contribute entries for a specific topic. Each template specifies the organizational framework for a topic, determining what aspects or questions participants address. Templates are prepared before the session and associated with topics to guide structured contribution.

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.

text extraction

The process of converting binary document formats (PDF, DOCX) into plain text for inclusion in LLM prompts. Text extraction parses document structure, removes formatting metadata, and produces a text representation suitable for prompt assembly. Extraction quality varies by document format and complexity; poor extraction (garbled text, missing content, incorrect ordering) can degrade prompt quality and AI output. The Context Library performs text extraction when documents are uploaded and stores the extracted text for prompt assembly.

threshold

The maximum monetary amount of outstanding fines that a member may have while remaining eligible to borrow additional books. This value is a configurable business rule that may vary by membership type or library policy.

tier of attachment

A classification indicating the priority, relevance, or inclusion method of a context document in an AI prompt, potentially distinguishing between mandatory documents (always included), conditional documents (included based on analysis type), and optional documents (included based on relevance scoring). The tier determines the order of inclusion, truncation behavior when token limits are reached, and the weight given to the document's content in the analysis.

timeline

No definition yet.

toggle

A user interface control (such as a checkbox, radio button group, or switch) that allows the analyst to select between discrete states for a configuration option, such as setting a category's enforcement level to required, advisory, or excluded. Toggles provide a visual, interactive mechanism for changing settings without requiring text entry.

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 budget

A configurable limit on the total number of tokens (prompt + completion) that can be consumed by LLM API calls for a given scope (per-analysis, per-requirement, per-organization, or per-time-period). Token budgets provide cost control and prevent runaway API usage. When a budget is approached or exceeded, the system generates warnings (per AR-21.P4) but does not block operations. Token budget visibility is provided by FR-21.6.

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 impact

The effect of context-library attachment decisions on the total token count consumed by AI analysis operations, measured as the cumulative token cost of all context documents (org-wide, template-scoped, and scope-scoped) that will be included in analysis prompts. Token impact directly affects API costs and is made visible to administrators to inform attachment decisions.

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_estimate

An approximate count of the number of tokens (as defined by the AI model's tokenization scheme, typically GPT-style byte-pair encoding) that the extracted text would consume when included in an AI prompt. The estimate is calculated during document upload and stored to help administrators assess the cost and feasibility of including the document in analysis contexts, and to support token budget management for AI operations.

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.

tool

A software application, service, or automated system selected for performing a specific function within the release process, such as static analysis tools, test execution frameworks, deployment automation platforms, or quality gate enforcement systems. Each tool has a default selection for its category, and analysts may override the default to use an alternative tool that better suits the release requirements.

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.

top-k

A retrieval parameter specifying the number (K) of most similar chunks to return from a vector similarity search, ranked by descending similarity score. For example, top-5 returns the five chunks with highest cosine similarity to the query embedding. The K value balances retrieval precision (higher K includes more context but may add noise) against token cost and relevance.

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.

transient failures

Temporary error conditions that are likely to resolve on their own or through retry attempts, such as network timeouts, temporary service unavailability (HTTP 503), rate limit errors (HTTP 429), or brief connectivity issues. Transient failures are distinguished from permanent failures (authentication errors, invalid requests, resource not found) that will not succeed even with retries.

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.

ttl

Time To Live - a time limit or expiration period after which a resource, token, or cached value becomes invalid and must be refreshed or discarded. In the context of this system, TTL applies to deep links, seat holds, and passenger option selections to ensure timely decisions and prevent stale data.

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.

union

A set operation that combines two collections by including all unique elements from both collections, eliminating duplicates. In the context of merging recommended_analyses, the union operation combines the current step-codes with the new template's step-codes, preserving each unique step-code exactly once in the resulting comma-separated list.

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.

upstream docs

Official documentation maintained by the creators or maintainers of static analysis tools (such as pylint's rule documentation, flake8's error code reference, or bandit's security check descriptions) that provides authoritative descriptions of rules, their rationale, and recommended fixes. Upstream docs serve as the source material for KB entries and are linked from stub entries to provide analysts with access to original tool documentation when curator-authored content is not yet available.

upstream url

A hyperlink to the official documentation or reference material published by the analysis tool vendor or maintainer that describes the rule, its purpose, and recommended remediation. Upstream URLs provide authoritative information about rules and serve as the initial KB content before detailed explanation and remediation are added by the team.

upstream_url

A hyperlink to the authoritative external documentation or source repository for a security rule, typically pointing to the tool vendor's official rule documentation, CVE database entry, or security advisory. The upstream URL provides users with access to the original rule definition, detailed technical explanation, and any updates or errata from the rule's maintainer.

use_mode

A configuration attribute on org_context_documents that determines how a document is made available to AI analyses, with valid values 'static-include' (document content is included in every prompt above the cache frontier) or 'retrieve-on-demand' (document is indexed as embeddings and relevant chunks are retrieved per-analysis below the cache frontier). The mode is suggested automatically based on document size but can be overridden by administrators.

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.

uuid v4 format

A Universally Unique Identifier generated using random or pseudo-random numbers according to RFC 4122 version 4 specification. UUID v4 has the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal digit and y is one of 8, 9, A, or B. This format provides 122 bits of randomness and is suitable for distributed systems where collision probability must be negligible.

V

validated

A state indicating that a mission statement has undergone analysis (likely through an AI-driven analysis step similar to requirement analysis) and all critical issues identified during analysis have been resolved or accepted. Validation serves as a quality gate ensuring the mission statement is sufficiently clear, complete, and unambiguous before being used as input for requirements generation.

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.

vector storage

A specialized database or storage system designed to persist and index high-dimensional numerical vectors (embeddings) representing semantic content, enabling efficient similarity search operations. Vector storage systems use indexing algorithms (such as HNSW, IVF, or LSH) to support approximate nearest neighbor queries, allowing retrieval of vectors similar to a query vector based on distance metrics like cosine similarity or Euclidean distance.

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.