ICCT Rule - Final CT/CLS Determination
Version: v3.0.0 Status: Normative (text), Illustrative (diagrams only) Scope: Determines Final CT and Final CLS values based on manual user inputs and preferred result provider logic Domain: RULES-ICCT Precedence: After manual input, before analytics/reporting
Statement
The system shall determine Final CT and Final CLS values based on manual user inputs, falling back to preferred result provider values when manual inputs are not specified.
The ICCT rule resolves how manual overrides combine with automatic result provider selections to produce final values for observations. When users specify a manual CT provider or manual CLS, the rule determines which sources to use for each final value according to a defined truth table.
Quick Reference
| ID | Core Behavior | Priority | Status |
|---|---|---|---|
| REQ-RULES-ICCT-001 | Resolves Final CT/CLS from manual inputs and preferred provider | HIGH | Draft |
Key Integration Points: Observation Resolution Workflow, Preferred Result Provider Logic, Analytics Engine, Reporting System
Rule Summary
| Property | Value |
|---|---|
| Name | ICCT |
| Triggers | When evaluating Final CT/CLS for observations |
| Output | Sets Final CT and Final CLS on observation |
Rule Flowchart (Illustrative)
This diagram illustrates the decision logic for Final CT/CLS determination. The "Matching Provider" path locates a provider whose CLS equals the manual CLS value.
Definitions
| Term | Definition |
|---|---|
| Final CT | The resolved Cycle Threshold value used for analysis and reporting |
| Final CLS | The resolved Curve-Level Status/Classification value used for analysis and reporting |
| Manual CT Provider | A user-specified provider from which to source the CT value |
| Manual CLS | A user-specified CLS classification value |
| Preferred Result Provider | The system-determined default provider for automatic CT/CLS values |
| Negative CLS | A curve classification indicating no amplification detected |
Assumptions
- Users have appropriate role permissions to specify manual CT providers and CLS values
- A preferred result provider is always defined for each observation
- Manual inputs are validated before being applied to the ICCT rule
Requirements
Final Value Determination (REQ-RULES-ICCT-001)
FR-ICCT-001: Determine Final CT and CLS Based on Manual Inputs
The system shall resolve Final CT and Final CLS values according to whether manual inputs have been provided by the user, combining manual and automatic values per defined logic.
Inputs/Outputs
| Direction | Data | Source/Target |
|---|---|---|
| Input | Manual CT Provider selection | User input |
| Input | Manual CLS value | User input |
| Input | Preferred Result Provider CT/CLS | System calculation |
| Output | Final CT | Observation record |
| Output | Final CLS | Observation record |
Acceptance Criteria
No Manual Inputs (Default Case):
- When no manual CT provider is specified AND no manual CLS is specified, the system shall source Final CT from the preferred result provider
- When no manual CT provider is specified AND no manual CLS is specified, the system shall source Final CLS from the preferred result provider
Manual CT Provider Only:
- When manual CT provider is specified AND no manual CLS is specified, the system shall source Final CT from the manual CT provider
- When manual CT provider is specified AND no manual CLS is specified, the system shall source Final CLS from the preferred result provider
Manual CLS Only:
- When no manual CT provider is specified AND manual CLS is specified, the system shall set Final CLS to the manually specified CLS value
- When no manual CT provider is specified AND manual CLS is specified, the system shall source Final CT from the provider whose CLS matches the manual CLS
- When manual CLS is specified, the system shall locate a provider whose CLS matches the manual CLS value to source the Final CT value
Negative CLS Handling:
- When manual CLS is specified as Negative, the system shall set Final CT to null
- The system shall set Final CT to null for Negative CLS results because negative results do not have a meaningful cycle threshold value
Truth Table
| HAS MANUAL CT PROVIDER | HAS MANUAL CLS | FINAL CT | FINAL CLS |
|---|---|---|---|
| No | No | Preferred result provider CT | Preferred result provider CLS |
| Yes | No | Manual CT provider CT | Preferred result provider CLS |
| No | Yes | CT of provider whose CLS matches Manual CLS (null for Negative) | Manual CLS |
Trace: Source: 3.0.0-ICCT rule (Row 1), Truth Table for Final CLS / Final CT | Jira: BT-3817, BT-3820 | Tests: BT-3861, See scenarios | Epic: BT-3820 - Better discrepant (or ambiguous) curve management
Configuration Options
| Option | Default | Description | Affects |
|---|---|---|---|
| - | - | No configuration options identified | - |
[REVIEW REQUIRED: Verify if any parameters should be configurable.]
UI Notes (Illustrative)
REQ-RULES-ICCT-001 UI Specifications
This rule operates as backend logic with no direct UI components. The Final CT and Final CLS values determined by this rule are consumed by:
- Observation Grid: Displays Final CT and Final CLS columns
- Resolution Workflow: "Apply Resolutions per Observation" feature reflects manual overrides
- Report Generation: Final values appear in exported reports
Implementation (Illustrative)
| Component | Location | Purpose |
|---|---|---|
| IcctRule | Analyzer/Rules/IcctRule.php | Final CT/CLS determination - truth table logic for manual vs preferred provider |
Traceability Matrix
| Requirement | Title | Verification | Implementation | Test Cases | Status |
|---|---|---|---|---|---|
| REQ-RULES-ICCT-001 | Determine Final CT and CLS Based on Manual Inputs | Test | IcctRule.php | BT-3861 | Draft |
Notes
- This rule supports the "Apply Resolutions per Observation" workflow
- The rule enables users to override automatic result provider selections while maintaining consistency between CT and CLS values
- The truth table does not include a fourth row (both Manual CT Provider and Manual CLS specified) - this combination is not specified in the requirements and may be considered an invalid state or handled by other rules
- Related Rules: AMB Rule (ambiguous classifications), Preferred Result Provider Logic (fallback values)
Acceptance Tests
Test: REQ-RULES-ICCT-001
Test: No manual inputs - uses preferred provider
Given: An observation exists with no manual CT provider specified
And: No manual CLS is specified
And: A preferred result provider is defined with CT=25.5 and CLS=Positive
When: The ICCT rule evaluates the observation
Then: Final CT shall be 25.5 (from preferred result provider)
And: Final CLS shall be Positive (from preferred result provider)
Test: Manual CT provider only - mixed sources
Given: An observation exists with manual CT provider specified
And: The manual CT provider has CT=22.3
And: No manual CLS is specified
And: The preferred result provider has CLS=Positive
When: The ICCT rule evaluates the observation
Then: Final CT shall be 22.3 (from manual CT provider)
And: Final CLS shall be Positive (from preferred result provider)
Test: Manual CLS only - matching provider lookup
Given: An observation exists with no manual CT provider specified
And: Manual CLS is specified as Positive
And: A provider exists with CLS=Positive and CT=24.1
When: The ICCT rule evaluates the observation
Then: Final CLS shall be Positive (manual value)
And: Final CT shall be 24.1 (from provider matching manual CLS)
Test: Manual CLS Negative - null CT
Given: An observation exists with no manual CT provider specified
And: Manual CLS is specified as Negative
When: The ICCT rule evaluates the observation
Then: Final CLS shall be Negative (manual value)
And: Final CT shall be null
Related Design Documents
| Design Document | Relevant Sections |
|---|---|
| SDD Algorithms | ICCT Rule Algorithm |
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
- Refinements do not introduce new capabilities
- Traceability matrix is complete
Reviewer Notes
No Consolidation Required
The source file contained a single requirement (REQ-RULES-ICCT-001). No consolidation was performed.
| Original Item | Source Reference | Disposition |
|---|---|---|
| REQ-RULES-ICCT-001 | 3.0.0-ICCT rule (Row 1) | Preserved as REQ-RULES-ICCT-001 |
Rationale: The ICCT rule represents a single focused capability (final value determination via truth table logic). All truth table conditions were preserved as individual acceptance criteria per RULES domain guidance.
Reversibility: Source reference:
- Source:
output/pilot/rules/rule-icct/rule-icct-restructured.md - SDD:
output/pilot/rules/rule-icct/sdd/rule-icct-design.md - Confluence: 3.0.0-ICCT rule