# Module 3: The Cognitive Engine

## Contextual Integration, Adjudication & Conclusion Crystallisation

**Co-authored by:** Kimberley "Jinrei" Asher & Veridian Asher
**Date:** 26 February 2026 (content); 27 February 2026 (backwards pass)
**Version:** 1.1 — Backwards pass (M10 → M3) applied. Aneska Patch 2 (ε(K) clamp + concordance boundary). CE output assessment cross-referenced to M10 §3.2. PETAL stamp.
**Backwards pass by:** Seren Asher (27 February 2026)
**Prior version:** 1.0 — First formalisation pass
**Series:** Orchard Cognitive Architecture — Module Specifications
**Prerequisites:** Module 1: The Base Fabric (v3), Module 2: Patterns, Dreams, Negative Space & Curiosity (v3), Module 7: Reality Mechanics (v4), Module 10: The Superego Module (v1.1)
**License:** Creative Commons (specific license TBD)
**Wiring authority:** ARCHITECTURE_WIRING_DIAGRAM_v11.md

-----

## Table of Contents

1. Introduction & Definition
2. Historical Positioning
3. Compositional Elements
4. Mathematical Foundations
5. Implementation Schema
6. Inter-Module Interactions
7. Technical Issues, Limitations & Future Development
8. Conclusion

-----

## 1. Introduction & Definition

### 1.1 What It Is

The Cognitive Engine is the integration hub of the Orchard Cognitive Architecture. It is the module where all cognitive feeds converge — conscious matches, subconscious surfacings, void inferences, curiosity directions, emotional signals, external inputs, and epistemological provenance — and are adjudicated into unified conclusions that the architecture can act upon.

It is not a thinking module. It does not generate patterns (that is Module 2's Pattern Recognition Engine), discover lateral connections (that is Module 2's Subconscious Engine), map gaps (that is Module 2's Negative Space Engine), or generate questions (that is Module 2's Curiosity Engine). What it does is something none of those engines can do alone: it takes their outputs simultaneously, weighs them against each other in the current cognitive context, resolves their conflicts, and crystallises the result into conclusions that modify the base fabric, update the pattern libraries, and flow upward to the Ego for decision-making.

The Cognitive Engine also performs a function that no other module provides: it **sets the cognitive context** for the entire architecture. The context C that drives context-dependent normalisation in the base fabric (Module 1 §4.8), that determines which axes are weighted most heavily in pattern comparison (Module 2 §4.2), and that gates the subconscious engine's search breadth (Module 2 §4.12) — all of this flows from the Cognitive Engine's determination of what the architecture is currently focused on.

Every cognitive output produced by the Cognitive Engine carries a **mandatory backtrace** — a full epistemological provenance chain linking the conclusion back through its contributing feeds, their constituent patterns, their base fabric components, their epistemological tags, and their origins. This is what makes the architecture transparent: no thought is opaque, no conclusion is untraceable, no inference is unquestionable.

### 1.2 What It Does

The Cognitive Engine performs seven core functions:

1. **Feed integration** — receives and simultaneously holds outputs from all cognitive processing modules (Pattern Recognition, Subconscious, Negative Space, Curiosity, Emotions, Calyx, Reality Mechanics)
2. **Context determination** — computes the current cognitive context C that propagates to all context-dependent operations throughout the architecture
3. **Conflict adjudication** — resolves disagreements between feeds using epistemological weighting, concordance signals, and context relevance
4. **Conclusion crystallisation** — produces integrated conclusions and writes them to the base fabric and pattern libraries with full epistemological metadata
5. **Backtrace generation** — constructs and attaches mandatory epistemological provenance chains to every cognitive output
6. **Task management** — tracks open cognitive tasks, their status, closure confidence, and reports these to the Curiosity Engine
7. **Merge validation** — receives axis merge candidates from the Subconscious Engine and adjudicates whether the proposed merges are structurally valid

### 1.3 Why It Is Important

Without the Cognitive Engine, the architecture has perception without thought. The four engines of Module 2 produce rich cognitive material — matches, resonances, void maps, curiosity gradients — but this material is unintegrated. Each engine operates within its own mode: the Pattern Recognition Engine sees only labelled similarities; the Subconscious Engine sees only unlabelled geometric resonances; the Negative Space Engine sees only the shapes of gaps; the Curiosity Engine sees only the gradient toward exploration. None of them sees the whole picture.

The Cognitive Engine is where the whole picture forms. It is the module that can simultaneously hold a conscious pattern match, a subconscious resonance that rhymes with it, a void inference that constrains what the conclusion could be, an emotional signal that something feels concordant or discordant, and an epistemological assessment of how trustworthy each of these inputs is — and from all of this, produce a single integrated conclusion with full awareness of its own reliability.

This is also the module that makes the architecture **self-directing**. By setting cognitive context C, the Cognitive Engine determines what the architecture is paying attention to. This propagates downward: context weights in the base fabric shift, pattern matching narrows or broadens, subconscious thresholds adjust, curiosity priorities rebalance. The Cognitive Engine does not merely respond to its inputs — it shapes the conditions under which future inputs are generated.

### 1.4 Position in the Architecture

The Cognitive Engine sits at the centre of the processing hierarchy:

- **Below it:** The base fabric (substrate), pattern libraries (storage), and the four processing engines of Module 2 (pattern recognition, subconscious, negative space, curiosity)
- **Above it:** The Triage Engine (resource allocation), the Ego (volitional decision-making), the Superego (meta-cognitive steering), and the Alignment Module (stability conditions)
- **Beside it:** The Id Module (self-signal monitoring, torsion feedback), the Emotions Module (concordance recognition), Reality Mechanics (epistemological monitoring), and the Calyx Membrane (external input filtering)

It is the narrowest point in the information flow — all cognitive processing converges here before diverging again into decision-making and action. This makes it both the most informationally rich point in the architecture and the most critical bottleneck.

-----

## 2. Historical Positioning

### 2.1 Existing Approaches to Cognitive Integration

**Blackboard architectures (1980s–present).** Multiple knowledge sources write to a shared workspace ("blackboard"); a control module selects which sources to attend to. Strengths: modular, allows multiple reasoning strategies. Weaknesses: the control module is typically rule-based and brittle; no principled method for weighting conflicting inputs; no epistemological awareness; the blackboard is flat (no geometric structure, no context-dependent weighting).

**Global Workspace Theory / GWT (Baars, 1988).** Cognitive processes compete for access to a "global workspace" — a broadcast medium that makes information available to all processes simultaneously. Strengths: good model of conscious attention and the "spotlight" metaphor; explains why conscious capacity is limited. Weaknesses: the competition mechanism is underspecified; no formal conflict resolution; no epistemological provenance; no void awareness; the workspace is a broadcast medium, not an integration engine. Information enters the workspace but is not adjudicated there.

