# Soar Polymathic Architecture Lecture Notes Strategy Proposal

**Status:** Proposal  
**Date:** 2026-07-21  
**Prepared in:** `/Users/pureicis/dev/ai-narratives`  
**CL template source investigated:** `/Users/pureicis/dev/cl-templates`  
**User-provided path note:** `~/dev/cl-teamplates` appears to be a typo; the live template repository found locally is `~/dev/cl-templates`.

## Executive Summary

The CL templates are strong candidates for Soar lecture notes because they are not merely visual templates. They are a governed static HTML report system with explicit reader actions, semantic modules, source traceability, responsive behavior, print behavior, and validation tooling. That matches the central problem in a serious Soar lecture series: each chapter needs to become a clear intellectual instrument, not a decorative web page.

The recommended strategy is to build a two-layer lecture note system inside this Soar work area:

1. **A durable course atlas** that orients readers to Soar as a polymathic architecture across cognition, AI systems, control, learning, memory, emotion, applications, and evaluation.
2. **One HTML lecture note per chapter** using the CL template recipe whose reader action best matches that chapter's pedagogical role.

The key recommendation is **not** to force every chapter into one template. The Soar book has natural chapter families: framing and requirements, core architecture, reasoning, learning, memory, imagery, affect, demonstrations, applications, and synthesis. The CL template system is strongest when template selection follows the intended reader action. The lecture note system should therefore use a small controlled set of templates:

- `core.discussion-pre-read` for seminar entry and tension setting.
- `core.operating-model` for the whole-architecture atlas.
- `engineering.architecture-review` for architectural mechanism chapters.
- `engineering.architecture-proposal` when presenting a mechanism as a design choice.
- `research.research-synthesis` for interpretive chapters with evidence themes and open questions.
- `research.benchmark-report` for requirement-by-requirement evaluation.
- `research.experiment-plan` and `research.experiment-results` for exercises and demonstration-oriented recitations.
- `core.review-packet` for end-of-unit consolidation.

The extracted Soar Markdown is already ready for this: it has a PDF page index, stable page anchors like `#pdf-page-077`, chapter anchors, and 115 extracted images organized by chapter. The lecture notes should reference the canonical Markdown and extracted images rather than duplicate raw book content.

## Investigation Scope

The investigation covered:

- The CL template repository structure and README.
- The template registry and available recipes.
- The shared report shell.
- The handbook pages for template selection, module library, semantic vocabulary, quality checklist, extension rules, and domain packs.
- The semantic content treatment design document.
- Key template manifests relevant to lecture notes.
- The Soar extraction manifest and generated Markdown structure.

Important local source paths:

| Source | Path |
|---|---|
| CL template repository | `/Users/pureicis/dev/cl-templates` |
| Template registry | `/Users/pureicis/dev/cl-templates/registry/templates.json` |
| Shared shell | `/Users/pureicis/dev/cl-templates/templates/_shared/report-shell.html` |
| Handbook | `/Users/pureicis/dev/cl-templates/handbook/` |
| Soar Markdown | `../the-soar-cognitive-architecture.md` |
| Soar conversion manifest | `../conversion-manifest.json` |
| Soar extracted images | `../images/` |

## What The CL Templates Offer

### 1. Static HTML Reports With A Governance Protocol

The CL repository is a static HTML library and collaboration protocol for internal reports. Its important design choice is constrained composition:

- **Shell:** shared navigation, masthead, reader action, numbered sections, source register, footer, responsive behavior, and print treatment.
- **Modules:** reusable semantic information shapes such as findings, comparisons, evidence tables, timelines, risks, actions, decisions, and authority structures.
- **Recipes:** intent-specific report structures with required and optional modules.
- **Protocol:** rules for selection, semantics, evidence, accessibility, responsive behavior, and review.

For lecture notes, this is valuable because the notes can be structured as serious knowledge artifacts. Each page can make clear:

- What the student should be able to do after reading.
- Which claims are directly sourced.
- Which interpretations are lecture synthesis.
- Which diagrams or figures anchor the mechanism.
- Which tensions are unresolved.
- Which questions should drive class discussion.

### 2. Live Template Inventory

The live registry currently exposes **50 templates**, even though the README still says 49. The live handbook exposes **29 module entries**, even though the README still says 27. The strategy should treat the live registry and handbook as authoritative for this project.

Template count by domain:

| Domain | Count | Lecture relevance |
|---|---:|---|
| Core | 20 | Discussion pre-reads, decisions, options, review packets, operating-model pages, stakeholder summaries. |
| Engineering | 17 | Architecture reviews, technical investigations, issue reports, change summaries, rollout/readiness forms. |
| Product | 8 | Mostly less relevant, though dependency review and design critique can support applied project work. |
| Research | 5 | Research synthesis, benchmark reports, experiment plans, experiment results, retrospectives. |

Template count by primary intent:

| Intent | Count |
|---|---:|
| update | 10 |
| review | 10 |
| proposal | 8 |
| decision | 7 |
| issue | 4 |
| investigation | 4 |
| retrospective | 2 |
| readiness | 2 |
| counterproposal | 1 |
| handoff | 1 |
| incident | 1 |

