Glossary

Generated 2026-08-20 14:37. 1062 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 (124)
• B (49)
• C (122)
• D (78)
• E (29)
• F (25)
• G (16)
• H (25)
• I (47)
• J (4)
• K (3)
• L (22)
• M (36)
• N (22)
• O (38)
• P (106)
• Q (8)
• R (90)
• S (111)
• Symbols (2)
• T (63)
• U (20)
• V (14)
• W (8)

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

abuse correlation

The process of identifying patterns of malicious or fraudulent access requests by analyzing IP addresses, email domains, submission timing, and request content to detect coordinated spam campaigns, bot activity, or repeated attempts from blocked sources. Correlation enables proactive filtering and helps distinguish legitimate requests from abuse.

abuse patterns

Repeated or systematic misuse of the OAuth authentication system, including but not limited to: high-frequency sign-in attempts from the same IP or email, credential stuffing attacks, automated bot traffic, or attempts to exploit OAuth flows for unauthorized access. Abuse patterns are detected through analysis of authentication logs and may trigger rate limiting, account lockout, or security alerts.

accept header

An HTTP request header field (as defined in RFC 7231) that specifies the media types (MIME types) that the client is willing to receive in the response. The Accept header enables content negotiation, allowing the server to distinguish between browser-based requests (typically Accept: text/html) and API requests (typically Accept: application/json) and respond with appropriate content types and error handling.

acceptable performance thresholds

The maximum elapsed time or resource consumption limits within which a system operation must complete to meet user experience and system performance requirements. For avatar rendering, this would typically include image load time, rendering latency, and browser memory consumption constraints that ensure smooth user interaction without perceptible delay.

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.

access-request flow

The user journey and sequence of interactions through which a prospective user requests access to the REQQA platform, beginning from an entry point (login page, OAuth rejection page, or marketing site) and culminating in submission of an access request via the /requestAccess endpoint. The flow encompasses discovery of the request mechanism, navigation to the request form, and submission of the access request.

account

No definition yet.

account balance

The total monetary amount owed by a member to the library, calculated as the sum of all outstanding fines minus any payments or credits applied. The account balance is updated in real-time as fines are assessed or payments are received, and is used to determine whether borrowing privileges should be suspended.

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.

actionable findings

Analysis results that identify specific quality issues in requirements or stories and provide concrete recommendations for resolution. Actionable findings include: a clear description of the problem, its location in the artifact, severity rating (HIGH/MEDIUM/LOW), impact assessment, and specific remediation guidance. Each finding must be sufficiently detailed that an analyst can understand the issue and take corrective action without requiring additional clarification.

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.

adapter interface

A software abstraction layer that provides a consistent API for interacting with a specific technology or service, decoupling client code from the underlying implementation. The adapter pattern allows the underlying technology to be replaced without changing client code, as long as the new implementation satisfies the same interface contract. In this context, the adapter isolates the embedding pipeline and retrieval logic from direct dependencies on Qdrant.

adjudication

The process by which the AI model makes a semantic judgement on a flagged statement to determine whether a potential defect (such as a combinator joining capabilities versus conditions) represents an actual violation requiring a finding, as opposed to an acceptable usage.

adjustment

A modification to a passenger's booking, entitlements, or compensation resulting from a disruption event, executed according to policy-compliant re-accommodation workflows. These changes are recorded in the Case timeline with full auditability, including the rules applied, the previous state, and the deterministic decision that triggered the modification.

admin record

A database record in the access request management table that stores submitted access request details, accessible through the administrative interface at the path /adminInfoRequest/<id> for review and processing by REQQA team members with administrative privileges.

admin triage

The administrative process of reviewing candidate FAQ topics from the candidate queue and making a disposition decision: publish as FAQ entry (creating new content), improve existing content (updating related help pages), merge with existing FAQ (consolidating duplicates), or dismiss (marking as not requiring FAQ coverage). Triage includes evaluating signal strength (volume, recency), assessing whether existing content addresses the topic, and recording the decision rationale for audit purposes.

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.

agenda_sequence

An integer field on the help_pages table that defines the display order of pages within the demo agenda, with lower numbers appearing earlier in the walk-through. The sequence is editorially assigned (not derived) and applies only to pages with demo_inclusion != 'none'. Pages with NULL agenda_sequence or demo_inclusion='none' are excluded from the demo agenda rendering.

ai generation request

A user-initiated action that triggers the AI persona generation workflow, consisting of a text prompt describing the desired persona characteristics and optional scope parameters (org-wide or app-specific). The request initiates the process of retrieving existing personas, constructing the AI prompt with negative examples, invoking the AI service, and returning a persona draft for user review.

ai model

A machine learning model (such as GPT-4, Claude, or similar large language model) that has been trained to generate human-like text responses based on input prompts. In the context of persona generation, the AI model accepts a natural-language description of a desired persona and produces structured persona attributes (name, role, goals, frustrations, description, avatar_prompt) that conform to the persona scaffold format.

ai persona generation

The automated process by which an AI model creates a complete persona draft from a natural-language prompt, including generating appropriate values for all persona fields (name, role, goals, frustrations, description, avatar_prompt) that are internally consistent, contextually appropriate, and distinct from existing personas in the organization or application scope.

ai prompt

The complete text input submitted to an AI language model that includes instructions, context, constraints, examples, and the user's request, structured to elicit a specific type of response. In the context of persona generation, the AI prompt contains the user's generation request, existing persona data as negative examples, formatting instructions, and constraints to ensure the generated output meets system requirements.

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 service invocation

The act of making an API call to an external AI service provider to request persona generation, including constructing the request payload, transmitting the request, awaiting the response, and handling success or error outcomes.

ai-drafted helper

An AI-powered workflow component that generates suggested persona attribute values (name, role, description, goals, frustrations) based on minimal user input such as a role name or brief description. The helper invokes an AI service to produce draft content that users can review, modify, or discard before saving the persona, following REQQA's standard AI token accounting and error handling patterns.

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.

aiservice

The software component or module in REQQA responsible for interfacing with AI providers, managing API calls, and tracking token consumption. The aiService maps token counts returned by AI providers to REQQA's internal token bucket categories (prompttokens, completiontokens, cachecreationtokens, cachereadtokens).

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 registry

A centralized registration mechanism in modules/shared/analyzerRegistry.py that maps analysis step codes to their implementing classes, enabling the analysis engine to discover and instantiate the correct analyser component for each step. The registry provides the runtime binding between step codes (R-D, R-F, R-C, etc.) and the Python classes that execute those analyses.

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.

analyser step-code registry

A system-maintained reference data store containing all valid analyser step-codes (such as R-D, R-F, R-C) with their descriptions and metadata, used to validate recommended_analyses field values during template creation and updates. The registry serves as the authoritative source for determining which step-codes are recognized by the system and available for configuration on requirement templates.

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.

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

analysis run

A single execution of one or more analysis steps (R-D, R-F, etc.) against a specific requirement or story artifact, identified by a unique run identifier and timestamp. An analysis run groups multiple AI calls that were performed together as part of a coordinated analysis operation, enabling cost and usage reporting at the run level.

analysis step

A discrete analytical procedure within the DeFOSPAM methodology that examines a requirement or story from a specific perspective (such as Definitions, Features, or Outcomes). Each step applies predefined evaluation criteria, generates structured findings with severity ratings, and produces step-specific data structures. Steps are identified by codes (D-D, D-F, D-O, D-S, D-P, D-A, D-M) and can be executed independently or as part of the complete suite.

analysis-efficiency metric

A calculated measure of the cost-effectiveness of AI analysis operations, expressed as tokens consumed and monetary cost per issue found. This metric is computed as (total tokens used / total issues detected) and (total cost / total issues detected) for a given analysis run, requirement, or time period, enabling assessment of whether analysis operations are producing findings efficiently or consuming excessive resources relative to output quality.

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

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.

analytics profile

A predefined column selection configuration for AI log exports that includes dimensional data (date, artifact type, requirement, call type, model, provider, user, analysis step) and quantitative measures (input tokens, output tokens, total tokens, cache write tokens, cache read tokens, cache hit rate, latency, computed cost), while excluding the full prompt and response text. The analytics profile is optimized for performance analysis, cost tracking, and usage pattern identification in spreadsheet or business intelligence tools.

analyzers

Software components or modules within ReqQA that execute specific types 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 analyzer corresponds to a step-code and produces analysis results stored in the analyses and analysis_issues tables.

ancestor chain

The hierarchical path from a requirement upward through its parent requirement, grandparent, and all successive ancestors to the root of the requirement tree. The ancestor chain provides the hierarchical context necessary to assess whether a requirement's level of detail and abstraction is appropriate to its position in the requirement structure.

anonymized

The process of irreversibly transforming personal data such that it can no longer be attributed to a specific individual without the use of additional information kept separately. Anonymization techniques may include data masking, aggregation, generalization, or pseudonymization with key destruction, ensuring that re-identification is not reasonably possible even with computational effort.

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 credentials

Authentication information required to access an external API service, typically consisting of an API key, secret key, or token that proves the caller's identity and authorization to use the service. API credentials are issued by the service provider, must be kept confidential, and are validated by the provider before granting access to API endpoints.

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 request

An HTTP request made programmatically to a REST API endpoint (as opposed to a browser-based web request), typically identified by the Accept header containing 'application/json' or similar content type, and expecting a structured JSON response rather than HTML. API requests are used by external systems, mobile applications, or JavaScript clients to interact with the system programmatically.

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.

app-scoped

A persona generation mode where the AI model is provided with context about a specific application (its purpose, domain, existing requirements, and user stories) to generate personas whose roles and goals are relevant to that application's functionality. App-scoped generation produces personas tailored to the application's user base rather than generic user archetypes.

app-scoped persona

A persona that is restricted to a single application within an organization (identified by a non-NULL appid value), representing user archetypes relevant only to that application's domain or user base. App-scoped personas are generated with application context to ensure relevance to the application's specific workflows and are not offered for selection in other applications within the same organization.

app-specific

A scope classification indicating that a persona is restricted to a single application within an organization, identified by a non-NULL appid value. App-specific personas represent user archetypes that are relevant only to one application's domain or user base, and are not offered for selection in other applications, enabling focused persona sets tailored to each application's context.

append-only

A data structure or storage pattern where records can only be added (appended) but never modified or deleted. This ensures immutability and provides a complete audit trail of all events in chronological order.

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.

application context

The currently active application scope within which a user is working, determined by the application selected or implied by the current requirement, story, or scope being viewed or edited. The application context determines which app-specific personas are visible and available for assignment, with org-wide personas (appid NULL) always available regardless of context. The context is typically derived from the application_id of the artifact being worked on or explicitly selected by the user when viewing persona lists.

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.

approximate cost figure

A monetary cost estimate calculated by multiplying token counts by the configured rate per token for the AI provider used in the analysis. The figure is 'approximate' because it reflects the rate configured in the system at display time, which may differ from the actual rate charged by the provider if rates have changed or if volume discounts apply. Displayed in the organization's configured currency with appropriate precision (typically 2-4 decimal places).

appview

The primary landing page or dashboard displayed to authenticated users after successful login, serving as the main entry point for accessing REQQA application features and navigation.

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.

artefact-scoped analysis

An analysis operation that examines a single requirement or artifact in isolation, using only the content of that artifact, its ancestor chain, and the application mission as input. Artefact-scoped analyses cannot assess properties that require examining relationships between peer requirements or the completeness of a requirement set as a whole.

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.

artifacts

Unintended visual distortions or anomalies introduced into a digital image during processing, compression, or resizing operations. Common artifacts include blocking, ringing, banding, or noise patterns that degrade image quality and were not present in the original source image.

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.

assigned requirements count

A numeric display value showing the total number of requirements to which a persona is currently assigned, calculated by counting active requirement_personas join table records for that persona and displayed as a summary metric on the persona detail view.

assigned requirements list

A tabular or list-based UI component displayed on the persona detail view showing all requirements to which the persona is currently assigned, with columns for requirement ID, title, and assignment type (Primary/Secondary), derived from the requirement_personas join table and ordered by requirement ID or assignment timestamp.

assignment

The association or linkage of a persona to a requirement, indicating that the requirement is written from the perspective of or is relevant to that persona's goals and needs. Assignments are stored as references (foreign keys) rather than copies, so changes to the persona record automatically propagate to all requirements that reference it. Multiple personas can be assigned to a single requirement to represent different user perspectives.

assignment count

The total number of current requirement_personas join table records linking a specific persona to requirements, representing how many requirements currently reference that persona. The assignment count is calculated dynamically by counting active assignments and is used to determine whether a persona can be deleted (count must equal zero).

assignment history

A chronological record of all persona-to-requirement assignments and removals for a specific requirement, stored in the requirements_history table as immutable snapshots. Each history entry captures the persona's name and role at the time of assignment, preserving the persona state even if the persona is later edited or deleted. Assignment history enables audit trails and ensures historical requirement context remains intact regardless of subsequent persona changes.

assignment history snapshot

A point-in-time capture of a persona's identifying attributes (name and role) stored in the requirements_history table when a persona assignment is created or modified. The snapshot preserves the persona's identity at the time of assignment, ensuring historical records remain intact even if the persona is later modified or deleted.

assignment interface

A user interface component or modal dialog that allows Org Members to select personas for assignment to a requirement, designate one as primary, set drives_stories flags, and save the assignments. The interface displays org-scoped personas, provides controls for primary designation, and enforces validation rules before persisting changes.

assignment list

An ordered collection of persona assignments displayed in the user interface, showing which personas are currently assigned to a requirement. The list may be rendered as a table, dropdown, tag collection, or other UI component, and provides visual representation of the many-to-many relationship between the requirement and its assigned personas.

assignment operation

The process of creating or updating a persona-to-artifact association in REQQA, consisting of: (1) authentication and authorization checks verifying the user belongs to the same organisation as both the persona and the target artifact, (2) validation that the persona and artifact exist and are accessible, (3) creation or update of the assignment record with full audit metadata, and (4) enforcement of idempotency rules to prevent duplicate assignments. The operation is atomic and must maintain referential integrity across the persona, artifact, and organisation entities.

assignment record

A database entity that establishes the relationship between a persona and a requirement or story, storing the persona ID, artifact ID (requirement or story), artifact type, organisation ID (orgid), assigning user ID, assignment timestamp, and audit metadata. The record enforces tenant isolation by validating that the persona's orgid matches the authenticated user's orgid before creation.

assignment type

A classification indicating whether a persona assignment to a requirement is designated as 'Primary' (the principal user perspective for the requirement) or 'Secondary' (an additional user perspective), derived from the is_primary flag in the requirement_personas join table and displayed in the assigned requirements list.

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.

asynchronous

A processing pattern where email sending operations are decoupled from the user request-response cycle, allowing the system to accept the notification request, queue it for later processing, and immediately return control to the calling operation without waiting for email delivery completion. This prevents slow email operations from blocking user-facing transactions and improves system responsiveness.

atomically

A property of a database operation where all changes within a transaction either complete successfully together as a single indivisible unit, or all fail together with no partial effects, ensuring data consistency. In the context of primary persona changes, this means both the unset of the old primary flag and the set of the new primary flag occur in a single transaction with no intermediate state where zero or multiple primary personas exist.

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.

audit profile

A comprehensive column selection configuration for AI log exports that includes all fields from the gptlog table, including the complete prompt text and response text for each AI call. The audit profile is restricted to users with is_system_admin privileges and is intended for compliance investigations, security audits, and detailed forensic analysis of AI system behavior. Access to the audit profile is logged and subject to heightened security controls due to the potential presence of sensitive information in prompt and response content.

audit trail

A chronological record of all changes to a data entity, capturing who made each change, when it occurred, and what was modified. In the context of persona assignments, the audit trail consists of the created_at, created_by, updated_at, and updated_by fields that enable tracing the complete lifecycle of each assignment from creation through all subsequent modifications.

audit trail entry

A single immutable record in the audit trail that captures metadata about a specific system event or user action, including the action type, acting user identifier, timestamp, affected entity, changed fields, and optionally before/after values. Audit trail entries enable traceability, accountability, and forensic investigation of system changes.

authentication context

The set of identity and authorization metadata associated with the current request or session, including the authenticated user's ID, email, organization membership, authentication method (UI session or API token), and permissions. The authentication context is established during login or API token validation and is used to populate audit fields (created_by, updated_by) and enforce access control rules.

authentication token

A cryptographically secure credential (such as a session token, JWT, or API key) that proves a user's authenticated identity and is transmitted with each request to verify the user's authorization to access protected resources. Authentication tokens may be stored in cookies, HTTP headers, or local storage depending on the authentication mechanism.

authoring worklist

A filtered view or queue of help pages that require human review or editing, including pages flagged as stale, pages in draft status, or pages identified by GUIDE skills as having gaps or inconsistencies. The authoring worklist provides a prioritized task list for help content maintainers and surfaces pages needing attention.

authorised user

A user with sufficient permissions to perform persona management operations, including creating, editing, and viewing personas within their organization. Authorization is determined by role-based access control rules and organizational membership, ensuring only users with appropriate privileges can modify persona definitions.

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.

auth_user

The database table or model in py4web that stores user account records, including authentication credentials, profile information, and account status, serving as the primary user identity store for the application.

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.

auto-resized

The automated process of adjusting an uploaded image's dimensions to match predefined target dimensions through scaling algorithms, performed by the system without user intervention during avatar upload processing.

autocomplete

A user interface feature that predicts and suggests possible completions for partially-typed input, displaying a dropdown list of matching options as the user types. In this context, autocomplete queries the definitions.term field to show matching glossary terms after the user enters 2 or more characters, enabling faster term lookup without requiring exact spelling or full term entry.

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.

available categories

The set of tag category identifiers from the system tag catalogue that are valid for assignment when creating or editing custom tags, presented to administrators as selection options in the category field. Available categories are drawn from the category catalogue (FR-03.1.1) and represent the complete taxonomy of tag classification types.

avatar

A graphical image or icon representing a persona, typically a photograph, illustration, or stylized portrait that provides visual identification and humanizes the persona record. The avatar is stored as binary image data in the database and displayed in persona lists, cards, and requirement associations to enable quick visual recognition.

avatar generation

The automated process of creating a persona avatar image by constructing a text prompt from persona attributes (name, role, description, goals, frustrations) and invoking an image-generation model to produce a visual representation. Avatar generation is an optional alternative to manual image upload, requiring configuration of an image-generation model and producing images that are normalized and stored as blobs per FR-26.7 requirements.

avatar thumbnail

A small graphical representation or icon (typically 40x40 to 100x100 pixels) associated with a persona that visually identifies the persona's role or character, displayed in list views and summary displays to provide quick visual recognition without requiring full-size images.

avatar_prompt

A text description stored with a persona (per FR-26.8) that describes the desired visual characteristics, role, and appearance of the persona's avatar image. The prompt is used as input to an image-generation model to create a visual representation of the persona, and can also be copied and pasted into external image generation tools when in-app generation is unavailable. The prompt typically includes details such as role, age, setting, style, and any specific visual attributes that characterize the persona.

avatar_prompt field

A database field or UI element on the persona creation/editing form that stores or displays the text prompt that would be used for avatar generation, enabling users to copy the prompt for use in external image generation tools when the system's built-in avatar generation is unavailable. The field is populated automatically from persona attributes and is read-only or copy-only, not editable by users.

average per-call retrieval cost

