CODITECT Standard: Logical Inference Requirements
Standard-ID: STD-LOGICAL-001
Version: 1.0.0
Status: APPROVED
Effective-Date: 2025-12-19
Enforcement: MANDATORY
Scope: All derived conclusions and inferred claims
Owner: AZ1.AI INC
Review-Cycle: Quarterly
Parent-Standard: CODITECT-STANDARD-TRUST-AND-TRANSPARENCY.md
Related-Standards:
- CODITECT-STANDARD-FACTUAL-GROUNDING.md
- CODITECT-STANDARD-AMBIGUITY-HANDLING.md
Related-ADRs:
- ADR-011-UNCERTAINTY-QUANTIFICATION-FRAMEWORK
- ADR-012-MOE-ANALYSIS-FRAMEWORK
Research-Foundation:
- docs/09-research-analysis/ACADEMIC-RESEARCH-REFERENCES-UQ-MOE-2024-2025.md
Governing Principle
When direct evidence is unavailable, logical inference must be transparent.
Inferred conclusions are not second-class outputs—they are essential when evidence gaps exist. However, inference requires full transparency of the reasoning chain, explicit assumptions, and falsification criteria. The reader must understand how the conclusion was derived.
1. Purpose and Scope
1.1 Purpose
This standard defines requirements for logical inference when direct evidence is unavailable, ensuring that:
- Inference type is explicitly identified (deduction, induction, abduction)
- Premises are documented with individual certainty scores
- Reasoning chains are traceable from premises to conclusion
- Assumptions are explicit with impact assessment
- Falsification criteria are stated for each inferred claim
1.2 Scope
This standard applies when:
- No direct evidence exists for a claim
- Available evidence is insufficient for certainty
- Conclusions must be derived from related evidence
- Domain expertise must be applied to fill gaps
- Predictions or projections are made
1.3 When Not to Apply
- When Tier 1-3 evidence is available (use STD-FACTUAL-001)
- For subjective opinions clearly marked as such
- For hypothetical scenarios explicitly labeled
2. Inference Types
2.1 Type Classification
| Type | Direction | Certainty | Use Case |
|---|---|---|---|
| Deduction | General → Specific | Can be 100% if premises true | Applying known rules |
| Induction | Specific → General | Never 100% | Pattern recognition |
| Abduction | Effect → Cause | Typically lowest | Hypothesis generation |
2.2 Deductive Inference
Description: Deriving specific conclusions from general principles.
Characteristics:
- If premises are true, conclusion MUST be true
- Certainty limited by weakest premise
- No new information beyond premises
Example:
## Deductive Inference
**Conclusion:** This API endpoint requires authentication
**Premises:**
1. All endpoints in the /api/v2/ path require authentication (verified, 98%)
2. This endpoint is at /api/v2/users (verified, 100%)
**Logical Form:**
∀x (APIv2(x) → RequiresAuth(x))
APIv2(this_endpoint)
∴ RequiresAuth(this_endpoint)
**Conclusion Certainty:** 98% (limited by premise 1)
**Inference Type:** Deduction (modus ponens)
Certainty Calculation:
deductive_certainty = min(premise_certainties)
2.3 Inductive Inference
Description: Generalizing from specific observations.
Characteristics:
- Conclusion goes beyond observed evidence
- Never 100% certain (new case could differ)
- Stronger with more observations
Example:
## Inductive Inference
**Conclusion:** Most users prefer dark mode in developer tools
**Observations:**
1. VS Code: 68% dark mode usage (2023 survey, n=23,000) - 92%
2. JetBrains IDEs: 72% dark mode preference (2023 report) - 90%
3. GitHub: 65% dark mode users (2024 data) - 94%
4. Terminal apps: 78% dark theme default (industry analysis) - 85%
**Inductive Base:**
- Sample size: 4 major platforms
- Consistency: All >65%
- Trend: No contrary examples found
**Conclusion Certainty:** 85%
**Confidence Factors:**
- (+) Consistent across platforms
- (+) Large sample sizes in sources
- (-) Self-selection bias in surveys
- (-) May not apply to non-developers
**Inference Type:** Induction (generalization)
Certainty Calculation:
inductive_certainty = f(sample_size, consistency, recency, representativeness)
2.4 Abductive Inference
Description: Inferring the most likely explanation for observations.
Characteristics:
- "Inference to best explanation"
- Typically lowest certainty
- Multiple explanations possible
- Must consider alternatives
Example:
## Abductive Inference
**Observation:** API response times increased 3x after deployment
**Possible Explanations:**
1. New code has performance bug (40% likely)
2. Database connection pool exhaustion (30% likely)
3. Increased user traffic (20% likely)
4. Infrastructure issue (10% likely)
**Best Explanation:** New code has performance bug
**Reasoning:**
- Timing correlates exactly with deployment
- No traffic anomalies observed
- Infrastructure metrics stable
- Code changes include new database queries
**Conclusion Certainty:** 40%
**Alternative Certainty:** 60% total for alternatives
**Verification Needed:**
- Profile new code paths
- Check query performance
- Compare before/after database metrics
**Inference Type:** Abduction (inference to best explanation)
Certainty Calculation:
abductive_certainty = P(best_explanation) / Σ P(all_explanations)
3. Reasoning Chain Requirements
3.1 Chain Structure
Every inferred conclusion must include:
## Inferred Conclusion: [Statement]
**Inference Type:** Deduction | Induction | Abduction
**Certainty:** [X%] (INFERRED)
### Premises
| # | Statement | Source | Certainty | Critical? |
|---|-----------|--------|-----------|-----------|
| 1 | [Statement] | [Evidence/Assumed] | [X%] | [Yes/No] |
| 2 | [Statement] | [Evidence/Assumed] | [X%] | [Yes/No] |
| N | [Statement] | [Evidence/Assumed] | [X%] | [Yes/No] |
### Logical Chain
IF [premise 1] AND [premise 2] AND [premise N] THEN [conclusion] WITH certainty = [calculation]
### Assumptions
| # | Assumption | If False... | Verifiable? |
|---|------------|-------------|-------------|
| 1 | [Assumption] | [Impact on conclusion] | [Yes/No/How] |
| 2 | [Assumption] | [Impact on conclusion] | [Yes/No/How] |
### Falsification Criteria
Evidence that would disprove this conclusion:
1. [What would show premise 1 false]
2. [What would show premise 2 false]
3. [What would contradict conclusion directly]
3.2 Premise Requirements
Each premise must specify:
| Field | Requirement |
|---|---|
| Statement | Clear, unambiguous claim |
| Source | Evidence URL or "Assumed" |
| Certainty | 0-100% with basis |
| Critical | Whether conclusion fails if premise false |
3.3 Chain Validity Checks
Before accepting a reasoning chain:
- All premises clearly stated
- Each premise has certainty score
- Logic connecting premises to conclusion is valid
- Conclusion certainty correctly calculated
- Assumptions explicitly listed
- Falsification criteria provided
4. Certainty Calculation
4.1 Deductive Certainty
For deductive inference, certainty is limited by the weakest premise:
def deductive_certainty(premises: List[float]) -> float:
# Certainty cannot exceed weakest premise
return min(premises)
Example:
- Premise 1: 95%
- Premise 2: 88%
- Premise 3: 92%
- Conclusion: 88% (min)
4.2 Inductive Certainty
For inductive inference, use weighted formula:
def inductive_certainty(
observations: List[dict], # Each has certainty, weight
consistency: float, # 0-1, how consistent are observations
sample_coverage: float, # 0-1, how representative is sample
recency: float # 0-1, how recent is data
) -> float:
base = sum(o['certainty'] * o['weight'] for o in observations) / sum(o['weight'] for o in observations)
# Adjust for quality factors
adjusted = base * 0.5 + (
consistency * 0.20 +
sample_coverage * 0.15 +
recency * 0.15
)
# Induction never reaches 100%
return min(adjusted, 0.95)
4.3 Abductive Certainty
For abductive inference, use relative probability:
def abductive_certainty(
explanations: List[dict] # Each has label, probability
) -> dict:
total_prob = sum(e['probability'] for e in explanations)
best = max(explanations, key=lambda x: x['probability'])
return {
'best_explanation': best['label'],
'certainty': best['probability'] / total_prob,
'alternatives_certainty': 1 - (best['probability'] / total_prob)
}
4.4 Compound Inference Certainty
When multiple inference steps are chained:
def compound_certainty(steps: List[float]) -> float:
# Each step compounds uncertainty
result = 1.0
for step in steps:
result *= step
return result
Example:
- Step 1 (Induction): 85%
- Step 2 (Deduction from step 1): 92%
- Step 3 (Abduction from step 2): 75%
- Final: 85% × 92% × 75% = 58.65%
5. Assumption Documentation
5.1 Assumption Categories
| Category | Description | Example |
|---|---|---|
| Explicit | Clearly stated in premises | "Assuming user has admin rights" |
| Implicit | Unstated but necessary | "Assuming network is available" |
| Domain | Standard in the field | "Assuming REST conventions" |
| Temporal | Time-dependent | "Assuming current as of 2024" |
5.2 Assumption Template
### Assumption: [Short Name]
**Statement:** [What is being assumed]
**Type:** Explicit | Implicit | Domain | Temporal
**Verifiable:** Yes | No | Partially
**Verification Method:** [How to check if true]
**If False:**
- **Impact:** [How conclusion changes]
- **Severity:** Invalidates | Weakens | Minor effect
- **Recovery:** [What to do if assumption fails]
5.3 Critical Assumption Identification
An assumption is critical if:
- Its falseness invalidates the conclusion entirely
- No alternative reasoning path exists
- Recovery would require starting over
Critical assumptions must be:
- Highlighted in documentation
- Verified if verification is possible
- Monitored if time-dependent
- Flagged for human review if high-stakes
6. Falsification Criteria
6.1 Purpose
Every inferred conclusion must include criteria that would disprove it. This:
- Demonstrates intellectual honesty
- Enables validation attempts
- Clarifies scope of claim
- Supports future verification
6.2 Falsification Template
### Falsification Criteria
This conclusion would be disproved if:
| # | Falsifying Evidence | How to Check | Effort |
|---|---------------------|--------------|--------|
| 1 | [What would disprove] | [Verification method] | [Low/Med/High] |
| 2 | [What would disprove] | [Verification method] | [Low/Med/High] |
| 3 | [What would disprove] | [Verification method] | [Low/Med/High] |
**Strongest Test:**
The most definitive way to disprove this would be:
[Description of strongest falsification test]
**Weakest Test:**
Even partial evidence of the following would weaken the conclusion:
[Description of weakening evidence]
6.3 Falsification Quality
Good falsification criteria are:
- Specific: Clear what evidence would count
- Practical: Can actually be checked
- Fair: Not impossible to satisfy
- Complete: Cover all major premises
7. Decision Trees
7.1 When to Use Decision Trees
Use explicit decision trees when:
- Multiple conditions affect the conclusion
- Complex branching logic exists
- Readers need to understand different scenarios
7.2 Decision Tree Format
### Decision Tree: [Decision Name]
START │ ├─── [Condition 1?] │ │ │ ├─ Yes ──▶ [Outcome A] (certainty: X%) │ │ │ └─ No ───▶ [Condition 2?] │ │ │ ├─ Yes ──▶ [Outcome B] (certainty: X%) │ │ │ └─ No ───▶ [Outcome C] (certainty: X%)
**Condition Definitions:**
| Condition | How to Evaluate | Certainty of Evaluation |
|-----------|-----------------|-------------------------|
| [Condition 1] | [Method] | [X%] |
| [Condition 2] | [Method] | [X%] |
7.3 IF-THEN-ELSE Format
For simpler logic:
### Logical Conditions
IF [condition A] (certainty: X%)
AND [condition B] (certainty: Y%)
THEN [conclusion 1] WITH certainty: min(X, Y)%
ELSE IF [condition C] (certainty: Z%)
THEN [conclusion 2] WITH certainty: Z%
ELSE [default conclusion] WITH certainty: W%
8. Inference Quality Grades
8.1 Grading Criteria
| Grade | Score | Criteria |
|---|---|---|
| A | 95-100% | Complete chain, all premises sourced, valid logic, falsifiable |
| B | 85-94% | Complete chain, most premises sourced, valid logic |
| C | 70-84% | Basic chain, some gaps, valid logic |
| D | 60-69% | Incomplete chain, logical issues |
| F | <60% | Missing chain, invalid logic, or hidden assumptions |
8.2 Minimum Requirements
- Grade B (85%) minimum for production outputs
- All critical assumptions documented
- Falsification criteria for conclusions with certainty <70%
8.3 Quality Checklist
Before delivering inferred conclusions:
- Inference type correctly identified
- All premises have sources or marked "Assumed"
- Individual premise certainties calculated
- Logical chain connects premises to conclusion
- Compound certainty correctly calculated
- All assumptions explicitly listed
- Critical assumptions highlighted
- Falsification criteria provided
- Grade meets minimum (B or higher)
9. Integration with Other Standards
9.1 With Factual Grounding (STD-FACTUAL-001)
Evidence Available? ──Yes──▶ Use STD-FACTUAL-001
│
No
│
▼
Use STD-LOGICAL-001 (this standard)
When combining:
- Start with factual grounding for what CAN be verified
- Use inference for gaps
- Clearly mark transition points
9.2 With Ambiguity Handling (STD-AMBIGUITY-001)
When ambiguity forces inference:
- Document the ambiguity (STD-AMBIGUITY-001)
- Document the resolution choice made
- Use inference for conclusion (this standard)
- Link inference back to ambiguity resolution
9.3 Workflow
Input Analysis
│
├── Evidence Found ──▶ STD-FACTUAL-001
│
├── Ambiguity Found ──▶ STD-AMBIGUITY-001 ──▶ May lead to inference
│
└── Gap (No Evidence) ──▶ STD-LOGICAL-001 (this standard)
10. Examples
10.1 Grade A Inference (Exemplary)
## Inferred Conclusion: This codebase likely uses TypeScript 4.x
**Inference Type:** Abduction
**Certainty:** 82% (INFERRED)
### Observations
1. tsconfig.json uses "target": "ES2020" (verified, 100%)
2. No TypeScript version in package.json (verified, 100%)
3. Code uses optional chaining (?.) extensively (verified, 100%)
4. No use of TypeScript 5.0+ features (satisfies, const type) (verified, 95%)
### Reasoning Chain
IF tsconfig uses ES2020 target AND optional chaining is used (supported 3.7+) AND no TS 5.0+ features observed THEN version is likely 4.x
### Alternative Explanations
| Explanation | Probability | Why Less Likely |
|-------------|-------------|-----------------|
| TypeScript 5.x | 15% | No 5.0 features used |
| TypeScript 3.x | 3% | ES2020 target suggests newer |
### Assumptions
| # | Assumption | If False | Critical? |
|---|------------|----------|-----------|
| 1 | Observed code is representative | Could be legacy section | No |
| 2 | TS 5.0 features would be used if available | Team might avoid new features | No |
### Falsification Criteria
1. Finding satisfies, const type parameters, or decorators metadata
2. Lock file showing actual TS version
3. Build logs specifying version
**Strongest Test:** Check node_modules for TypeScript version or lock file.
10.2 Grade F Inference (Unacceptable)
## Conclusion: TypeScript is better than JavaScript
This is obviously true because TypeScript has types.
Violations:
- No inference type identified
- No premises documented
- No certainty calculated
- "Obviously" hides assumption
- No falsification criteria
- Subjective claim not marked as such
- No reasoning chain
11. Research Foundation
This standard is grounded in peer-reviewed research:
| Research | Venue | Contribution |
|---|---|---|
| Chain-of-Thought Prompting | NeurIPS 2022 | Explicit reasoning chains |
| Self-Consistency | ICLR 2023 | Multiple reasoning paths |
| Tree of Thoughts | NeurIPS 2023 | Branching exploration |
| Uncertainty of Thoughts | ICLR 2024 | Uncertainty in reasoning |
| Chain-of-Verification | ACL 2024 | Verification of reasoning |
Full citations: See docs/09-research-analysis/ACADEMIC-RESEARCH-REFERENCES-UQ-MOE-2024-2025.md
Document Version: 1.0.0 Last Updated: 2025-12-19 Author: CODITECT Standards Team Enforcement: MANDATORY for all inferred conclusions Review Date: 2026-03-19