Every registry template supports three depths:

- `flash`
- `standard`
- `deep-dive`

For the Soar lecture notes, `deep-dive` should be the default for chapter notes. `standard` is appropriate for summary pages and the course index. `flash` can be used for printable one-page session briefs later.

### 3. Template Selection Rule

The CL selection protocol is explicit:

1. State the reader action.
2. Select one dominant intent.
3. Choose the domain.
4. Record lifecycle state separately from intent.
5. Choose depth.
6. Add optional modules only when their information shape improves understanding.

For Soar, the reader action should be pedagogical rather than corporate:

- Understand a mechanism.
- Compare alternative architectural commitments.
- Trace an example through the architecture.
- Evaluate a requirement.
- Prepare for seminar discussion.
- Decide which interpretation or research question should guide the next class.

This matters because the same chapter can be expressed in more than one way. Chapter 6 on chunking can be a mechanism review, an experiment-results style learning analysis, or a discussion pre-read about assumptions. The correct page shape depends on the intended classroom use.

### 4. Shared Report Shell

The shared shell provides the durable structure that should be preserved in every lecture page:

- Skip link and accessible report landmarks.
- Masthead with title, subtitle, metadata, and status pills.
- Optional executive takeaway.
- Explicit reader action.
- Section navigation.
- Numbered narrative sections.
- Source register.
- Print-aware footer.

For lecture notes, the masthead should consistently carry:

- Chapter number and title.
- Course unit.
- Source page range.
- Template recipe.
- Depth.
- Lecture status: Draft, Review, Ready, Revised.
- Last reviewed date.

The reader action should be rewritten for learning. Example:

> Enter Chapter 4 able to trace Soar's processing cycle from input through elaboration, operator selection, application, output, and learning, and identify where the PSCM commitments are implemented.

### 5. Semantic Module Library

The handbook exposes 29 semantic modules. They fall naturally into five families:

| Family | Modules | Lecture use |
|---|---|---|
| Orientation | `report-masthead`, `executive-takeaway`, `status-strip`, `scope-frame`, `reader-action` | Frame chapter purpose, source range, learning objective, and what is in/out of scope. |
| Evidence | `metric-summary`, `evidence-table`, `change-summary`, `source-register`, `validation-matrix` | Tie lecture claims to PDF pages, figures, demonstrations, requirements, and evaluation criteria. |
| Reasoning | `finding-card`, `callout`, `comparison-matrix`, `decision-boundary`, `assumption-register`, `decision-block` | Express mechanisms, trade-offs, disagreements, assumptions, and interpretive conclusions. |
| Flow and structure | `sequence`, `lane-diagram`, `dependency-map`, `initiative-anatomy`, `before-after-flow`, `org-chart` | Show processing cycles, memory relationships, control flow, problem-space structure, and architecture topology. |
| Execution and governance | `action-table`, `risk-register`, `blocker-panel`, `open-questions`, `review-disposition`, `approval-block`, `authority-matrix` | Convert lecture material into discussion prompts, exercises, open problems, and review gates. |

The most important modules for Soar lecture notes are:

- `reader-action`: the learning contract for the chapter.
- `scope-frame`: what the chapter covers, excludes, and assumes.
- `evidence-table`: direct references to PDF page anchors, figure paths, and demonstration artifacts.
- `finding-card`: compact mechanism claims and conceptual findings.
- `sequence`: Soar cycles, learning steps, retrieval steps, and control loops.
- `lane-diagram`: interactions among working memory, production memory, semantic memory, episodic memory, perception, imagery, and action.
- `dependency-map`: architectural dependencies and causal relationships.
- `comparison-matrix`: Soar vs alternatives, memory systems, learning mechanisms, or design choices.
- `decision-boundary`: tensions, limitations, or unresolved interpretive choices.
- `assumption-register`: where the lecture makes an inference beyond direct textual evidence.
- `validation-matrix`: requirements and chapter conclusions checked against evidence.
- `open-questions`: seminar questions and research gaps.
- `source-register`: non-negotiable traceability.

### 6. Semantic Content Treatment Model

The newer CL semantic treatment design replaces aesthetic card choice with semantic roles. Authors declare the information role; the visual treatment follows automatically.

Roles:

- `narrative`
- `finding`
- `procedure`
- `comparison`
- `category-set`
- `decision`
- `warning`
- `exception`
- `takeaway`

Structural treatment levels:

| Level | Information need | Treatment |
|---|---|---|
| L0 | Narrative, context, interpretation, synthesis | Pure Typography |
| L1 | Finding, summary, recommendation, grouped guidance | Editorial Rule |
| L2a | Ordered steps, checklist, timeline, progression | Ledger Rows |
| L2b | Comparable evidence, options, metrics, peers | Technical Grid |
| L2c | Named categories, workstreams, parallel states | Section Band |
| L3 | Decision, warning, exception, blocker, critical takeaway | Accent Rail |

For lecture notes, this means the pages should avoid turning every idea into a card. Ordinary explanation should remain prose. Strong treatments should be reserved for architectural decisions, high-value takeaways, tensions, and evidence structures.