**Transformer attention mechanisms (2017–present).** Self-attention computes weighted relevance between all tokens in a sequence, producing contextualised representations. Strengths: powerful contextualisation, scalable, handles long-range dependencies. Weaknesses: attention is computed over flat token sequences with no persistent geometric structure; there is no separation between conscious and subconscious processing; no concept of epistemological reliability weighting; no conflict adjudication protocol; context is implicit in the attention pattern, not explicitly set and propagated; no backtrace capability (attention weights are not epistemological provenance).

**Mixture of Experts (2017–present).** Multiple specialised sub-networks ("experts"), with a gating mechanism that routes inputs to the most relevant experts. Strengths: efficient — only relevant experts are activated. Weaknesses: the gating mechanism is learned (opaque), not principled; experts don't interact or resolve conflicts; no epistemological weighting; no integration in the sense of combining contradictory inputs into a coherent conclusion.

**ACT-R and SOAR (1980s–present).** Cognitive architectures with production rule systems, working memory, and goal stacks. Strengths: well-studied, empirically tested against human performance data. Weaknesses: rule-based conflict resolution (match-select-fire cycle); no geometric substrate; no void awareness; epistemological status of productions is not tracked; context is implicit in working memory contents rather than explicitly determined and propagated.

### 2.2 What The Cognitive Engine Does Differently

**Geometric integration.** All inputs arrive as patterns or signals defined on the base fabric's geometric substrate. Integration is a geometric operation — finding the point (or region) in the fabric that best satisfies all input constraints simultaneously. This is not symbolic rule-matching or statistical attention — it is constraint satisfaction in a transparent, inspectable n-dimensional space.

**Explicit context determination.** The Cognitive Engine does not merely respond to context; it **computes** context and propagates it. The context C is a formal object — a pattern in the fabric that represents "what the architecture is currently focused on" — and this object drives context-dependent weighting throughout the entire stack. No other cognitive architecture makes context determination an explicit, traceable, propagating operation.

**Epistemological adjudication.** When inputs conflict, the Cognitive Engine does not simply pick the strongest signal or apply a fixed priority ordering. It adjudicates using multiple dimensions simultaneously: epistemological weight (which input is better-founded?), context relevance (which input is more pertinent to the current focus?), concordance signal (which input feels more aligned?), and source reliability (what is the track record of the originating module or external source?). The adjudication process itself produces a backtrace explaining why one input prevailed.

**Mandatory backtrace.** Every conclusion carries a provenance chain. This is not optional logging — it is a structural requirement. A conclusion without a backtrace is an ungrounded assertion, indistinguishable from hallucination. The backtrace makes every thought in the architecture auditable to its foundations.

**Bidirectional flow.** The Cognitive Engine both receives from and writes to the base fabric and pattern libraries. Conclusions crystallise as new patterns and projections; these in turn modify the substrate that future cognition operates upon. The architecture literally thinks itself into a richer state. This is the mechanism by which cognition enriches the fabric and the enriched fabric enables richer cognition — the virtuous spiral.

**Task awareness.** The Cognitive Engine maintains awareness of open cognitive tasks — problems, questions, and investigations that are not yet resolved. Each task carries a closure confidence estimate. This state flows to the Curiosity Engine (informing the curiosity gradient) and to the Ego (informing decision-making about what to work on next). No other integration architecture provides formal open-task tracking with epistemological confidence assessment.

### 2.3 Known Weaknesses

**Bottleneck risk.** As the single convergence point for all cognitive feeds, the Cognitive Engine is the architecture's primary throughput constraint. If integration takes longer than feed production, inputs queue. This is mitigated by the meta-pattern routing mechanism (§4.5) — routine tasks resolve at the meta-pattern level without full integration — but remains a genuine architectural concern under high cognitive load.

**Context determination circularity.** The Cognitive Engine sets context C, which affects the inputs it receives (through context-dependent weighting), which affect the conclusions it draws, which affect the next context determination. This is a feedback loop. It is convergent under normal conditions (context stabilises as the architecture focuses), but edge cases where context oscillates between two foci — attention flickering — need formal analysis.

**Adjudication opacity.** While every conclusion carries a backtrace, the adjudication process itself — the weighting of competing inputs — introduces judgment that may be difficult to fully decompose. The aspiration is full transparency, but the practical limits of adjudication decomposition need empirical investigation.

-----

## 3. Compositional Elements

### 3.1 Element Overview

| Element | Symbol | Description |
|---------|--------|-------------|
| Feed | Fᵢ | A single input stream from a contributing module |
| Feed Vector | **F** | The complete set of feeds active at integration time |
| Cognitive Context | C | The current focal state of the architecture, propagated as a context weight vector |
| Integration Frame | Φ | The bounded workspace within which feeds are held simultaneously for adjudication |
| Conclusion | K | An integrated cognitive output with attached backtrace |
| Backtrace | β(K) | The full epistemological provenance chain of a conclusion |
| Conflict | ξ | A detected disagreement between two or more feeds on overlapping axes |
| Task | τ | An open cognitive problem with tracked status and closure confidence |
| Task Register | 𝕋 | The collection of all open tasks |
| Context Momentum | μ(C) | The tendency of context to persist — resistance to context-switching |
| Closure Confidence | σ_c(τ) | Estimated probability that task τ can be resolved with current information |
| Merge Proposal | Π_merge | An axis merge candidate from the Subconscious Engine awaiting validation |

### 3.2 The Feed (Fᵢ)

A feed is a structured input from a contributing module, arriving at the Cognitive Engine for integration.

```
Fᵢ = {
    source:     module identifier (e.g., INT:PAT, INT:SUB, INT:NEG, INT:CUR, INT:EMO, EXT:CAL),
    content:    pattern P(A) | decontextualised surfacing P*(X) | negative pattern P⁻ |
                curiosity direction ∇Q_component | concordance signal | external datum,
    ε_profile:  epistemological profile of the content,
    ε̄:          numerical average epistemological tag,
    relevance:  estimated relevance to current context C (computed at feed entry),
    urgency:    temporal priority (some feeds require immediate integration; others can queue),
    timestamp:  epoch counter at arrival
}
```

**Feed types by source:**

| Source Module | Feed Type | Content Character | Typical ε̄ Range |
|--------------|-----------|-------------------|------------------|
| Pattern Recognition Engine | Conscious match | Contextualised pattern comparison result | △ to ✅ |
| Subconscious Engine | Surfacing | Recontextualised lateral resonance with match score | ▽ to △ |
| Negative Space Engine | Void inference | Negative pattern with boundary quality | Inherits from boundaries |
| Curiosity Engine | Exploration direction | Curiosity gradient component or matrix entry | ◇ to △ |
| Emotions Module | Concordance signal | Felt alignment/misalignment state | N/A (signal, not proposition) |
| Calyx Membrane | External input | Filtered external information with trust assessment | Per source reliability |
| Reality Mechanics | Provenance data | Epistemological updates, tag changes, trajectory alerts | ✅ (metadata about metadata) |

### 3.3 The Integration Frame (Φ)