The mean monetary cost incurred for retrieving context document chunks during a single AI analysis operation, calculated by multiplying the average retrieved tokens per call by the token pricing rate for the configured AI provider. This metric enables organisations to estimate the incremental cost impact of retrieval-mode documents on their AI analysis operations.

average retrieved tokens per call

A computed metric representing the mean number of tokens from a specific context document that are included in AI prompts across multiple analysis operations, calculated by summing retrieved token counts from FR-23.5 provenance records over a defined period (last N analyses) and dividing by the number of analyses. This metric indicates the typical token cost contribution of a document to each analysis operation.

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 item #273

A work item or issue tracked in the REQQA development backlog system that documents the retrofit effort to create formal requirement specifications for the eleven analysis steps (R-D through R-M) that were implemented before this parent requirement existed.

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.

backlog-to-requirement link

A confirmed association between one backlog item and one requirement, recording the item, the requirement, the user who confirmed it and the time of confirmation. The link is proposed by the system where an item's text names a requirement reference, but is never created without human confirmation; it may be removed, and its removal is recorded. It is the relationship through which a backlog item's elaboration stage above E0 is derived. The qualified term is used in preference to the bare word "link", which occurs throughout the corpus in its ordinary sense.

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.

balanced judgement

An analytical assessment where the evidence for two competing interpretations or classifications is approximately equal in strength, such that neither reading can be definitively preferred over the other. In REQQA analysis, balanced judgements are typically raised as MEDIUM severity findings with both interpretations stated, allowing the human analyst to make the final determination rather than the analysis step imposing a choice.

base plugin

The parent OAuth authentication plugin class provided by the web framework (py4web/pydal) that implements standard OAuth 2.0 authentication flow including token exchange, user profile retrieval, and account creation. The base plugin is delegated to by provider-specific subclasses after the invite-gating logic passes, allowing the standard authentication flow to proceed.

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.

believability

A quality attribute of a persona indicating that the persona's characteristics, goals, frustrations, and behaviors form a coherent, realistic representation of a plausible individual that stakeholders can relate to and use for design decisions. A believable persona has internally consistent attributes, avoids stereotypes or contradictions, and reflects authentic user motivations and contexts.

bi tool

Business Intelligence tool - a software application that analyzes, visualizes, and reports on business data to support decision-making. BI tools typically provide capabilities for data import, transformation, aggregation, visualization (charts, dashboards), and interactive exploration. Examples include Tableau, Power BI, Looker, and Metabase. In the context of AI log exports, BI tools consume CSV exports to create dashboards tracking token usage, cost trends, and analysis patterns.

blob

Binary Large Object - a database column type designed to store binary data such as images, documents, or multimedia files directly in the database as a sequence of bytes, as opposed to storing a file path reference to filesystem-stored content.

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.

blocking edge

A directed dependency between two backlog items meaning the target cannot proceed until the source is complete. The only edge kind that constrains ordering, and the only kind among which cycles are detected.

bmp

Bitmap Image File - a raster graphics image file format native to Microsoft Windows, identified by the .bmp extension. BMP files typically store uncompressed pixel data, resulting in large file sizes but preserving exact image quality. BMP supports various color depths from monochrome to 32-bit true color.

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.

book

A physical or digital item in the library's collection that can be borrowed by members, identified by a unique catalog identifier. Books have attributes including availability status, loan history, and classification (e.g., reference vs circulating material).

bootstrap script

A one-time executable program or database script that creates the initial demo organisation and application by cloning content (requirements, stories, personas, analyses) from an existing production application. The script runs once during initial setup to populate the demo data, after which the fixture file becomes the authoritative source for subsequent re-seeding operations.

bot-style traffic

Automated or scripted authentication attempts from non-human actors, such as web crawlers, security scanners, or malicious bots that attempt to create accounts using random or harvested OAuth credentials. Bot-style traffic is characterized by high volume, lack of valid invitations, and attempts to create accounts without legitimate user intent.

boundary

The extreme or edge values of a valid input range, including minimum values, maximum values, empty/null values, and values just inside and outside the valid range. Boundary testing validates system behavior at these edge cases to ensure proper validation and error handling.

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.

brown cow model

A requirements analysis framework developed by Robertson and Robertson that uses a four-quadrant model to distinguish between current/future states and how/what perspectives, helping analysts separate solution-focused thinking from needs-focused thinking and avoid premature design constraints in requirements.

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 assertion

An automated verification check executed during the build or CI/CD pipeline that validates a specific condition must be true before the build can succeed. If the assertion fails (condition evaluates to false), the build process terminates with an error, preventing deployment of the artifact. In this context, a build assertion verifies that help content version stamps match the application version being released.

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.

build step

A discrete operation or task executed as part of an automated build pipeline, typically defined in a build script or CI/CD configuration file, that performs a specific function such as compiling code, running tests, or generating documentation. Build steps execute sequentially or in parallel according to dependency rules and can fail independently, halting the build if critical.

build-coupling

A deployment strategy where help documentation is compiled and versioned in lockstep with application code during the build process, ensuring that the help content displayed to users always matches the exact version of the application they are running. Build-coupling prevents version drift between code and documentation by making help content an integral part of the release artifact.

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.

built_for_version

A database column in the help_pages table that stores the application version number (in semantic versioning format X.Y.Z) for which the help content row was compiled and released. This column enables runtime verification that displayed help content matches the running application version and supports detection of version mismatches.

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 persona retrieval

An API operation that fetches multiple persona records in a single request by providing a list of persona identifiers, typically using a query parameter format such as '?ids=id1,id2,id3'. The operation returns only personas that belong to the authenticated user's organization and that the user has permission to access.

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 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. This metric is tracked per organization and measures the effectiveness of prompt caching strategies.

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-read

The process of reusing previously cached prompt content from the AI provider's cache, avoiding reprocessing costs. Cache-read tokens represent content served from cache and are typically priced significantly lower than input tokens, providing cost savings for repeated prompt segments.

cache-write

The process of storing prompt content in the AI provider's cache for the first time, incurring a one-time caching cost. Cache-write tokens represent newly cached content and are typically priced higher than standard input tokens but lower than uncached processing on subsequent calls.

cachecreationtokens

The count of tokens that were newly added to the AI provider's cache during an API call, corresponding to the cache-write operation. These tokens incur a one-time caching cost and are tracked separately from standard input tokens and cache-read tokens.

cached data

A previously computed and stored copy of dashboard metrics (pipeline funnel, conversion rates, time-to-place, staff caseload) that can be served to users without re-executing database queries, reducing response time during high load. Cached data includes a timestamp indicating when it was computed and is served with a staleness indicator when fresh data cannot be computed within the degradation threshold.

cached tokens

Tokens from previously processed prompt content that are stored and reused by the AI provider to reduce processing costs. Cached tokens are divided into cache-write tokens (newly cached content) and cache-read tokens (reused cached content), each with distinct pricing.

cachereadtokens

The count of tokens that were served from the AI provider's cache during an API call, corresponding to the cache-read operation. These tokens incur a reduced cost compared to standard input tokens and represent reused prompt content.

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.

caddy

An open-source web server and reverse proxy written in Go that provides automatic HTTPS certificate management, HTTP/2 support, and simple configuration syntax. In this system, Caddy serves as the reverse proxy in front of the py4web application server, handling TLS termination and request routing.

call type

A classification of AI operations by their purpose and workflow context, such as 'requirement_analysis', 'story_generation', 'synthesis', or 'mission_validation'. Call type is identified by the promptname field in gptlog and determines how the call is categorized in usage reports and cost summaries.

callback

An HTTP endpoint in the application that receives the authorization response from an OAuth2 provider after user authentication, processes the authorization code or error, exchanges the code for an access token, retrieves user profile information, and completes the sign-in flow by creating or updating the user session.

callback handler

A server-side endpoint or function that receives the OAuth authorization response from an OAuth provider after a user completes authentication. The callback handler processes the authorization code, exchanges it for an access token, retrieves user profile information, and completes the sign-in flow by creating or updating the user's session in REQQA.

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.

canonical metadata

The authoritative, reference version of template configuration data (specifically recommended_analyses values) that serves as the source of truth for inheritance by requirements created from those templates. Canonical metadata is established through the population process and represents the reviewed, approved default analysis selections that will be propagated to new requirements, ensuring consistency across the organization's requirement creation workflow.

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.

capped limit

The maximum file size permitted for persona avatar uploads, expressed in megabytes (MB) or kilobytes (KB), enforced to prevent excessive storage consumption and ensure reasonable upload times. Uploads exceeding this limit are rejected with a validation error.

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.

capture errors

Failures that occur during Playwright screenshot capture, including: HTTP 500 errors when navigating to pages, authentication failures preventing login, missing UI elements that the script expects to find, browser crashes, timeout errors waiting for page load, filesystem errors writing screenshot files, or any other exception that prevents successful screenshot generation. Capture errors are distinguished from warnings or non-critical issues and cause the script to fail the build.

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 delete

A database referential integrity constraint that automatically deletes child records when their parent record is deleted. In the context of basket management, when a Basket record is deleted, all associated BasketItem records are automatically deleted by the database due to the foreign key constraint with ON DELETE CASCADE, ensuring data consistency without requiring explicit application-level deletion logic.

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.

case-insensitive comparison

A string comparison operation that treats uppercase and lowercase letters as equivalent, such that 'Custom-Tag', 'custom-tag', and 'CUSTOM-TAG' are considered identical matches. Typically implemented by converting both strings to the same case (upper or lower) before comparison, or using locale-aware comparison functions that ignore case differences.

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.

chained

A sequential evaluation approach where the output of one analysis phase (deterministic pattern matching) serves as input to a subsequent phase (AI-assisted semantic evaluation). In the R-W step, deterministic checks may flag candidate issues (such as statements containing combinators) which are then adjudicated by the language model to determine if they represent actual defects.

checkbox control

A user interface input element that allows users to select or deselect multiple options independently by clicking on small boxes that display a checkmark when selected. In the context of template editing, checkbox controls enable Template Administrators to select multiple analyser step-codes simultaneously for the recommended_analyses field, with each step-code represented by its own checkbox that can be toggled on or off.

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.

checksum

A computed value derived from data content using a mathematical algorithm, used to verify data integrity during transmission or storage. In the context of event processing and audit trails, checksums ensure that disruption events, passenger records, and policy rules have not been corrupted or tampered with, supporting the system's auditability requirements.

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 count

The total number of discrete text segments (chunks) into which a context document has been divided during the indexing process for retrieval operations. Each chunk represents a semantically coherent portion of the document that can be independently retrieved and included in AI prompts based on similarity scoring.

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.

chunked

The process of dividing a large document into smaller, overlapping or non-overlapping segments (chunks) of fixed or variable size (typically 500-2000 tokens) for embedding and retrieval. Chunking enables semantic search at a granular level and ensures retrieved context fits within token limits. Chunk boundaries may respect sentence or paragraph boundaries to preserve semantic coherence.

chunking

The process of dividing a large document into smaller, overlapping segments (chunks) of text for embedding generation and vector storage. Chunking strategies balance semantic coherence (keeping related content together) against chunk size constraints imposed by embedding models and retrieval performance requirements.

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.

chunk_index

A zero-based sequential integer assigned to each chunk within a document, indicating the chunk's position in the original document order. The chunk_index enables reconstruction of document structure, supports ordered retrieval of adjacent chunks, and provides a stable identifier for chunks within a document revision.

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.

claude-code skills

Executable workflow automation capabilities in Claude Code that are defined as markdown files in the .claude/commands/ directory and invoked via slash commands to perform specific development tasks such as generating documentation, creating stubs, or producing reports. Skills encapsulate reusable logic that can be triggered independently during the development lifecycle.

clause

A numbered section or subsection within an ISO/IEC/IEEE standard document that contains specific requirements, definitions, or guidance. Clauses are hierarchically organized (e.g., 5.2.5, 5.2.6) and serve as the standard's structural units for referencing specific content.

cleanup tab

A user interface tab within the requirement view that provides access to the requirement cleanup facility, displaying mechanical quality reports, section quality analysis, and controls for applying corrections. The cleanup tab is the primary interface for accessing FR-02.1 functionality.

clear message

An error message displayed to users when a hard stop is triggered, containing: (1) a statement that the budget limit has been reached, (2) the specific threshold exceeded (token or cost), (3) the current usage level, (4) instructions for how to proceed (contact administrator, wait for reset, request budget increase), and (5) a reference code for support purposes. The message must be non-technical, actionable, and displayed prominently in the user interface.

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.

cold visitor

A prospective user who arrives at the REQQA login page without a pre-existing invitation, account, or prior relationship with the system. Cold visitors are not authorized to create accounts directly but can submit an access request via the public /requestAccess form (FR-20.6), which is reviewed by system administrators who may issue an invitation if approved.

cold visitors

Users who attempt to access REQQA without a pending invite or existing account. Cold visitors are individuals who have not been pre-authorized to use the system and arrive via direct URL access, search engines, or other discovery mechanisms. In an invite-only system, cold visitors are redirected to an informational page (FR-20.6) explaining that REQQA is invite-only and providing instructions for requesting access.

collision

A matching ambiguity that occurs when multiple artifacts (requirements or stories) have identical or near-identical titles, making it impossible to uniquely resolve an orphaned AI log to a single artifact based on title alone. Collisions require additional disambiguation using analysis timing windows and artifact IDs to determine the correct match.

combinator

A conjunction or coordinating word (such as 'and', 'or', 'but', 'also', 'however') that joins two or more elements in a requirement statement. Combinators are significant in singularity analysis because they may join either multiple capabilities (a defect) or multiple conditions/objects/qualifiers for a single capability (acceptable).

comma-separated values

A text format for representing multiple values in a single string by separating each value with a comma character, optionally with whitespace trimming. In configuration contexts, comma-separated values allow specifying multiple email addresses (e.g., 'user1@example.com, user2@example.com, user3@example.com') in a single configuration parameter, which the application parses into a list for processing.

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.

common.py

A Python module in the py4web application that contains shared initialization code executed during application startup, including authentication configuration, OAuth provider registration, and other common setup tasks. The file is located in the application root directory and is imported by py4web's initialization process. OAuth provider plugins are conditionally registered in common.py based on the presence of credentials in settings.py.

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.

completed analysis

An analysis operation that has finished execution (successfully or with errors) and has persisted its results to the analyses table, including all associated token usage data in gptlog. A completed analysis has a definitive outcome (success, failure, or partial completion) and is no longer in 'running' or 'queued' state. Distinguished from in-progress analyses which may not yet have final token counts available.

completiontokens

The count of output tokens generated by the AI provider in response to a prompt, representing the AI's generated text. Completion tokens are priced at the output rate and are distinct from input tokens (prompttokons and cached tokens).

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

Occurring or executing at the same time or overlapping in time, such that multiple operations are in progress simultaneously and may interact or conflict with each other. In the context of database operations, concurrent requests are those that are processed by the system in overlapping time windows, potentially accessing or modifying the same data, requiring coordination mechanisms (locks, transactions, optimistic concurrency control) to maintain data consistency.

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 edge

A directed dependency meaning the target waits on a result produced by the source rather than on its completion. Carries the condition and the decision point at which it is judged, and is treated as a stop rather than an ordering: completing the source does not satisfy it.

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.

configurable fraction

A user-defined percentage or ratio of the total budget threshold at which a soft warning is triggered, expressed as a decimal (e.g., 0.8 for 80%) or percentage (e.g., 80%). The fraction allows organizations to receive advance notice before reaching hard limits, with typical values ranging from 0.5 to 0.9 depending on risk tolerance and operational needs.

configuration changes

Modifications to system parameters, data definitions, or operational settings that alter system behavior without changing executable code, including topic definitions, templates, coverage steering parameters, and other moderator-prepared data that can be deployed independently of application code releases.

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 email

An automated email message sent to a newly registered member's provided email address, confirming successful account creation and typically containing the assigned membership number, welcome information, and next steps for using library services.

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.

conformance

The degree to which a requirement adheres to the structural and content rules defined by its assigned template, including the presence of all mandatory sections, correct use of terminology, and satisfaction of template-specified characteristics. Conformance is verified through automated analysis steps that compare requirement content against template declarations.

consistency check

A validation performed by the R-N analysis step to verify that a requirement's content is consistent with its stated parent requirement, ensuring the requirement represents a decomposition, refinement, or constraint of the parent rather than addressing unrelated concerns. The consistency check detects drift from the parent's scope.

console output

Text written to the standard output stream (stdout) of a command-line process, typically displayed in the terminal or command prompt window where the script was executed. Console output can be redirected to files or piped to other processes using shell operators.

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.

constructed prompt

A text string assembled by the system from persona attributes (name, role, description, goals, frustrations) that serves as input to an image-generation model, formatted according to the model's prompt requirements to specify the desired characteristics of the avatar image to be generated.

content shape

The expected structure, format, and metadata requirements for markdown files within a content surface, including required frontmatter fields (title, date, author, tags), heading hierarchy conventions, use of Docusaurus-specific features (admonitions, tabs, code blocks), and any surface-specific formatting rules that ensure consistency and enable proper rendering and indexing.

content surfaces

Distinct categories or sections of documentation content within the Docusaurus site, such as how-to guides, FAQ entries, manual pages, and other organized content directories that are indexed separately but searchable through a unified interface.

contentid

A database column in the gptlog table that stores the unique identifier of the artifact (requirement or story) being analyzed, enabling linkage between AI calls and the specific content they operated on. For requirements, this is the requirement ID; for stories, this is the story ID. The contentid enables filtering and reporting of AI calls by artifact.

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.

contribution

A markdown-formatted text entry created by a participant under a specific template heading within a selected topic. Each contribution is individually owned by its creator (identified by nickname), can only be edited or deleted by that creator, and is attributed to the creator in all exports. Contributions are the atomic unit of workshop output and are counted in moderator statistics.

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.

conversion rate

The percentage of shopping sessions or baskets that result in a completed purchase transaction, calculated as (completed checkouts / total baskets created) × 100. Conversion rate is a key e-commerce performance metric used to measure the effectiveness of the shopping experience and basket functionality.

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.

correlation id

A unique identifier assigned to a sequence of related events or messages that enables tracing a transaction or fault scenario across multiple system components (device, tablet, HQ client) by linking log entries that share the same correlation ID, supporting root cause analysis in distributed systems.

corrupted image file

An image file that contains invalid, incomplete, or malformed data that prevents successful parsing, decoding, or rendering by standard image processing libraries. Corruption may result from incomplete file transfers, storage media errors, intentional tampering, or files that claim to be images (by extension) but contain non-image data. Detection typically involves attempting to decode the file header and verifying structural integrity.

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.

create new persona action

A user interface control (button, link, or menu item) displayed on the personas list page that, when activated, navigates the user to the persona creation form to begin defining a new persona record. The action is available to all Org Members with persona creation permissions.

cross-check

A validation step that disambiguates collision cases by comparing the orphaned log's timestamp against the time window of analysis runs (from started to completed) and verifying that the artifact ID in the candidate match corresponds to an analysis run that was active during the log's creation time. Cross-checking ensures that matched artifacts are temporally and contextually consistent with the orphaned log.

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.

cta

Call To Action - a button, link, or instruction in a user interface or message that prompts the user to take a specific action, such as 'Rebook Now', 'View Options', or 'Accept Compensation'. CTA placement and wording significantly affect user engagement and conversion rates.

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.

