Skip to main content
Version: 3.0.1

CC Rule (BCC)

Version: v3.0.0 Status: Normative (text), Illustrative (diagrams only) Scope: BCC rule validates that positive classifications have CT values within configured control range bounds Domain: RULES-CC Precedence: Within Curve Control validation sequence


Statement

The system shall execute the BCC (Curve Control) rule to validate that positive classifications have CT (Cycle Threshold) values within configured control range bounds.

The rule ensures curve control validity by checking classification status first, then verifying CT values fall within the upper and lower bounds configured for the observation's role-to-target mapping. When configuration is missing, the rule explicitly fails with a distinct error code rather than proceeding with defaults.


Quick Reference

IDCore BehaviorPriorityStatus
REQ-RULES-CC-001Validates classification is positive and CT within boundsHIGHDraft
REQ-RULES-CC-002Sets error when control range configuration is missingHIGHDraft

Key Integration Points: Analysis Engine, Kit Configuration (control range settings), Well/Observation data, Error handling system

Rule Summary

PropertyValue
NameBCC (Curve Control)
Alias"Control is valid"
TriggersWhen evaluating curve control validity for an observation
OutputSets error codes at well and target levels on failure

Rule Flowchart (Illustrative)

This diagram illustrates the sequential decision flow. The validation order is: configuration check, classification check, upper bound check, lower bound check.


Definitions

TermDefinition
BCCRule identifier for the Curve Control validation rule
CT (Cycle Threshold)The PCR cycle number at which fluorescence crosses a threshold, indicating target detection
Control Range SettingConfiguration that defines upper and lower CT bounds for a specific role-to-target mapping
Role-to-Target MappingAssociation linking an observation to its configured control range parameters
ClassificationThe determination of whether a target is positive, negative, or other status

Assumptions

  • Control range settings are configured prior to rule execution
  • Observations have a classification result assigned before BCC rule evaluation
  • Observations have a CT value available when classification is positive
  • Role-to-target mapping is established for observations

Requirements

Curve Control Validation (REQ-RULES-CC-001)

FR-CC-001: Validate Curve Control via Classification and CT Bounds

The system shall execute the BCC rule to validate curve control by verifying that the classification is positive and the CT value falls within the configured upper and lower bounds.

Acceptance Criteria

Validation Sequence:

  • The validation sequence shall be: classification check, then upper bound check, then lower bound check

Classification Check:

  • When classification is negative, the rule shall fail with FAILED_POS error codes

CT Bounds Check:

  • When CT value is greater than the configured upper bound, the rule shall fail with CONTROL_OUT_OF_RANGE_HIGH error codes
  • When CT value is less than the configured lower bound, the rule shall fail with CONTROL_OUT_OF_RANGE_LOW error codes
  • The CT bounds check shall use inclusive comparison (CT >= lower bound AND CT <= upper bound)

Pass Condition:

  • When classification is positive AND CT is within bounds (inclusive), the rule shall pass without error

Error Application:

  • Error codes shall be applied at both well level (_WELL) and target level (_TARGET)

Error Handling

ConditionError Code (Well)Error Code (Target)
Classification is negativeFAILED_POS_WELLFAILED_POS_TARGET
CT > upper boundCONTROL_OUT_OF_RANGE_HIGH_WELLCONTROL_OUT_OF_RANGE_HIGH_TARGET
CT < lower boundCONTROL_OUT_OF_RANGE_LOW_WELLCONTROL_OUT_OF_RANGE_LOW_TARGET

Trace: Source: 3.0.0-CC Rule / Requirements Table (Rows 1, 2, 3) | Jira: BT-1464 | Epic: BT-674 | Tests: BT-1333, BT-2119


Missing Configuration Handling (REQ-RULES-CC-002)

FR-CC-002: Set Error When Control Range Configuration Missing

The system shall set the CC_LIMITS_MISSED error code when the BCC rule is executed but the required control range settings are not configured for the observation being analyzed.

Acceptance Criteria

Configuration Lookup:

  • Control range settings shall be keyed by role-to-target mapping
  • When observation role-to-target mapping does not match any configured control range setting, the system shall set CC_LIMITS_MISSED error on the well

Behavior on Missing Config:

  • The error shall be set regardless of the observation's classification status
  • The rule shall not attempt to execute CT bound validation when configuration is missing
  • The rule shall explicitly fail rather than use defaults or silently pass when configuration is missing

Error Handling

ConditionError CodeLevel
No matching control range setting for observation's role-to-target mappingCC_LIMITS_MISSEDWell