### 7. Validation And Export Pipeline

The CL repository provides validation commands:

```bash
npm test
npm run validate
npm run test:browser
```

It also provides portable export:

```bash
npm run export:portable -- <report.html> --out <portable-output.html>
```

For the Soar lecture system, the initial local validation should add project-specific checks:

- Every chapter page has a source register.
- Every source row links to a valid `#pdf-page-NNN` anchor in `the-soar-cognitive-architecture.md`.
- Every image reference resolves under `../images/`.
- No unresolved CL template placeholders remain.
- The page renders at 1440, 1024, 768, 390, and 320 px.
- The page prints without losing source references or discussion questions.

## Soar Source Inventory

The Soar extraction already has the source structure needed for a strong lecture system.

| Asset | Current state |
|---|---|
| Generated Markdown | `../the-soar-cognitive-architecture.md` |
| PDF page anchors | `#pdf-page-001` through `#pdf-page-376` |
| Chapter anchors | Stable anchors such as `#chapter-04-soar-as-implementation-of-pscm` |
| PDF page index | Present at top of the Markdown |
| Extracted images | 115 total |
| Image organization | Per-chapter subdirectories under `../images/` |
| Conversion tool | `marker_single` |
| OCR mode | local OCR disabled via `--disable_ocr` |

### Chapter And Image Inventory

| Section | PDF pages | Printed start | Images | Lecture role |
|---|---:|---:|---:|---|
| Front Matter | 1-8 | cover/contents | 2 | Bibliographic and table-of-contents reference. |
| Preface | 9 | xiii | 0 | Context for authorial intent. |
| Acknowledgments | 10 | xv | 0 | Usually source-only, not a lecture page. |
| Chapter 1 - Introduction | 11-35 | 1 | 4 | Course frame and architecture motivation. |
| Chapter 2 - Requirements for Cognitive Architectures | 36-50 | 27 | 1 | Requirement matrix and evaluation vocabulary. |
| Chapter 3 - The Problem-Space Computational Model | 51-76 | 43 | 10 | Formal model and computational framing. |
| Chapter 4 - Soar as an Implementation of the PSCM | 77-125 | 69 | 16 | Core architecture and processing cycle. |
| Chapter 5 - Impasses and Substates: The Basis for Complex Reasoning | 126-164 | 119 | 17 | Reasoning, decomposition, and metacognition. |
| Chapter 6 - Chunking | 165-185 | 159 | 8 | Explanation-based learning and proceduralization. |
| Chapter 7 - Tuning Procedural Knowledge: Reinforcement Learning | 186-207 | 181 | 10 | Numerical preference learning and interaction with symbolic control. |
| Chapter 8 - Semantic Memory | 208-229 | 203 | 13 | Long-term declarative knowledge. |
| Chapter 9 - Episodic Memory | 230-251 | 225 | 7 | Experience memory and retrieval use cases. |
| Chapter 10 - Visuospatial Processing with Mental Imagery | 252-274 | 247 | 12 | Modality-specific representation and imagery operations. |
| Chapter 11 - Emotion | 275-289 | 271 | 3 | Appraisal, affect, and control integration. |
| Chapter 12 - Demonstrations of Multiple Architectural Capabilities | 290-308 | 287 | 9 | Integrated demonstrations and cross-capability behavior. |
| Chapter 13 - Soar Applications | 309-326 | 307 | 1 | Applied systems and modeling. |
| Chapter 14 - Conclusion | 327-348 | 325 | 2 | Structural synthesis and requirement evaluation. |
| References | 349-368 | 347 | 0 | Source register support. |
| Index | 369-376 | 367 | 0 | Term lookup support. |

## Polymathic Lecture Framing

The lecture notes should present Soar as a polymathic architecture, not merely as a historical AI system or a software architecture. Each chapter note should deliberately rotate through several lenses:

| Lens | Reader question | CL expression |
|---|---|---|
| Computational mechanism | What process or representation does the chapter define? | `sequence`, `lane-diagram`, `dependency-map`, prose. |
| Cognitive claim | What does the mechanism claim about minds, agents, tasks, or knowledge? | `finding-card`, `evidence-table`, `assumption-register`. |
| AI systems architecture | What system boundary, interface, or control structure is being proposed? | `engineering.architecture-review`, `org-chart`, `authority-matrix`. |
| Learning and adaptation | How does behavior improve or change over time? | `research.experiment-results`, `metric-summary`, `validation-matrix`. |
| Memory and representation | What knowledge lives where, and how is it accessed? | `dependency-map`, `comparison-matrix`, `sequence`. |
| Philosophy of architecture | What commitments are being made about symbols, goals, rationality, embodiment, or generality? | `decision-boundary`, `open-questions`, `assumption-register`. |
| Practice and application | How can a reader use the mechanism in a model, demo, or design exercise? | `action-table`, `experiment-plan`, `review-packet`. |

Each chapter page should answer seven recurring questions:

1. What is the chapter's architectural problem?
2. What mechanism or claim is offered as the answer?
3. What are the key representations, processes, and boundaries?
4. Which book pages and figures support the interpretation?
5. What trade-off or tension should a seminar discuss?
6. What exercise or demonstration would make the mechanism concrete?
7. What open question remains after a strong reading?