curated summary reports

A predefined, fixed set of summary views that present key metrics and insights from AI analysis operations in an at-a-glance format, as opposed to user-defined custom reports. Curated reports are designed by the system to answer common operational questions about token usage, costs, cache performance, and analysis efficiency.

curated summary set

A small, predefined collection of aggregate metrics and reports built into the application that provide high-level visibility into AI usage patterns, such as total calls per organization, cost by call type, or usage trends over time. The curated summary set is distinguished from the flexible CSV export capability and represents the minimal in-app reporting interface, with the expectation that detailed analysis will be performed via exported data.

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.

currency check

A validation performed by the R-N analysis step to determine whether a requirement is currently applicable and has not been made obsolete by the passage of time, changes to the system, or withdrawal of dependencies. The currency check examines applicability dates, system references, and requirement dependencies to detect obsolescence indicators.

current assignments

The set of active requirement_personas join table records linking a persona to requirements at the present moment, excluding historical assignments that have been removed or superseded. Current assignments represent the live, operational linkages between a persona and requirements that determine whether the persona can be deleted.

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.

dashboard tile

A discrete visual component within an administrative dashboard that displays a specific metric, summary, or data visualization in a self-contained rectangular area. Dashboard tiles typically include a title, primary metric value, supporting details, and may provide drill-down or navigation capabilities to detailed views.

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.

database blob

Binary Large Object (BLOB) - a database column type designed to store binary data such as images, documents, or multimedia files directly in the database rather than as file system references. In MySQL, BLOB types include TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB with varying size limits. For persona avatars, the blob stores the normalized image data after upload processing.

database column

A vertical data field in a database table that stores a specific attribute for all records in that table, identified by a column name and defined with a data type, constraints, and other metadata. In this context, 'req_templates.recommended_analyses' refers to the column named 'recommended_analyses' in the 'req_templates' table that stores the comma-separated list of analyser step-codes for each requirement template.

database connection

An active communication channel between an application and a database server that enables the application to execute queries, retrieve results, and perform transactions. Database connections are established through authentication, maintained during operation, and closed when no longer needed. Connection management includes pooling, timeout handling, and resource cleanup.

database sessions

A sequence of database operations performed within a single connection lifecycle, from connection establishment through query execution to connection closure. Database sessions maintain transaction context, temporary state, and connection-specific settings. Data persisting 'across database sessions' means it survives connection closure and is available in subsequent connections.

db blob

Database Binary Large Object - a database column type designed to store large binary data such as images, documents, or multimedia files directly within the database as raw bytes. BLOBs enable storage of unstructured binary content alongside structured relational data, though they may have size limits and performance implications compared to file system storage with database references.

dead-letter queue

A message queue that stores messages that cannot be processed successfully after multiple retry attempts, preventing them from blocking the main processing queue. Dead-letter queues enable manual inspection, debugging, and remediation of failed messages while maintaining system throughput for valid messages.

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.

decision record

A structured document or database record that captures the rationale, context, and justification for a specific design or operational decision, including the decision made, alternatives considered, reasons for the chosen approach, and any constraints or trade-offs. In the context of template analyses, a decision record documents why certain templates receive no recommended analyses, providing audit trail and knowledge preservation.

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 option

The pre-selected choice in a prompt or form that will be applied if the user dismisses the prompt without making an explicit selection, or that is visually indicated as the recommended choice. In the merge options prompt, 'Keep' is the default option, preserving the current recommended_analyses when the user dismisses the prompt or does not make an active selection.

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.

definition text

The verbatim wording from an ISO/IEC/IEEE standard that defines a term, concept, or requirement characteristic. Definition text is subject to copyright and licensing restrictions, and should not be reproduced without permission; instead, standards should be referenced by clause number.

defospam

A systematic methodology for analyzing user stories to ensure completeness and testability. The acronym stands for Definitions, Features, Outcomes, Scenarios, Prediction, Ambiguity, and Missing — seven analytical dimensions that examine whether a story is well-specified. Each dimension corresponds to an analysis step (D-D through D-M) that identifies specific types of defects or gaps.

degradation policy

A set of rules defining how the system should respond when performance targets cannot be met, specifying fallback behaviors, reduced functionality modes, and user notification strategies to maintain acceptable service levels under adverse conditions. The policy prioritizes graceful degradation over complete failure, ensuring users receive partial or cached information rather than errors.

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.

delete action

A user interface control (button, icon, or menu item) associated with a specific persona in the list view that, when activated, initiates the persona deletion workflow including validation of assignment status and display of a confirmation dialog. The action is available to Org Members with persona delete permissions and is disabled for personas with active requirement assignments.

deletion confirmation prompt

A modal dialog or UI overlay displayed when an administrator initiates deletion of a custom tag, requiring explicit user confirmation before proceeding with the irreversible deletion operation. The prompt typically displays the tag name, warns about the consequences of deletion, and provides 'Confirm' and 'Cancel' options.

deletion lifecycle

The sequence of validation checks, dependency resolution steps, and cascading operations that occur when a persona is deleted, including: checking for active assignments to requirements, handling persona-owned stories (in Part C), updating historical snapshots, and ensuring referential integrity across all persona-dependent entities. The lifecycle defines what can be deleted, when, and what side effects occur.

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.

demo organisation

A dedicated organisations table record marked with is_demo=true that contains curated demonstration content for screenshot capture and product demonstrations. The demo organisation is isolated from production customer data, excluded from production reports and listings, and its content is reset from a canonical fixture file during each release deployment to maintain consistency.

demo user

A pre-configured user account in the demo application (FR-17.10) with credentials, permissions, and seeded data designed to enable navigation of all help-relevant pages without requiring manual setup. The demo user has access to representative features, sample data, and UI states needed for screenshot capture, and is created as part of the demo application fixture.

demo_inclusion

A field in the canonical template inventory that indicates whether a template should be included in demonstration scenarios or training materials, used by demonstration-agenda rendering (FR-17.17) to filter which templates are presented in product demonstrations or onboarding workflows.

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 closure

The set of backlog items reached by following dependency edges outward from a submitted set, resolved against the whole open backlog rather than against the submitted set alone. Bounded at three hops or fifty items, whichever occurs first, with anything excluded reported rather than dropped.

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.

deployment-global default

A system-wide configuration value that applies to all organizations and documents within a REQQA deployment instance, serving as the fallback when no per-document override is specified. Deployment-global defaults are set by system administrators and define baseline behavior for retrieval parameters such as similarity floors, token limits, and warning thresholds.

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 constraint

A requirement or requirement element that limits the solution space by mandating specific technologies, products, architectures, algorithms, interfaces, or implementation approaches. Design constraints may be justified (when rationale is provided based on interoperability, regulatory, contractual, or integration needs) or unjustified (when specified without stated reason and alternative implementations would satisfy the same need).

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.

designation

The act of marking a persona assignment with the is_primary flag set to true, identifying that persona as the primary persona for a requirement. Designation is distinct from assignment (which creates the persona-requirement relationship) and specifically refers to setting or changing the primary status flag within an existing or new assignment.

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.

detail view

A user interface page or panel that displays comprehensive information about a single entity (such as a persona or requirement), showing all available fields, metadata, and related records in a read-only or editable format, typically accessed by selecting an item from a list view.

deterministic

Producing the same output for the same input every time, without randomness or variation. In the context of requirement analysis, deterministic evaluation uses algorithmic pattern matching and rule-based logic rather than AI models, ensuring consistent, repeatable results that do not depend on model behavior or API responses.

deterministic pass

An analysis execution mode that uses algorithmic pattern matching and rule-based logic to evaluate requirement quality, producing identical results for identical inputs without AI model involvement. A deterministic pass consumes no API tokens, executes quickly, and may identify candidates for subsequent model-based evaluation within the same analysis step.

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.

device

A distinct computing endpoint (computer, tablet, smartphone, or browser instance) from which a user accesses the application, identified for session management purposes. In the context of single-session enforcement, different devices are distinguished to ensure only one active session exists per user, with new logins from a different device invalidating previous sessions.

dimensional selections

The subset of analysis step codes in a requirement's recommended-analyses field that examine specific content dimensions (such as R-E for Entities, R-C for Consistency, R-B for Boundaries), as opposed to universal steps (R-N, R-P, R-W) that apply to all requirements. Dimensional selections vary by requirement type and template, representing content-dependent analysis choices.

dimensional steps

Analysis steps that examine specific content dimensions within a requirement, applying only when the requirement contains the type of content they evaluate. Examples include R-E (Entities), R-B (Boundaries), R-C (Consistency of decision logic), and R-I (Interfaces). Dimensional steps are content-dependent: their applicability varies by requirement type and template, making them unsuitable for universal defaults.

discount code

No definition yet.

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.

dismisses

A user action that closes a prompt or dialog without making an explicit selection from the presented options, typically performed by clicking outside the prompt area, pressing the ESC key, or clicking a close/cancel button. When a merge options prompt is dismissed, the system applies the default 'Keep' option, preserving the current recommended_analyses while updating the template.

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.

display name

A user-chosen label shown in the application interface to identify the authenticated user, typically displayed in the navigation bar, profile page, and user-specific messages. The display name may be the user's real name, a nickname, or any preferred identifier, and can be updated by the user at any time through the profile page. It is distinct from the email address used for authentication and does not need to be unique across users.

divergence

A difference between a REQQA requirement template claiming derivation from ISO/IEC/IEEE 29148 and the corresponding provision in the 2018 edition of that standard. Divergences include: sections the standard requires but the template omits, sections the template includes but the standard does not prescribe, characteristics the template asserts but the standard does not define, or guidance text that contradicts the standard's wording. Each divergence must be dispositioned as either corrected (template updated to match standard) or retained (kept with documented reason per BR-09.1-2).

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.

docusaurus

An open-source static site generator built with React that converts Markdown files into a documentation website with built-in search, versioning, and theming capabilities. Docusaurus is maintained by Meta (Facebook) and is commonly used for technical documentation sites.

docusaurus tree

The directory structure and file hierarchy of a Docusaurus documentation site, typically rooted at a 'docs/' or 'website/' directory, containing markdown content files, configuration files (docusaurus.config.js), static assets, and generated output. The tree follows Docusaurus conventions for organizing content into versioned docs, blog posts, and pages, with the file system structure determining URL routing and navigation hierarchy.

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.

domain b5

A security or compliance category within the organization's classification framework that specifically addresses AI and prompt safety concerns, including protection against prompt injection, PII leakage through AI systems, and secure handling of AI-generated content. Domain B5 represents one domain within a broader security taxonomy.

dormant

A state where an OAuth provider plugin is registered in the system but inactive and non-functional due to missing credentials (client_id or client_secret). A dormant plugin does not appear in the user interface, does not expose any login buttons or OAuth endpoints, and cannot process authentication requests. The plugin code remains loaded but is effectively disabled until valid credentials are configured.

downscaled

The process of reducing an image's pixel dimensions to a smaller size through resampling algorithms (such as bilinear, bicubic, or Lanczos interpolation), typically performed when the source image is larger than the target dimension. Downscaling preserves image content while reducing resolution and file size.

downstream consumer

A system, tool, or human role that receives and acts upon REQQA-generated stories after they have been created and handed over. Downstream consumers include testers who execute scenarios, developers who implement features, autonomous build agents that generate code, and test automation frameworks that parse Gherkin syntax.

draft state

A transient status for a persona record that has been generated or partially authored but not yet saved to the persistent persona repository. Draft state personas exist only in the user's current session or form context and are discarded if the user navigates away or explicitly discards the draft without saving.

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.

drift finding

An issue raised by the R-N analysis step when a requirement's stated capability is not a decomposition, refinement, or constraint of its parent requirement, or when it addresses concerns the parent does not raise. Drift findings indicate that the requirement has diverged from its claimed parent's scope, suggesting a traceability or scoping problem.

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.

drives_stories

A boolean flag in the requirement_personas join table indicating whether a persona should trigger story generation in Part C (FR-21). When true, the persona will be used by AI-powered story generation to create persona-specific user stories. This flag is captured in Part B but consumed only in the deferred Part C implementation.

drives_stories flag

A boolean field in the requirement_personas join table indicating whether a persona should trigger story generation in Part C (FR-21). When true, the persona will be used by AI-powered story generation to create persona-specific user stories. This flag is captured in Part B but consumed only in the deferred Part C implementation.

E

edit action

A logged event recording that a user has modified a candidate record, captured in the system's audit log with timestamp, user identity, and optionally the specific fields changed and their before/after values. Edit actions provide an audit trail of all modifications to candidate data for compliance, troubleshooting, and accountability purposes. The granularity of logging (field-level vs record-level) and retention period are defined by system audit policies.

edit form

A user interface component that displays the current values of an entity's fields in editable input controls (text fields, dropdowns, checkboxes, file upload widgets) and provides save/cancel actions to persist or discard changes. Edit forms typically include validation logic, error message display, and may support inline editing or modal dialog presentation.

edit persona

The action of modifying one or more attributes of an existing persona record (name, role, description, goals, frustrations, avatar, or scope) through the persona management interface, with changes propagating automatically to all requirements that reference the persona. Edit operations preserve the persona's identity and assignment relationships while updating current values, and are subject to validation rules ensuring required fields remain populated.

edition delta

The set of differences between two editions of a standard, including additions, deletions, and modifications to requirements, definitions, or guidance. The edition delta is used to identify what has changed between versions and what updates are needed in dependent artifacts.

effective vocabulary

The set of scenario tags in force for one organisation: the system tag catalogue with that organisation's overrides applied, plus its own organisation-owned tags. It is what the Tag Glossary page displays and, more importantly, what is injected into the story-generation prompt — so a tag's definition in the effective vocabulary is an operative instruction to the generator, not documentation. Tags in the proposed state are excluded until accepted.

Synonyms: effective tag vocabulary

See also: scenario tag, organisation-owned tag

elaboration stage

The position of a backlog item on the path from idea to buildable, expressed as one of E0 to E4 and derived from the artefact graph rather than asserted by a user. E0 idea only, no requirement linked; E1 a requirement is linked; E2 every linked requirement has a completed analysis with no finding left open; E3 active features exist; E4 stories exist and the item is scopeable. Distinct from analysis readiness, which judges whether an artefact is good enough rather than how far it has travelled.

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.

embedding model

A machine learning model that transforms text into dense numerical vector representations (embeddings) in a high-dimensional space, where semantically similar texts are positioned close together. Embedding models are characterized by their dimensionality (e.g., 1536 dimensions), training corpus, and performance on semantic similarity tasks. In this system, embeddings enable semantic search by comparing query vectors against document chunk vectors.

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.

embedding_model

The identifier of the machine learning model used to generate vector embeddings for a chunk's text, such as 'text-embedding-ada-002' or 'all-MiniLM-L6-v2'. The embedding_model determines the dimensionality and semantic properties of the embedding vector, and must match between indexing and retrieval operations for valid similarity comparisons.

empty

A field state where no value is present, represented as NULL in the database or an empty string ('') in the user interface, depending on field type and validation rules. For optional persona fields (description, goals, frustrations), empty indicates the field contains no text content after whitespace trimming.

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.

empty state

A user interface display shown when a list, collection, or data view contains no items, typically consisting of explanatory text, an icon or illustration, and optionally a call-to-action button to create the first item. Empty states provide user guidance and prevent confusion when no data is available to display.

empty state message

A user-facing text notification displayed when a list, collection, or data view contains no items, providing explanatory text and optionally a call-to-action to help users understand why the view is empty and what actions they might take. In the context of persona assignments, indicates that the persona is not currently assigned to any requirements.

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.

epistemic reach

The extent of knowledge or information available to an analysis step when making assessments. In the context of requirement analysis, epistemic reach determines what context (parent requirements, mission statements, source documents) the analyser can access to verify claims. Findings are severity-graded by epistemic reach: issues that cannot be verified due to limited available context receive reduced severity ratings with explicit statements of what could not be checked.

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.

error report

A structured output generated by the population process when failures occur, containing diagnostic information including the nature of the error, which template(s) were affected, the state of the system at failure, and sufficient detail to enable troubleshooting and remediation. The error report format, delivery mechanism (log file, console output, database record, notification), and required content fields should be specified by operational requirements.

escalation

No definition yet.

escaped characters

Special characters (such as newlines, tabs, quotes, or backslashes) that have been converted to their literal text representations (e.g., '\n' for newline, '\t' for tab) rather than being rendered as their intended formatting effects. Escaped characters typically result from import processes, copy-paste operations, or storage in formats that require escaping, and degrade readability when displayed in the user interface.

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.

excessive blank-line run

A sequence of three or more consecutive blank lines within requirement content. Excessive blank-line runs are considered mechanical damage because they degrade readability and typically result from repeated editing or import processes rather than intentional formatting. The cleanup feature collapses such runs to a single blank line.

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.

export utility

A system capability (referenced as FR-24.4) that enables users to extract raw analysis data in structured formats for custom reporting, data analysis, or integration with external tools. The export utility provides comprehensive data access beyond the fixed curated summary reports, supporting user-defined queries and flexible data extraction.

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

fan-out

A story generation pattern where a single requirement with multiple assigned personas produces multiple distinct user stories, with each story written from the perspective of one persona. Fan-out enables persona-specific story variants that address the same requirement from different user archetype viewpoints, supporting tailored acceptance criteria and scenarios per persona.

faq entry

A published question-and-answer pair in the Frequently Asked Questions surface, created by admin review of candidate signals (search terms, feedback, support questions), containing a user-facing question, detailed answer, metadata (source signal, publication date, admin author), and searchable via the unified search interface (FR-17.4). FAQ entries are first-class help content distinct from auto-generated responses.

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.

file-based persistence

A data storage approach where application state is persisted to the local filesystem as files or directories, rather than using a separate database server or remote storage service. File-based persistence typically involves writing data structures to disk in formats such as binary files, JSON, or custom serialization formats, with the application responsible for managing file I/O, locking, and consistency.

filter criteria

The set of attribute values and matching rules specified by a user to restrict a list view to show only records matching those conditions, typically expressed as field-value pairs with operators (equals, contains, greater than) and combinable with AND/OR logic.

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.

first login

The initial authentication event for a user account, occurring when a user successfully authenticates to REQQA for the first time after account creation. First login is detected by checking whether the user has any prior login history in the authentication audit log, and serves as the trigger for onboarding workflows.

five-stage lifecycle

The progression sequence through which each adoption category advances: baseline (initial state), stop-the-bleed (critical issues addressed), triage (prioritization complete), ratchet (enforcement active), and lock (standard permanently enforced). Each stage represents a maturity level with specific entry criteria and enforcement characteristics.

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 submission

The action of sending form data to the server for processing, typically triggered by clicking a submit button or pressing Enter in a form field. Form submission includes client-side validation, data serialization, HTTP request transmission, server-side processing, and handling of the response (success redirect or error display).

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.

fr-20.1 dormancy rule

A configuration rule (defined in requirement FR-20.1) that determines when an OAuth provider is considered dormant or inactive based on the absence of required credentials (client ID, client secret, redirect URI). Dormant providers do not render sign-in buttons in the user interface, preventing users from attempting authentication with unconfigured providers.

freshness record

The per-item record of when an elaboration stage was last computed and which artefact revisions it was computed from. Its purpose is to make a stale classification identifiable rather than merely suspected.

front door