Trace: Source: 3.0.0-BCC rule - add CC_LIMITS_MISSED error (Row 1) | Jira: BT-4154 | Epic: BT-4148 (Phase 2A) | Tests: BT-4167


Configuration Options

OptionDefaultDescriptionAffects
Control Range Upper BoundPer-mappingMaximum acceptable CT value for positive controlREQ-RULES-CC-001
Control Range Lower BoundPer-mappingMinimum acceptable CT value for positive controlREQ-RULES-CC-001
Role-to-Target MappingPer-observationLinks observation to its control range settingsREQ-RULES-CC-001, REQ-RULES-CC-002

Implementation (Illustrative)

ComponentLocation
Rule ClassAnalyzer/Rules/BccRule.php

Traceability Matrix

RequirementTitleVerificationImplementationTest CasesStatus
REQ-RULES-CC-001Validate Curve Control via Classification and CT BoundsTestBccRuleBT-1333, BT-2119Draft
REQ-RULES-CC-002Set Error When Control Range Configuration MissingTestBccRuleBT-4167Draft

Notes

  • Rule ID: BCC (also known as "Control is valid")
  • Part of Phase 2A initiative: Verify Rules have needed well/config info to run
  • Error code pattern uses dual-level application (*_WELL and *_TARGET) for traceability at both levels

Acceptance Tests

Test: REQ-RULES-CC-001

Back to requirement

Test: Negative classification fails rule

Given: An observation with final classification = Negative
And: Control range settings configured for the observation
When: BCC rule analyzes the observation
Then: The rule shall fail
And: FAILED_POS_WELL error shall be set on the well
And: FAILED_POS_TARGET error shall be set on the target

Test: CT above upper bound fails rule

Given: An observation with final classification = Positive
And: Control range upper bound = 30
And: Observation CT value = 35
When: BCC rule analyzes the observation
Then: The rule shall fail
And: CONTROL_OUT_OF_RANGE_HIGH_WELL error shall be set on the well
And: CONTROL_OUT_OF_RANGE_HIGH_TARGET error shall be set on the target

Test: CT below lower bound fails rule

Given: An observation with final classification = Positive
And: Control range lower bound = 20
And: Observation CT value = 15
When: BCC rule analyzes the observation
Then: The rule shall fail
And: CONTROL_OUT_OF_RANGE_LOW_WELL error shall be set on the well
And: CONTROL_OUT_OF_RANGE_LOW_TARGET error shall be set on the target

Test: Valid positive with CT in bounds passes rule

Given: An observation with final classification = Positive
And: Control range lower bound = 20
And: Control range upper bound = 30
And: Observation CT value = 25
When: BCC rule analyzes the observation
Then: The rule shall pass
And: No error codes shall be set

Test: REQ-RULES-CC-002

Back to requirement

Test: Missing control range configuration sets error

Given: Control Range Setting A with role to target mapping = map_A
And: Well with crossover = false
And: Observation with role to target mapping = map_B (different from control range setting)
And: Observation final classification = Positive
When: BCC rule analyzes the observation
Then: Well shall have CC_LIMITS_MISSED error set

Design DocumentRelevant Sections
SDD AlgorithmsRule execution, Error handling

Appendix: Process Artifacts

Completion Checklist

  • All requirements are capability-level (describe behavior, not UI)
  • Requirement variants consolidated (no requirement explosion)
  • UI details are fully demoted to Illustrative section
  • Configuration options are not encoded as requirements
  • Acceptance criteria describe behavior, not UI mechanics
  • Every requirement has acceptance criteria and source traceability
  • Error handling addressed for I/O, validation, and external system requirements
  • Open questions documented with owners assigned
  • Consolidations documented in Reviewer Notes with reversibility info
  • Module can survive a full UI redesign unchanged
  • Traceability matrix is complete

Reviewer Notes

No Consolidation Applied

Source contained 2 distinct requirements representing separate capabilities:

Original ItemSource ReferenceDisposition
REQ-RULES-CC-001 (Curve control validation)3.0.0-CC Rule Requirements TablePreserved as REQ-RULES-CC-001
REQ-RULES-CC-002 (Missing config error)3.0.0-BCC rule - CC_LIMITS_MISSEDPreserved as REQ-RULES-CC-002

Rationale: These requirements represent distinct capabilities - one for normal validation logic, one for configuration error handling. No consolidation appropriate per RULES domain guidance for conservative treatment of analytics rules.

Reversibility: Source file: output/pilot/rules/rule-cc/rule-cc-restructured.md