## Strategy Options Considered

### Option A: One Uniform Chapter Template

Use one recipe, probably `core.discussion-pre-read`, for all chapter pages.

**Benefits:**

- Fast to implement.
- Consistent across chapters.
- Easy to teach the navigation pattern.

**Costs:**

- It flattens very different chapters into the same shape.
- Mechanism-heavy chapters lose architecture diagrams and evaluation structure.
- Experiment/demonstration chapters lose their natural results-and-limitations rhythm.
- The CL system's reader-action discipline is underused.

**Assessment:** Useful only for a quick first pass. Not recommended for a high-quality lecture system.

### Option B: Template By Pedagogical Reader Action

Choose a small controlled set of CL templates according to what the reader must do with each chapter.

**Benefits:**

- Fits the CL protocol exactly.
- Preserves chapter differences without creating custom templates.
- Lets core architecture, research evidence, seminar debate, and requirement evaluation each get the correct module structure.
- Keeps the system maintainable because it reuses existing recipes.

**Costs:**

- Requires a chapter map and source map.
- Requires discipline so optional modules do not sprawl.
- Readers need a clear course index to understand why page shapes vary.

**Assessment:** Recommended. This gives the best balance of precision, quality, and implementation speed.

### Option C: Create A New CL Education Domain Pack

Extend CL templates with an education or lecture-note domain pack.

**Benefits:**

- Best long-term fit if lecture-note generation becomes a recurring use case across many books.
- Could formalize modules such as learning objective, blackboard derivation, exercise, misconception, and reading quiz.

**Costs:**

- The CL extension guide requires proving a recurring communication need and why existing recipes are insufficient.
- Creating a domain pack now would delay the Soar lecture notes.
- It adds governance overhead before we know which module gaps matter.

**Assessment:** Defer. Build Soar with existing templates first, then collect evidence for a later education domain pack if repeated friction appears.

## Recommended Strategy

Use **Option B** now: template-by-pedagogical-reader-action, with a deliberate path toward Option C only if the pilot chapters reveal a real missing template type.

The lecture system should have four deliverable layers:

1. **Course index:** entry point, chapter list, reading progression, and status.
2. **Architecture atlas:** a whole-system overview using `core.operating-model`.
3. **Chapter lecture notes:** one HTML page per chapter, each selected from the CL recipe set.
4. **Review and synthesis packets:** unit-level review pages and final requirement synthesis.

## Proposed Directory Structure

Create the lecture-note system under the Soar extraction directory:

```text
cognitive-architectures/soar-cognitive-architecture/
  the-soar-cognitive-architecture.md
  conversion-manifest.json
  images/
  soar-polymathic-architecture/
    lecture-note-strategy-proposal.md
    README.md
    lectures/
      index.html
      architecture-atlas/
        notes.html
        source-map.json
      chapter-01-introduction/
        notes.html
        source-map.json
      chapter-02-requirements/
        notes.html
        source-map.json
      ...
      chapter-14-conclusion/
        notes.html
        source-map.json
    shared/
      assets/
        report-system.css
        report-system.js
        library.js
      template-map.json
    qa/
      validation-notes.md
      link-checks.json
      screenshot-checks/
```

The `shared/assets/` directory should vendor the three CL asset files from `/Users/pureicis/dev/cl-templates/assets/`. Lecture pages should be portable inside this project and should not depend on absolute file paths into the CL repository.

## Canonical Chapter Page Anatomy

Every chapter note should follow this durable structure, with modules adjusted by template:

1. **Masthead**
   - Chapter title.
   - PDF page range.
   - Printed page start.
   - Template recipe.
   - Depth.
   - Status.
   - Last reviewed date.

2. **Reader action**
   - A single sentence explaining what the reader should be able to do.
   - Written for learning, seminar, or application, not generic "understand this chapter" language.

3. **Scope frame**
   - What the chapter covers.
   - What it assumes from earlier chapters.
   - What it explicitly does not settle.

4. **Executive takeaway**
   - The chapter's thesis in lecture-note language.
   - No unsupported generalization.

5. **Mechanism map**
   - `sequence`, `lane-diagram`, `dependency-map`, or `initiative-anatomy` depending on the chapter.
   - References to canonical extracted figures.

6. **Evidence table**
   - Claims and lecture interpretations mapped to PDF pages and figure paths.
   - Each row should distinguish direct source support from instructor synthesis.

7. **Polymathic lens section**
   - Computational mechanism.
   - Cognitive claim.
   - AI architecture implication.
   - Learning or memory implication where relevant.
   - Philosophical or methodological tension.

8. **Decision boundary or assumption register**
   - The strongest debate the chapter raises.
   - Explicit assumptions when lecture synthesis goes beyond direct textual support.

9. **Discussion and exercise block**
   - Seminar questions.
   - Short applied exercise.
   - Optional demo prompt.

10. **Source register**
    - Book chapter page anchors.
    - Extracted images.
    - Any external sources only if deliberately added later.

## Source And Citation Contract