The primary, direct registration path where users create accounts by providing email and password credentials through the /auth/register endpoint. This is the traditional self-service registration flow that is being disabled in the invite-only enforcement requirement. The term contrasts with 'side door' (OAuth-based registration) to distinguish between the two account creation mechanisms that must be gated.

front matter

Structured metadata at the beginning of a template file, typically in YAML or JSON format, containing machine-readable properties such as name, tags, recommended_analyses, and sections. Front-matter provides configuration and classification data that guides template usage and automated analysis.

front-matter

Structured metadata at the beginning of a template file, typically in YAML or JSON format, containing machine-readable properties such as name, tags, recommended_analyses, and sections. Front-matter provides configuration and classification data that guides template usage and automated analysis.

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.

generation prompt

A text string constructed from persona attributes (name, role, description, goals, frustrations) that is submitted to an image-generation model to specify the desired characteristics of the avatar image. The generation prompt follows a structured format that translates persona metadata into natural language instructions for the image model, enabling the model to produce a visual representation aligned with the persona's role and characteristics.

generation-time feature

A capability or behavior that is applied during the automated creation of stories from requirements, as opposed to features that operate on already-created artifacts. Generation-time features control what content is produced and how it is structured, but do not subsequently parse or modify that content once saved.

generator

The AI-powered story generation component in REQQA that creates Gherkin scenarios from requirement features and applies scenario tags according to the effective vocabulary. The generator operates during story creation workflows and is responsible for proposing new tags when existing vocabulary does not cover encountered situations.

gherkin at-req

A reference notation in Gherkin story syntax that links a scenario or feature to its parent requirement, typically formatted as '@req-XXX' where XXX is the requirement identifier. Used in the second matching pass to resolve orphaned story analysis logs by parsing the Gherkin content for requirement references and matching against the requirement database.

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.

gif

Graphics Interchange Format - a bitmap image format that supports up to 256 colors and lossless compression, identified by the .gif extension. GIF files can contain multiple frames for simple animations and support transparency through a single transparent color index. Commonly used for simple graphics, icons, and short animations on the web.

github developer settings

A section of GitHub's web interface (accessible at github.com/settings/developers) where users can create and manage OAuth Apps, configure application credentials, set callback URLs, and manage API access permissions for third-party integrations.

gitignored

A file or directory pattern listed in a .gitignore file that instructs Git version control to exclude matching files from tracking, staging, and commits. Gitignored files are not included in the repository history, are not pushed to remote repositories, and are typically used for generated artifacts, build outputs, local configuration, or sensitive credentials that should not be version-controlled.

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.

gpt.py

A Python module in the ReqQA codebase that contains legacy AI service integration code, including a chatCompletion function that defaults the 'table' field to 'stories'. This module is identified as requiring fixes or retirement as part of the attribution implementation.

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.

guest homepage

The public-facing landing page of REQQA accessible to unauthenticated visitors, which displays a subset of help content flagged with visibility='public' (such as feature overviews and release notes) to provide product information and marketing content without requiring login. The guest homepage is distinct from the authenticated user's home page.

H

h1-title