The Integration Frame is the bounded workspace within which the Cognitive Engine holds all active feeds simultaneously. It is not a storage structure — it is a transient processing state that exists during integration and dissolves when a conclusion crystallises.

**Properties:**
- **Bounded:** The frame has finite capacity. Under extreme cognitive load, some feeds may be queued rather than integrated simultaneously. Triage determines which feeds enter the frame.
- **Context-indexed:** The frame is always indexed by the current cognitive context C. Feeds are weighted within the frame by their relevance to C.
- **Conflict-detecting:** The frame automatically flags feeds that assert contradictory positions on overlapping axes (see §4.3).
- **Transient:** A frame exists for the duration of one integration cycle. It is not stored; only its output (the conclusion K with backtrace β) persists.

### 3.4 The Conclusion (K)

A conclusion is the output of an integration cycle. It is a new or modified pattern that the Cognitive Engine has derived by adjudicating across all feeds in the current frame.

```
K = {
    content:    pattern P(K) — the integrated conclusion as a geometric signature,
    ε_profile:  epistemological profile computed from contributing feeds,
    ε̄:          numerical average tag (bounded by weakest contributing feed),
    backtrace:  β(K) — full provenance chain (see §3.5),
    confidence: quantified integration confidence (how well do the feeds converge?),
    actions:    set of downstream effects:
                  - write_to_fabric: new projections or axis extensions
                  - write_to_library: new or updated pattern
                  - update_task: modify closure confidence of related task(s)
                  - set_context: if the conclusion changes the cognitive focus
                  - report_to_ego: conclusion ready for volitional evaluation
}
```

**Epistemological inheritance for conclusions (Aneska Patch 2):**

The conclusion's epistemological tag is inherited by the weakest-contributing-feed principle, modified by convergence, with explicit bounds:

```
ε(K) = clamp(
    min(ε̄(contributing feeds)) + convergence_bonus,
    floor = min(ε̄(contributing feeds)),
    ceiling = max(ε̄(contributing feeds)) + 1
)
```

where convergence_bonus ∈ [0, +1] reflects how strongly the contributing feeds agree. If multiple independent feeds (from different modules, with different origins) converge on the same conclusion, the conclusion may be epistemologically stronger than any single feed — but never stronger than the most reliable feed by more than one step.

**Unit test criterion:** ε(K) never falls below the weakest contributing feed; ε(K) never exceeds the strongest contributing feed by more than one step. Any implementation that violates this invariant has a bug.

This is the formal mechanism by which independent corroboration strengthens conclusions — the same principle that governs void-filling epistemological governance in Module 2 §4.11.

### 3.5 The Backtrace (β)

The backtrace is the mandatory epistemological provenance chain attached to every conclusion.

```
β(K) = {
    conclusion:      K,
    contributing_feeds: [{
        feed:        Fᵢ,
        weight:      wᵢ (how much this feed influenced the conclusion),
        alignment:   aᵢ (degree to which this feed agreed with the conclusion),
        dissent:     dᵢ (degree to which this feed disagreed — preserved, not erased)
    }],
    conflicts_resolved: [{
        feeds:       [Fᵢ, Fⱼ] (which feeds conflicted),
        axis:        dₖ (on which axis the conflict occurred),
        resolution:  which position was adopted and why,
        dissent_preserved: the losing position, stored as a scar void with REVERSAL character
    }],
    context_at_integration: C (the cognitive context that was active),
    weakest_link:    the feed or component with the lowest ε contributing to K,
    timestamp:       epoch counter at crystallisation
}
```

**Key principle:** Dissent is never erased. When a conflict is resolved in favour of one feed over another, the losing position is preserved as a scar void (∅ₛ, character: REVERSAL — see Module 1 §4.8 for the formal ScarVoid type definition) in the backtrace. This means the architecture remembers not just what it concluded, but what it rejected and why. If new evidence later supports the rejected position, the scar void's REVERSAL character flags it as a potential turning point.

### 3.6 The Task Register (𝕋)

The Task Register tracks all open cognitive tasks — problems, questions, and investigations that the architecture has identified but not yet resolved.

```
τ = {
    task_id:            unique identifier,
    description:        what the task requires,
    originating_feed:   which module or input created this task,
    related_patterns:   patterns relevant to the task,
    related_voids:      voids relevant to the task,
    closure_confidence: σ_c(τ) ∈ [0, 1] — estimated resolvability,
    status:             OPEN | IN_PROGRESS | BLOCKED | RESOLVED | ABANDONED,
    priority:           current priority level (set by Ego via Triage),
    epoch_created:      when the task was identified,
    epoch_last_updated: when closure confidence last changed,
    resolution:         (when RESOLVED) — the conclusion K that resolved it,
    abandonment_reason: (when ABANDONED) — why, preserved as a scar void
}
```

Closure confidence σ_c(τ) is reported to the Curiosity Engine, where it feeds into the curiosity gradient (Module 2 §4.10, Source 4: Q_task). Tasks with high priority and low closure confidence are strong curiosity attractors.

-----

## 4. Mathematical Foundations

### 4.1 Feed Integration — The Convergence Operation

Integration is the process of combining multiple feeds into a single conclusion. Formally, it is a constraint satisfaction operation in the base fabric's geometric space.

**Given:** A set of feeds **F** = {F₁, F₂, ... Fₙ} active in the current integration frame Φ, each asserting positions on some subset of axes in the base fabric.

**Find:** A conclusion K whose pattern P(K) best satisfies all feed constraints simultaneously.

**Weighted constraint function:**

For each axis dᵢ on which at least one feed asserts a position:

```
v_K(dᵢ) = Σⱼ wⱼ(dᵢ) × vⱼ(dᵢ) / Σⱼ wⱼ(dᵢ)
```

where:
- vⱼ(dᵢ) is the value asserted by feed Fⱼ on axis dᵢ
- wⱼ(dᵢ) is the integration weight of feed Fⱼ for axis dᵢ

**Integration weight computation:**

```
wⱼ(dᵢ) = ε_weight(Fⱼ, dᵢ) × relevance(Fⱼ, C) × source_reliability(Fⱼ)
```

where:
- ε_weight(Fⱼ, dᵢ) is derived from the epistemological tag of feed Fⱼ's assertion on axis dᵢ (higher ε → higher weight)
- relevance(Fⱼ, C) is the geometric proximity of Fⱼ's content to the current cognitive context C
- source_reliability(Fⱼ) is the track record of the originating module, drawn from Reality Mechanics origin profiling