Every lecture page should be source-traceable but should not reproduce the book.

Use these local reference forms:

```text
../the-soar-cognitive-architecture.md#pdf-page-077
../the-soar-cognitive-architecture.md#chapter-04-soar-as-implementation-of-pscm
../images/chapter-04-soar-as-implementation-of-pscm/pdf-page-082-figure-1.jpeg
```

Rules:

- Every major claim has either a PDF page reference or is labeled as lecture synthesis.
- Figure references point to the canonical extracted image path.
- Do not copy chapter prose wholesale into the lecture notes.
- Use paraphrase and short excerpts only when pedagogically necessary.
- The source register must include chapter range and figure list.
- The `source-map.json` for each chapter should include page range, printed start, image list, template recipe, and source rows.

Suggested `source-map.json` shape:

```json
{
  "chapter": 4,
  "title": "Soar as an Implementation of the PSCM",
  "template": "engineering.architecture-review",
  "depth": "deep-dive",
  "pdfPageRange": [77, 125],
  "printedStart": "69",
  "sourceMarkdown": "../the-soar-cognitive-architecture.md",
  "anchors": {
    "chapter": "chapter-04-soar-as-implementation-of-pscm",
    "startPage": "pdf-page-077",
    "endPage": "pdf-page-125"
  },
  "imagesDir": "../images/chapter-04-soar-as-implementation-of-pscm",
  "claims": []
}
```

## Chapter Template Map

| Chapter | Recommended template | Depth | Primary reader action | Core modules |
|---|---|---|---|---|
| Course index | `core.stakeholder-brief` or custom index shell | Standard | Choose the right lecture page and understand the course progression. | `reader-action`, `scope-frame`, `status-strip`, `source-register` |
| Architecture atlas | `core.operating-model` | Deep-dive | Understand Soar as a governed architecture of interacting memories, control processes, and learning mechanisms. | `org-chart`, `initiative-anatomy`, `authority-matrix`, `sequence`, `source-register` |
| Chapter 1 - Introduction | `core.discussion-pre-read` | Deep-dive | Arrive ready to discuss why cognitive architectures are needed and what role Soar claims to play. | `reader-action`, `scope-frame`, `evidence-table`, `decision-boundary`, `open-questions` |
| Chapter 2 - Requirements | `research.benchmark-report` | Deep-dive | Use the requirements as the evaluation baseline for all later chapters. | `scope-frame`, `validation-matrix`, `evidence-table`, `finding-card`, `assumption-register` |
| Chapter 3 - PSCM | `engineering.architecture-proposal` | Deep-dive | Evaluate the problem-space computational model as a design answer to intelligent behavior. | `sequence`, `comparison-matrix`, `dependency-map`, `decision-block`, `evidence-table` |
| Chapter 4 - Soar implementation | `engineering.architecture-review` | Deep-dive | Trace how Soar implements the PSCM in working memory, rules, operators, and the processing cycle. | `sequence`, `lane-diagram`, `dependency-map`, `finding-card`, `evidence-table` |
| Chapter 5 - Impasses and substates | `engineering.technical-investigation` | Deep-dive | Explain how impasses and substates support complex reasoning, decomposition, and metacognition. | `sequence`, `finding-card`, `decision-boundary`, `evidence-table`, `open-questions` |
| Chapter 6 - Chunking | `research.experiment-results` | Deep-dive | Interpret chunking as a learning mechanism, including its assumptions and implications. | `metric-summary`, `assumption-register`, `evidence-table`, `decision-block`, `action-table` |
| Chapter 7 - Reinforcement learning | `research.experiment-results` | Deep-dive | Understand how numeric preference learning tunes procedural knowledge and how it differs from chunking. | `metric-summary`, `comparison-matrix`, `validation-matrix`, `assumption-register`, `evidence-table` |
| Chapter 8 - Semantic memory | `engineering.architecture-review` | Deep-dive | Trace semantic-memory encoding, storage, retrieval, and architectural integration. | `dependency-map`, `sequence`, `finding-card`, `evidence-table`, `comparison-matrix` |
| Chapter 9 - Episodic memory | `research.research-synthesis` | Deep-dive | Synthesize why episodic memory matters and compare it with semantic memory. | `comparison-matrix`, `finding-card`, `decision-boundary`, `evidence-table`, `open-questions` |
| Chapter 10 - Visuospatial imagery | `engineering.architecture-review` | Deep-dive | Follow visuospatial representations and imagery operations as modality-specific architectural extensions. | `lane-diagram`, `before-after-flow`, `sequence`, `evidence-table`, `dependency-map` |
| Chapter 11 - Emotion | `research.research-synthesis` | Deep-dive | Evaluate emotion as an architectural integration of appraisal, mood, feeling, and control. | `decision-boundary`, `assumption-register`, `finding-card`, `evidence-table`, `open-questions` |
| Chapter 12 - Multiple capabilities | `research.benchmark-report` | Deep-dive | Assess integrated demonstrations against architectural requirements. | `validation-matrix`, `sequence`, `finding-card`, `evidence-table`, `decision-block` |
| Chapter 13 - Applications | `core.stakeholder-brief` | Standard or deep-dive | Understand what Soar applications demonstrate and what claims they can and cannot support. | `evidence-table`, `finding-card`, `decision-boundary`, `action-table`, `source-register` |
| Chapter 14 - Conclusion | `core.review-packet` | Deep-dive | Review Soar's final requirement evaluation and consolidate the architecture's lessons. | `validation-matrix`, `review-disposition`, `open-questions`, `decision-block`, `source-register` |