The top-level heading text of a requirement or story document, typically formatted as a level-1 markdown heading (# Title). In the context of orphaned log matching, this refers to the title field extracted from the AI analysis prompt that can be compared against requirement or story titles in the database for exact-match resolution.

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.

hash-based indexing

A database indexing technique that uses hash functions to map key values to storage locations, enabling constant-time O(1) average-case lookup performance. Hash indexes are optimized for equality comparisons but do not support range queries or sorting operations, unlike B-tree indexes.

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.

help analytics

A system capability that collects, aggregates, and reports metrics on help system usage including search queries, result counts, page views, and user feedback, enabling identification of content gaps, popular topics, and areas requiring improvement through quantitative analysis of user interaction patterns.

help build

The process of generating the complete help documentation artifact, including running the Playwright screenshot capture script, compiling Docusaurus content, generating PDFs, and producing the final help system deliverable. The help build is a stage within the release build (FR-17.13) and must complete successfully before the release can proceed.

help glossary

A scoped view over the existing definitions and termindex tables that presents only terms relevant to REQQA's help system and user-facing documentation, distinguished from project-specific requirement terms by a scope column value of 'help' or 'both'. The help glossary reuses the project glossary engine but filters content for end-user consumption.

help page

A discrete unit of help content in the GUIDE system, keyed to a specific user-visible template or template-plus-panel combination, containing documentation that explains the purpose, usage, and behavior of that interface element. Each help page has metadata including visibility scope, role restrictions, staleness indicators, and lifecycle status.

hierarchical position

The location of a requirement within the requirement tree structure, determined by its depth from the root and its relationship to parent and child requirements. Hierarchical position determines the expected level of abstraction and detail: higher-level requirements (closer to root) should be more abstract and strategic, while lower-level requirements (deeper in tree) should be more detailed and specific.

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.

hint guidance

Contextual help text or examples provided to users to clarify what type of information should be entered in a form field, typically displayed as placeholder text within the field, help text below the field, or accessible via an info-icon. Hint guidance provides specific examples or formatting instructions to supplement scaffold guidance.

historical assignment record

A preserved snapshot of a persona's attributes at the time it was assigned to a requirement, stored in the requirements_history table to maintain an immutable record of the persona state that influenced the requirement's creation or modification, even after the persona is subsequently edited or the assignment is removed.

history snapshot

A complete, immutable copy of a requirement's content and metadata captured at a specific point in time before a modification is applied. History snapshots enable rollback to previous states and provide an audit trail of changes. Each snapshot is timestamped and associated with the user who triggered the change.

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.

home page

The primary landing page of the library system that serves as the entry point for authenticated library members. This page provides navigation to key features, displays personalized information (such as current loans and notifications), and serves as the reference point for measuring navigation depth to other system functions.

honeypot

An anti-spam technique where a hidden form field is added to the access request form that is invisible to human users but visible to automated bots. Legitimate users leave the field empty, while bots typically fill all fields. Submissions with the honeypot field populated are silently rejected as bot traffic. This provides basic bot protection without requiring user interaction like CAPTCHA.

hooks

Predefined callback points in software code where external modules or plugins can register custom logic to be executed at specific lifecycle events or processing stages. Hooks enable extensibility by allowing new functionality to be injected into existing workflows without modifying the core system code.

hotfix

An urgent code or configuration change deployed outside the normal release cycle to address a critical defect affecting production functionality, typically bypassing standard review and testing processes while maintaining minimal safeguards to prevent further issues. Hotfixes are deployed with a target lead time of ≤2 hours from identification to production.

how-to guide

A task-oriented instructional article that provides step-by-step guidance for completing a specific user goal or workflow spanning multiple pages or system components. How-to guides are discoverable through search and help index, contain forward links to referenced context pages, and are versioned with staleness metadata to ensure accuracy over time.

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.

hybrid

An implementation approach that combines two distinct evaluation methods—deterministic pattern matching for lexical rules and AI-assisted semantic analysis for contextual rules—within a single analysis step. The hybrid approach optimizes for speed and cost by using deterministic evaluation where possible and AI only where semantic judgement is required.

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.

idempotent no-op

An operation that can be executed multiple times with the same input without changing the result beyond the initial application, and which produces no side effects when the precondition is already satisfied. In this context, resetting an override that doesn't exist completes successfully without error, leaving the system in the same state as before the operation.

image model

A machine learning model or AI service (such as DALL-E, Stable Diffusion, or Midjourney) that generates images from text descriptions, accepting natural language prompts and producing visual representations in standard image formats. The model is configured at the system level and invoked via API to create persona avatars from persona attribute descriptions.

image model configuration page

A web-based administrative interface accessible only to system administrators that provides controls for enabling/disabling avatar generation, selecting the active image-generation model provider (DALL-E 3, Midjourney, Stable Diffusion), entering and validating API credentials, and viewing current configuration status. The page enforces tenant isolation, displays masked credentials for security, and validates configuration changes before persisting them.

image model provider

A third-party AI service (such as DALL-E 3, Midjourney, or Stable Diffusion) that generates images from text prompts, identified by a provider name and accessed via API credentials. The provider determines the image generation capabilities, pricing, quality characteristics, and API integration requirements available to the system.

image processing

The set of operations performed on a valid uploaded image file to prepare it for storage, including decoding the image format, resizing to standard avatar dimensions, format conversion, compression, and quality adjustment. Image processing transforms the raw upload into a normalized avatar blob suitable for database storage.

image-generation model

An AI model or service (such as DALL-E, Stable Diffusion, or Midjourney) that generates images from text descriptions or prompts, producing visual representations based on natural language input. The model accepts textual descriptions of desired image content and outputs image files in standard formats (PNG, JPEG). Image-generation models are distinct from text-generation models (LLMs) and typically have separate API endpoints, pricing structures, and configuration requirements.

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.

impact mapping

A strategic planning technique developed by Gojko Adzic that helps teams avoid premature solution specification by mapping the relationship between business goals, actors, impacts, and deliverables, ensuring that requirements focus on outcomes and needs rather than predetermined solutions.

implementation free

A characteristic of requirements defined in ISO/IEC/IEEE 29148:2011 (predecessor to the 'Appropriate' characteristic in the 2018 edition) stating that a requirement should specify what capability is needed without prescribing how that capability should be implemented, thereby preserving design freedom and avoiding unjustified constraints on solution approaches.

in-app help footer

A UI component displayed at the bottom of the help content popover (as defined in FR-17.2) that shows metadata about the help content being viewed, including the built_for_version value from the resolved help_pages row. The footer provides transparency about which version of help documentation the user is viewing.

in-context cost

The nominal cost of AI calls displayed within the context of a specific artifact (requirement, story, or analysis result), showing the user how much AI usage was consumed to produce or analyze that particular artifact. In-context cost provides localized cost visibility at the point of use, complementing organization-wide cost reporting.

in-use persona

A persona that has been assigned to at least one requirement in the current application and organization context, as evidenced by the existence of one or more requirement_personas join table rows linking that persona to requirements. In-use personas are the only personas displayed in the persona filter dropdown, ensuring the filter options reflect actual data assignments rather than all defined personas in the system.

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 job

An asynchronous background process that reads a retrieve-on-demand document's content, splits it into chunks, generates embeddings for each chunk, stores chunks in the org_context_chunks table, and creates corresponding Qdrant points. The indexing job transitions the document's indexing_state from 'pending' through 'indexing' to 'indexed' (or 'failed' on error), and populates last_index_error if failures occur.

indexing state

A status attribute on org_context_documents indicating the current stage of the asynchronous embedding and indexing process, with values such as 'pending' (upload complete, indexing queued), 'in_progress' (actively chunking and embedding), 'completed' (indexed and queryable), or 'failed' (indexing error occurred). The state is displayed in the library UI and determines whether a document is available for retrieval.

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.

indexing_state

A database field tracking the lifecycle status of a document's embedding and vector store indexing process, with valid values including 'pending' (awaiting indexing), 'indexing' (currently being processed), 'indexed' (successfully completed), and 'failed' (indexing encountered an error). State transitions are managed by the indexing pipeline and determine whether a document is available for retrieval.

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.

info_requests

A database table that stores access request submissions from prospective users, containing fields for requester contact information, submission timestamp, processing status (new, approved, declined, spam), and any associated notes or follow-up actions. Each row represents a single access request and serves as the authoritative record for tracking and processing user access inquiries.

initiates deletion

The user action that begins the deletion workflow for a custom tag, typically by clicking a 'Delete' button, selecting a 'Delete' option from a context menu, or invoking a delete command in the tag management interface. Initiation triggers the display of the deletion confirmation prompt but does not immediately execute the deletion.

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.

inline validation 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.

intended use

The recommended playing context or purpose for which a tennis ball product is designed, such as 'hard court', 'clay court', 'grass court', 'all court', 'high altitude', 'junior players', or 'ball machines'. Intended use helps customers select appropriate products for their specific playing conditions and skill level.

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.

invite

A pre-authorized permission record stored in the system that grants a specific email address the right to create an account in REQQA. An invite is created by an existing user with appropriate permissions, contains the invitee's email address and target organization, and transitions from 'pending' to 'consumed' state when the invitee completes registration. Invites may have expiration timestamps and can be revoked before use.

invite-acceptance

The process by which a user who has received an email invitation to join REQQA completes their account setup by providing a password and accepting the invitation, creating an email/password authentication credential. This is the only remaining path for creating email/password users after the /auth/register endpoint was disabled.

invite-acceptance flow

A registration workflow where users can only create accounts by accepting an invitation sent by an administrator or authorized user, typically involving a unique invitation token or link that pre-authorizes account creation and may pre-populate certain account attributes (email, role, organization). This flow bypasses the standard self-service registration process and ensures controlled user onboarding.

invite-acceptance page

A web page displayed when a user follows an invitation link, allowing them to accept the invitation and create an account or join an organization. The page typically displays invitation details (inviter name, organization, role), provides authentication options (including OAuth provider buttons), and validates the invitation token before allowing account creation or association.

invite-only page

A web page displayed to users who attempt to register or authenticate without a valid invitation, explaining that REQQA operates on an invitation-only basis and providing instructions for requesting an invitation or contacting support.

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.

iso/iec/ieee 29148:2018

International standard titled 'Systems and software engineering — Life cycle processes — Requirements engineering', published jointly by ISO, IEC, and IEEE in 2018. The standard defines processes, activities, and tasks for eliciting, analyzing, specifying, validating, and managing requirements throughout the system lifecycle. In SQUAD-STATE context, this standard provides the framework for ensuring requirements completeness and traceability from mission-stated functions to implemented capabilities.

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.

is_demo

A boolean flag on the organisations table that marks an organisation record as containing demonstration or test data rather than production customer data. When true, the organisation is excluded from production listings, reports, and analytics, and its data may be reset or overwritten during release deployments without affecting real customer information.

is_primary

A boolean database field on the requirement_personas join table that indicates whether a particular persona assignment is designated as the primary persona for that requirement. When multiple personas are assigned to a requirement, exactly one must have is_primary=true, identifying which persona represents the main user perspective or stakeholder for that requirement.

is_primary flag

A boolean field in the requirement_personas join table that indicates whether a particular persona assignment is designated as the primary persona for that requirement. When multiple personas are assigned to a requirement, exactly one must have is_primary=true, identifying the main user perspective for that requirement.

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

J

job-queue views

User interface pages or components that display the status of queued and executing background analysis jobs, showing job metadata including job type, target artifact, submission time, execution state (queued/running/completed/failed), and progress indicators. Job-queue views enable users to monitor long-running analysis operations and access results when jobs complete.

join table

A database table that establishes many-to-many relationships between entities by storing foreign key pairs, enabling multiple records from one table to be associated with multiple records from another table. In this context, the requirement_personas join table links personas to requirements with additional metadata such as is_primary flag and timestamp.

journey

No definition yet.

jpeg

Joint Photographic Experts Group - a commonly used lossy compression format for digital images, particularly photographs, identified by file extensions .jpg or .jpeg. JPEG files use discrete cosine transform compression to reduce file size while maintaining acceptable visual quality, making them suitable for web display and storage of photographic content.

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.

last-write-wins

A conflict resolution strategy for concurrent edits where the most recent update (based on timestamp) overwrites any previous changes without attempting to merge or reconcile conflicting modifications. In the context of persona editing, if two users edit the same persona simultaneously, the last modification to be committed to the database becomes the authoritative state, and earlier modifications are discarded.

last_index_error

A database field storing the error message or diagnostic information from the most recent failed indexing attempt for a document, enabling debugging and user notification of indexing failures. The field is populated when indexing_state transitions to 'failed' and may be cleared when indexing is retried or succeeds.

legacy field

A database column (requirements.personaid) that was previously used to store persona assignments but is being phased out in favor of the requirement_personas join table. The legacy field is no longer written to but may still contain historical data, and all read operations must be redirected away from it to complete the migration.

level 1

The deployment-global default configuration tier for retrieval budget thresholds, set in settings.py (overridable via settings_private.py) by system operators, applying uniformly to all organisations and documents unless overridden by Level 2 per-document settings. Level 1 represents the baseline threshold values that govern warning behavior across the entire REQQA deployment instance.

lexical comparison

A deterministic text comparison method that analyzes the surface form and structure of text (words, tokens, syntax) without interpreting semantic meaning or context. Lexical comparison operates on normalized token sequences and can be performed without AI assistance, ensuring repeatable results for the same input.

lexical pre-screening

An initial deterministic pattern-matching phase that identifies candidate issues (such as statements containing combinators) before invoking semantic AI evaluation, filtering out statements that do not require contextual judgement to reduce AI call volume and cost.

lexical rules

Writing rules that can be evaluated through pattern matching and syntactic analysis without requiring semantic interpretation or contextual understanding. Examples include detection of superfluous infinitives, escape clauses, oblique symbols, and placeholder text. Lexical rules operate on the surface form of text and can be implemented deterministically without AI assistance.

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.

linkedin developer portal

LinkedIn's web-based developer console (https://www.linkedin.com/developers/) where developers register OAuth2 applications, obtain client credentials (client ID and client secret), configure authorized redirect URIs, and manage API access permissions for LinkedIn authentication and data access.

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.

load-bearing

In the context of requirement analysis, a term is load-bearing when the requirement's obligation cannot be understood, implemented, or tested without knowing what the term means. A load-bearing term is essential to interpreting the requirement's scope, constraints, or acceptance criteria, such that different interpretations of the term would lead to materially different implementations.

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.

location block

An nginx configuration directive that defines how to process requests for specific URL paths or patterns. A location block specifies the document root, proxy settings, or other handling rules for URLs matching its pattern. Location blocks enable serving multiple sites or applications from different paths under a single domain (e.g., example.com/docs, example.com/app).

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.

log file

A persistent text file stored on disk that records events, operations, and messages generated by a system or application, typically including timestamps and severity levels. Log files support debugging, audit trails, and operational monitoring by preserving a chronological record of system activity.

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.

low-similarity chunks

Document chunks that have a similarity score below a defined threshold when compared to the analysis query or context, indicating weak semantic relevance. Low-similarity chunks contribute minimal value to AI prompt context but still incur token costs when retrieved, making them candidates for exclusion or pruning to optimize retrieval budget efficiency.

lunr

Lunr.js - a lightweight, client-side full-text search library for JavaScript that enables search functionality in static websites without requiring a server-side search backend. Lunr builds an inverted index from document content at build time, which is then loaded in the browser to perform fast, offline-capable searches. Commonly used in static site generators like Docusaurus to provide search over documentation content.

M

machine-readable form

A structured data format (such as YAML, JSON, or XML) that can be parsed and processed programmatically without human interpretation, enabling automated validation, analysis, and transformation. In the context of template sections, this means a list format that analysis tools can read to verify requirement conformance.

malformed response

An AI model response that does not conform to the expected structure, format, or schema, including invalid JSON, missing required fields, unexpected data types, or responses that cannot be parsed by the analysis engine's response handler.

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.

marked as overridden

A visual indicator displayed in the tag glossary UI that identifies a tag as having an organisation-specific override of its system default definition. The marker distinguishes overridden tags from system tags used without modification and from organisation-owned custom tags.

master template files

The authoritative source files for requirement templates stored in the static/templates/reqs_templates/ directory, used to seed new organizations during provisioning. Master template files define the canonical structure, headings, and default metadata (including recommended-analyses) for each template type. Changes to master files affect only newly provisioned organizations; existing organization template records remain unchanged until explicitly migrated.

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

matching

The process of pairing a qualified candidate with a client requiring home care services, based on factors such as candidate skills, availability, location, and client needs. Matching is a distinct stage in the recruitment pipeline that occurs after interviewing and before placement.

meaning-bearing token

A word that survives normalization after removing markdown syntax, list markers, punctuation, whitespace, lowercasing, and applying a fixed stop-word list of articles, conjunctions, prepositions, and auxiliary verbs. Meaning-bearing tokens represent the semantic content of text that restructuring should preserve.

mechanical damage

Structural and formatting defects introduced into requirement content through automated processes (import, synthesis) or repeated manual editing, including duplicate sections, escaped newline and tab characters, excessive blank-line runs, and stranded template placeholders. Mechanical damage degrades readability and analysis quality without affecting the semantic content of the requirement.

mechanical fixes

Automated corrections applied to requirement content to resolve structural and formatting defects such as duplicate sections, escaped characters, excessive blank lines, and stranded template placeholders. Mechanical fixes are deterministic, reversible through history snapshots, and do not alter the semantic content of the requirement.

merge options prompt

A specific type of prompt displayed when a requirement's template is changed and the new template's recommended_analyses differ from the current value. The prompt presents three mutually exclusive options: 'Replace' (adopt new template defaults), 'Keep' (retain current values), or 'Merge' (union of current and new values), with 'Keep' as the default selection.

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 layer

The database schema versioning and evolution mechanism that manages incremental changes to database structure through versioned migration scripts, ensuring consistent schema state across development, staging, and production environments while preserving existing data during schema modifications.

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.

minimum-viable admin list view

A basic administrative user interface displaying a tabular list of records with essential columns and minimal functionality, sufficient for core operational needs but lacking advanced features such as bulk operations, complex filtering, or rich formatting. The minimum-viable implementation typically includes: display of key record attributes, basic sorting, simple status updates, and navigation to detail views, with the understanding that enhanced UI capabilities will be added in future iterations.

missing organization context

A system state where an authenticated user session lacks the required organization identifier (orgid) needed to scope data access and enforce tenant isolation. This may occur due to authentication system errors, incomplete user provisioning, or corrupted session data. Operations requiring organization context must be rejected when this condition is detected.

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.

mit-licensed

Software distributed under the MIT License, a permissive open-source license that allows free use, modification, and distribution of the software with minimal restrictions. The MIT License requires only that the original copyright notice and license text be included in copies or substantial portions of the software. This license is considered business-friendly as it permits commercial use without copyleft 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.

model pass

An analysis execution mode that uses AI model inference to evaluate requirement quality, as opposed to deterministic rule-based evaluation. A model pass consumes API tokens, may produce variable results across runs, and is typically used for complex semantic analysis that cannot be captured in algorithmic rules.

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.

mtbf

Mean Time Between Failures — a reliability metric representing the average operational time between consecutive failures of a repairable or replaceable system, measured in hours. For the body-worn device, MTBF of >720 hours means the device is expected to operate for more than 720 hours on average before experiencing a failure requiring replacement.

mttr

Mean Time To Repair — a reliability metric representing the average time required to repair a failed system and restore it to operational status. In this requirement, MTTR is marked as N/A because the body-worn device is not field-repairable and is replaced rather than repaired when it fails.

multi-select

A user interface control that allows users to select multiple items from a list simultaneously, typically implemented as a list box with checkboxes, a dropdown with multi-selection capability, or a tag-based picker. Multi-select controls enable users to choose zero or more options from the available set.

multi-tenant isolation

A security mechanism in multi-tenant systems that ensures data and resources belonging to one tenant (organization) are completely separated from and inaccessible to other tenants, preventing cross-tenant data leakage. Isolation is typically enforced through database-level filtering (WHERE orgid = current_org), access control checks, and architectural patterns that scope all queries and operations to the authenticated tenant's context.

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

n analyses

A configurable lookback window parameter that determines how many recent analysis operations are included when computing average retrieved tokens per call for a document. The value of N defines the sample size for statistical calculations, balancing recency (smaller N captures recent behavior) against stability (larger N smooths out variance). The specific value of N and whether it is configurable per-document or deployment-wide should be specified in implementation requirements.

naming conventions

A documented set of rules governing how files and directories within a content surface should be named, including patterns for file extensions (.md, .mdx), use of hyphens vs underscores, capitalization rules, date formats for time-series content (e.g., release notes), and any required prefixes or suffixes that enable proper sorting, discovery, and automated processing.

natural-language prompt

A free-form text input provided by a user in conversational human language (as opposed to structured data or code) that describes the desired characteristics of a persona to be generated. The prompt may range from a single word (e.g., 'teacher') to a detailed description (e.g., 'A senior business analyst working in healthcare compliance') and serves as the input to the AI model for persona generation.

navigation bar

A persistent UI component displayed at the top or side of the application interface that provides navigation links to key application sections and displays user context information such as the authenticated user's display name and logout option. The navigation bar is present across all authenticated pages and updates dynamically when user profile information changes.

necessity finding

An issue raised by the R-N analysis step when a requirement lacks a substantive rationale, fails to identify the need or policy it serves, or does not explain the consequence of its removal. Necessity findings indicate that the requirement's justification for existence is absent or insufficient, making it impossible to verify whether the requirement is truly necessary.

negative examples

A list of existing entity instances (in this case, persona names and roles) provided to an AI model during generation to explicitly instruct the model to avoid creating duplicates or near-duplicates of those instances. Negative examples serve as exclusion constraints in the AI prompt, guiding the model to generate novel, distinct outputs.

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.

nginx

A high-performance open-source web server and reverse proxy server that handles HTTP requests, serves static files, and can route traffic to application servers. In REQQA's context, nginx is the existing web server infrastructure that will host the Docusaurus-generated documentation site alongside the main application.

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.

nominal ai usage

The expected or typical volume of AI API calls and token consumption for an organization under normal operating conditions, used as a baseline for setting budget thresholds and detecting anomalous usage patterns. Nominal usage may be calculated from historical averages, projected workload, or organizational capacity planning.

nominal cost

An estimated or calculated cost for AI API usage based on token consumption and configured pricing rates, representing the approximate expense that would be incurred if the organization were paying for AI services. Nominal cost is distinguished from actual billing amounts and may be zero for self-hosted models or when clients use their own API keys. Nominal cost provides usage visibility and budget planning data without implying a direct financial charge.

non-primary

A persona assignment where the is_primary flag is set to false, indicating that the persona provides additional context for the requirement but is not the principal user perspective. Non-primary personas may still drive story generation (if drives_stories=true) but are subordinate to the primary persona for requirement interpretation and design trade-off decisions.

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.

normal load

The expected operational conditions representing typical concurrent user activity during a workshop session, defined as up to 60 concurrent participants performing standard workflows (registration, team joining, topic selection, contribution submission, and view refreshing) with intermittent activity bursts during structured phases of the workshop.

normalised

The process of converting an uploaded image to a standardized format, dimension, and quality level to ensure consistency across all stored avatars, typically involving resizing to a fixed dimension, converting to a specific image format (e.g., PNG or JPEG), and applying compression to meet size constraints.

normalised to standard dimensions

The process of resizing and reformatting an uploaded avatar image to conform to predefined width and height specifications (e.g., 200x200 pixels), ensuring consistent display across the application regardless of the original upload dimensions.

normalization

No definition yet.

normalized avatar

An avatar image that has been processed to conform to standardized storage requirements, including resizing to standard dimensions (e.g., 200x200 pixels), converting to a specific image format (PNG or JPEG), applying compression to meet size constraints, and stripping metadata. Normalization ensures consistent display and storage characteristics regardless of the original upload format or dimensions.

normalized blob

A binary large object (BLOB) that has been processed to conform to standardized storage requirements, including consistent file format (e.g., PNG), resolution constraints, file size limits, color space normalization, and metadata stripping. Normalization ensures that stored images meet system requirements for display, performance, and security regardless of their original format or source (user upload or AI generation).

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

oauth callback

An HTTP endpoint in the REQQA application that receives the authorization response from an OAuth2 identity provider after the user has authenticated and granted permissions. The callback receives an authorization code or access token, validates it, and completes the authentication process by creating or updating the user session. In py4web, this is typically handled by the framework's OAuth plugin at a URL like /auth/plugin/google/callback.

oauth code

A short-lived authorization code returned by an OAuth provider to the callback URL after successful user authentication. The code is exchanged by the application for an access token through a server-to-server request, following the OAuth 2.0 authorization code grant flow. The code typically expires within minutes and can only be used once.

oauth flow

The sequence of HTTP redirects and token exchanges that occur when a user authenticates via an OAuth 2.0 provider, including: (1) redirecting the user to the provider's authorization page, (2) the provider authenticating the user and requesting consent, (3) the provider redirecting back to the application with an authorization code, (4) the application exchanging the code for an access token, and (5) the application using the token to retrieve user profile information and establish a session.

oauth provider

A third-party authentication service (such as Google, GitHub, or LinkedIn) that implements the OAuth 2.0 protocol and allows users to authenticate to REQQA using their existing account credentials from that service. The provider handles user authentication and returns user profile information (including email address) to REQQA after successful authentication.

oauth rejection page

A web page displayed to users when their OAuth authentication attempt is rejected or fails, typically because they attempted to log in with an OAuth provider (such as Google or Microsoft) but do not have an existing REQQA account or invitation. The page explains why access was denied and provides alternative options for gaining access, such as requesting an invitation from a colleague or submitting an access request to the REQQA host.

oauth sign-in

An authentication event where a user successfully authenticates to REQQA using credentials from an external identity provider (Google, GitHub, LinkedIn) via the OAuth 2.0 or OpenID Connect protocol, resulting in the creation or update of a user session without requiring REQQA-managed credentials.

oauth-returned email

The email address provided by an OAuth provider in the user profile response after successful authentication. This email is extracted from the provider's user info endpoint (e.g., Google's userinfo API, GitHub's /user API) and is used by REQQA to match against pending invites or existing auth_user records. The email may or may not be verified by the provider, and REQQA must handle cases where the provider does not return an email address.

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

oauth2 plugin

A modular software component that implements the OAuth2 authentication protocol for a specific identity provider (such as LinkedIn), encapsulating the authorization flow, token exchange, and user profile retrieval logic. In py4web, OAuth2 plugins subclass the framework's OAuth2 base class and configure provider-specific endpoints and credential handling.

oauth2github

A py4web authentication plugin class that implements OAuth 2.0 authentication flow with GitHub as the identity provider, handling authorization requests, token exchange, and user profile retrieval according to GitHub's OAuth API specification.

oauth2google

A py4web authentication plugin that implements OAuth 2.0 authentication flow with Google as the identity provider, handling the authorization redirect, token exchange, and user profile retrieval from Google's authentication services.

obsolescence finding

An issue raised by the R-N analysis step when a requirement shows signs of being outdated or no longer applicable, including: expired applicability dates, references to deprecated systems or processes, or dependencies on withdrawn requirements. Obsolescence findings indicate that the requirement may no longer be relevant to the current system state.

obsolescence indicator

Evidence within a requirement's text or its supplied context that suggests the requirement may no longer be applicable, including: (a) an explicit expiry or applicability date earlier than the analysis date, (b) text describing a system, process or regulation as retired, superseded, deprecated or replaced, or (c) a stated dependency on a parent or referenced requirement whose context records it as withdrawn. Obsolescence indicators are assessed from available context only, never from external knowledge.

onboarding

A guided first-run experience presented to new users on their initial login that introduces key system concepts (applications, requirements, stories, analyses), navigation patterns, and help resources. Onboarding is user-dismissible, can be re-launched from the help menu, and is tracked per user to prevent automatic re-display after dismissal.

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.

orchestrator

An open-source MySQL high availability and replication management tool that monitors MySQL topologies, detects failures, and performs automatic failover. Orchestrator provides a web interface for visualizing replication topology, supports automated master promotion during failures, and can reconfigure replicas to follow a new master. It is commonly used to automate database failover and reduce recovery time.

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 member

A user role representing an authenticated user who belongs to an organization in REQQA, with permissions to view personas within their organizational and application context. Org Members can browse persona lists, navigate to persona details, and access personas scoped to their organization (org-wide) or their current application (app-specific).

org-wide

A scope classification indicating that a persona is available for use across all applications within an organization, not restricted to a single application. Org-wide personas (identified by appid = NULL) represent user archetypes that are relevant to multiple applications or the organization's overall user base, enabling persona reuse and consistency across the application portfolio.

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.

organisation template records

Database records in the req_templates table that store organization-specific instances of requirement templates, including structure, headings, and recommended-analyses defaults. Each organization receives its own set of template records during provisioning, copied from master template files. These records are what live requirements actually reference, and changes to them affect only the owning organization.

organisation's persona list

A user interface view that displays all saved personas belonging to the current organization, typically showing persona name, role, and usage count (number of requirements referencing each persona). The list provides navigation to persona detail views and may support filtering, sorting, and search operations. Only personas in saved state are included; drafts are excluded.

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.

organization member

A user who has been granted access to a specific organization in REQQA through invitation or assignment, with permissions to view and interact with that organization's data, personas, requirements, and other resources. Organization membership determines the scope of data access and is enforced through tenant isolation mechanisms.

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.

origin

A story attribute that records how the story was created: 'generated' for stories produced by AI-assisted generation from requirement features, or 'manual' for stories authored directly by users. The origin determines whether a story can be overwritten during regeneration: manual stories are protected, while generated stories may be replaced if the parent requirement's features change.

orphan

A database record or entity reference that has lost its relationship to a parent or referenced entity, typically due to deletion of the parent without proper cascade handling or referential integrity enforcement. In this context, refers to requirement-to-persona links that would reference a deleted persona, creating invalid foreign key references.

orphan finding

An issue raised by the R-N analysis step when a requirement has no recorded parent requirement, no documented source (stakeholder, policy, standard), and no explicit linkage to the application mission statement. Orphan findings indicate a complete lack of traceability, making it impossible to verify the requirement's origin or necessity.

orphan requirement

A requirement that has no recorded parent requirement, no documented source (stakeholder, policy, standard), and no explicit linkage to the application mission statement. An orphan requirement lacks traceability to any authoritative origin, making it impossible to verify necessity or assess whether it is an accurate transformation of stated needs. Distinct from database orphans (records with broken foreign key references).

othercorp

A sample organization name used in test scenarios to represent a different organization from the authenticated user's organization, used to verify tenant isolation and cross-organization access control enforcement. OtherCorp serves as a standard fixture name for testing multi-tenant security boundaries.

overlap

The number of tokens or characters shared between consecutive chunks in a chunking strategy, designed to preserve context across chunk boundaries and improve retrieval recall by ensuring that concepts spanning chunk boundaries appear in multiple chunks. Overlap is typically expressed as a percentage of chunk size or an absolute token count.

override creation workflow

The user interface flow and process steps by which an Organisation Administrator creates an override of a system tag's definition for their organisation, typically involving: selecting the system tag to override, entering the organisation-specific definition and usage note, confirming the override, and saving the override record to the org_tag_overrides table.

override record

A database record that stores an organisation's customised definition and usage note for a system tag, replacing the system default values for that organisation only. The record links the organisation ID, tag name, custom definition, and custom usage note, and can be deleted to restore system defaults.

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 reload

The action of refreshing a web page by requesting it again from the server, typically triggered by the browser's reload button or F5 key, causing the page to be re-rendered with current data from the database. Used to verify that changes have been persisted to the database and are not merely held in client-side state or browser cache.

page size

The maximum number of records displayed on a single page of a paginated list, configured as a system default (e.g., 50 items per page) and optionally adjustable by users through UI controls or query parameters within defined minimum and maximum bounds.

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.

panel key

An optional identifier for a sub-view or embedded component within a user-visible template, used to provide context-sensitive help for specific panels or sections of a page rather than the entire page. Panel keys enable granular help targeting when a single template contains multiple distinct functional areas that warrant separate documentation.

partial

An analysis completion status indicating that some but not all selected analysis steps completed successfully, typically due to step failure, timeout, or resource unavailability. A Partial analysis preserves the findings from steps that completed while recording which steps failed and why, and is never presented as a complete analysis in reporting or UI.

partial completion

A migration execution state where some operations succeeded and were committed before an error occurred, resulting in a database state that reflects incomplete migration progress. Partial completion requires the migration report to document which operations succeeded and which failed, enabling manual remediation or rollback decisions.

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.

participant

A user role representing workshop attendees who select topics, view moderator-provided background and instructions, and contribute structured content according to the topic's markdown template during an active workshop session. Participants do not have permissions to create or modify topics.

pathway 1

The invitation flow where a REQQA system administrator creates a new organization and issues the first invitation to that organization's initial user via the adminOrgCreate function. This pathway is used for onboarding new organizations to REQQA and grants the invited user administrative privileges within their organization. Pathway 1 invitations are issued by the REQQA host, not by existing users.

pathway 1 flow

An existing user onboarding workflow in REQQA where an administrator with appropriate permissions sends an invitation to a prospective user, granting them access to create an account and join an organization. The pathway includes invitation generation, email delivery, recipient acceptance, and account creation steps, and is referenced as the mechanism through which approved access requests are converted into actual user accounts.

pathway 2

The invitation flow where an existing organization member invites a colleague to join their organization via the teamInvite function. This pathway is used for growing an existing organization's user base and is available to any member with invitation privileges. Pathway 2 invitations are issued by organization members, not by the REQQA host, and the invited user joins the inviting member's organization.

pattern match

A text analysis technique that identifies occurrences of predefined character sequences, regular expressions, or syntactic structures within requirement text. Pattern matching is used in lexical rule evaluation to detect specific phrases (e.g., 'shall be able to'), symbols (e.g., '/', '<', '>'), or structural elements (e.g., parenthetical text) without interpreting semantic meaning.

payload filter

A query constraint applied to vector search operations that restricts results based on metadata fields stored alongside vectors in the vector database. Payload filters enable combining semantic similarity search with structured filtering (e.g., 'find similar documents WHERE orgid = 123'), allowing precise control over which vectors are considered during similarity search without requiring separate collections.

payload-filtered

A vector store query capability where retrieval results are filtered based on metadata attributes (payload) attached to each vector, enabling multi-tenant isolation by restricting searches to vectors matching specific criteria (e.g., orgid = current_user_org). Payload filtering is applied at query time by the vector store engine before similarity ranking, ensuring users only retrieve chunks from documents they are authorized to access.

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.

pending invite

An invitation record in the 'invitations' table with status='pending' that has been sent to a specific email address but not yet accepted or expired. A pending invite grants the recipient authorization to create a REQQA account using that email address through OAuth authentication. The invite remains pending until the recipient completes sign-in (transitioning to 'accepted') or the invitation expires.

per-artefact cache layer

A caching tier in the prompt assembly architecture where content specific to a single artifact (requirement or story) is cached separately from organization-wide content, enabling cache reuse across multiple analyser calls for the same artifact while maintaining isolation between different artifacts. The per-artifact layer sits between the org-wide cache layer (shared across all artifacts) and the per-analyser layer (unique to each analysis step).

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.

per-category verdict

A pass/fail/warning assessment for a single static analysis category, indicating whether the analyzed code meets the quality thresholds defined for that category. The verdict is derived from the category's results and included in the per-category result payload.

per-org token and cost budget thresholds

Organization-specific limits on AI API consumption, consisting of: (1) a token threshold (maximum number of tokens that can be consumed across all analyses within a time period), and (2) a cost threshold (maximum monetary amount that can be spent on AI API calls within a time period). Both thresholds are configurable per organization and enforced independently, with the more restrictive limit taking precedence.

perceptible delay

A delay in system response time that is noticeable to users and degrades the user experience, typically defined as latency exceeding 100-200 milliseconds for interactive operations. In the context of requirement save operations, a perceptible delay would be one that causes users to notice the system is processing rather than experiencing immediate feedback.

period

A user-selectable time range for which summary report metrics are calculated and displayed, such as 'last 7 days', 'last 30 days', 'current month', 'last month', 'current quarter', or a custom date range. The period determines which analysis operations and token usage data are included in the aggregated metrics.

permanently removed

The irreversible deletion of a persona record from the active system state, where the persona no longer appears in any operational lists, cannot be assigned to new requirements, and cannot be restored through standard user operations. Distinguished from soft deletion or archival, permanent removal means the persona record is either physically deleted from the database or marked with a deletion flag that excludes it from all active queries. Historical references to the persona in requirement snapshots and audit trails are preserved for traceability.

persona

A named, believable user archetype representing a specific role with defined goals, frustrations, and characteristics, used to provide human context for requirements and guide system design decisions. Personas can be organization-wide (appid NULL) or application-specific (appid set), and are assigned to requirements to indicate which user types the requirement serves.

persona assignment

A database record in the requirement_personas join table that establishes a relationship between a specific requirement and a specific persona, indicating that the requirement is relevant to that persona's role, goals, or needs. Each assignment represents one persona's association with one requirement, enabling many-to-many relationships where requirements can have multiple personas and personas can be assigned to multiple requirements.

persona attributes

The set of data fields that define a persona's characteristics, consisting of required fields (name, role) and optional fields (description, goals, frustrations, avatar, avatar_prompt, appid). Persona attributes collectively describe the user archetype and determine how the persona is displayed, filtered, and used in requirement analysis. Changes to persona attributes propagate automatically to all requirements that reference the persona.

persona creation form

A web-based user interface component that collects persona attributes through input fields including name (required), role (required), description (optional), goals (optional), frustrations (optional), and scope selection (org-wide or app-specific), with inline validation, scaffold guidance, and submit/cancel actions.

persona detail view

A user interface page or panel that displays comprehensive information about a single persona record, including all attributes (name, role, description, goals, frustrations, avatar), scope classification, and a list of requirements to which the persona is currently assigned with assignment type indicators.

persona display

A user interface component on the requirement view page that shows the list of personas assigned to a requirement, including their names, roles, avatars (if present), and primary/secondary designation. The display may be a dedicated section, panel, or embedded list within the requirement details, and provides visual indication of which personas the requirement serves.

persona draft

A temporary, unsaved state of a persona record that has been generated by AI but not yet committed to the persona repository. The draft exists in editable form controls and can be modified, saved, or discarded by the Requirements Analyst. Draft state is distinct from saved state and is lost if the user navigates away without saving.

persona list

A user interface view that displays all personas accessible to the authenticated user within a specific organizational or application scope, showing persona attributes such as name, role, and scope indicator (org-wide or app-specific), with filtering applied based on the current application context to show only personas available for use in that application.

persona list page

A web page that displays all personas accessible to the authenticated user, filtered by organization scope and optionally by application scope, showing persona name, role, and scope indicator, with navigation to individual persona detail views and persona creation functionality.

persona management actions

The set of operations that authenticated users can perform on persona records within their organization, including viewing persona lists, accessing persona details, creating new personas, editing existing persona attributes, and deleting unassigned personas. These actions are subject to authentication enforcement and organizational membership validation.

persona repository

The persistent data store containing all saved persona records for an organization, accessible to Requirements Analysts for viewing, editing, and assignment to requirements. The repository maintains persona metadata including creation timestamp, last modified timestamp, and usage tracking (which requirements reference each persona). Only personas in saved state (not draft state) are included in the repository.

persona scaffold

A predefined template structure that defines the standard set of fields and their organization for creating a persona, including name, role, goals, frustrations, description, and avatar prompt. The scaffold provides a consistent framework ensuring all personas capture the same categories of information in a uniform format.

persona selection dropdown

A user interface component (dropdown menu or combobox) that displays a list of available personas for assignment to a requirement, filtered by the authenticated user's organisation scope. The dropdown presents persona names and roles, supports search/filtering, and enables single or multiple persona selection depending on the assignment context.

persona selection list

A user interface component (dropdown menu, multi-select list, or searchable picker) that displays available personas filtered by the authenticated user's organisation scope, enabling selection of one or more personas for assignment to a requirement. The list presents persona names and roles and supports the designation of one persona as primary.

persona snapshot

A point-in-time capture of a persona's identifying attributes (name and role) stored as text in the requirements_history table when a persona assignment is created or modified. The snapshot preserves the persona's identity at the time of assignment, ensuring historical records remain intact even if the persona is later modified or deleted.

persona-aware ai

AI analysis and generation capabilities that consume assigned persona information (role, goals, frustrations) as context when analyzing requirements or generating user stories. Persona-aware AI tailors its outputs to reflect the perspective, needs, and constraints of the assigned user archetypes, producing persona-specific stories, acceptance criteria, and analysis findings.

persona-owned stories

User stories that are explicitly associated with a specific persona through a foreign key relationship, indicating that the story was generated from or is primarily relevant to that persona's goals and context. Persona-owned stories have a lifecycle dependency on their owning persona, requiring special handling during persona deletion to prevent orphaned story records.

personas

A feature in REQQA that manages user persona definitions—archetypal user profiles representing distinct user types, roles, or stakeholder groups with specific characteristics, goals, needs, and behaviors. Personas are used to inform requirement analysis, story writing, and design decisions by providing concrete representations of target users. Personas are organization-scoped entities that can be created, viewed, edited, and referenced throughout the requirements management process.

personas list

A user interface view that displays all saved personas belonging to the current organization, typically showing persona name, role, avatar thumbnail (if present), scope indicator (org-wide or app-specific), and usage count (number of requirements referencing each persona). The list provides navigation to persona detail views and persona creation functionality, and may support filtering, sorting, and search operations.

personas list page

A web page that displays all personas accessible to the authenticated user, filtered by organization scope and optionally by application scope, showing persona name, role, and thumbnail avatar for each entry, with navigation to individual persona detail views and persona creation functionality. The page implements the personas list display feature and serves as the primary interface for browsing available personas.

personas parameter

An optional parameter in the requirements write API that specifies the set of personas to be assigned to a requirement and which persona is designated as primary. The parameter accepts a collection of persona identifiers with primary designation flags, and when omitted defaults to zero persona assignments.

persona_id

A unique identifier assigned to each persona record in the system, used as the primary key for persona retrieval, assignment, and access control operations. The identifier format (UUID, integer, or other) determines how personas are referenced in API calls, database queries, and cross-table relationships.

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.

phase-entry skill

A Claude Code skill named 'guide-entry' that executes at the beginning of a development phase to read existing help content for templates in scope, identify templates lacking help pages, and generate a reading list and gap list to provide Claude with context about the current help system state before implementation work begins.

phase-exit skill

A Claude Code skill named 'guide-exit' that executes at the completion of a development phase to update or create help pages for templates modified during the phase, set last_touched_at and last_touched_by_phase metadata, trigger glossary re-indexing, flag stale screenshots, and generate the canonical template inventory for coverage reporting.

pii fields

Database columns, object properties, or data structure fields that contain Personally Identifiable Information (PII) such as names, email addresses, phone numbers, addresses, or other data that can identify an individual. In the context of AI systems, these are fields that should not be logged or included in prompts without proper sanitization or consent.

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.

pitch

The level of abstraction or detail at which a requirement is written, relative to its position in the requirement hierarchy. Appropriate pitch means the requirement provides detail consistent with its hierarchical level—neither too implementation-specific (pitched below its position) nor too abstract or heading-like (pitched above its position). A requirement with correct pitch adds meaningful capability, constraint, or quality factors beyond its parent without descending into implementation detail inappropriate to its level.

pitch finding

An analysis issue raised by the R-P step when a requirement's level of abstraction or detail is inappropriate to its position in the requirement hierarchy—either too implementation-specific (pitched below position) or too abstract/heading-like (pitched above position)—or when the requirement adds no capability, constraint, or quality factor beyond its parent's.

pixelation

A visual artifact in digital images where individual pixels become visible as distinct blocks or squares, typically occurring when a low-resolution image is displayed at a larger size or when aggressive compression is applied. Pixelation degrades image quality and is generally considered undesirable in user-facing avatars.

placeholder

A visual element or text displayed in a user interface when the actual content is absent or unavailable, providing a default representation that indicates the field exists but contains no data. Placeholders may include text like 'No description provided', empty state graphics, or grayed-out field labels.

placeholder file

A minimal markdown file placed in a content directory to satisfy build requirements and demonstrate directory structure, typically containing stub content, a title, and explanatory text indicating that real content will be added later. The file ensures the Docusaurus build process completes successfully even when substantive content has not yet been authored.

placement

The successful assignment of a candidate to a client care position, representing the completion of the recruitment and matching process. A placement occurs when a candidate accepts a position with a client and begins work. Placements are the primary business outcome metric for the agency, with a stated growth objective from 300 to 600 placements per year.

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.

playwright

An open-source browser automation framework developed by Microsoft that enables automated testing and screenshot capture across Chromium, Firefox, and WebKit browsers. Playwright provides APIs for controlling browsers programmatically, capturing screenshots, and simulating user interactions, commonly used for end-to-end testing and documentation screenshot generation.

playwright script

A Python or JavaScript automation script using the Playwright browser automation framework that programmatically controls a web browser to navigate pages, interact with UI elements, and capture screenshots. The script runs in a headless or headed browser mode, executes navigation sequences, waits for page load completion, and saves rendered page images to disk.

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.

plugin registration

The process by which an OAuth provider plugin is initialized and made available to the py4web authentication system. Registration involves loading the provider's configuration (client_id, client_secret, callback URLs), instantiating the provider's authentication handler, and making the provider available for user authentication flows. Registration occurs conditionally in common.py based on the presence of required credentials in settings.py.

plugin subclasses

Python classes that inherit from a base OAuth authentication plugin class and override specific methods to implement provider-specific authentication logic. Plugin subclasses for Google and GitHub extend the base plugin's callback handling to add the invite-gating logic before delegating to the parent class for account creation and session establishment.

png

Portable Network Graphics - a raster graphics file format that uses lossless compression, supporting transparency (alpha channel) and true color. PNG files are identified by the .png extension and are commonly used for web graphics, logos, and images requiring transparency or precise color reproduction without compression artifacts.

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.

policy decision-history

An audit trail or log that records all changes to adoption ratchet category status, including the date of each status change, the previous and new status values, the release in which the change occurred, the user who authorized the change, and the rationale for advancement or rollback. This history provides traceability and accountability for policy enforcement decisions.

popover

A small overlay UI component that appears adjacent to a triggering element (such as a button) when activated, displaying contextual information or actions without navigating away from the current page. Popovers typically include a close mechanism, position themselves automatically relative to the trigger, and dismiss when the user clicks outside or presses ESC. Distinguished from tooltips (which show on hover) and modal dialogs (which block the entire page).

population process

The execution workflow that assigns recommended_analyses values to requirement templates, including validation of template existence, determination of appropriate step-codes based on template type, assignment of values to the database, error detection and reporting, and rollback on failure. The process operates transactionally to ensure data integrity and provides idempotent behavior when re-executed.

post-update state

The complete state of a requirement's persona assignments after a modification operation has been committed to the database, representing the new current state that will be captured in the requirements history entry. Distinguished from pre-update state, the post-update state reflects all changes applied by the update transaction.

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.

pre-ticked

A checkbox UI state where the checkbox is initially rendered in a selected/checked state when the form or interface is first displayed, indicating a default or recommended selection. The user can modify this state by clicking to uncheck the checkbox. Also referred to as 'pre-selected' or 'default-checked'.

pre-update state

The complete state of a requirement's persona assignments before a modification operation is applied, representing the baseline condition that will be replaced by the post-update state. The pre-update state is used for comparison and audit purposes to track what changed during an update transaction.

primary

The designated main persona for a requirement, representing the principal user perspective that should guide requirement interpretation and story generation. When multiple personas are assigned to a requirement, the primary persona indicates which user role's needs take precedence in case of conflicting requirements or design trade-offs.

primary persona

The designated main persona among multiple personas assigned to a requirement, indicated by the is_primary flag in the requirement_personas join table. Exactly one persona must be marked as primary when multiple personas are assigned, representing the principal user archetype the requirement is designed to serve.

probe

A discrete validation check within the R-W analysis step that examines a specific aspect of template conformance (section presence, placeholder detection, or sentence pattern matching). Each probe can be independently gated based on template metadata availability, executes deterministically without AI calls, and produces a recorded status (checked, skipped, or compliant) in the analysis result.

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.

prompt suffix

The final section of an AI prompt that appears after the cached static content and immediately before the user's requirement text, containing dynamic per-request context such as retrieved document chunks. The suffix is not cached and is regenerated for each analysis call, allowing request-specific information to be injected while preserving cache benefits for the static prefix.

promptname

A database column in the gptlog table that stores a standardized identifier indicating the purpose or type of an AI call, using a controlled vocabulary such as 'analysis:STEP' for requirement analysis operations, 'generate_story' for story generation, or 'getTermDefinition' for glossary lookups. The promptname enables categorization and filtering of AI calls by their functional purpose.

prompttokens

The count of input tokens sent to the AI provider that are not served from cache, representing newly processed prompt content. Prompttokens are distinct from cached tokens (cachecreationtokens and cachereadtokens) and are priced at the standard input rate.

propagates

The automatic reflection of changes made to a referenced entity across all locations where that entity is used, without requiring manual updates to each reference. In the context of persona edits, propagation means that when a persona's attributes are modified, all requirements that reference that persona immediately display the updated persona information without requiring separate update operations on each requirement.

prose content-substring match

A fuzzy matching technique used in the third pass of the matcher that compares text fragments from the orphaned log's prompt content against the full text of requirements, looking for substantial substring overlap or similarity. This method handles cases where title matching fails but the prompt content contains recognizable excerpts from the requirement body.

prospective users

Individuals who are interested in using REQQA but do not currently have an account or invitation, and who may submit an access request to be considered for onboarding. Prospective users are unauthenticated visitors to the platform who represent potential future customers or team members, and their access requests are evaluated by the REQQA host before granting access.

prospective-user

An individual who has expressed interest in using REQQA by submitting an access request form but has not yet been granted an account or authenticated access to the system. Prospective users are in a pre-registration state awaiting triage and approval by REQQA administrators.

provenance

No definition yet.

provenance lookups

Queries that retrieve historical chunk records to trace the origin and revision history of retrieved context, enabling audit trails and understanding of which document version contributed to an analysis result. Provenance lookups access old chunks (from superseded document revisions) that are no longer used for active retrieval but are retained for traceability.

provenance view

A user interface component or database view accessible from the analysis page that displays the complete set of context documents and chunks used in an AI analysis call, including both static-include documents and RAG-retrieved chunks with their associated metadata (chunk_id, similarity_score, document_revision). The provenance view enables analysts to inspect and verify what information was provided to the AI during analysis.

provider plugin

A software module or component that implements OAuth 2.0 authentication integration with a specific identity provider (Google, GitHub, LinkedIn, etc.). Each provider plugin encapsulates provider-specific configuration (client credentials, endpoints), implements the OAuth authorization code flow, handles provider-specific API responses, and extracts standardized user profile information (email, name) for use by REQQA's authentication system. Provider plugins are referenced in FR-20.2 (Google), FR-20.3 (GitHub), and FR-20.4 (LinkedIn).

py4web mailer

A built-in email sending component of the py4web framework that provides a simplified interface for composing and sending email messages via SMTP. The Mailer class handles SMTP connection management, message formatting, and delivery, and is typically configured through framework settings with SMTP server credentials and connection parameters.

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

qdrant

An open-source vector database written in Rust that provides high-performance similarity search over dense vector embeddings. Qdrant supports payload filtering (enabling multi-tenant isolation by orgid), HNSW indexing for fast approximate nearest neighbor search, and RESTful/gRPC APIs for vector operations. It can run as a single-node instance or distributed cluster, with persistent storage and snapshot-based backups.

qdrant point

A vector database record in Qdrant consisting of a unique identifier (chunk_id), a high-dimensional embedding vector, and optional payload metadata. Each point represents a chunk's semantic content in vector space and enables similarity-based retrieval through nearest-neighbor search.

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.

quantity

No definition yet.

quarterly policy review

A scheduled review process occurring every three months where security policies, compliance rules, and control effectiveness are evaluated by designated stakeholders. The review assesses whether existing rules remain appropriate, identifies gaps, and approves updates to security controls including Semgrep rules.

quick-scan

An existing analysis implementation in REQQA that performs rapid, deterministic checks on requirement content, including placeholder text detection. The quick-scan runs before full analysis steps and provides early feedback on structural issues. The R-W step's placeholder probe reuses the quick-scan's placeholder detection logic rather than duplicating it.

quick-scan implementation

An existing lightweight validation mechanism in REQQA that performs rapid pattern-based checks on requirement content, specifically used for detecting placeholder text through regex pattern matching without invoking AI analysis. The quick-scan runs during requirement save operations and provides immediate feedback on structural issues.

R

rag contributions

Context information provided to an AI analysis call through Retrieval-Augmented Generation (RAG), consisting of chunks dynamically retrieved from a vector store based on semantic similarity to the analysis query. RAG contributions are distinguished from static-include documents by having associated chunk_id and similarity_score values in provenance records.

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 limit error

An error response returned by an AI service provider when the number of API requests from the organization exceeds the provider's allowed quota within a specified time window (e.g., requests per minute, tokens per day). Rate limit errors typically include HTTP status code 429 (Too Many Requests) and may include a Retry-After header indicating when requests can resume.

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-ranking

A two-stage retrieval refinement technique where an initial set of candidate chunks retrieved by vector similarity is re-scored using a more sophisticated model (often a cross-encoder) to improve relevance ranking. Re-ranking trades additional computational cost for higher precision in the final result set. Explicitly out of scope for this requirement.

re-seeded

The process of deleting all existing content in the demo application (requirements, stories, personas, analyses) and repopulating it from the canonical fixture file, restoring the demo data to a known, consistent state. Re-seeding occurs automatically during release deployments to ensure screenshot capture scripts always operate against predictable, up-to-date demonstration content.

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.

reassign

The action of changing a persona assignment from one requirement to a different requirement, or replacing one persona with another persona on the same requirement. Reassignment may be implemented as an atomic operation (single transaction) or as separate unassign-then-assign operations, depending on system design.

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.

reconnaissance traffic

Malicious or suspicious authentication attempts where an attacker systematically probes the OAuth sign-in endpoints with various email addresses to discover which accounts exist in the system, identify valid user emails, or map the organization's user base without legitimate authorization. Logging rejected OAuth attempts helps detect such reconnaissance patterns for security monitoring.

redirect uri

A pre-registered URL endpoint in an OAuth2 application configuration that specifies where the authorization server should redirect the user's browser after authentication completes, carrying an authorization code or error response. The redirect URI must exactly match the value registered with the OAuth2 provider to prevent authorization code interception attacks.

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.

registered user

A person who has completed the registration process by providing email, first name, surname, and password, but whose email address has not yet been confirmed through the confirmation link. Registered users cannot access the system until they become confirmed users.

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.

rejected oauth attempt

An OAuth authentication attempt that REQQA refuses to complete because the user's email address does not have a pending invitation in the system (per FR-20.5.2). The OAuth flow with the provider may succeed, but REQQA rejects the sign-in and does not create or update a user session. The rejection is logged with the reason 'no pending invite' for security monitoring.

rejection page

A web page displayed to users who attempt to sign in via OAuth without a valid invitation or existing account, explaining that REQQA is invite-only and providing instructions for obtaining an invitation. The page includes explanatory text, a call-to-action link to request access, and prevents any account creation from occurring.

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 build

An automated build process executed as part of the software release workflow that compiles, packages, and publishes all release artifacts including documentation, binaries, and deployable assets. The release build runs in a CI/CD pipeline and must complete successfully for a release to be published.

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 pipeline

An automated continuous integration/continuous deployment (CI/CD) workflow that executes a sequence of build, test, and deployment steps when releasing a new version of REQQA. The pipeline includes stages for code compilation, automated testing, database migrations, and deployment to staging and production environments. In the context of demo data, the pipeline includes a re-seeding step that restores the demo organisation's content from the canonical fixture file.

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 tag

A Git tag or version control system marker that identifies a specific commit as a release candidate or published release, typically following semantic versioning format (e.g., v1.2.3). The release tag serves as the authoritative source of the application version number during the build process and is used to stamp all release artifacts including help documentation.

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.

reordering

The user action of changing the display sequence or priority position of assigned personas in the requirement's persona list through drag-and-drop, up/down buttons, or manual sequence number entry in the user interface. Reordering changes the visual presentation order but does not affect the primary designation unless explicitly changed by the user.

reqqa branding

The visual identity and design elements that distinguish REQQA's user interface and documentation, including the REQQA logo, color palette (primary and accent colors), typography choices, footer content, and any other brand-specific styling that ensures consistent appearance across the application and documentation site.

reqqa host

The organization or team responsible for operating and administering the REQQA platform instance, who receives and processes access requests from prospective users. The REQQA host has a configurable email address for receiving access request notifications and is responsible for reviewing submissions, sending admin invitations to approved requesters, and managing spam or declined requests.

reqqa's own email-verification step

REQQA's internal email verification process where the system sends a confirmation email containing a unique, time-limited verification link to a newly registered user's email address. The user must click this link to verify email ownership before gaining full account access. This process is bypassed for OAuth users when the identity provider has already verified the email address.

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 artifact

A formal specification document or record in REQQA that describes a system capability, constraint, or quality attribute. Requirements are a specific type of artifact (as defined in the glossary) that can have associated analyses and issues. Distinguished from other artifact types such as stories, scopes, and applications.

requirement edit screen

A user interface page or modal dialog that displays a requirement's current attributes and provides form controls for modifying those attributes, including persona assignments, requirement text, metadata, and other editable fields. The edit screen is accessed by authorized users to update requirement details and persists changes to the database upon save.

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 seeding feature

A system capability that automatically populates initial values or metadata on newly created requirements based on their parent template's configuration, including inheriting recommended_analyses values from the template's canonical metadata. The seeding feature reduces manual data entry, ensures consistency with organizational standards, and provides sensible defaults that users can override if needed.

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.

requirements_history table

A database table that maintains an audit trail of all changes to requirement records, storing historical versions of requirement attributes including previous and new values, timestamps of changes, and the user who made each modification. This table enables version tracking, rollback capabilities, and compliance with audit requirements by preserving the complete change history for each requirement.

requirement_personas

A database join table that establishes the many-to-many relationship between requirements and personas, storing which personas are assigned to which requirements. Each row represents a single persona assignment to a requirement, with foreign keys to both the requirements table and the personas table. The table enables a requirement to be assigned multiple personas and a persona to be assigned to multiple requirements, supporting the persona-based filtering and requirement organization capabilities.

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.

resolver

A software component or function that determines which help content to display by matching the current page context (template_key and panel_key) against the help_pages table and returning the appropriate help_pages record or NULL if no match exists. The resolver encapsulates the lookup logic and applies role-based filtering (per FR-17.3) to ensure users only see help content appropriate to their permissions.

resolver query

A database query executed by the FR-17.2 help content resolver to locate the appropriate help_pages record for a given template_key, active_panel_key, and viewer role combination. The query implements a prioritized matching strategy that first attempts to find a role-specific entry (role_tag = viewer's role), then falls back to a generic entry (role_tag IS NULL), returning the first match according to this precedence order.

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.

response status

An HTTP status code returned by an API endpoint indicating the outcome of a request, consisting of a three-digit numeric code and associated reason phrase (e.g., '200 OK', '403 Forbidden', '201 Created') as defined in RFC 7231. The status code communicates whether the request succeeded, failed due to client error, or encountered a server error, enabling programmatic handling of different response conditions.

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.

retrieval-mode

A document processing mode where the document's content is chunked, embedded, and indexed in a vector database for semantic search and retrieval during analysis operations, as opposed to static-include mode where the entire document is provided as context. Retrieval-mode documents are accessed on-demand based on semantic similarity to analysis queries.

retrieval-mode documents

Context documents attached to an organisation that are indexed and queried during AI analysis operations to retrieve relevant chunks for inclusion in AI prompts. Distinguished from documents used in other modes (reference-only, training data). Retrieval-mode documents incur token costs based on the volume of chunks retrieved per analysis call.

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.

retrieve-on-demand document

A context document (regulatory text, policy corpus, or reference material) that has been indexed in the vector store and is configured to be queried dynamically during AI analysis rather than being statically included in every prompt. Retrieve-on-demand documents are attached at org/template/scope tiers and only contribute content when their chunks match the similarity threshold for the requirement being analyzed.

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.

review queue

A user interface view or data structure that displays all proposed tags in PROPOSED state for a specific organisation, enabling analysts to review, accept, or reject each proposal. The queue provides a workflow interface for tag triage, showing tag metadata (name, category, definition, usage note) and offering accept/reject actions. Items remain in the queue until explicitly accepted (transitioning to organisation-owned status) or rejected (deleted from the system).

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.

rfc calls

Remote Function Call - a protocol mechanism used to invoke functions or procedures in SAP systems remotely, enabling external applications to interact with SAP business logic and data through a standardized interface.

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.

role visibility

A field on help_pages that specifies which user roles (e.g., analyst, builder, admin) are permitted to view a particular help page, enabling role-based filtering of help content so that admin-only topics are hidden from ordinary users. Role visibility is distinct from the public/authenticated visibility flag and provides finer-grained access control within authenticated users.

role_tag column

A database column (likely on the help_pages table) that stores role-based visibility metadata, enabling help content to be filtered or displayed based on the authenticated user's role. The column may store a single role identifier or a comma-separated list of roles, and is used by the contextual help layer to enforce role-aware visibility without requiring a separate role visibility engine.

roll back

The exceptional action of transitioning a category from its current lifecycle stage to a previous stage in the sequence (e.g., from ratchet back to triage), typically performed when enforcement proves too strict or when organizational readiness is insufficient. Rollback is discouraged by the ratchet mechanism but permitted in exceptional circumstances with documented justification.

rollback

The process of reverting a production deployment to the previous known-good state when a defect is discovered post-deployment, including restoring previous configuration data, application code, and database schema while preserving contribution data submitted between the failed deployment and the rollback operation.

rolling migration.sql

A database schema migration script that is incrementally updated during development to capture all schema changes (such as column additions, data type modifications, or constraint changes) in a single file that can be applied to bring a database from the previous release state to the current development state. Rolling migrations are consolidated into versioned migration files at release time.

round

A discrete time-boxed period during the workshop session in which teams select a topic, work on it, and produce contributions. The workshop consists of multiple sequential rounds (typically 3-4 as per mission statement), with teams potentially selecting different topics in each round. Rounds structure the workshop timeline and provide natural breakpoints for topic selection and contribution capture.

rounded

A persona quality indicating completeness and depth across all defining characteristics, where the persona has sufficient detail in demographics, role, goals, motivations, and behaviors to feel like a real individual rather than a shallow stereotype. A rounded persona has no obvious gaps, internal contradictions, or one-dimensional traits, and provides enough context to inform design decisions.

rq job

An asynchronous background task managed by the RQ (Redis Queue) job processing system, which executes long-running operations outside the main request-response cycle to maintain application responsiveness. RQ jobs are enqueued with parameters, executed by worker processes, and can be monitored for status, retried on failure, and cancelled if needed.

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

saga

A design pattern for managing distributed transactions across multiple services by breaking a long-running transaction into a sequence of local transactions, each with a compensating action that can undo its effects if a later step fails. In the context of booking orchestration, a saga ensures that partial booking failures (e.g., seat assignment succeeds but payment fails) can be rolled back consistently.

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.

scaffold guidance

Instructional text displayed within or adjacent to a form field that explains the expected content, format, or purpose of that field, helping users understand what information to provide. Scaffold guidance may appear as placeholder text, help text below the field, tooltips, or info-icons, and remains visible or accessible while the user completes the form.

scenario

A single concrete example of system behaviour within a user story, written as a Scenario: block of Given-When-Then steps. A story contains one or more scenarios; each is intended to be independently verifiable. A Scenario Outline: is the parameterised form, driven by an Examples table. Scenarios carry tags declaring their purpose, the characteristic under test, and their standing in the acceptance gate.

Synonyms: Gherkin scenario

See also: Gherkin, scenario tag

schema migration

A controlled database schema change operation that modifies table structures, columns, indexes, or constraints while preserving existing data. Schema migrations are typically versioned, reversible, and executed through automated tools (such as /pydal-migrate) to ensure consistent database evolution across development, staging, and production environments.

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 indicator

A visual UI element displayed on the persona detail view that shows whether a persona is organisation-wide (appid NULL) or app-specific (appid set), typically rendered as text such as 'Organisation-wide' or 'App-specific: [App-ID]' to distinguish persona scope at a glance.

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.

scopeable

Of a backlog item: able to be placed in a release scope. An item is scopeable if and only if it stands at elaboration stage E4, meaning stories exist against its linked requirements. A scope holds stories, so an item with none cannot be scoped however well specified it otherwise is.

scoped

The process of filtering a complete set of available items (such as tag definitions or glossary terms) to include only those items that are actually referenced or used within a specific context (such as a release scope). Scoping reduces information volume by excluding unused definitions, ensuring consumers receive only relevant vocabulary rather than the entire catalogue.

screening

The initial evaluation stage in the recruitment process where candidate applications are reviewed to determine basic eligibility and suitability for home care roles, typically involving verification of qualifications, experience, and availability before progressing to interview.

secondary

A persona assignment classification indicating that the persona represents an additional user perspective for a requirement, as opposed to the primary persona which represents the main user role. Secondary personas are assigned when a requirement serves multiple user types, with the primary persona taking precedence in case of conflicting design decisions.

secondary persona

A persona assigned to a requirement that is not designated as the primary persona. Secondary personas represent additional user roles or stakeholder perspectives that the requirement should consider, but which are not the principal focus. When multiple personas are assigned to a requirement, all non-primary personas are classified as secondary. Secondary personas are displayed in the persona list after the primary persona and without the primary visual distinction.

section

A named, delimited portion of a requirement document that contains related content under a specific heading. Sections organize requirement content into logical units such as 'Rationale', 'Behaviour', 'Acceptance Criteria', and 'Out of Scope'. Each section has measurable attributes including word count, character count, and may be subject to size thresholds for analysis quality.

sections key

A machine-readable field in template front-matter that contains an ordered list of section headings declared by the template, used by FR-18.3.6.14 to verify requirement conformance. The key stores section names in the sequence they appear in the template structure.

seeding operation

A one-time or periodic administrative process that populates empty or missing field values in existing database records by copying values from related reference records (such as templates), typically executed by system administrators to backfill data for records created before a feature was implemented or to synchronize derived values with their authoritative sources.

semantic rules

Writing rules that require contextual understanding and interpretation of meaning to evaluate, such as determining whether a combinator joins two capabilities versus two conditions, or whether a phrase relies on heading context for clarity. Semantic rules cannot be reliably evaluated through pattern matching alone and require AI-assisted judgement to assess correctly.

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.

separation of concerns

A design principle where distinct aspects of a system (such as data storage, business logic, and presentation) are isolated into separate components with minimal overlap. Each component addresses a specific concern or responsibility, enabling independent modification and testing. In this context, topic definition, template structure, and contribution capture are separate concerns that should be implemented in distinct, loosely-coupled components.

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.

server-side

Execution or measurement occurring on the application server infrastructure rather than in the client's browser or device. In the context of performance measurement, server-side timing excludes network latency, client rendering time, and browser processing, measuring only the time spent executing application logic and database operations on the server.

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.

set characteristics

Properties that apply to a collection of requirements as a whole rather than to individual requirements, as defined in ISO/IEC/IEEE 29148:2018 §5.2.6. These include Complete, Consistent, Feasible, Comprehensible, and Able to be validated, and can only be assessed by examining the relationships and coverage across multiple requirements rather than analyzing a single requirement in isolation.

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.

shipped

Released to production and available to end users in a previous version of the REQQA product. In the context of requirement analysis steps, 'shipped' indicates that the analysis functionality was implemented and deployed before formal requirement documentation was created, distinguishing it from new capabilities being specified in the current release.

shipping address

No definition yet.

side door

The OAuth-based registration path where users create accounts by authenticating with a third-party identity provider (Google, GitHub, LinkedIn) instead of providing email and password credentials directly to REQQA. This is the alternative account creation mechanism that must also be gated by invite-only enforcement. The term contrasts with 'front door' (direct email/password registration) to distinguish between the two account creation mechanisms.

sidebar

A navigation component in the Docusaurus documentation site that displays a hierarchical list of documentation pages and sections, defining the order and structure in which content is presented. The sidebar configuration determines the sequence of sections in generated PDF output and provides the canonical ordering for documentation content.

sidebar entry

A navigation item in Docusaurus's sidebars.js configuration file that defines how a content directory or document appears in the site's left-hand navigation menu, including its label, position, and hierarchical relationship to other entries.

similarity score

A numerical measure (typically 0.0 to 1.0 for cosine similarity, or unbounded for Euclidean distance) quantifying how semantically similar a retrieved chunk's embedding is to the query embedding. Higher scores indicate greater relevance. Similarity scores are computed by the vector store during retrieval and recorded in provenance to enable assessment of retrieval quality and debugging of relevance issues.

similarity-descending order

A sorting sequence where retrieved chunks are ordered from highest similarity score to lowest similarity score, ensuring the most relevant chunks appear first in the injected prompt content. Similarity is typically measured using cosine similarity or other distance metrics between the query embedding and chunk embeddings.

similarity-search

A query operation that finds vectors in a vector database that are most similar to a given query vector, typically using distance metrics such as cosine similarity, Euclidean distance, or dot product. Similarity search returns the k-nearest neighbors (top-k results) ranked by similarity score, enabling semantic retrieval where conceptually related items are found even if they don't share exact keywords.

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

skipped stage

An elaboration stage that an item's evidence never satisfied although the item stands at a higher one. Recorded rather than corrected: an item whose stories exist but whose findings were never settled stands at E4 with E2 skipped, and the skip is a signal about the quality of the specification rather than an error in classification.

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.

smtp

Simple Mail Transfer Protocol - an Internet standard communication protocol for electronic mail transmission, used by mail servers and clients to send email messages over TCP/IP networks. SMTP defines the message format and transfer process for delivering email from sender to recipient mail servers, typically operating on port 25, 587, or 465.

soft truncation

A token limit enforcement strategy where retrieval stops when adding the next chunk would exceed the maximum token budget, but already-retrieved chunks are retained. Soft truncation allows partial chunk inclusion up to the limit, as opposed to hard truncation which might discard all chunks if the limit is exceeded. The term 'soft' indicates graceful degradation rather than strict rejection.

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.

solution-freedom

A quality characteristic of a requirement indicating that it specifies what capability or outcome is needed without prescribing how that capability should be implemented, thereby preserving design options and avoiding unjustified constraints on implementation choices. A solution-free requirement states needs rather than solutions, allowing alternative technical approaches to satisfy the same objective.

solution-freedom finding

An analysis issue raised by the R-P step when a requirement specifies a particular implementation technology, product, structure, algorithm, or interface mechanic without stating a rationale for constraining the design, and where an alternative implementation would satisfy the same underlying need.

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 citation

Metadata appended to each retrieved chunk in the injected prompt that identifies the originating document, chunk location, and optionally the similarity score. Source citations enable the AI to reference specific regulatory or policy sources in its analysis and provide traceability for audit purposes. Format and content of citations are defined by the injection logic.

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.

span

A contiguous portion of requirement text identified by an analysis step as exhibiting a particular characteristic or defect. In the context of R-P analysis, a span is the specific phrase, sentence, or text fragment judged to constitute implementation detail or inappropriate pitch, quoted in the finding to enable verification of the analyser's reasoning.

spend

The total monetary cost incurred by an organization for AI analysis operations during a specified time period, calculated by aggregating token costs (prompt tokens, completion tokens, and cached tokens) across all analysis calls, multiplied by the applicable provider pricing rates. Spend is tracked per organization and reported in the organization's base currency.

sql injection

A code injection attack where an attacker inserts malicious SQL statements into application input fields (such as login forms, search boxes, or API parameters) to manipulate the database query executed by the application. Successful SQL injection can allow attackers to bypass authentication, access unauthorized data, modify or delete data, or execute administrative operations on the database. SQL injection is prevented through parameterized queries, input validation, and least-privilege database accounts.

sso

Single Sign-On - an authentication mechanism that allows users to access multiple applications or services with one set of credentials, typically by authenticating once with a central identity provider (such as Google, GitHub, or LinkedIn) and then being automatically authenticated to other integrated applications without re-entering credentials. In this context, SSO enables REQQA users to log in using their existing accounts at external identity providers rather than creating separate REQQA-specific passwords.

sso_id

A field in the auth_user table that stores the unique identifier assigned by an OAuth2 identity provider to a user account, enabling py4web to link multiple authentication methods (password, Google, GitHub, LinkedIn) to the same REQQA user record. When a user authenticates via OAuth, py4web matches the provider's user ID and email against existing auth_user records to determine whether to log in to an existing account or create a new one.

stable directory

A filesystem directory path that remains constant across releases and build executions, ensuring that generated screenshot files are written to a predictable location that Docusaurus content can reference without path changes. The directory is version-controlled or mounted at a fixed location in the build environment, and its structure (subdirectories, naming conventions) is consistent across runs.

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.

staging environment

A pre-production deployment environment that mirrors the production platform configuration, hosting a copy of the application with migrated data for user acceptance testing, training, and final verification before go-live. The staging environment allows representative users to perform realistic task scenarios without affecting live operational data.

stale screenshots

Screenshot images embedded in help pages that depict UI elements or templates that have been modified since the screenshot was captured, making the image no longer accurately represent the current system state. The guide-exit skill flags these for human review or regeneration to maintain help content accuracy.

standard avatar dimension

A fixed pixel dimension (width × height) configured in the system to which all uploaded avatar images are resized during normalization, ensuring consistent display size across all personas. Typically expressed as a square dimension (e.g., 200×200 pixels) or a specific width and height pair.

standard dimensions

A fixed pixel dimension (width × height) configured in the system to which all uploaded avatar images are resized during normalization, ensuring consistent display size across all personas. Typically expressed as a square dimension (e.g., 200×200 pixels) or a specific width and height pair.

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.

static-include documents

Documents that are explicitly included in the analysis context by configuration or rule rather than retrieved dynamically through RAG similarity search. Static-include documents are always provided to the AI regardless of query relevance, typically representing foundational context, templates, or mandatory reference materials. Distinguished from RAG-retrieved chunks by the absence of chunk_id and similarity_score in provenance records.

static-site generator

A build tool that transforms source content (typically Markdown files, templates, and assets) into a complete set of static HTML, CSS, and JavaScript files that can be served by any web server without requiring server-side processing or databases at runtime. Static site generators enable fast page loads, simple hosting, and improved security compared to dynamic content management systems.

static/prompts/

A designated directory in the application codebase where AI prompt templates are centrally stored and managed, following a convention that separates prompt content from application logic. Prompts in this directory are subject to version control, review processes, and are the approved location for prompt definitions.

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

An individual analysis operation within the ReqQA analysis framework, identified by a step code (e.g., R-D, R-F, R-C) that represents a specific analytical dimension such as Definitions, Features, or Consistency. Each step corresponds to a distinct AI prompt template and produces a structured analysis result. In the context of AI logging, the step is encoded in the promptname field to enable step-level cost and usage reporting.

step code

A short alphanumeric identifier (such as R-D, R-F, R-N, R-P, R-W) that uniquely identifies a specific analysis step within the REQQA analysis framework. Step codes are registered in the STEP_CODES enumeration and used in recommended-analyses fields to specify which analyses should be performed on a requirement.

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.

step_codes

An ordered enumeration or configuration constant within REQQA that defines the canonical sequence of analysis step codes (R-D, R-G, R-F, R-I, R-R, R-E, R-C, R-B, R-Q, R-A, R-M, etc.), used to determine the numbering and ordering of analysis step requirements under parent FR-18.3.4.

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.

stop-word list

A fixed, non-configurable list of common words (articles, conjunctions, prepositions, auxiliary verbs) that are excluded from meaning-bearing token analysis because they serve structural rather than semantic purposes. Examples include 'the', 'and', 'or', 'is', 'are'. The list is system-defined to ensure consistent token analysis across all requirements.

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.

structural metadata

Tags that provide traceability and organizational information about a scenario's origin and priority rather than describing test characteristics or behavior. In REQQA's context, structural metadata includes provenance tags (@feature:, @req:, @priority:) that link scenarios back to their source requirements and features. These tags are excluded from the tag vocabulary because they serve a different purpose than scenario classification tags.

structured logging

A logging approach where log entries are written in a consistent, machine-parseable format (typically JSON) with predefined fields (timestamp, severity, correlation_id, user_id, action, module, outcome, duration_ms) enabling efficient querying, filtering, and analysis of log data by automated tools and monitoring systems.

structured markdown

A markdown-formatted text file that follows a specific hierarchical organization defined by the requirement: topic titles as top-level headings, template headings as subheadings, and entries as list items or paragraphs under each subheading. The structure preserves the topic → heading → entry hierarchy and uses markdown syntax (# for headings, - or * for lists) to create a human-readable, machine-parseable document.

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.

stub message

A placeholder message displayed to users when they request help for a page or panel that does not yet have authored help content. The stub message informs the user that help is not yet available (rather than showing a 404 error) and logs the template_key to support gap detection analytics (FR-17.12). The message content and format should be consistent across all stub instances.

subclass

In object-oriented programming, a class that inherits properties and methods from a parent class (superclass) while adding or overriding specific functionality. In this context, creating a new Python class that extends OAuth2Github to customize its callback behavior while retaining its core OAuth flow implementation.

subpath

A URL path segment that appears after the domain name, used to organize content under a single domain. For example, in 'reqqa.ai/docs', '/docs' is a subpath. Serving content via subpath (using nginx location blocks) is an alternative to using a subdomain (vhost) and affects URL structure, routing configuration, and cookie/session scope.

substantive

In the context of requirement rationales, a rationale is substantive when it provides meaningful justification by naming at least one of: (a) a stakeholder or role whose need would go unmet, (b) a policy, regulation, standard or contractual obligation being discharged, (c) a parent requirement or mission objective being served, or (d) a stated consequence of removal. A substantive rationale goes beyond restating the requirement in different words and establishes the necessity of the requirement through external reference or impact analysis.

substantive rationale

A rationale section that states information not present in the requirement statement itself, specifically identifying the need, policy, parent requirement, or mission objective served by the requirement, or describing the consequence of its removal. A substantive rationale provides justification for the requirement's existence beyond restating what the requirement does. Contrast with non-substantive rationales that merely rephrase the requirement, assert generic value without naming beneficiaries, or are absent entirely.

success message

A temporary user-facing notification displayed after successful completion of an operation, typically shown as a banner, toast, or alert at the top of the page, containing confirmation text and automatically dismissing after a few seconds or requiring user acknowledgment.

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 catalogue

The master set of tag definitions shipped with REQQA and maintained by the product team, serving as the baseline vocabulary available to all organisations. The system catalogue defines standard tags across all categories (scenario purpose, test characteristics, data conditions, risk levels, acceptance gates) and cannot be modified by individual organisations, though organisations may override individual tag definitions or add custom tags.

system default definition

The original definition text provided by REQQA for a system tag in the tag catalogue, which applies to all organisations unless overridden. The system default serves as the baseline definition and is displayed beneath organisation overrides in the tag glossary for comparison purposes.

system prefix

The initial portion of an AI prompt that contains system-level instructions, context, and configuration that applies to all analyses of a given type, assembled before artifact-specific content is added. The system prefix may include role instructions, output format specifications, analysis methodology guidance, and organizational context that remains constant across multiple artifact analyses.

system time

The current timestamp as reported by the application server's operating system clock, typically in UTC format with microsecond precision. System time is used as the default value for timestamp fields (created_at, updated_at) when no explicit timestamp is provided in a request. The system time must be synchronized across all application servers using NTP or equivalent time synchronization protocols.

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.

systemd unit

A configuration file that defines a service, mount point, device, or other system resource managed by systemd (the Linux system and service manager). A systemd unit file specifies how to start, stop, and monitor a service, including dependencies, restart policies, resource limits, and logging configuration. Unit files typically have extensions like .service, .socket, or .timer and are stored in /etc/systemd/system/ or /lib/systemd/system/.

T

tag catalogue

The master reference collection of all system-defined scenario tags available across the REQQA platform, containing tag names, definitions, usage notes, and category assignments. The tag catalogue serves as the baseline vocabulary from which organisations can create overrides or extensions.

tag glossary

A user-facing display page or interface component that presents the complete effective vocabulary for an organisation, showing each tag's name, category, definition, and usage note, organized by category and sorted alphabetically within each category. The tag glossary enables administrators to review available tags and understand their intended usage.

tag line

A line in Gherkin syntax that begins with '@' and contains one or more scenario tags, appearing immediately before a Feature, Rule, or Scenario declaration. Tag lines are the structural location where tags are authored and from which they are extracted during parsing, as distinct from '@'-prefixed tokens that may appear within step text or examples tables.

tag vocabulary

The complete set of scenario tags available for use within an organization, consisting of system-defined tags (with optional organization overrides) and organization-specific custom tags. Each tag in the vocabulary includes a name, definition, and usage guidance that instructs the story generator how to apply it.

target chunk size

The desired number of tokens per chunk in a chunking strategy, serving as a guideline for splitting documents while allowing variation to respect natural text boundaries (paragraphs, sentences). The target is a soft constraint that may be exceeded or undershot to maintain semantic coherence, with hard limits enforced by embedding model token limits.

team

A group of workshop participants (typically 2-4 individuals) who collaborate on exploring and contributing to topics during the session. Teams are formed at the start of the workshop, select topics to work on, and produce contributions that are captured by the system. Each team is tracked as a distinct entity for coverage calculation and topic assignment purposes.

techcorp

A sample organization name used in test scenarios and examples to represent a fictional company for demonstration purposes. TechCorp serves as a placeholder organization identifier in acceptance criteria and test data, distinct from production organization names.

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.

template heading

A predefined section label within a topic template that structures discussion entries into logical categories or questions. Template headings provide the organizational framework for team discussions, with entries grouped and displayed under their corresponding headings in a defined sequence.

template inventory

A canonical, system-maintained catalog of all user-reachable templates in REQQA, listing each template's key (template_key and optional panel_key), current help-page status (none/stub/draft/published/stale), freshness metadata (last_touched_at, last_touched_by_phase), and demo-inclusion flag. The inventory is derived (not manually authored) and regenerated by the phase-exit skill on every phase close, serving as the single source of truth for gap detection, PDF export filtering, and demo agenda construction.

template key

A unique identifier assigned to each context page template (e.g., 'reqsList', 'analysisKickoff') used in forward link references to establish canonical relationships between how-to guides and context pages. Template keys are validated against a registry of known templates, and unknown keys are flagged in the authoring UI to prevent broken references.

template placeholder

Instructional or example text included in a requirement template to guide authors in completing each section. Placeholders typically use distinctive formatting (italics, brackets, or specific phrasing like 'Describe the...') and are intended to be replaced with actual content. When a section is populated with real content, any remaining placeholder text becomes obsolete and should be removed.

template structure

The hierarchical organization of headings, sections, and fields that define the format for participant contributions to a specific topic. Template structures are configurable per topic and stored as data (not code), enabling moderators to customize contribution formats without developer intervention. Example: A template might specify headings like 'Context', 'Problem', 'Solution', 'Benefits'.

template_key

A unique identifier assigned to each user-visible template in REQQA that serves as the primary lookup key for resolving context-sensitive help content. The template_key corresponds to the template file name or route identifier and is used in combination with active_panel_key to locate the appropriate help page entry in the help_pages table.

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.

three-pass matcher

A sequential matching algorithm that attempts to resolve orphaned AI analysis logs to their source artifacts through three progressively broader matching strategies: (1) exact H1-title match, (2) Gherkin feature/requirement reference parsing, and (3) prose content substring matching. Each pass operates only on records unresolved by previous passes, with confidence scores assigned based on the matching method used.

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.

throughput

A performance metric measuring the number of candidates or placements processed by a staff member or the entire team over a defined time period (e.g., per week, per month). Throughput indicates processing capacity and productivity.

thumbnail avatar

A small graphical representation or icon (typically 40x40 to 100x100 pixels) associated with a persona that visually identifies the persona's role or character, displayed in list views and summary displays to provide quick visual recognition without requiring full-size images.

thumbnail avatar image

A small graphical representation or icon (typically 40x40 to 100x100 pixels) displayed in list views to visually identify a persona, combining the properties of both 'thumbnail avatar' (small preview image) and 'avatar' (persona representation image) from the glossary.

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 count

The total number of tokens (input prompt tokens plus output completion tokens) consumed by one or more AI API calls during an analysis operation, measured according to the AI provider's tokenization scheme (typically GPT-style byte-pair encoding). Token count is the primary unit for measuring AI API usage and calculating costs.

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 contributing documents

The subset of retrieval-mode documents that account for the highest proportion of total retrieval tokens consumed by an organisation during a specified period, ranked in descending order by their cumulative token contribution. Typically displayed as a top-N list (e.g., top 5 or top 10) to highlight documents with the greatest cost impact.

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.

top-k chunks

The K most similar document chunks to a query, ranked by similarity score in descending order, where K is a configurable integer parameter (e.g., top-5, top-10). In RAG systems, top-K retrieval returns the most semantically relevant chunks from the vector store to include in the AI prompt context.

top-k query

A vector similarity search operation that retrieves the K most similar vectors (chunks) to a query vector, ranked by similarity score in descending order. K is a configurable parameter determining how many results to return. In this context, the query returns the most relevant document chunks for a requirement, subject to similarity threshold and token limit constraints.

topic

A discrete subject area or discussion theme prepared by the moderator for team exploration during the workshop session, serving as the unit of work assignment and coverage tracking. Each topic represents a distinct area requiring team input and contribution, with the system tracking how many teams have worked on or completed each topic.

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.

traceability

The documented relationship between a requirement and its sources (stakeholder needs, policies, regulations, standards, parent requirements) that demonstrates the requirement's origin and justification. Traceability enables verification that requirements accurately transform their sources and supports impact analysis when sources change. In REQQA, traceability is established through recorded Source sections, parent-child requirement relationships, and mission linkages.

traceability check

A validation performed by the R-N analysis step to verify that a requirement has documented traceability to its sources, including recorded source attribution (stakeholder, policy, standard), parent requirement linkage, or mission statement connection. The traceability check ensures requirements are not orphaned and can be traced to their origin.

transaction commit

The point at which a database transaction is successfully completed and all changes are permanently written to the database, making them visible to other users and processes. In the context of holding modifications, this is when the create, update, or delete operation is finalized and the new state becomes the authoritative record.

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.

transition event

A queryable record that a backlog item's elaboration stage changed, carrying the item, the stage moved from, the stage moved to, the time, and the structured cause. A recomputation producing an unchanged stage writes no event.

transitive walk

The traversal that produces a dependency closure, resolving the dependencies of items already drawn in, and their dependencies in turn. Bounded so that an unbounded pull cannot drag an arbitrary share of the backlog into a proposal.

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.

unassign

The action of removing the association between a persona and a requirement by deleting the corresponding record in the requirement_personas join table, making the persona no longer assigned to that requirement. Unassignment does not delete the persona itself, only the linkage to a specific requirement.

unassigned persona

A persona record that has zero current assignments to requirements, as evidenced by the absence of requirement_personas join table rows linking that persona to any requirement. Unassigned personas can be deleted without requiring reassignment workflows, as they have no active dependencies on requirements.

unauthenticated request

An HTTP request to a protected API endpoint or web page that lacks valid authentication credentials, either because no authentication token or session cookie is provided, or because the provided credentials are invalid, expired, or malformed. Unauthenticated requests are rejected with HTTP 401 status and do not proceed to authorization checks.

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.

universal steps

Analysis steps that apply to every requirement regardless of content type or domain, assessing intrinsic characteristics of the requirement itself rather than examining specific content dimensions. Universal steps include R-N (Necessity), R-P (Pitch), and R-W (Well-formedness/conformance to template), which evaluate whether a requirement is justified, appropriately scoped, and properly structured.

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.

upscaling

The process of increasing an image's pixel dimensions to a larger size through interpolation algorithms, typically performed when the source image is smaller than the target dimension. Upscaling adds pixels through estimation, which can result in quality degradation or blurriness if the size increase is significant.

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.

usage list

A display component within the persona deletion interface that shows all requirements currently assigned to the persona being deleted, typically including requirement identifiers, titles, and navigable links. The usage list provides the analyst with visibility into the persona's current assignments to inform their decision about whether to proceed with reassignment or abandon the deletion.

user archetype

A representative model of a typical user type or role, characterized by common goals, behaviors, frustrations, and needs, used to provide human context and empathy when specifying requirements. User archetypes aggregate patterns observed across real users into a fictional but realistic character that guides design and prioritization decisions.

user-reachable template

A template in REQQA that is accessible to authenticated users through normal navigation, excluding system-internal templates, error pages, or administrative interfaces not exposed in the standard user interface. User-reachable templates are the set of pages for which context-sensitive help should be provided, as defined by HR-17.P2's inclusion criterion. The set is discovered automatically by the phase-exit skill through template registry scanning.

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.

validation error

A system-generated error message displayed to users when submitted data fails to meet defined validation rules, constraints, or business logic requirements, preventing the operation from completing until the invalid input is corrected.

validation set

A derived data structure in modules/rautils.py that contains the set of valid analysis step codes that may be recommended by templates or requirements, generated from STEP_CODES to ensure recommended-analyses metadata references only registered steps. The validation set is used to validate step code references during template authoring and requirement metadata assignment.

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.

vector store

A specialized database optimized for storing, indexing, and querying high-dimensional vector embeddings, supporting efficient similarity search operations (typically using approximate nearest neighbor algorithms like HNSW or IVF). Vector stores enable fast retrieval of semantically similar content by computing distance metrics (cosine similarity, Euclidean distance) between query vectors and stored document vectors.

verification status

A data field indicating the current state of a candidate's background verification process in Phase 2, with possible values including: not_started, garda_vetting_pending, garda_vetting_complete, references_pending, references_complete, qualifications_pending, qualifications_complete, verification_passed, verification_failed. The status is updated by the Verification module and read by Screening, Matching, and Placement modules to determine candidate eligibility for progression.

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.

version stamp

A metadata attribute attached to an embedded screenshot or diagram that identifies the specific version or iteration of that image, typically represented as a version number, timestamp, or hash value. The version stamp enables tracking of image updates over time and comparison against system version to detect staleness. When the system version advances beyond the image's version stamp by more than the configured freshness window, the image is flagged as potentially outdated and requiring review.

vhost

Virtual host - a web server configuration that allows multiple domain names or websites to be served from a single physical server or IP address. In nginx, a vhost is configured through a server block that defines the domain name, document root, and routing rules for a specific site. The term 'vhost' is shorthand for 'virtual host'.

viewport width

The visible width of a web browser window or device screen in which content is rendered, measured in CSS pixels. Viewport width determines which responsive design breakpoints are active and affects layout calculations. It excludes browser chrome (toolbars, scrollbars) and represents only the content rendering area.

visually distinguished

A visual design treatment applied to the primary persona in the persona display that differentiates it from secondary personas, making it immediately recognizable as the principal user perspective for the requirement. Visual distinction may be achieved through formatting techniques such as bold text, distinctive background color, border styling, icon placement, position (appearing first in the list), font size, or other visual emphasis that draws user attention and clearly indicates primary status.

vocabulary entry

A single record in the tag vocabulary response that describes one scenario tag, containing the tag's name, category, definition, usage notes, and metadata indicating whether it is system-defined, organisation-overridden, or custom. Each vocabulary entry corresponds to one tag found in the release's stories and provides the authoritative interpretation of that tag for downstream consumers.

vocabulary response

A structured API response payload returned by the tag vocabulary endpoint that contains the scoped set of tag definitions relevant to a specific release, including tag names, categories, definitions, source attribution, and test strategy information. The response format includes metadata fields and follows the standard API response structure with status codes and error handling.

W

warehouse manager

No definition yet.

warn-and-allow

A validation policy where structural or syntactic issues are reported to the user as warnings but do not prevent the operation from completing. In the context of Gherkin validation, warn-and-allow means that stories with imperfect syntax can still be saved, with validation issues surfaced for the author to address later rather than blocking the save operation.

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.

whitespace normalization

A text processing operation that standardizes whitespace characters in a string by: (1) trimming leading and trailing whitespace, (2) replacing sequences of multiple whitespace characters (spaces, tabs, newlines) with a single space, and (3) optionally converting all whitespace types to standard ASCII space (U+0020). Whitespace normalization ensures consistent string comparison by eliminating formatting variations that do not affect semantic content.

work factor

A configurable parameter in the bcrypt password hashing algorithm that determines the computational cost of generating a hash, expressed as an exponent (2^work_factor iterations). Higher work factors increase security by making brute-force attacks more expensive, but also increase legitimate authentication time. Typical values range from 10 to 14.

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.