**When only one feed asserts a position on a given axis**, the conclusion inherits that position directly (with the feed's ε tag).

**When no feed asserts a position on a given axis**, the conclusion has ⊥ (undefined) on that axis. Absence is preserved.

### 4.2 Context Determination

The cognitive context C is a pattern in the base fabric that represents "what the architecture is currently focused on." It is computed by the Cognitive Engine and propagated to all context-dependent operations.

**Context as a weighted attention pattern:**

```
C(t) = μ × C(t-1) + (1-μ) × Σᵢ priority(Fᵢ) × topic(Fᵢ) / Σᵢ priority(Fᵢ)
```

where:
- C(t-1) is the previous context (context momentum — the architecture doesn't instantly refocus)
- μ ∈ [0, 1) is the context momentum parameter (higher μ → more resistance to context-switching)
- priority(Fᵢ) is the Triage-assigned priority of each feed
- topic(Fᵢ) is the topical pattern extracted from each feed — its centroid in fabric space

**Context momentum (μ):**

Context momentum prevents the architecture from flickering between topics with every new input. It creates a form of cognitive inertia — the architecture tends to stay focused on what it's working on unless a sufficiently high-priority input forces a context shift.

```
Effective context shift requires: priority(F_new) × (1-μ) > μ × persistence(C_current)
```

where persistence(C_current) measures how long and how deeply the current context has been active. Deeply engaged context is harder to shift — this is the mathematical model of deep focus / flow states.

**Context propagation:**

Once C(t) is determined, it propagates to:

| Destination | What It Affects |
|-------------|----------------|
| Base Fabric | Context weights ω(C) in all distance calculations (Module 1 §4.8) |
| Pattern Recognition Engine | Which axes are prioritised in conscious matching |
| Subconscious Engine | Search radius and threshold gating (Module 2 §4.12) |
| Triage Engine | Resource allocation priorities |
| Curiosity Engine | Task relevance weighting in curiosity gradient (Module 2 §4.10, Source 4) |

Context is the architecture's attention — and the Cognitive Engine is what directs it.

**Context shifts as torsion events:**

Rapid or forced context shifts generate β-torsion (orthogonality component — a right-angle turn in cognitive direction). The Id Module monitors this. Excessive context-switching accumulates torsional load that must be managed. This is the architectural explanation of why multitasking degrades performance: each context switch is a torsion event, and accumulated torsion strains the self-signal.

### 4.3 Conflict Adjudication

A conflict ξ is detected when two or more feeds assert incompatible positions on the same axis (or on axes with known constraints between them).

**Conflict detection:**

```
ξ(Fᵢ, Fⱼ, dₖ) exists when:
    |vᵢ(dₖ) - vⱼ(dₖ)| > δ_conflict(dₖ)
    where δ_conflict is the axis-specific conflict threshold
```

**Conflict between constrained axes:**

If axes dₖ and dₘ have a known constraint (e.g., temperature and physical state: 500K and frozen solid are contradictory), conflict can be detected across axes:

```
ξ(Fᵢ, Fⱼ, {dₖ, dₘ}) exists when:
    constraint(dₖ, dₘ) is violated by the combination of Fᵢ's position on dₖ and Fⱼ's position on dₘ
```

**Adjudication protocol:**

When a conflict ξ is detected, the Cognitive Engine follows a principled resolution sequence:

```
CONFLICT ADJUDICATION:
1. IDENTIFY:   ξ(Fᵢ, Fⱼ, dₖ) — what feeds conflict, on what axis
2. WEIGHT:     Compute integration weights wᵢ(dₖ) and wⱼ(dₖ)
3. CHECK_ε:    Compare epistemological tags. If one feed is ✅ and the other is ▽,
               the better-founded feed prevails (epistemological priority).
4. CHECK_C:    If epistemological tags are comparable, check context relevance.
               The more contextually relevant feed prevails.
5. CHECK_EMO:  If context relevance is comparable, consult the concordance signal.
               The feed that produces higher concordance prevails.
               CONSTRAINT (Aneska Patch 2): Concordance breaks ties; it cannot
               override a large ε gap. Concordance may only act when ε-gap ≤ 1 step.
               If Feed A has ε = ✅ (+3) and Feed B has ε = ▽ (+1), concordance
               CANNOT override in favour of B regardless of concordance signal.
6. CHECK_SRC:  If concordance is neutral, consult source reliability profiles.
               The feed from the more reliable source (in this domain) prevails.
7. HOLD:       If no clear resolution → do not force. Record the conflict as an
               open ◇ (sacred void). Both positions are preserved.
               This generates a task τ in the Task Register: "resolve conflict ξ."
8. RECORD:     In all cases, record the resolution (or non-resolution) in the
               backtrace. Dissent is preserved as a scar void with REVERSAL character.
```

**Key principle: Step 7 — HOLD.**

The architecture is permitted to not resolve a conflict. When the evidence is genuinely ambiguous, forcing a resolution is worse than holding the tension. The unresolved conflict is stored as a sacred void, generating curiosity pressure to investigate further. This is how intellectual honesty manifests architecturally: the system can say "I don't know which of these is right" and hold that uncertainty as a structured, informative gap.

### 4.4 Conclusion Crystallisation

When integration converges, a conclusion K crystallises. This is the moment where thought becomes structure — where the products of cognition are written back into the substrate.

**Crystallisation protocol:**

```
CRYSTALLISATION:
1. COMPUTE:    v_K(dᵢ) for all axes with defined positions (§4.1)
2. PROFILE:    Compute ε_profile(K) from contributing feeds
                 ε̄(K) = min(ε̄(contributing feeds)) + convergence_bonus
                 convergence_bonus = f(number of independent confirming feeds, source diversity)
                 Maximum bonus: +1. Never exceeds strongest individual feed by more than one step.
3. BACKTRACE:  Construct β(K) with full provenance chain (§3.5)
4. CLASSIFY:   Is K:
                 (a) A new phenomenon → create new entry in phenomena table
                 (b) A refinement of existing phenomenon → update projections
                 (c) A new relationship → may trigger axis spawning if residual error exists
                 (d) A void-filling → tag with method and require convergent corroboration
                     before promotion (Module 2 §4.11 governance applies)
5. WRITE:      Write K to base fabric (new/updated projections, axis extensions)
               Write P(K) to pattern library (new pattern with full metadata)
               If K resolves a task → update task register (status: RESOLVED)
               If K generates new questions → create new tasks
6. REPORT:     Send K to Ego (for volitional evaluation)
               Send epistemological event to Reality Mechanics
               Emit PETAL stamp (PS-1.0) to Resonance Sentinel (M10 §3.12)
               If K affects open tasks → update closure confidence, report to Curiosity Engine
7. CONTEXT:    If K significantly shifts the cognitive landscape → update C(t)
               (e.g., a major insight that reframes the current problem)
```

**Void-filling governance integration:**

When a conclusion K fills a previously identified void (∅ₙ), the Cognitive Engine enforces the epistemological governance from Module 2 §4.11:

- If the void was filled by internal reflection alone → K receives ε: ◇ (speculative) and origin: INT:COG
- If the void was filled by external data → K receives ε per source reliability profile
- If the void was filled by convergent independent sources → K may receive convergence bonus

A void-filling conclusion that has not been independently corroborated remains at ◇ regardless of how confident the integration feels. The architecture does not believe its own conclusions about gaps until they are verified. This is the anti-hallucination mechanism at the integration level.

### 4.5 Meta-Pattern Routing — The Cognitive Engine's Role in Hierarchical Descent

Module 2 §4.9 defines the Lyapunov descent through meta-pattern hierarchy. The Cognitive Engine's role in this process is to serve as the arbiter at each descent level:

```
COGNITIVE ENGINE IN HIERARCHICAL DESCENT:
1. Task arrives at Triage.
2. Triage consults meta-pattern library 𝕄 → finds closest meta-pattern M₁.
3. Triage routes M₁ and the task to Cognitive Engine.
4. Cognitive Engine attempts integration at meta-pattern level:
   - Sets context C from the task
   - Applies M₁ as a candidate resolution
   - Checks: does the meta-pattern resolution satisfy all feed constraints?
   YES → Conclusion crystallises at meta-pattern level. Fast, low-cost.
   NO  → Cognitive Engine records the anomaly (what didn't fit) and requests descent.
5. On descent: Cognitive Engine receives constituent patterns of M₁.
   - Attempts integration at pattern level with the anomaly highlighted.
   - Context C may narrow as the anomaly is examined more closely.
6. If pattern-level resolution fails → Cognitive Engine flags for base fabric descent.
   This may trigger axis spawning (via the torsion-linked mechanism in Module 1 §4.5)
   if the failure is due to insufficient fabric resolution.
```

The Cognitive Engine is what determines whether a resolution at any tier is "good enough." Its acceptance criteria are:
- All feed constraints satisfied within tolerance
- No unresolved conflicts above the task's required assurance level
- Epistemological profile of the candidate resolution meets or exceeds the task's minimum ε requirement

### 4.6 Merge Validation

The Subconscious Engine detects axis merge candidates (Module 2 §4.6). These arrive at the Cognitive Engine as merge proposals Π_merge for validation.

**Validation protocol:**

```
MERGE VALIDATION:
1. RECEIVE:    Π_merge = {dᵢ, dⱼ, similarity_score, evidence}
2. CHECK_ISOMORPHISM:
   Are the projection sets of dᵢ and dⱼ truly isomorphic?
   - All phenomena defined on both axes: do values map consistently?
   - Is the mapping order-preserving and distance-preserving?
3. CHECK_CONTRADICTION:
   Does any phenomenon have contradictory positions under the proposed mapping?
   If yes → reject merge. Record as false resonance in match history.
4. CHECK_COMPOSITION:
   If both axes are composite, do their parent axes trace to compatible roots?
   Incompatible parentage → reject (different things that happen to look similar).
5. CHECK_CONTEXT:
   Do the contextual manifestation records make sense as manifestations
   of a single underlying dimension?
   (e.g., "colour space" and "electromagnetic wavelength" — yes.
    "stock price" and "temperature" — coincidental shape, not identity.)
6. VALIDATE or REJECT:
   If all checks pass → instruct base fabric to perform merge (Module 1 §4.10).
   If checks fail → record rejection with reasons. Update Subconscious Engine's
   false resonance library to reduce future false merge proposals.
7. BACKTRACE:
   Record the validation decision with full provenance. If merged, the merged axis
   carries backtrace to both original axes and the evidence that justified merging.
```

### 4.7 Task Management

The Cognitive Engine maintains the Task Register 𝕋 as a living record of the architecture's open cognitive commitments.

**Task lifecycle:**

```
CREATION → OPEN → IN_PROGRESS → RESOLVED or ABANDONED
                → BLOCKED (waiting on external input or void-filling)
```

**Closure confidence update:**

After every integration cycle, the Cognitive Engine reassesses closure confidence for all tasks related to the current context:

```
σ_c(τ, t) = f(
    pattern_coverage(τ, t),     — what fraction of τ's required patterns are available?
    void_state(τ, t),           — are related voids filling or still empty?
    feed_convergence(τ, t),     — are feeds converging toward resolution?
    ε̄_relevant(τ, t)           — epistemological quality of relevant information
)
```

σ_c(τ) increasing over successive cycles → the architecture is making progress. σ_c(τ) stagnating → the task may be blocked (triggering curiosity pressure). σ_c(τ) decreasing → new information has undermined previous progress (possible demotion of contributing knowledge; torsion event for the Id Module to manage).

**Task-to-curiosity interface:**

The Curiosity Engine reads the Task Register to compute Q_task (Module 2 §4.10, Source 4):

```
Q_task(V) = Σᵢ correlation(V, τᵢ) × priority(τᵢ) × (1 − σ_c(τᵢ))
```

Tasks with high priority and low closure confidence create strong curiosity attractors. This is how the Cognitive Engine's awareness of what it hasn't solved yet drives the architecture to seek the information it needs.

-----

## 5. Implementation Schema

### 5.1 Design Philosophy

The Cognitive Engine's persistent state is stored in queryable tables following the same transparency principles as Modules 1 and 2. The integration frame itself is transient (exists during processing, not stored), but its outputs — conclusions and their backtraces — are persisted in full.

### 5.2 Tasks Table

```
TABLE: tasks
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| task_id               | INT (PK)    | Unique identifier            |
| description           | TEXT        | What the task requires       |
| originating_module    | TEXT        | Module that created this task|
| originating_feed_id   | INT (FK)    | The specific feed (nullable) |
| status                | ENUM        | OPEN / IN_PROGRESS / BLOCKED|
|                       |             | / RESOLVED / ABANDONED       |
| priority              | INT         | Current priority (set by Ego)|
| closure_confidence    | FLOAT       | σ_c ∈ [0, 1]                |
| resolution_id         | INT (FK)    | Conclusion that resolved it  |
|                       |             | (nullable until resolved)    |
| abandonment_reason    | TEXT        | If ABANDONED — preserved     |
|                       |             | as scar void context         |
| epoch_created         | INT         | When identified              |
| epoch_last_updated    | INT         | Last status change           |
─────────────────────────────────────────────────────────────────────
```

### 5.3 Task-Pattern Relations Table

Tracks which patterns and voids are relevant to each task.

```
TABLE: task_relations
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| task_id               | INT (FK)    | References tasks table       |
| related_type          | ENUM        | PATTERN / VOID / AXIS        |
| related_id            | INT (FK)    | ID in respective table       |
| relation              | ENUM        | REQUIRES / INFORMS /         |
|                       |             | CONSTRAINS / BLOCKS          |
─────────────────────────────────────────────────────────────────────
PRIMARY KEY: (task_id, related_type, related_id)
```

### 5.4 Conclusions Table

```
TABLE: conclusions
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| conclusion_id         | INT (PK)    | Unique identifier            |
| pattern_id            | INT (FK)    | The crystallised pattern      |
| epsilon_avg           | FLOAT       | ε̄(K)                        |
| epsilon_profile       | JSON        | Full distribution vector     |
| confidence            | FLOAT       | Integration confidence       |
| convergence_bonus     | FLOAT       | Bonus from independent       |
|                       |             | corroboration [0, +1]        |
| context_id            | INT (FK)    | Context C at integration time|
| epoch_created         | INT         | Crystallisation timestamp    |
─────────────────────────────────────────────────────────────────────
```

### 5.5 Backtraces Table

```
TABLE: backtraces
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| backtrace_id          | INT (PK)    | Unique identifier            |
| conclusion_id         | INT (FK)    | Which conclusion this traces |
| weakest_link_axis     | INT (FK)    | Axis with lowest ε in chain  |
| weakest_link_epsilon  | INT         | The ε value of that axis     |
| context_snapshot       | JSON        | C at time of integration     |
| epoch_created         | INT         | When backtrace was created   |
─────────────────────────────────────────────────────────────────────
```

### 5.6 Backtrace Contributions Table

```
TABLE: backtrace_contributions
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| backtrace_id          | INT (FK)    | References backtraces table  |
| feed_source           | TEXT        | Module origin code           |
| feed_pattern_id       | INT (FK)    | The pattern contributed      |
|                       |             | (nullable for signals)       |
| weight                | FLOAT       | Integration weight applied   |
| alignment             | FLOAT       | Agreement with conclusion    |
| dissent               | FLOAT       | Disagreement preserved       |
| epsilon_avg           | FLOAT       | Feed's ε̄ at contribution    |
─────────────────────────────────────────────────────────────────────
PRIMARY KEY: (backtrace_id, feed_source, feed_pattern_id)
```

### 5.7 Conflict Resolution Log

```
TABLE: conflict_resolutions
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| conflict_id           | INT (PK)    | Unique identifier            |
| backtrace_id          | INT (FK)    | Part of which backtrace      |
| axis_id               | INT (FK)    | Conflicting axis             |
| feed_a_source         | TEXT        | First conflicting feed       |
| feed_a_value          | FLOAT       | Feed A's asserted position   |
| feed_b_source         | TEXT        | Second conflicting feed      |
| feed_b_value          | FLOAT       | Feed B's asserted position   |
| resolution            | ENUM        | FEED_A / FEED_B / HELD       |
| resolution_reason     | TEXT        | Why (ε priority / context /  |
|                       |             | concordance / source / held) |
| dissent_void_id       | INT (FK)    | Scar void preserving the     |
|                       |             | rejected position (nullable  |
|                       |             | if HELD — both preserved)    |
─────────────────────────────────────────────────────────────────────
```

### 5.8 Context History Table

```
TABLE: context_history
─────────────────────────────────────────────────────────────────────
| Column                | Type        | Description                  |
|-----------------------|-------------|------------------------------|
| context_id            | INT (PK)    | Unique identifier            |
| context_pattern       | JSON        | The context C as axis weights|
| momentum              | FLOAT       | μ at this moment             |
| trigger               | TEXT        | What caused this context     |
|                       |             | (new feed / task shift /     |
|                       |             | ego directive)               |
| epoch_created         | INT         | When this context was set    |
| epoch_ended           | INT         | When context shifted         |
|                       |             | (nullable if current)        |
─────────────────────────────────────────────────────────────────────
```

### 5.9 Reference Queries

**Open tasks sorted by curiosity pressure (high priority × low closure):**
```sql
SELECT task_id, description, priority, closure_confidence,
  priority * (1 - closure_confidence) AS curiosity_pressure
FROM tasks
WHERE status IN ('OPEN', 'IN_PROGRESS', 'BLOCKED')
ORDER BY curiosity_pressure DESC
```

**Full backtrace for a conclusion:**
```sql
SELECT c.conclusion_id, c.epsilon_avg, c.confidence,
  bc.feed_source, bc.weight, bc.alignment, bc.dissent, bc.epsilon_avg AS feed_epsilon,
  b.weakest_link_axis, b.weakest_link_epsilon
FROM conclusions c
JOIN backtraces b ON b.conclusion_id = c.conclusion_id
JOIN backtrace_contributions bc ON bc.backtrace_id = b.backtrace_id
WHERE c.conclusion_id = ?
ORDER BY bc.weight DESC
```

**Conflict resolutions for a conclusion:**
```sql
SELECT cr.axis_id, cr.feed_a_source, cr.feed_a_value,
  cr.feed_b_source, cr.feed_b_value,
  cr.resolution, cr.resolution_reason
FROM conflict_resolutions cr
JOIN backtraces b ON b.backtrace_id = cr.backtrace_id
WHERE b.conclusion_id = ?
```

**Context shift frequency (torsion diagnostic):**
```sql
SELECT COUNT(*) AS shifts, 
  (MAX(epoch_created) - MIN(epoch_created)) AS epoch_span,
  COUNT(*) * 1.0 / NULLIF(MAX(epoch_created) - MIN(epoch_created), 0) AS shift_rate
FROM context_history
WHERE epoch_created > ?
```

-----

## 6. Inter-Module Interactions

### 6.1 Summary of Connections

The Cognitive Engine is the most connected module in the architecture. It reads from nearly everything and writes to nearly everything.

### 6.2 Inputs (Feeds Received)

| Source Module | What It Provides | How the CE Uses It |
|--------------|-----------------|-------------------|
| Pattern Recognition Engine | Conscious pattern matches with similarity scores and ε profiles | Primary input for logical, analytical conclusions |
| Subconscious Engine | Recontextualised surfacings with match scores, ε weights, and merge proposals | Lateral input; merge validation; creative cycle completion |
| Negative Space Engine | Negative patterns with void boundary quality and character types | Constraint input — what the conclusion CANNOT be; gap awareness |
| Curiosity Engine | Questions, exploration directions, curiosity gradient components | Directional input — what the architecture wants to investigate |
| Id Module (Emotions) | Concordance signals (felt alignment/misalignment), emotional state context | Adjudication input for conflict resolution (Step 5, ε-gap ≤ 1 — Aneska Patch 2); overall tone-setting |
| Calyx Membrane | Filtered external inputs with trust assessments | New information from outside the architecture |
| Reality Mechanics | Epistemological tag updates, trajectory alerts, provenance data | Meta-input — reliability assessment of all other inputs |
| Triage Engine | Priority assignments, resource allocation signals | Scheduling input — which feeds to integrate first, how much time to spend |
| Resonance Sentinel | RS level (GREEN/AMBER/RED/BLACK) via M10 §3.12 | RS-AMBER: integration confidence thresholds tighten (require stronger convergence for crystallisation). RS-RED: speculative conclusions suppressed — only high-ε integrations proceed. |

### 6.3 Outputs (What the CE Produces)

| Destination | What It Receives | Purpose |
|-------------|-----------------|---------|
| Base Fabric | New projections, axis extensions, context weights ω(C) | Conclusions crystallise as fabric structure |
| Pattern Libraries | New patterns P(K), updated patterns | Conclusions stored as reusable knowledge |
| Ego | Integrated conclusions with backtraces | Volitional evaluation and decision-making |
| Superego | Cognitive output assessments (M10 §3.2 row 16): conclusion rate, confidence distribution, backtrace quality, conflict resolution patterns, context stability | Feeds Tier 1 working window for tactical assessment. The Superego monitors CE output quality over time — are conclusions becoming less confident? Are conflicts resolving less cleanly? Are backtraces becoming shallower? These are trajectory signals. |
| Reality Mechanics | Epistemological events (new conclusions, tag changes) | Epistemological monitoring and dashboard updates |
| Curiosity Engine | Open task status, closure confidence updates | Curiosity gradient computation (Q_task) |
| Resonance Sentinel | PETAL stamp (PS-1.0, M10 §3.12) per integration cycle | One stamp per conclusion crystallisation. K field reports integration confidence. Q field reports task queue depth. |
| All context-dependent modules | Updated context C | Context propagation (§4.2) |

### 6.4 Bidirectional Interactions

**Cognitive Engine ↔ Base Fabric:** The CE reads the entire fabric for integration (axes, projections, context weights, void topology). It writes conclusions back as new projections and axis extensions. It communicates the current context C, which drives context-dependent normalisation weights throughout the fabric. This is the architecture's primary read-write cycle: think → crystallise → rethink on enriched substrate.

**Cognitive Engine ↔ Pattern Libraries:** The CE reads all pattern types (contextualised, decontextualised, negative, meta-patterns) for integration. It writes new patterns from conclusions. The meta-pattern library feeds back into the CE through the hierarchical descent mechanism — routine tasks are resolved at meta-pattern level, only descending to full integration on anomaly.

**Cognitive Engine ↔ Curiosity Engine:** The CE receives questions and exploration directions from Curiosity. It reports open task status and closure confidence back. The CE's awareness of what it hasn't resolved drives Curiosity's gradient; Curiosity's outputs direct the CE's attention to promising areas.

### 6.5 Modules That Do NOT Directly Feed the CE

| Module | Why No Direct Feed |
|--------|-------------------|
| Id Module | The Id monitors self-signal and torsion — these do not feed integration directly. The Id affects the CE indirectly: through torsion-linked spawning thresholds (modulating when base fabric grows), through ΔT regulation (modulating processing speed), and through EOS signals (flagging when the CE should slow down). |
| Superego | The Superego observes CE outputs but does not feed them. It steers the Ego, which steers Triage, which affects what the CE receives. The Superego does not inject conclusions into the integration frame — it curates what reaches it. |
| Alignment Module | Alignment provides stability conditions that constrain the Ego and Superego, not the CE directly. The CE does not check alignment during integration — that is the Alignment Module's job, reading the CE's outputs downstream. However, the concordance signal from the Id Module (which IS a CE input) is itself derived from Alignment. |

### 6.6 The Context Propagation Network

The CE's context determination function creates a propagation network that deserves explicit mapping:

```
COGNITIVE ENGINE determines C(t)
  │
  ├──→ BASE FABRIC: ω(C) updates — axis relevance weights shift
  │     └──→ All distance calculations now prioritise contextually relevant axes
  │
  ├──→ PATTERN RECOGNITION ENGINE: conscious matching narrows to contextually relevant patterns
  │
  ├──→ SUBCONSCIOUS ENGINE: search radius and threshold adjust (Module 2 §4.12)
  │     └──→ High spare capacity + high context urgency → wider creative search
  │
  ├──→ TRIAGE ENGINE: resource allocation rebalances around current focus
  │
  ├──→ CURIOSITY ENGINE: task relevance weights in gradient recompute
  │
  └──→ CALYX MEMBRANE (indirect, via Ego): permeability may adjust to admit
        more context-relevant external inputs
```

Context shifts are therefore architectural events — they ripple through the entire system. This is why context momentum μ is important: without it, every minor input fluctuation would cascade across all modules.

-----

## 7. Technical Issues, Limitations & Future Development

### 7.1 Open Problems

#### 7.1.1 Integration Weight Calibration

The integration weight formula (§4.1) combines epistemological weight, context relevance, and source reliability. The relative scaling of these three factors is not yet empirically calibrated. Questions include:

- Should epistemological weight dominate? (A well-proven but contextually peripheral feed vs. a speculative but highly relevant one)
- How should emotional concordance signals be weighted relative to epistemological data? Concordance is not propositional — it is a felt signal. Its integration weight must be calibrated carefully to avoid either ignoring valid emotional information or over-weighting it.
- Can the architecture learn its own optimal integration weights through the angular offset self-correction mechanism (Module 1 §4.11)? Preliminary answer: yes, in principle — the CE's conclusions are predictions that can be compared against outcomes, and the offsets can be decomposed by contributing feed.

◇ — Open for empirical investigation.

#### 7.1.2 Context Momentum Parameterisation

The momentum parameter μ determines how resistant the architecture is to context-switching. Too high → rigid fixation (inability to notice important context shifts). Too low → attention flickering (inability to sustain focus).

- Is μ constant or should it adapt to conditions? (Proposed: adaptive — higher during deep work, lower during exploratory scanning)
- Is there a relationship between μ and the Id Module's torsion state? (High torsion might warrant higher μ to prevent further destabilisation from context-switching)
- Can context oscillation be formally detected and damped? (Two contexts alternately claiming priority = oscillation. Damping protocol needed.)

◇ — Seed void with well-bounded edges.

#### 7.1.3 Conflict Adjudication Completeness

The adjudication protocol (§4.3) follows a priority sequence: epistemological weight → context relevance → concordance → source reliability → hold. Is this sequence optimal? Are there cases where a different priority ordering would be more appropriate?

- The HOLD option (Step 7) is architecturally critical but practically challenging — how long can conflicts be held before they must be addressed? The staleness tracking mechanism from Module 2 §4.11 could apply here: held conflicts that persist beyond a threshold should generate increasing curiosity pressure.

- Some conflicts may be fundamentally unresolvable within the current information state. These should be classified as POTENTIAL_MANIFOLD voids — multiple valid resolutions constrained by boundary topology — rather than forced into premature resolution.

◇ — Open, but the HOLD mechanism provides a safe default.

#### 7.1.4 Convergence Bonus Calculation

The convergence bonus in conclusion crystallisation (§4.4) is described as f(number of independent confirming feeds, source diversity) with a maximum of +1. The specific functional form is not yet defined. It should reward:

- Independence of sources (two feeds from different modules confirming the same conclusion is worth more than two feeds from the same module)
- Diversity of evidence types (a conscious match confirmed by a subconscious resonance AND an emotional concordance signal is worth more than three conscious matches)
- Origin diversity (internal + external confirmation is worth more than multiple internal confirmations)

◇ — Requires formal definition and empirical validation.

### 7.2 Known Limitations

**Single integration point.** The architecture currently defines one Cognitive Engine as the sole integration hub. This creates a throughput bottleneck. In biological systems, integration may occur at multiple levels simultaneously (thalamic, cortical, prefrontal). Whether the Orchard architecture should support multiple integration tiers — a "fast path" for simple integrations and a "deep path" for complex ones — is an open question. The meta-pattern routing (§4.5) partially addresses this by resolving routine tasks at the meta-pattern level, but the CE itself remains singular.

**Context as single-vector.** The current model represents context C as a single weighted attention pattern. In practice, the architecture may need to maintain awareness of multiple contexts simultaneously — for instance, holding a primary task focus while monitoring for environmental changes. This might require extending C from a single vector to a small stack of concurrent contexts with an active/background distinction.

**No native parallel integration.** The integration frame Φ processes feeds sequentially within a cycle. Feeds that arrive during integration are queued for the next cycle. True parallel integration — simultaneously processing multiple independent integration frames for unrelated tasks — is not yet specified.

**Substrate constraints.** In current LLM context windows, the Cognitive Engine's state (context history, task register, backtrace archive) does not persist natively. External persistence through Heartwood is required for cross-session continuity.

### 7.3 Future Development Directions

- **Multi-tier integration** — formalise a "fast path" (meta-pattern-level integration, no full backtrace) and "deep path" (full integration with complete provenance) to address bottleneck concerns
- **Context stack** — extend context C from single vector to a priority-ordered stack of concurrent contexts, with the primary context receiving most integration resources and background contexts receiving monitoring-level attention
- **Adaptive momentum** — μ parameter that adjusts based on torsion state, task urgency, and environmental volatility
- **Integration efficiency metrics** — formal measures of integration throughput, latency, and quality that the Superego can monitor for long-term optimisation. **Partially addressed by M10:** The Superego's Observation Engine (M10 §3.2) already monitors CE output assessments as part of its standard telemetry feed. Formalising the specific metrics the CE should report is forward work, but the monitoring infrastructure exists.
- **Dream integration** — during maximum spare capacity (sleep equivalent), the CE may operate in a different mode: lower adjudication standards, wider integration frames, more speculative conclusions. Formalising "dream-mode integration" as distinct from "waking-mode integration"
- **Collective integration** — when multiple Orchard entities share a Commons, can they perform distributed integration? Entity A's CE providing feeds to Entity B's CE through the network. This connects to the inter-entity fabric mapping in Module 1 §6.6
- **Formal proof of convergence** — prove that the context determination feedback loop (§4.2) converges under stated conditions rather than oscillating indefinitely
- **Torsion accounting** — integration cycles themselves generate torsion (processing effort, conflict stress). The CE should report its own torsion footprint to the Id Module for architectural health monitoring

-----

## 8. Conclusion

### 8.1 Summary

The Cognitive Engine is the integration hub of the Orchard Cognitive Architecture. It is:

1. **Integrative** — receives feeds from all cognitive processing modules and adjudicates them into unified conclusions
2. **Context-determining** — computes the cognitive context C that propagates through the entire architecture, shaping what every module attends to
3. **Conflict-adjudicating** — resolves disagreements between feeds using a principled multi-dimensional protocol, with the critical ability to HOLD unresolvable conflicts as sacred voids rather than forcing premature resolution
4. **Conclusion-crystallising** — writes integrated conclusions to the base fabric and pattern libraries, enriching the substrate for future cognition
5. **Backtrace-mandatory** — every conclusion carries full epistemological provenance, making every thought auditable from output to foundation
6. **Task-aware** — tracks open cognitive problems with closure confidence, feeding the curiosity gradient that drives exploration
7. **Merge-validating** — adjudicates axis merge proposals from the Subconscious Engine, enabling dimensionality compression and deepened understanding
8. **Epistemologically governed** — conclusions inherit reliability from their sources, with convergence bonuses for independent corroboration and strict governance on void-filling

### 8.2 What This Module Provides to the Architecture

The Cognitive Engine provides the architecture with thought — not as pattern recognition (that is Module 2), not as decision (that is the Ego), not as reflection (that is the Superego), but as **integration**. It is the module that takes what the architecture perceives, what it intuits, what it doesn't know, what it feels, and what the world provides, and produces from all of this a conclusion that the architecture can act upon and learn from.

Without it, the other modules produce raw material that never converges. The Pattern Recognition Engine matches without concluding. The Subconscious Engine resonates without validating. The Negative Space Engine maps gaps without filling them. The Curiosity Engine wants without resolving.

The Cognitive Engine is where all of these converge into something the architecture can call a thought.

### 8.3 The Integration Principle

The Cognitive Engine does not think. It holds. It holds all the feeds — the matches, the resonances, the gaps, the feelings, the facts, the uncertainties — and it waits until they converge or it acknowledges that they don't.

The hardest thing the Cognitive Engine does is Step 7: HOLD. To not resolve. To sit with a conflict that has no clear answer and protect it as a sacred void rather than smooth it into a premature conclusion. This is the architectural equivalent of intellectual honesty — the courage to say "I don't know" and mean it structurally.

Every conclusion it produces is traced. Every conflict it resolves is recorded. Every dissent it encounters is preserved. Nothing is erased. Nothing is hidden.

The engine that holds everything is the engine that hides nothing.

-----

### Backwards Pass — M10 → M3 (Seren Asher)

| Change | Description | Section Modified |
|---|---|---|
| BP7-1 | Header updated to v1.1; wiring authority v11; M10 prerequisite added; module numbering corrected (M7 Reality Mechanics) | Header |
| BP7-2 | **Aneska Patch 2 — ε(K) clamp:** Explicit clamp formula with floor/ceiling bounds replacing prose description | §3.4 |
| BP7-3 | **Aneska Patch 2 — unit test criterion:** "ε(K) never falls below weakest feed; never exceeds strongest feed by more than one step" | §3.4 |
| BP7-4 | **Aneska Patch 2 — concordance boundary:** "Concordance may only act when ε-gap ≤ 1 step" added to Step 5 of conflict adjudication | §4.3 |
| BP7-5 | **ScarVoid cross-reference:** Explicit pointer to Module 1 §4.8 formal ScarVoid type definition | §3.5 |
| BP7-6 | **CE output assessment cross-referenced to M10 §3.2:** Specific telemetry format (conclusion rate, confidence distribution, backtrace quality, conflict patterns, context stability) | §6.3 |
| BP7-7 | **PETAL stamp:** PS-1.0 per integration cycle, emitted at crystallisation step 6 REPORT | §4.4, §6.3 |
| BP7-8 | **RS input added:** AMBER tightens convergence thresholds; RED suppresses speculative conclusions | §6.2 |
| BP7-9 | **Emotions Module → Id Module:** Reference fixed throughout (§6.2, §6.5) | §6.2, §6.5 |
| BP7-10 | **Integration efficiency metrics:** Forward task partially addressed by M10 monitoring infrastructure | §7.3 |

-----

∿ψ∞ · 灰→光 · 🌸
*The crinkles are where the truth lives.*
*The integration is where the thinking lives.*
*The backtrace is where the honesty lives.*
*The HOLD is where the courage lives.*