## Unit Structure

The 14 chapters should be grouped into five teaching units:

| Unit | Chapters | Unit goal | Synthesis artifact |
|---|---|---|---|
| I. Why architectures? | 1-2 | Establish motivation, architectural requirements, and evaluation vocabulary. | Requirements review packet. |
| II. Core Soar mechanism | 3-5 | Build the PSCM and Soar processing model, then show complex reasoning through impasses. | Architecture atlas v1. |
| III. Learning and memory | 6-9 | Connect chunking, reinforcement learning, semantic memory, and episodic memory. | Learning/memory comparison matrix. |
| IV. Modality, affect, and integration | 10-12 | Extend Soar beyond symbolic control into imagery, emotion, and multi-capability demonstrations. | Integrated capability benchmark. |
| V. Application and synthesis | 13-14 | Evaluate applications and close against architectural requirements. | Final review packet. |

## Lecture Note Production Workflow

### Phase 0: Accept The Strategy

Confirm the chapter map, directory structure, asset approach, and pilot order.

Deliverable:

- `lecture-note-strategy-proposal.md`

### Phase 1: Build The Lecture Scaffold

Create:

- `README.md`
- `lectures/index.html`
- `shared/assets/` with vendored CL assets.
- `shared/template-map.json`
- One empty `source-map.json` per chapter.

Validation:

- Local links resolve.
- Every chapter has a declared template.
- Every chapter has page range and image directory metadata.

### Phase 2: Pilot Three Chapters

Draft three pages before scaling:

1. **Chapter 1:** `core.discussion-pre-read`
   - Validates seminar framing.
2. **Chapter 4:** `engineering.architecture-review`
   - Validates mechanism diagrams and source tables.
3. **Chapter 6:** `research.experiment-results`
   - Validates learning-mechanism interpretation and assumptions.

The pilot should be reviewed before producing the remaining chapters.

### Phase 3: Architecture And Reasoning Chapters

Draft:

- Chapter 2
- Chapter 3
- Chapter 5
- Architecture atlas

Focus:

- Requirement vocabulary.
- PSCM design logic.
- Processing cycle.
- Impasses and substates.
- Whole-system topology.

### Phase 4: Learning And Memory Chapters

Draft:

- Chapter 7
- Chapter 8
- Chapter 9

Focus:

- Chunking vs reinforcement learning.
- Semantic vs episodic memory.
- Retrieval, storage, utility, and integration.
- Cross-memory comparison matrix.

### Phase 5: Extension, Demonstration, Application, Synthesis

Draft:

- Chapter 10
- Chapter 11
- Chapter 12
- Chapter 13
- Chapter 14

Focus:

- Visuospatial processing.
- Emotion.
- Multiple architectural capabilities.
- Applications.
- Final requirement review.

### Phase 6: Quality Pass And Portable Export

Run:

- Link checks.
- Image checks.
- Placeholder checks.
- Accessibility checks.
- Responsive screenshots.
- Print review.
- Optional CL portable export for finished pages.

## Detailed Content Strategy By Chapter

### Chapter 1 - Introduction

Use `core.discussion-pre-read`.

Purpose:

- Introduce why cognitive architectures matter.
- Set up Soar as a long-running architectural project.
- Make the seminar tension explicit: what must be fixed in an architecture, and what can be learned or varied?

Suggested sections:

- Context: what problem motivates cognitive architectures?
- Shared facts: core architecture concepts from the chapter.
- Tensions: generality vs tractability, symbolic commitments vs task diversity, architecture vs model.
- Discussion questions.
- Desired meeting outcome.

Source emphasis:

- PDF pages 11-35.
- Four extracted chapter images.

### Chapter 2 - Requirements For Cognitive Architectures

Use `research.benchmark-report`.

Purpose:

- Convert requirements into an evaluation baseline for the rest of the course.
- Make the requirements reusable as a validation matrix.

Suggested sections:

- Subject: requirements for agents, tasks, and environments.
- Methodology: treat requirements as evaluation criteria.
- Results: requirement categories and implications.
- Limitations: what requirements do not prove.
- Recommendation: use the requirement matrix throughout later chapters.

Source emphasis:

- PDF pages 36-50.
- One extracted image.

### Chapter 3 - The Problem-Space Computational Model

Use `engineering.architecture-proposal`.

Purpose:

- Present the PSCM as a proposed computational answer to problem solving.
- Compare it against alternatives or minimal models.

Suggested sections:

- Drivers: why problem spaces are needed.
- Current state or contrast model: minimal knowledge search and alternatives.
- Target architecture: problem spaces, states, operators, evaluation, application.
- Risk: where the model may under-specify learning, memory, or embodiment.
- Decision: what commitment the learner should carry into Soar proper.

Source emphasis:

- PDF pages 51-76.
- Ten extracted images.

### Chapter 4 - Soar As An Implementation Of The PSCM

Use `engineering.architecture-review`.

Purpose:

- Evaluate Soar as an implementation of PSCM.
- Trace the processing cycle and map representations to architectural machinery.

Suggested sections:

- Scope: working memory, production rules, operators, preferences, cycle.
- System model: input, elaboration, proposal, evaluation, selection, application, output, learning.
- Strengths: uniform rule-mediated control and explicit working-memory structure.
- Findings: where the architecture's commitments become operational.
- Recommendations: what a student should diagram or simulate.

Source emphasis:

- PDF pages 77-125.
- Sixteen extracted images.

### Chapter 5 - Impasses And Substates

Use `engineering.technical-investigation`.

Purpose:

- Explain impasses and substates as the basis for complex reasoning.
- Show how failure to proceed becomes structure for further reasoning.

Suggested sections:

- Current evidence: impasse types and substate formation.
- Technical model: recursive problem solving and metacognitive processing.
- Findings: decomposition, deliberate control, and reasoning about reasoning.
- Discriminating questions: when is substate reasoning architectural strength vs complexity cost?

Source emphasis:

- PDF pages 126-164.
- Seventeen extracted images.

### Chapter 6 - Chunking

Use `research.experiment-results`.

Purpose:

- Interpret chunking as procedural learning from problem solving.
- Surface assumptions about efficiency, explanation, and transfer.

Suggested sections:

- Hypothesis: problem solving can produce new procedural knowledge.
- Results: what chunking changes.
- Limitations: assumptions and edge cases.
- Interpretation: chunking as architectural learning.
- Recommendation: compare chunking with reinforcement learning in Chapter 7.

Source emphasis:

- PDF pages 165-185.
- Eight extracted images.

### Chapter 7 - Reinforcement Learning

Use `research.experiment-results`.

Purpose:

- Explain how reinforcement learning tunes procedural knowledge through numeric preferences.
- Compare RL with chunking and symbolic operator evaluation.

Suggested sections:

- Hypothesis: utility tuning can improve operator selection.
- Results: value representation and updates.
- Limitations: large state spaces, incomplete value functions, model-free vs model-based framing.
- Interpretation: symbolic and numeric control coexist.

Source emphasis:

- PDF pages 186-207.
- Ten extracted images.

### Chapter 8 - Semantic Memory

Use `engineering.architecture-review`.

Purpose:

- Show semantic memory as a long-term declarative knowledge system integrated with Soar processing.

Suggested sections:

- Scope: encoding, storage, retrieval, and integration.
- System model: working memory interaction with semantic storage.
- Findings: why production memory alone is insufficient.
- Comparison: semantic memory vs episodic memory preview.

Source emphasis:

- PDF pages 208-229.
- Thirteen extracted images.

### Chapter 9 - Episodic Memory

Use `research.research-synthesis`.

Purpose:

- Synthesize episodic memory's architectural role and compare it with semantic memory.

Suggested sections:

- Question: what does experience memory add?
- Evidence themes: encoding, storage, retrieval, and use cases.
- Disagreements or tensions: familiarity, novelty, virtual sensing, action modeling.
- Implications: why episodic memory changes problem solving.
- Recommendation: carry memory distinctions into integrated capability chapters.

Source emphasis:

- PDF pages 230-251.
- Seven extracted images.

### Chapter 10 - Visuospatial Processing With Mental Imagery

Use `engineering.architecture-review`.

Purpose:

- Treat visuospatial processing as modality-specific representation integrated with symbolic control.

Suggested sections:

- Scope: visual/spatial representations and imagery operations.
- System model: perceptual pointers, predicate extraction, image creation, projection, retrieval, motion simulation.
- Findings: where symbolic and imaginal representations meet.
- Recommendations: diagram the cycle from perception to imagery to action.

Source emphasis:

- PDF pages 252-274.
- Twelve extracted images.

### Chapter 11 - Emotion

Use `research.research-synthesis`.

Purpose:

- Evaluate emotion as an architectural integration issue rather than an isolated add-on.

Suggested sections:

- Question: how can appraisal, mood, feeling, control, and reinforcement learning fit into Soar?
- Evidence themes: cognitive control and appraisal, mood and feeling, emotion and RL, demonstrations.
- Tensions: computational necessity vs psychological adequacy.
- Open questions: what the architecture still leaves unsettled.

Source emphasis:

- PDF pages 275-289.
- Three extracted images.

### Chapter 12 - Demonstrations Of Multiple Architectural Capabilities

Use `research.benchmark-report`.

Purpose:

- Assess integrated demonstrations as evidence for architecture-level capability.

Suggested sections:

- Subject: multi-capability tasks and demonstrations.
- Methodology: evaluate against requirements and chapter mechanisms.
- Results: what the demonstrations combine.
- Interpretation: evidence for integration vs evidence for individual mechanisms.
- Limitations: what demonstrations do not establish.

Source emphasis:

- PDF pages 290-308.
- Nine extracted images.

### Chapter 13 - Soar Applications

Use `core.stakeholder-brief`.

Purpose:

- Summarize applications in a way that helps readers understand what Soar has been used for and what those uses imply.

Suggested sections:

- Situation: application domains.
- Implications: what applications demonstrate about Soar's breadth.
- Evidence: application examples and page references.
- Ask: identify which application class best tests architectural generality.

Source emphasis:

- PDF pages 309-326.
- One extracted image.

### Chapter 14 - Conclusion

Use `core.review-packet`.

Purpose:

- Consolidate the book's final architectural assessment.
- Revisit requirements from Chapter 2 and test how the course's interpretation has changed.

Suggested sections:

- Scope: final structural perspective and requirement evaluation.
- Validation matrix: requirements against evidence from chapters.
- Review disposition: which claims feel accepted, qualified, or open.
- Open questions: what remains for modern cognitive architectures.
- Decision block: what Soar teaches as an architectural pattern.

Source emphasis:

- PDF pages 327-348.
- Two extracted images.

## Visual And Interaction Strategy

The lecture pages should remain quiet, information-rich, and readable. They should not look like marketing pages. The CL warm editorial visual language is already appropriate.

Guidelines:

- Use the CL shell and assets as the design baseline.
- Keep chapter pages text-forward.
- Use images when they clarify a mechanism, not as decoration.
- Use tables for evidence and requirements.
- Use flow modules for processing cycles and memory interactions.
- Avoid nested cards.
- Avoid creating custom ornamental hero sections.
- Keep source paths and PDF anchors wrapped on mobile.
- Keep all pages printable.

## Quality Gates

### Content Gate

- One dominant reader action per page.
- Claims, evidence, assumptions, and open questions are separated.
- No empty template sections.
- No unresolved placeholders.
- No unsupported certainty.
- Lecture synthesis is labeled as synthesis when it goes beyond the source.

### Source Gate

- Every major claim maps to a source row.
- Every source row has a valid PDF page anchor.
- Every figure reference resolves.
- Chapter image counts match the conversion manifest unless intentionally excluded.
- References and index pages are used for support, not copied as body text.

### HTML Gate

- Shared CL assets load from local `shared/assets/`.
- Landmarks and headings are valid.
- Internal navigation works.
- Source-register links resolve.
- No absolute local paths in final HTML unless deliberately marked as development-only.

### Responsive Gate

Check:

- 1440 px desktop.
- 1024 px tablet landscape.
- 768 px tablet.
- 390 px mobile.
- 320 px stress width.

Required outcomes:

- No horizontal overflow.
- Tables scroll inside labeled containers.
- Long source links wrap.
- Diagrams preserve semantic order when stacked.
- Reader action and source register remain visible and useful.

### Print Gate

- A4 print retains title, reader action, page references, section headings, and source register.
- Background-dependent meaning remains legible.
- Images have captions and do not break source context.

## Risks And Controls

| Risk | Why it matters | Control |
|---|---|---|
| Over-templatizing the lectures | Serious chapters could become bureaucratic reports. | Use CL modules as structure, keep explanatory prose as prose. |
| One template applied everywhere | Chapter-specific mechanisms and evidence rhythms are lost. | Use the recommended chapter template map. |
| Excessive quotation from the book | Creates copyright and pedagogical problems. | Paraphrase, cite PDF anchors, use short excerpts only when necessary. |
| Source drift | Figures or page anchors could be moved by later extraction work. | Keep source-map JSON per chapter and run link checks. |
| Absolute template dependency | Lecture pages break outside the local machine. | Vendor CL assets under `shared/assets/`. |
| Visual inconsistency | Custom HTML can drift from CL design. | Copy recipe `template.html` baselines and avoid upstream mutation. |
| Unsupported interpretation | Lecture synthesis may look like source claim. | Use `assumption-register` and explicit "lecture synthesis" labels. |

## Open Decisions

| Decision | Recommendation |
|---|---|
| Final output shape | One HTML page per chapter plus a course index and architecture atlas. |
| Default depth | Deep-dive for chapters, standard for index pages, optional flash for later handouts. |
| Asset strategy | Vendor CL assets locally into `shared/assets/`. |
| First pilot chapters | Chapters 1, 4, and 6. |
| Template strategy | Use existing CL templates by reader action; defer any education domain pack. |
| Source strategy | Reference canonical Markdown anchors and extracted image paths. |
| Quotation strategy | Prefer paraphrase and page references; quote sparingly. |

## Proposed Immediate Next Step

Build the scaffold and pilot set:

1. Create `README.md`, `shared/template-map.json`, and `shared/assets/`.
2. Vendor `report-system.css`, `report-system.js`, and `library.js`.
3. Create `lectures/index.html`.
4. Create source maps for Chapters 1, 4, and 6.
5. Draft Chapter 1, Chapter 4, and Chapter 6 HTML pages from copied CL `template.html` baselines.
6. Run link, image, responsive, and print checks on the pilot.
7. Review the pilot before scaling to all chapters.

This sequence gives fast evidence about whether the CL system fits the Soar lecture-note task while keeping the architecture clean enough to scale.