Directory Structure

.husky/
  pre-commit
README.md
SUMMARY.md
canonical-index.md
core-concepts/
  README.md
  clarity-laws.md
  coherence-debt.md
  continuity-disruption-balance.md
  epistemic-substrate-theory.md
  epistemophany.md
  friction-ontology.md
  modal-layer-architecture.md
  multi-axis-integration.md
  return-as-intelligence.md
  role-structure-coherence.md
  semantic-friction.md
  structural-debt.md
  structural-receptivity.md
  structure-memory-interaction.md
  test-concept.md
  universal-evolutionary-stages.md
docs/
  PRD-ci-coder.md
  PRD‑ci‑coder.md
  canonical-source-documents/
    ballup-canonical-source.md
    cognitive-amnesia-canonical-source.md
    coherence-debt-canonical-source.md
    epistemic-substrate-theory-canonical-source.md
    epistemophany-canonical-source.md
    hero-structure-inverse-correlation-law-canonical-source.md
    hero-syndrome-canonical-source.md
    metastable-intelligence-canonical-source.md
    metric-mirage-canonical-source.md
    semantic-friction-canonical-source.md
    structural-receptivity-canonical-source.md
    structure-debt-canonical-source.md
    toolification-canonical-source.md
    trigger-chaos-canonical-source.md
    universal-evolutionary-stages-canonical-source.md
  json-guide.md
  scripts-guide.md
  source-documents/
    toolification-epistemological-source.md
json/
  README.md
  anti-patterns/
    ballup.json
    cognitive-amnesia.json
    dashboard-theater.json
    hero-syndrome.json
    metastable-intelligence.json
    metric-mirage.json
    over-layering.json
    semantic-drift.json
    toolification.json
    trigger-chaos.json
  core-concepts/
    clarity-laws.json
    coherence-debt.json
    continuity-disruption-balance.json
    epistemic-substrate-theory.json
    epistemophany.json
    fiction-ontology.json
    modal-layer.architecture.json
    multi-axis-integration.json
    return-as-intelligence.json
    role-structure-coherence.json
    semantic-friction.json
    structural-debt.json
    structural-receptivity.json
    structure-memory-interaction.json
    test-concept.json
    universal-evolutionary-stages.json
  docs/
    canonical-source-documents/
      ballup-canonical-source.json
      cognitive-amnesia-canonical-source.json
      coherence-debt-canonical-source.json
      epistemic-substrate-theory-canonical-source.json
      epistemophany-canonical-source.json
      hero-structure-inverse-correlation-law-canonical-source.json
      hero-syndrome-canonical-source.json
      metastable-intelligence-canonical-source.json
      metric-mirage-canonical-source.json
      semantic-friction-canonical-source.json
      structural-receptivity-canonical-source.json
      structure-debt-canonical-source.json
      toolification-canonical-source.json
      trigger-chaos-canonical-source.json
      universal-evolutionary-stages-canonical-source.json
    source-documents/
      toolification-epistemological-source.json
  meta/
    ci-document-schema.json
    ci-schema.json
  patterns/
    canonical-ids.json
    closed-loop-feedback.json
    hero-structure-inverse-correlation-law.json
    layered-modularity.json
    progressive-typing.json
    return-path-engineering.json
    semantic-foundation.json
    single-source-of-truth.json
ontology.json
package.json
patterns-and-anti-patterns/
  README.md
  anti-patterns/
    ballup.md
    cognitive-amnesia.md
    dashboard-theater.md
    hero-syndrome.md
    metastable-intelligence.md
    metric-mirage.md
    premature-optimization.md
    semantic-drift.md
    toolification.md
    trigger-chaos.md
  patterns/
    canonical-ids.md
    closed-loop-feedback.md
    hero-structure-inverse-correlation-law.md
    layered-modularity.md
    progressive-typing.md
    return-path-engineering.md
    semantic-foundation.md
    single-source-of-truth.md
scripts/
  ensure-json-files.js
  update-related-sections.js
  validate-all.js
sources/
  CITATION_EXAMPLES.md
  CONTRIBUTING.md
  README.md
  excerpts/
    FIELD_GUIDE_2024/
      001-introduction.md
    README.md
  index.yaml
  manuscripts/
    cognitive-infrastructure-field-guide.md
    test-concept-manuscript.md
tools/
  add-source.js
  ci-coder.js
  ci-writer.js
  create-excerpt.js
  cursor-rules.json
  excerpt.py
  validate-index-yaml.js
  validate_citations.py

README.md

# Cognitive Infrastructure> "You can't evolve what you can't articulate."Cognitive Infrastructure studies the architectural patterns that keep intelligence usable over time. It designs the structures, memories, and interactions that let humans, organizations, and machines retain clarity, evolve understanding, and act coherently. The field treats knowledge as an environment to engineer, diagnosing friction and guiding systems toward self‑improving alignment, continuously.
## Core ConceptsCognitive Infrastructure rests on a small set of first‑principles. Each concept below is a **source‑of‑truth definition**: short enough to read in one sitting, stable enough to cite, and versioned for evolution.
| Concept | One‑Line Essence ||---------|------------------|| Structure–Memory–Interaction (SMI) Triad | Usable intelligence = organisation + return + recursive refinement. || Modal Layer Architecture | Data → Logic → Interface → Orchestration → Feedback. Five separable, integ­ratable layers. || Clarity Laws | Empirical rules on how structure constrains capability. || Structural Debt | Hidden cost of mis‑aligned architecture; grows like interest. || Friction Ontology | Taxonomy of recurring clarity frictions. || Multi‑Axis Integration | Vertical, horizontal, end‑to‑end coherence across organisations. || Continuity–Disruption Balance | Safely evolving systems without breaking trust. || Universal Evolutionary Stages | 0–7 maturity ladder from fragmentation to integrated intelligence. || Role–Structure Coherence | Responsibility must match the scaffold that supports it. || Return‑as‑Intelligence | Revisiting understanding is itself a generative act. || Epistemophany | The moment when a system perceives the architecture shaping its understanding. || Coherence Debt | Cumulative deficit in shared meaning and interpretive trust. || Structural Receptivity | System's capacity to incorporate new knowledge without fragmentation. || Epistemic Substrate Theory | Foundational architecture determining possible forms of knowledge. || Semantic Friction | Resistance encountered when translating meaning across boundaries. |## Patterns & Anti‑PatternsArchitecture lives in recurring shapes. *Patterns* capture designs that preserve clarity. *Anti‑patterns* (frictions) describe structures that erode it.
### Implementation Patterns| Pattern | Purpose ||---------|---------|| Canonical IDs | Create stable, globally unique identifiers that transcend specific systems. || Closed-Loop Feedback | Design measurement systems that immediately inform adjustments. || Layered Modularity | Align system boundaries with Modal Layers for independent evolution. || Progressive Typing | Begin with flexible data structures that tighten as understanding grows. || Return Path Engineering | Design explicit routes back to previous knowledge and contexts. || Semantic Foundation | Establish unified definitions for consistent meaning across systems. || Single Source of Truth | Establish authoritative entity records from which all others derive. || Hero-Structure Inverse Correlation Law | Balance between individual heroism and structural maturity. |### Anti-Patterns| Anti‑Pattern | Symptom ||--------------|---------|| Ballup | Same friction resurfaces despite fixes. || Semantic Drift | Words mean different things in different teams. || Dashboard Theater | Beautiful visuals, zero trusted decisions. || Hero Syndrome | Operations rely on irreplaceable individuals. || Cognitive Amnesia | Org solves a problem, forgets, repeats. || Trigger Chaos | Automations behave unpredictably under change. || Metric Mirage | Metrics exist, but behaviour doesn't change. || Over‑Layering | Layers piled on without refactoring; brittle complexity. || Toolification | Adopting new tools instead of addressing architectural issues. || Metastable Intelligence | Systems appear functional until stress reveals fragilities. |## DocumentationThis repository contains comprehensive documentation on Cognitive Infrastructure concepts, patterns, and anti-patterns.
### Document Types#### Canonical Source DocumentsComprehensive canonical source documents are available in the `docs/canonical-source-documents/` directory. These in-depth treatments provide full context, theoretical underpinnings, and detailed examples for key concepts, patterns, and anti-patterns. Each follows a consistent structure:
- **Conceptual Layer**: Canonical definition, one-line summary, and contrast map
- **Theoretical Layer**: Foundational thinkers, epistemological implications, and OIF placement
- **Diagnostic Layer**: Quick-scan checklist, severity gradient, and example vignettes
- **Linguistic Layer**: Various forms, cross-lingual analogues, and subtype taxonomy
- **Narrative Layer**: Metaphors, illustrative scenes, and taglines
- **Cultural & Economic Layer**: Trend dynamics, cultural narratives, and economic mechanisms
#### Epistemological Source DocumentsEpistemological source documents, located in `docs/source-documents/`, provide research and external references rather than definitive concept descriptions. They explore the broader implications and connections of concepts within the field.
## The Publishing Workflow: From Draft to TruthCognitive Infrastructure follows a specific recursive publishing workflow that ensures content is structured, verified, and interconnected. This is not a "write once, forget" approach, but rather a continuous process of write, structure, validate, reuse, and evolve.
### How It Works1. **You drop a new manuscript into `/sources`**
   - Place raw manuscripts in `/sources/manuscripts/`   - Place PDF files in `/sources/raw-pdf/`   - Create excerpts in `/sources/excerpts/`2. **Run CI-Writer to auto-generate documentation**
   - CI-Writer scans for TODO markers in Markdown files
   - It finds relevant content from your manuscripts
   - It fills in TODOs with structured, consistent content
   ```bash   node tools/ci-writer.js [--path specific-file-or-dir]

1. Run CI-Coder to validate and maintain the repository

• Validates JSON files against schemas
• Updates related sections across files
• Fixes broken links and ensures consistency

node tools/ci-coder.js validate
node tools/ci-coder.js fix-links
node scripts/update-related-sections.js

1. Review and commit the changes

• Check the generated content for quality
• Make any necessary manual adjustments
• Commit the changes to the repository

1. GitBook updates automatically with the new content

• CI/CD processes deploy the updated documentation
• Users see the latest version with proper linking and structure

1. Both AI models and humans benefit from the structure

• Machine-readable JSON enables AI integration
• Human-readable Markdown provides clear documentation
• The structural connections allow for deeper exploration For detailed information about the tools and scripts available, see the Scripts Guide.

Getting Started

To explore the Cognitive Infrastructure framework:

1. Browse the Core Concepts to understand the foundational ideas
2. Examine the Patterns for practical implementation approaches
3. Learn to recognize Anti-Patterns to avoid common pitfalls
4. Dive deep into Canonical Source Documents for comprehensive understanding

Contributing to Cognitive Infrastructure

Contributions to Cognitive Infrastructure are welcome. Please follow these steps:

1. Set up your environment

# Install dependenciesnpm install
# Set up OpenAI API key (required for CI-Writer and CI-Coder)export OPENAI_API_KEY=your_api_key_here

1. Follow the publishing workflow

• Start by adding your content to the /sources directory
• Use the tools to generate and validate documentation
• Maintain consistent formatting and structure

1. Validate before submitting

# Validate JSON files against schemanpm run validate
# Run linting checksnpm run lint

1. Submit your contribution

• Create a pull request with your changes
• Ensure all validation checks pass
• Provide context for your contribution

License

MIT © Rashid Azarang

## core-concepts/README.md

```md
# Core Concepts

> *"You can't evolve what you can't articulate."*
> *— Field Axiom #1*

Cognitive Infrastructure rests on a small set of first‑principles.
Each concept below is a **source‑of‑truth definition**: short enough to read in one sitting, stable enough to cite, and versioned for evolution.

| Concept | One‑Line Essence |
|---------|------------------|
| **[Structure–Memory–Interaction (SMI) Triad](structure-memory-interaction.md)** | Usable intelligence = organisation + return + recursive refinement. |
| **[Modal Layer Architecture](modal-layer-architecture.md)** | Data → Logic → Interface → Orchestration → Feedback. Five separable, integ­ratable layers. |
| **[Clarity Laws](clarity-laws.md)** | Empirical rules on how structure constrains capability. |
| **[Structural Debt](structural-debt.md)** | Hidden cost of mis‑aligned architecture; grows like interest. |
| **[Friction Ontology](friction-ontology.md)** | Taxonomy of recurring clarity frictions. |
| **[Multi‑Axis Integration](multi-axis-integration.md)** | Vertical, horizontal, end‑to‑end coherence across organisations. |
| **[Continuity–Disruption Balance](continuity-disruption-balance.md)** | Safely evolving systems without breaking trust. |
| **[Universal Evolutionary Stages](universal-evolutionary-stages.md)** | 0–7 maturity ladder from fragmentation to integrated intelligence. |
| **[Role–Structure Coherence](role-structure-coherence.md)** | Responsibility must match the scaffold that supports it. |
| **[Return‑as‑Intelligence](return-as-intelligence.md)** | Revisiting understanding is itself a generative act. |
| **[Epistemophany](epistemophany.md)** | The moment when a system perceives the architecture shaping its understanding. |
| **[Coherence Debt](coherence-debt.md)** | Cumulative deficit in shared meaning and interpretive trust. |
| **[Structural Receptivity](structural-receptivity.md)** | System's capacity to incorporate new knowledge without fragmentation. |
| **[Epistemic Substrate Theory](epistemic-substrate-theory.md)** | Foundational architecture determining possible forms of knowledge. |

→ Start reading with the [SMI Triad](structure-memory-interaction.md); every other idea builds on it.
All concept files follow this block format:

```text
START_DEFINITION
<50–100 words canonical definition>
END_DEFINITION

## Why It Matters
<Explanation of the concept's importance and implications>

## Key Principles
<List of core principles that define the concept>

Canonical Source Documents

For more comprehensive exploration of these concepts, refer to the canonical source documents in the docs/canonical-source-documents/ directory. These documents provide in-depth treatments including:

• Theoretical underpinnings and foundational thinkers
• Diagnostic frameworks and severity gradients
• Linguistic variations and cross-lingual analogues
• Narrative metaphors and illustrative scenes
• Cultural and economic implications

Conceptual Relationships

These core concepts are interconnected, forming a coherent framework for understanding Cognitive Infrastructure:

1. Foundational Frameworks:

• Structure-Memory-Interaction Triad
• Modal Layer Architecture
• Universal Evolutionary Stages

1. Diagnostic Tools:

• Clarity Laws
• Friction Ontology
• Epistemic Substrate Theory

1. Operational Principles:

• Role-Structure Coherence
• Multi-Axis Integration
• Return-as-Intelligence

1. Evolutionary Dynamics:

• Structural Receptivity
• Continuity-Disruption Balance
• Epistemophany

1. Systemic Challenges:

• Structural Debt
• Coherence Debt

## json/README.md
```markdown
# Cognitive Infrastructure JSON RepositoryThis directory contains structured JSON representations of all concepts, patterns, anti-patterns, and source documents in the Cognitive Infrastructure framework. These files provide machine-readable definitions that can be validated, indexed, and used in applications.
## Directory Structure- **meta/** - Contains JSON schemas that define the structure of the various JSON files
  - `ci-schema.json` - Schema for concepts, patterns, and anti-patterns
  - `ci-document-schema.json` - Schema for canonical and epistemological source documents
- **core-concepts/** - JSON representations of core concepts
- **patterns/** - JSON representations of implementation patterns
- **anti-patterns/** - JSON representations of anti-patterns
- **docs/** - JSON representations of documentation
  - **canonical-source-documents/** - JSON files for canonical source documents
  - **source-documents/** - JSON files for epistemological source documents
## File Structure### Concept/Pattern/Anti-Pattern JSON```json{  "@context": { ... },  "@id": "ci:concept.example-concept",  "@type": "ci:Concept", // or ci:Pattern, ci:AntiPattern  "version": "1.0",  "label": {    "en": "Example Concept"  },  "description": {    "en": "Brief description of the concept."  },  "definition": {    "en": "Canonical definition of the concept."  },  "principles": [ ... ],  "relatedConcepts": [ ... ],  "canonicalDate": "YYYY-MM-DD",  "createdDate": "YYYY-MM-DD",  "modifiedDate": "YYYY-MM-DD"}

Canonical Source Document JSON

{  "@context": { ... },  "@id": "ci:canonical-source.example-concept",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Example Concept: Canonical Source",  "category": "canonical-source",  "author": "Author Name",  "sourceFile": "docs/canonical-source-documents/example-concept-canonical-source.md",  "documentStructure": {    "conceptualLayer": [ ... ],    "theoreticalLayer": [ ... ],    ...  },  "canonicalDate": "YYYY-MM-DD"}

Epistemological Source Document JSON

{  "@context": { ... },  "@id": "ci:epistemological-source.example-concept",  "@type": "ci:EpistemologicalSource",  "version": "1.0",  "title": "Example Concept: Epistemological Source",  "category": "epistemological-source",  "author": "Author Name",  "sourceFile": "docs/source-documents/example-concept-epistemological-source.md",  "documentType": "epistemological",  "researchAreas": [ ... ],  "externalReferences": [ ... ],  "canonicalDate": "YYYY-MM-DD"}

Usage

These JSON files serve multiple purposes:

1. Validation - Ensuring that all concepts, patterns, and documents follow a consistent structure
2. Indexing - Supporting search and discovery across the knowledge base
3. Integration - Enabling programmatic access to the Cognitive Infrastructure framework
4. Semantic Web - Providing structured data that can be consumed by semantic web applications
5. Version Control - Tracking changes to concepts and documentation over time JSON files are validated against schemas in the meta/ directory using a script in the root of the repository:

npm run validate

Contributing

When adding new concepts, patterns, or documents to the Cognitive Infrastructure framework, ensure that corresponding JSON files are created and validated against the appropriate schema.

1. Create the JSON file in the appropriate directory
2. Validate it against the schema
3. Update related JSON files with new cross-references if needed

## package.json

```json
{
  "name": "cognitive-infrastructure",
  "version": "1.0.0",
  "description": "Architectural patterns that keep intelligence usable over time",
  "main": "index.js",
  "scripts": {
    "validate": "ajv validate -s json/meta/ci-schema.json -r 'json/meta/*.json' -d 'json/{core-concepts,patterns,anti-patterns}/*.json'",
    "validate:docs": "ajv validate -s json/meta/ci-document-schema.json -r 'json/meta/*.json' -d 'json/docs/**/*.json'",
    "validate:all": "node scripts/validate-all.js",
    "validate:citations": "python tools/validate_citations.py sources/index.yaml $(git ls-files '*.md')",
    "validate:index": "node tools/validate-index-yaml.js",
    "lint": "lint-staged",
    "ensure-json": "node scripts/ensure-json-files.js",
    "update-related": "node scripts/update-related-sections.js",
    "excerpt": "python tools/excerpt.py",
    "source:add": "node tools/add-source.js",
    "source:excerpt": "node tools/create-excerpt.js",
    "ci-writer": "node tools/ci-writer.js",
    "ci-coder": "node tools/ci-coder.js",
    "prepare": "husky install"
  },
  "author": "Rashid Azarang",
  "license": "MIT",
  "lint-staged": {
    "*.md": [
      "markdownlint-cli2",
      "npm run validate:citations --"
    ],
    "*.json": "ajv validate -s json/meta/ci-schema.json",
    "sources/index.yaml": "npm run validate:index"
  },
  "devDependencies": {
    "ajv-cli": "^5.0.0",
    "husky": "^8.0.0",
    "js-yaml": "^4.1.0",
    "lint-staged": "^13.2.3",
    "markdownlint-cli2": "^0.8.1"
  },
  "dependencies": {
    "openai": "^4.95.0"
  }
}

patterns-and-anti-patterns/README.md

# Patterns & Anti‑PatternsArchitecture lives in recurring shapes.
*Patterns* capture designs that preserve clarity. *Anti‑patterns* (frictions) describe structures that erode it.
## Using This Library1. Diagnose your system → identify a pattern or anti‑pattern.
2. Follow the "Forces → Remedies" table to decide interventions.
3. Contribute improvements via pull‑request (see `CONTRIBUTING.md`).
### Implementation Patterns| Pattern | Intent ||---------|--------|| **[Semantic Foundation](patterns/semantic-foundation.md)** | Establish shared definitions before automation. || **[Layered Modularity](patterns/layered-modularity.md)** | Separate concerns along Modal Layers. || **[Single Source of Truth (SSoT)](patterns/single-source-of-truth.md)** | Authoritative entity records; everything else derives. || **[Closed‑Loop Feedback](patterns/closed-loop-feedback.md)** | Measurements that immediately inform adjustments. || **[Canonical IDs](patterns/canonical-ids.md)** | Stable, global identifiers for entities and concepts. || **[Progressive Typing](patterns/progressive-typing.md)** | Start loose, tighten types as understanding grows. || **[Return Path Engineering](patterns/return-path-engineering.md)** | Design explicit routes back to prior knowledge. || **[Hero-Structure Inverse Correlation Law](patterns/hero-structure-inverse-correlation.md)** | Balance between individual heroism and structural maturity. |### Anti‑Patterns| Anti‑Pattern | Symptom ||--------------|---------|| **[Ballup](anti-patterns/ballup.md)** | Same friction resurfaces despite fixes. || **[Semantic Drift](anti-patterns/semantic-drift.md)** | Words mean different things in different teams. || **[Dashboard Theater](anti-patterns/dashboard-theater.md)** | Beautiful visuals, zero trusted decisions. || **[Hero Syndrome](anti-patterns/hero-syndrome.md)** | Operations rely on irreplaceable individuals. || **[Cognitive Amnesia](anti-patterns/cognitive-amnesia.md)** | Org solves a problem, forgets, repeats. || **[Trigger Chaos](anti-patterns/trigger-chaos.md)** | Automations behave unpredictably under change. || **[Metric Mirage](anti-patterns/metric-mirage.md)** | Metrics exist, but behaviour doesn't change. || **[Over‑Layering](anti-patterns/over-layering.md)** | Layers piled on without refactoring; brittle complexity. || **[Toolification](anti-patterns/toolification.md)** | Adopting new tools instead of addressing architectural issues. || **[Metastable Intelligence](anti-patterns/metastable-intelligence.md)** | Systems appear functional until stress reveals fragilities. |> 🔗 Every pattern file ends with "See also" links to clarify relationships and avoid semantic drift inside the library itself.## Pattern StructureEach pattern and anti-pattern document follows a consistent structure:
### Pattern Files Format

START_DEFINITION <50-100 words canonical definition> END_DEFINITION

Intent

Context

Forces

Solution

Implementation

Consequences

Examples

Related Patterns

### Anti-Pattern Files Format

START_DEFINITION <50-100 words canonical definition> END_DEFINITION

Symptoms

Causes

Forces

Consequences

Remedies

Examples

Related Anti-Patterns

## Diagnostic Frameworks

The patterns and anti-patterns in this library can be used with the following diagnostic frameworks:

1. **Structural Debt Assessment**: Identify accumulated architectural misalignments using anti-patterns as indicators.
2. **Modal Layer Analysis**: Evaluate pattern implementation across the five layers (Data, Logic, Interface, Orchestration, Feedback).
3. **Semantic Coherence Check**: Measure the consistency of terminology and definitions across teams.
4. **Return Path Audit**: Assess how effectively systems can revisit and refine previous understanding.

## Evolutionary Context

Patterns and anti-patterns exist within the context of [Universal Evolutionary Stages](../core-concepts/universal-evolutionary-stages.md):

- **Stages 0-2**: Focus on implementing foundational patterns like Semantic Foundation and Canonical IDs
- **Stages 3-4**: Address anti-patterns like Hero Syndrome and Cognitive Amnesia
- **Stages 5-7**: Apply advanced patterns like Layered Modularity and Return Path Engineering

sources/README.md

# Source LibraryThis directory contains immutable source materials that form the foundation of the Cognitive Infrastructure knowledge base.
## Directory Structure- `/manuscripts/` - Markdown versions of whitepapers, books, and articles for easy diffing and referencing
- `/raw-pdf/` - Original PDF versions of documents (tracked with Git LFS)
- `/excerpts/` - Chunked sections of manuscripts organized by logical ID for efficient LLM processing
## Citation SystemAll source materials are assigned a unique logical ID in `index.yaml`. These IDs should be used for citation throughout the repository using the following format:
```markdown<!--cite:LOGICAL_ID p.15-->

Guidelines

1. Never modify original source materials once committed
2. Always register new sources in index.yaml before citation
3. Create excerpts for frequently referenced sections
4. Use Git LFS for binary files like PDFs

Contributing New Sources

1. Add your markdown version to /manuscripts/
2. Add the original file (if binary) to /raw-pdf/
3. Register a logical ID in index.yaml
4. Create excerpts as needed in /excerpts/<LOGICAL_ID>/
5. Reference in documentation using the citation format

## sources/excerpts/README.md

```md
# Source Excerpts

This directory contains structured excerpts from source materials, organized for efficient reference and LLM processing.

## Organization

Excerpts are organized by logical ID, with each source having its own directory:

excerpts/ ├── FIELD_GUIDE_2024/ │ ├── 001-introduction.md │ ├── 002-key-concepts.md │ └── … ├── INT_STACK_2024/ │ ├── 001-executive-summary.md │ └── … └── …

## Excerpt Format

Each excerpt file should include metadata:

```markdown
---
source: LOGICAL_ID
title: "Section Title"
pages: "12-15"
context: "Brief description of what this excerpt covers"
---

# Section Title

[Excerpt content...]

Purpose

These excerpts serve several key functions:

1. LLM Context Management: Allows CI-Writer to access only relevant portions of documents, preventing token bloat and reducing the risk of hallucinations
2. Quick Reference: Provides easy access to frequently cited sections
3. Granular Citation: Enables precise citation of specific ideas and concepts

When to Create Excerpts

Create excerpts when:

• A section is frequently cited in documentation
• A concept spans multiple source documents and needs consolidation
• A document is too large for efficient processing

Usage with CI-Writer

When using CI-Writer, you can reference specific excerpts:

@ci-writer Please explain Modal Layer Architecture based on excerpt INT_STACK_2024/003-modal-layers.md

## json/anti-patterns/ballup.json

```json
{
  "@context": {
    "ci": "https://cognitiveinfrastructure.org/schema#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "schema": "http://schema.org/"
  },
  "@id": "ci:antipattern.ballup",
  "@type": "ci:AntiPattern",
  "version": "1.0",
  "label": {
    "en": "Ballup"
  },
  "description": {
    "en": "Chronic recurring issues despite repeated attempts to fix them."
  },
  "tagline": {
    "en": "No matter how many times we fix it, this problem keeps coming back."
  },
  "symptoms": [
    "Teams repeatedly solve the same issue every few months",
    "Fixes don't stick",
    "Chronic 'priority interruptions' for predictable failures",
    "Escalating workaround complexity"
  ],
  "rootCause": {
    "en": "Current architectural structure cannot adequately hold the complexity pushing on it; attempted fixes address symptoms while ignoring structural pressures."
  },
  "impact": {
    "en": "Chronic firefighting culture; morale erosion as problems recur; escalating maintenance costs; increasing technical and structural debt; opportunity cost as innovation capacity diverts to recurring issues."
  },
  "structuralCure": {
    "en": "Conduct Modal Layer diagnosis to identify which layer is under pressure. Re-evaluate architectural balance and implement appropriate patterns (e.g., Layered Modularity, Semantic Foundation). Refactor rather than patch the affected subsystem."
  },
  "quickFixes": [
    "Document workarounds as explicit playbooks to reduce handling time",
    "Add monitoring specifically for early detection of recurring pattern",
    "Create designated handling team to protect wider organization while restructuring occurs"
  ],
  "relatedFrictions": [
    "ci:antipattern.over-layering",
    "ci:antipattern.trigger-chaos"
  ],
  "createdDate": "2024-04-16",
  "modifiedDate": "2024-04-16",
  "relatedConcepts": [
    "ci:concept.structural-debt",
    "ci:pattern.layered-modularity",
    "ci:pattern.semantic-foundation",
    "ci:antipattern.trigger-chaos"
  ]
}

json/anti-patterns/cognitive-amnesia.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.cognitive-amnesia",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Cognitive Amnesia"  },  "description": {    "en": "Organizations repeatedly solving the same problems without building on past solutions."  },  "tagline": {    "en": "Didn't we solve this exact problem last year?"  },  "symptoms": [    "Organization repeatedly solves the same problems",    "Valuable insights fade rather than compound",    "Past decisions are revisited without reference to previous reasoning",    "Teams reinvent solutions that already exist elsewhere"  ],  "rootCause": {    "en": "Memory mechanisms focus on storage rather than retrieval; context lost between solution instances; documentation that captures what but not why; missing connection between related problem occurrences."  },  "impact": {    "en": "Wasted effort recreating known solutions; inconsistent approaches to similar problems; inability to learn from experience at organizational scale; knowledge assets that grow in size but not in value."  },  "structuralCure": {    "en": "Implement Return Path Engineering pattern to create explicit revisitation routes. Build problem-solution repositories with rich contextual metadata. Create connection mechanisms between related issues across time. Design deliberate learning cycles that explicitly incorporate historical perspective."  },  "quickFixes": [    "Create simple issue pattern recognition guide",    "Assign 'organizational memory' role in key meetings",    "Implement basic context capture templates",    "Schedule recurring retrospectives specifically focused on pattern recognition across time"  ],  "relatedFrictions": [    "ci:antipattern.hero-syndrome",    "ci:antipattern.ballup"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:pattern.return-path-engineering",    "ci:antipattern.ballup",    "ci:antipattern.hero-syndrome"  ]}

json/anti-patterns/dashboard-theater.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.dashboard-theater",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Dashboard Theater"  },  "description": {    "en": "Impressive-looking visualizations that mask underlying data and logic weaknesses."  },  "tagline": {    "en": "It looks impressive until someone asks what the numbers actually mean."  },  "symptoms": [    "Beautiful visualizations that don't drive decisions",    "Extensive manual preparation before using reports",    "Increasing dashboard count without corresponding insight growth",    "Persistent questions about metric definitions"  ],  "rootCause": {    "en": "Interface layer sophistication has advanced beyond Logic and Data layer foundations; visualization tools used to create meaning rather than reflect it; aesthetic considerations prioritized over structural accuracy."  },  "impact": {    "en": "Declining trust in operational metrics; increasing time spent debating numbers rather than implications; decisions driven by offline analysis rather than systems; shadow reporting structures emerging to compensate."  },  "structuralCure": {    "en": "Pause dashboard development to strengthen Logic and Data layers. Implement Semantic Foundation pattern for key metrics. Create clear data lineage from source to visualization. Rebuild interfaces to accurately reflect underlying data quality and certainty."  },  "quickFixes": [    "Add data quality indicators to existing visualizations",    "Document known limitations in prominent locations",    "Create simplified 'most trusted' views with fewer but more reliable metrics",    "Clearly separate facts from interpretations"  ],  "relatedFrictions": [    "ci:antipattern.semantic-drift",    "ci:antipattern.metric-mirage"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:pattern.semantic-foundation",    "ci:antipattern.metric-mirage",    "ci:antipattern.semantic-drift"  ]}

json/anti-patterns/hero-syndrome.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.hero-syndrome",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Hero Syndrome"  },  "description": {    "en": "Critical operations dependent on specific individuals rather than system structure."  },  "tagline": {    "en": "Everything works fine as long as Sarah is here to fix it."  },  "symptoms": [    "Operations depend on specific individuals",    "Anxiety when key people take vacation",    "Long onboarding times as tribal knowledge transfers slowly",    "Resistance to system changes due to fragile understanding"  ],  "rootCause": {    "en": "Critical knowledge and process control exist in people's heads rather than system structure; operational complexity exceeds documentation; institutional memory substitutes for architectural clarity."  },  "impact": {    "en": "Scaling bottlenecks as hero capacity limits growth; burnout among critical individuals; retention risk with catastrophic knowledge loss potential; increasing workarounds as heroes compensate for structural issues."  },  "structuralCure": {    "en": "Implement knowledge externalization program to document tribal knowledge. Build structural memory through explicit process definitions and decision criteria. Create learning pathways that systematically distribute expertise. Apply Role-Structure Coherence to align responsibilities with supporting systems."  },  "quickFixes": [    "Implement pairing protocols to spread knowledge",    "Create 'break glass' runbooks for critical hero-dependent processes",    "Establish backup roles with scheduled rotation",    "Record hero problem-solving sessions for later reference"  ],  "relatedFrictions": [    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.ballup"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.role-structure-coherence",    "ci:antipattern.ballup",    "ci:antipattern.cognitive-amnesia"  ]}

json/anti-patterns/metastable-intelligence.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.metastable-intelligence",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Metastable Intelligence"  },  "description": {    "en": "Systems that appear intelligent and functional until stress reveals their hidden structural fragilities."  },  "definition": {    "en": "A pattern in which systems exhibit apparent functionality and intelligence while containing hidden architectural fragilities that make them prone to disproportionate or catastrophic degradation when subjected to stress, perturbation, or context change—creating an illusion of robustness that masks underlying structural weaknesses."  },  "principles": [    {      "name": "Compensatory Coherence",      "description": "The system achieves apparent coherence not through structural integrity but through compensatory mechanisms—typically heroic human effort, informal coordination, or excessive resource allocation—that mask underlying architectural disconnections."    },    {      "name": "False Redundancy",      "description": "The system appears to have redundant paths or capabilities, but these share hidden common dependencies or failure modes, creating the illusion of resilience while actually harboring systemic vulnerabilities."    },    {      "name": "Semantic Fragmentation",      "description": "While presenting a unified interface, the system contains inconsistent or conflicting definitional frameworks that function adequately in isolation but generate cascading contradictions when integrated or stressed."    },    {      "name": "Technical Debt Accumulation",      "description": "The system accumulates unaddressed technical or structural debt below the threshold of operational visibility, functioning normally until the accumulated debt crosses a critical threshold."    },    {      "name": "Context-Dependent Functionality",      "description": "The system functions reliably within a narrow set of conditions but lacks the architectural foundations to adapt to changing contexts, creating brittle rather than robust intelligence."    }  ],  "relatedConcepts": [    "ci:concept.structural-debt"  ],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/anti-patterns/metric-mirage.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.metric-mirage",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Metric Mirage"  },  "description": {    "en": "Measurements that don't influence behavior or drive adaptation despite comprehensive tracking."  },  "tagline": {    "en": "We track everything but nothing changes as a result."  },  "symptoms": [    "Proliferating metrics without corresponding improvement initiatives",    "Reports generated but rarely referenced in decision-making",    "Continued focus on metrics that haven't changed after extended measurement",    "Metrics that don't connect to action pathways",    "Growing measurement sophistication without growing system adaptation"  ],  "rootCause": {    "en": "Feedback loops that don't close—gathering data without connecting it to response mechanisms; metrics selected for ease of measurement rather than actionability; missing ownership of metric-driven improvement; measuring what's available instead of what matters."  },  "impact": {    "en": "Wasted effort on meaningless measurement; declining trust in data-driven approaches; growing cynicism about metrics programs; measurements that obscure rather than reveal system behavior; false sense of control while real issues go undetected."  },  "structuralCure": {    "en": "Implement Closed-Loop Feedback pattern linking each critical metric to specific action pathways. Create metric lifecycle management that regularly evaluates measurement relevance. Build feedback layer that explicitly incorporates learning mechanisms. Establish clearer ownership of metric-driven improvements."  },  "quickFixes": [    "Audit current metrics and prune those without clear influence on decisions",    "For key metrics, explicitly document desired actions based on different readings",    "Categorize metrics by actionability rather than domain",    "Add 'Last caused action on...' timestamp to measurement displays"  ],  "relatedFrictions": [    "ci:antipattern.dashboard-theater",    "ci:antipattern.cognitive-amnesia"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.epistemic-substrate-theory",    "ci:pattern.closed-loop-feedback",    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.dashboard-theater"  ]}

json/anti-patterns/over-layering.json

{    "@context": {      "ci": "https://cognitiveinfrastructure.org/schema#",      "rdfs": "http://www.w3.org/2000/01/rdf-schema#",      "schema": "http://schema.org/"    },    "@id": "ci:antipattern.over-layering",    "@type": "ci:AntiPattern",    "version": "1.0",    "label": {      "en": "Over-Layering"    },    "description": {      "en": "Accumulation of complexity layers without corresponding simplification or refactoring."    },    "tagline": {      "en": "It's incredibly sophisticated—if only someone still understood how it worked."    },    "symptoms": [      "Systems that no single person fully understands",      "Multiple overlapping technologies addressing similar concerns",      "Lengthy onboarding for new team members",      "Growing reluctance to modify core components",      "Increasing 'archeological' discussions to understand why things work as they do"    ],    "rootCause": {      "en": "Continuous addition of capabilities, technologies, and abstractions without corresponding simplification or removal; prioritization of feature delivery over architectural coherence; avoidance of refactoring due to perceived risk; accumulation of multiple approaches to similar problems."    },    "impact": {      "en": "Growing maintenance costs as complexity compounds; increasing brittleness as interactions between layers create unexpected behaviors; declining productivity as cognitive load exceeds human capacity; erosion of architectural integrity as original design principles become buried."    },    "structuralCure": {      "en": "Implement Layered Modularity pattern to clarify separation of concerns. Create architectural rubric for new capabilities that includes removal/simplification criteria. Invest in systematic refactoring to consolidate redundant layers. Develop clearer abstractions that encapsulate complexity appropriately."    },    "quickFixes": [      "Create system component map showing interaction points and complexity hotspots",      "Implement 'complexity budget' requiring simplification to accompany new features",      "Schedule regular tech debt reduction sprints",      "Document 'just enough' architecture to enable safe navigation of complex components"    ],    "relatedFrictions": [      "ci:antipattern.ballup",      "ci:antipattern.trigger-chaos"    ],    "createdDate": "2024-04-16",    "modifiedDate": "2024-04-16"  }

json/anti-patterns/semantic-drift.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.semantic-drift",  "@type": "ci:AntiPattern",  "version": "1.0",  "category": "antipattern",  "author": "Rashid Azarang",  "canonicalDate": "2024-04-10",  "label": {    "en": "Semantic Drift"  },  "description": {    "en": "The gradual divergence in meaning of key terms and concepts across teams, systems, and time."  },  "definition": {    "en": "Semantic Drift describes the gradual divergence in meaning of key terms and concepts across teams, systems, and time. This anti-pattern emerges when terms begin with shared understanding but evolve differently in separate contexts, causing increasing misalignment, communication failures, and integration challenges as differences compound over time."  },  "principles": [    {      "name": "Divergent Evolution",      "description": "Terms naturally evolve in different directions within isolated teams or systems."    },    {      "name": "Context Loss",      "description": "Original meaning context is forgotten as organizations change and evolve."    },    {      "name": "Translation Burden",      "description": "Increasing resources must be devoted to translating between divergent terminologies."    },    {      "name": "Trust Erosion",      "description": "Inconsistent term usage leads to declining trust in data and communication."    },    {      "name": "Integration Friction",      "description": "Systems with different semantic models require complex reconciliation."    }  ],  "relatedConcepts": [    "ci:pattern.canonical-ids",    "ci:pattern.semantic-foundation",    "ci:pattern.single-source-of-truth",    "ci:antipattern.cognitive-amnesia"  ],  "tags": [    "semantic",    "communication",    "integration",    "terminology"  ],  "symptoms": [    "Recurring disagreements about meaning of key terms",    "Different teams using same words to mean different things",    "Meetings where 'we need to get on the same page' repeatedly",    "Inconsistent reports showing different numbers for the same metric",    "Seemingly agreed decisions that result in divergent actions"  ],  "rootCause": {    "en": "Absence of canonical definitions for core business concepts; terminology evolving independently across different teams; inherited language from multiple legacy systems; inconsistent documentation that fails to express shared understanding."  },  "impact": {    "en": "Wasted time in definitional debates; frequent reconciliation efforts between systems; erosion of trust in operational reporting; broken cross-team handoffs; increased need for translational heroics between departments; delays in decision-making as teams resolve semantic misalignments."  },  "structuralCure": {    "en": "Implement Semantic Foundation pattern to establish canonical business language. Create an official business glossary with explicit versioning and governance. Develop clear ownership for key definitions and metrics. Build semantic alignment into system architecture through master data models. Design explicit translation mechanisms between legacy terminology and canonical definitions."  },  "quickFixes": [    "Start small with definitions for 5-10 most contested terms",    "Create a lightweight glossary for critical metrics",    "Document key term meanings at the top of reports",    "Include definitional footnotes in dashboards",    "Add semantic clarification sessions to cross-team handoffs"  ],  "relatedFrictions": [    "ci:antipattern.dashboard-theater",    "ci:antipattern.metric-mirage"  ],  "createdDate": "2024-04-10",  "modifiedDate": "2024-04-16"}

json/anti-patterns/toolification.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.toolification",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Toolification"  },  "description": {    "en": "Toolification is what happens when we grab another app instead of fixing the system."  },  "definition": {    "en": "A recurrent, system-level pattern in which structural friction is met with the rapid adoption of additional tools—software, platforms, automations—instead of architectural redesign. Toolification offers transient relief yet compounds hidden complexity: fragmented data, brittle integrations, logic dispersed across vendors, and deferred human learning. Epistemologically it signals a breakdown in the co-evolution of human and tool systems, substituting the illusion of progress for genuine clarity."  },  "author": "Rashid Azarang",  "language": "en",  "tags": [    "anti-patterns",    "architecture",    "system-design",    "technical-debt",    "complexity"  ],  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-17",  "principles": [    {      "name": "Compensatory Mechanism",      "description": "Toolification emerges as a reflexive response to structural friction, applying surface-level fixes through new applications rather than addressing root architectural issues."    },    {      "name": "Hidden Complexity Amplification",      "description": "Each added tool introduces its own data model, logic, and interface layers, compounding integration challenges and creating exponential growth in system complexity."    },    {      "name": "Cognitive De-Augmentation",      "description": "As tools proliferate faster than human understanding can integrate them, the supposed augmentation of capabilities inverts into a burden on collective sense-making."    },    {      "name": "Architectural Amnesia",      "description": "The rationale behind system design becomes increasingly obscured as logic is dispersed across numerous tools, configurations, and integrations, resisting coherent documentation."    },    {      "name": "Creation-Integration Imbalance",      "description": "Creating new tool instances becomes progressively easier than meaningfully integrating them into a coherent architecture, skewing incentives toward accumulation over rationalization."    }  ],  "relatedConcepts": []}

json/anti-patterns/trigger-chaos.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:antipattern.trigger-chaos",  "@type": "ci:AntiPattern",  "version": "1.0",  "label": {    "en": "Trigger Chaos"  },  "description": {    "en": "Complex automations operating through invisible logic creating unpredictable outcomes."  },  "tagline": {    "en": "Nobody knows exactly what happens when we press this button."  },  "symptoms": [    "Unexpected side effects from automated processes",    "Difficulty predicting system behavior in new conditions",    "Fear of modifying certain triggers or workflows",    "Incomplete documentation of automation logic",    "Surprise at what systems do automatically"  ],  "rootCause": {    "en": "Automation logic hidden across multiple systems; orchestration implemented without sufficient visibility or feedback; triggers that cascade unpredictably; lack of comprehensive understanding of interaction chains."  },  "impact": {    "en": "Increasing operational risk as system behavior becomes unpredictable; resistance to change due to fear of breaking hidden dependencies; expanding complexity as workarounds accommodate mysterious behavior; declining trust in automation."  },  "structuralCure": {    "en": "Implement explicit Orchestration layer with clear visibility of workflow logic. Create comprehensive trigger maps showing all cause-effect relationships. Implement Layered Modularity pattern to separate orchestration from execution. Build stronger feedback mechanisms that track automated decisions."  },  "quickFixes": [    "Create 'trigger inventory' documenting known automation points",    "Add logging to capture trigger execution and decision paths",    "Build simple visualization of automation dependencies",    "Establish sandbox environments for safely testing trigger behavior"  ],  "relatedFrictions": [    "ci:antipattern.ballup",    "ci:antipattern.over-layering"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": []}

json/core-concepts/clarity-laws.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.clarity-laws",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Clarity Laws"  },  "description": {    "en": "Empirical rules showing how weak layers cap capability."  },  "definition": {    "en": "Clarity Laws are empirical rules governing how operational systems behave, regardless of acknowledgment. They reveal structural constraints that determine capability limits, integration dynamics, and evolutionary potential across intelligence systems."  },  "principles": [    {      "name": "You don't rise above your weakest layer",      "description": "Operational capability is constrained by the least mature layer in your system. Advanced interfaces can't compensate for fragmented data; sophisticated automations can't overcome inconsistent logic."    },    {      "name": "Automation without architecture accelerates entropy at scale",      "description": "When processes lack architectural integrity, automation compounds problems rather than solving them, creating more exceptions than efficiencies."    },    {      "name": "Interfaces accelerate dysfunction if upstream layers are broken",      "description": "Dashboards and tools built atop weak foundations don't just fail to solve problems; they actively reinforce dysfunction by creating false confidence."    },    {      "name": "Feedback is not a report; it's whether the system learns",      "description": "Measurements that don't drive adaptation aren't feedback—they're noise."    },    {      "name": "Semantic alignment is a structural advantage",      "description": "Organizations where everyone agrees on what key terms mean operate with significantly less friction than those with semantic fragmentation."    }  ],  "relatedConcepts": [    "ci:concept.modal-layer-architecture",    "ci:concept.structural-debt"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/coherence-debt.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.coherence-debt",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Coherence Debt"  },  "description": {    "en": "Coherence Debt is what you owe when everyone uses the same words for different things."  },  "definition": {    "en": "The cumulative deficit in shared meaning, narrative alignment, and interpretive trust that arises when a system's data, language, or purpose diverges across its actors. It degrades decision quality and erodes collective intelligence even when the underlying mechanics still function."  },  "principles": [    {      "name": "Knowledge Externalization Deficit",      "description": "When shared meaning exists primarily in informal conversations rather than explicit structures, divergent interpretations proliferate across teams and time."    },    {      "name": "Process Formalization Gap",      "description": "Without documented semantic standards, glossaries, and feedback loops, language evolution occurs unevenly, creating hidden rifts in understanding."    },    {      "name": "Narrative Alignment Failure",      "description": "Strategic intent becomes fragmented as different teams operate with conflicting interpretations of goals, metrics, and priorities."    },    {      "name": "Interpretive Trust Breakdown",      "description": "As metrics return different values from different sources, data skepticism grows, eroding trust in the informational foundation needed for collaboration."    },    {      "name": "Decision Quality Degradation",      "description": "When people use the same terms to mean different things, the quality of cross-functional decisions degrades even while individual teams appear functional."    }  ],  "relatedConcepts": [],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/core-concepts/continuity-disruption-balance.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.continuity-disruption-balance",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Continuity-Disruption Balance"  },  "description": {    "en": "Framework for safe evolution without breaking trust."  },  "definition": {    "en": "Continuity-Disruption Balance addresses a fundamental tension in intelligent systems: the need to both preserve essential stability and enable necessary evolution, providing frameworks for determining where and how systems can change without collapsing."  },  "principles": [    {      "name": "Stability Thresholds",      "description": "Every system has a range within which it can adapt while maintaining coherence. Beyond this range, phase transitions occur—sometimes gradually, sometimes suddenly."    },    {      "name": "Dimensional Readiness",      "description": "The Continuity-Disruption Balance varies across three key dimensions: Domain Readiness (different functional areas), Change Type Readiness (categories of change), and Temporal Readiness (timing factors)."    },    {      "name": "Evolution Intensity",      "description": "Different types of change affect systems with varying intensity: Process Optimization (minimal disruption), Capability Enhancement (moderate disruption), Structural Reconfiguration (higher disruption), and Identity Transformation (maximum disruption)."    },    {      "name": "Targeted Transformation",      "description": "Change should be prioritized where pain is highest, return on investment is clearest, and stakeholder buy-in exists, rather than attempting comprehensive transformation."    }  ],  "relatedConcepts": [    "ci:concept.structural-debt",    "ci:concept.universal-evolutionary-stages"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/epistemic-substrate-theory.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.epistemic-substrate-theory",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Epistemic Substrate Theory"  },  "description": {    "en": "All intelligence operates upon hidden foundations that determine what can be known, connected, and evolved within that system."  },  "definition": {    "en": "The foundational architecture that determines the possible forms, connections, persistence, and evolution of knowledge within any system of intelligence, acting as an active matrix that shapes what forms of understanding can develop while rendering others structurally impossible."  },  "principles": [    {      "name": "Affordance Creation",      "description": "Each substrate creates specific cognitive affordances—possibilities for thought, memory, or understanding that are made available by its structure."    },    {      "name": "Constraint Imposition",      "description": "Substrates limit what forms of knowledge can emerge or persist, creating not merely practical but ontological constraints on understanding."    },    {      "name": "Pattern Reinforcement",      "description": "Substrates tend to privilege and reinforce certain patterns of thought or knowledge organization while suppressing others, creating path dependencies in cognitive evolution."    },    {      "name": "Visibility Filtering",      "description": "Substrates determine what aspects of reality become visible or invisible to the intelligence operating upon them, establishing perceptual boundaries by determining what can be registered as meaningful."    },    {      "name": "Recursive Self-Modification",      "description": "The capacity of a substrate to be modified by the knowledge it supports determines its evolutionary potential and adaptive capacity."    }  ],  "relatedConcepts": [],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/core-concepts/epistemophany.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.epistemophany",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Epistemophany"  },  "description": {    "en": "The moment when you suddenly see the structures that have been invisibly shaping your thinking."  },  "definition": {    "en": "The moment when a person or system perceives the structural architecture that has been shaping their understanding—a revelation of the previously invisible cognitive infrastructure that enables and constrains what can be known, triggering a recursive awareness that fundamentally changes how the system processes all subsequent information."  },  "principles": [    {      "name": "Infrastructure Revelation",      "description": "Epistemophany reveals the previously invisible cognitive foundations that have been shaping understanding, making the substrate of thought suddenly perceptible."    },    {      "name": "Recursive Awareness",      "description": "The system gains the ability to perceive its own perceptual structures, creating a feedback loop that allows for higher-order cognitive evolution."    },    {      "name": "Transformative Reframing",      "description": "After epistemophany, questions shift from content-focused to structure-focused, allowing for architectural rather than merely informational evolution."    },    {      "name": "Coherence Restructuring",      "description": "The revelation enables reorganization of knowledge based on deeper structural understanding rather than surface categorization."    },    {      "name": "Threshold Transition",      "description": "Epistemophany represents a non-linear shift in understanding—not incremental learning but a qualitative change in how learning itself occurs."    }  ],  "relatedConcepts": [],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/core-concepts/fiction-ontology.json

{    "@context": {      "ci": "https://cognitiveinfrastructure.org/schema#",      "rdfs": "http://www.w3.org/2000/01/rdf-schema#",      "schema": "http://schema.org/"    },    "@id": "ci:concept.friction-ontology",    "@type": "ci:Concept",    "version": "1.0",    "label": {      "en": "Friction Ontology"    },    "description": {      "en": "Taxonomy of recurring clarity frictions and their signals."    },    "definition": {      "en": "Friction Ontology catalogs recurring patterns where intelligence systems resist clarity, providing a diagnostic taxonomy to identify structural issues from their symptoms, root causes, and characteristic impacts across different contexts."    },    "principles": [      {        "name": "Frictions as Signals",        "description": "Each friction pattern indicates specific architectural tensions, not merely operational inefficiency. They reveal where evolution wants to occur."      },      {        "name": "Universal Recurrence",        "description": "These patterns manifest across vastly different domains and technologies because they emerge from fundamental structural properties rather than specific implementations."      },      {        "name": "Diagnostic Value",        "description": "Identifying the correct friction pattern provides immediate insight into appropriate remediation strategies and likely evolution paths."      },      {        "name": "Structural Transformation",        "description": "Permanent resolution requires addressing the underlying architectural pattern rather than superficial symptoms, typically involving rebalancing modal layers."      }    ],    "relatedConcepts": [      "ci:concept.structural-debt",      "ci:antipattern.ballup",      "ci:antipattern.dashboard-theater",      "ci:antipattern.semantic-drift",      "ci:antipattern.hero-syndrome",      "ci:antipattern.cognitive-amnesia",      "ci:antipattern.trigger-chaos",      "ci:antipattern.metric-mirage",      "ci:antipattern.over-layering"    ],    "createdDate": "2024-04-16",    "modifiedDate": "2024-04-16"  }

json/core-concepts/modal-layer.architecture.json

{    "@context": {      "ci": "https://cognitiveinfrastructure.org/schema#",      "rdfs": "http://www.w3.org/2000/01/rdf-schema#",      "schema": "http://schema.org/"    },    "@id": "ci:concept.modal-layer-architecture",    "@type": "ci:Concept",    "version": "1.0",    "label": {      "en": "Modal Layer Architecture"    },    "description": {      "en": "Five‑layer model that keeps operational intelligence evolvable."    },    "definition": {      "en": "Modal Layer Architecture separates operational intelligence into five cooperative layers—Data, Logic, Interface, Orchestration, Feedback—so each can evolve without breaking the others."    },    "principles": [      {        "name": "Separation of Concerns",        "description": "Each layer has a distinct purpose: Data establishes what exists, Logic determines what it means, Interface controls how it's presented, Orchestration manages how it flows, and Feedback enables how it learns."      },      {        "name": "Clear Contracts",        "description": "Layers communicate through well-defined interfaces, allowing internal implementation details to change without disrupting other layers."      },      {        "name": "Balanced Evolution",        "description": "System capability is constrained by the least mature layer; imbalances between layers create characteristic dysfunctions like 'Dashboard Theater' or 'Trigger Chaos.'"      }    ],    "relatedConcepts": [      "ci:concept.structure-memory-interaction"    ],    "createdDate": "2024-04-16",    "modifiedDate": "2024-04-16"  }

json/core-concepts/multi-axis-integration.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.multi-axis-integration",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Multi-Axis Integration"  },  "description": {    "en": "Vertical, horizontal, end-to-end coherence across structures."  },  "definition": {    "en": "Multi-Axis Integration addresses how intelligence must flow coherently across three dimensions: vertical (between levels of abstraction), horizontal (across functional domains), and end-to-end (through sequential processes) to maintain operational clarity."  },  "principles": [    {      "name": "Vertical Integration",      "description": "Connects levels of abstraction and authority within a domain, establishing how information flows up and down hierarchical structures, how decisions cascade, and how accountability aligns."    },    {      "name": "Horizontal Integration",      "description": "Spans across functional domains at similar levels of abstraction, enabling coordination between parallel capabilities, creating consistent experiences across boundaries, and facilitating collaborative work."    },    {      "name": "End-to-End Integration",      "description": "Links stages in sequential processes or lifecycles, ensuring that handoffs between phases preserve context and intent, and that earlier stages effectively enable later ones."    },    {      "name": "Balanced Development",      "description": "Improvement strategies must consider impacts across all three axes, as advancing one integration dimension often creates tensions in others unless deliberately managed."    }  ],  "relatedConcepts": [    "ci:concept.modal-layer-architecture",    "ci:concept.role-structure-coherence"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/return-as-intelligence.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.return-as-intelligence",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Return-as-Intelligence"  },  "description": {    "en": "Revisiting understanding is itself a generative cognitive act."  },  "definition": {    "en": "Return-as-Intelligence inverts conventional models by recognizing that revisiting, reengaging, and recontextualizing previous understanding is not merely maintenance but a core mechanism through which intelligence compounds and evolves."  },  "principles": [    {      "name": "From Capture to Return",      "description": "Shift design focus from efficient information collection to enabling meaningful reengagement, creating not just storage but retrieval architectures."    },    {      "name": "Strategic Revisitation",      "description": "Not all information warrants equal return investment; distinguish between reference material (needs findability) and evolutionary material (needs engagement pathways)."    },    {      "name": "Context Restoration",      "description": "Effective return requires restoring not just content but intention, constraints, and surrounding thought—the original frame that made information meaningful."    },    {      "name": "Layered Interaction",      "description": "Design for multiple return depths: quick reference (minimal context), deeper review (moderate restoration), and fundamental reengagement (complete reimmersion)."    },    {      "name": "Return Path Engineering",      "description": "Explicitly design the routes, triggers, and interfaces that enable return, treating them as core infrastructure rather than incidental features."    }  ],  "relatedConcepts": [    "ci:pattern.return-path-engineering"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/role-structure-coherence.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.role-structure-coherence",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Role-Structure Coherence"  },  "description": {    "en": "Alignment of responsibility with supporting scaffolding."  },  "definition": {    "en": "Role-Structure Coherence addresses the essential relationship between responsibilities assigned to individuals or teams and the supporting scaffolding that enables those functions—revealing where architecture must evolve to support changing roles."  },  "principles": [    {      "name": "Role Clarity vs. Rigidity",      "description": "Effective roles establish clear boundaries and expectations without constraining adaptation. Role clarity creates shared understanding about responsibilities and coordination; role rigidity creates brittle definitions that prevent evolution."    },    {      "name": "Common Mismatches",      "description": "Several patterns indicate role-structure incoherence: the Accountability-Authority Gap (responsibility without control), the Expertise-Information Mismatch (specialized roles without access to needed information), and the Boundary-Interface Disconnect (clear domains without defined interaction points)."    },    {      "name": "Coherent Evolution",      "description": "When roles or structures change, the corresponding element must evolve synchronously. New responsibilities require supporting infrastructure; new tools and processes require clear ownership and accountability."    },    {      "name": "Hero Dependency Remediation",      "description": "Converting individual-dependent processes into structurally supported systems requires externalizing tacit knowledge, creating structural memory, and developing transition paths that maintain capability while reducing dependency on specific individuals."    }  ],  "relatedConcepts": [    "ci:concept.multi-axis-integration",    "ci:antipattern.hero-syndrome"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/semantic-friction.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.semantic-friction",  "@type": "ci:Concept",  "version": "1.0",  "category": "concept",  "author": "Rashid Azarang",  "label": {    "en": "Semantic Friction"  },  "description": {    "en": "The resistance encountered when attempting to translate meaning across boundaries in knowledge systems."  },  "definition": {    "en": "Semantic Friction is the energy lost during information transfer due to inconsistent ontologies, divergent mental models, and misaligned conceptual frameworks. Unlike simple misunderstanding that can be resolved through clarification, semantic friction represents structural impedance in how different parts of a system fundamentally organize and interpret reality."  },  "principles": [    {      "name": "Ontological Misalignment",      "description": "Different domains often categorize and structure reality in fundamentally different ways, creating barriers to shared understanding."    },    {      "name": "Translation Loss",      "description": "Energy and meaning are lost when information crosses semantic boundaries, reducing fidelity and utility."    },    {      "name": "Scaling Impact",      "description": "Semantic friction compounds exponentially as systems and organizations grow, creating escalating coordination costs."    },    {      "name": "Boundary Costs",      "description": "Crossing knowledge boundaries requires structured translation processes that add overhead to collaboration."    },    {      "name": "Hidden Coordination Tax",      "description": "Semantic friction creates invisible transaction costs in communication that rarely appear in budgets but significantly impact productivity."    }  ],  "relatedConcepts": [    "ci:concept.coherence-debt",    "ci:concept.friction-ontology",    "ci:pattern.canonical-ids",    "ci:pattern.semantic-foundation",    "ci:antipattern.cognitive-amnesia"  ],  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/structural-debt.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.structure-debt",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Structure Debt"  },  "description": {    "en": "Structure Debt is the hidden mortgage on every quick-and-dirty fix to your system's backbone."  },  "definition": {    "en": "The accumulated liability created when a system's underlying architecture—its data models, process flows, component boundaries, and governance rules—drifts out of alignment with the purposes it must serve. The debt manifests as brittleness, redundancy, and escalating integration costs; like financial interest, its \"payments\" appear as growing effort to make even minor changes."  },  "principles": [    {      "name": "Architectural Misalignment",      "description": "The system's fundamental structures diverge from the core purposes they are meant to serve, creating cascading inconsistencies between intent and implementation."    },    {      "name": "Progressive Rigidification",      "description": "What begins as flexibility hardens into constraint as accretions of patched structure make even simple changes require complex coordination across multiple subsystems."    },    {      "name": "Integration Friction Acceleration",      "description": "The effort required to connect components grows non-linearly as structural inconsistencies compound, eventually dominating development and operational costs."    },    {      "name": "Feedback Obstruction",      "description": "Poorly structured systems make it difficult to trace cause and effect, obscuring the signals that would normally guide adaptation and improvement."    },    {      "name": "Emergent Liability Transfer",      "description": "Structure debt shifts liability from the system's visible mechanics to its invisible architecture, creating a gap between apparent stability and underlying fragility."    }  ],  "relatedConcepts": [],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/core-concepts/structural-receptivity.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.structural-receptivity",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Structural Receptivity"  },  "description": {    "en": "How well a system's architecture can absorb and integrate new knowledge without becoming fragmented or friction-laden."  },  "definition": {    "en": "A system's capacity to incorporate new knowledge into its architecture without fragmentation, measured by how effectively new information integrates with rather than accumulates alongside existing structures, maintaining or enhancing coherence while reducing rather than increasing friction over time."  },  "principles": [    {      "name": "Integration vs. Accumulation",      "description": "Receptive systems connect new knowledge to existing structures rather than merely piling information alongside them, creating enrichment rather than complexity."    },    {      "name": "Coherence Maintenance",      "description": "Systems with high receptivity preserve or enhance overall coherence when incorporating novelty rather than developing internal contradictions or fragmentation."    },    {      "name": "Friction Dynamics",      "description": "The effort required to incorporate new knowledge decreases rather than increases over time in receptive systems, indicating sustainable architectural evolution."    },    {      "name": "Boundary Permeability",      "description": "Receptive systems maintain semi-permeable boundaries that allow selective incorporation of valuable novelty while preventing disintegration."    },    {      "name": "Recursive Self-Modification",      "description": "Truly receptive systems can modify their own architecture in response to persistent novelty, evolving their structure rather than merely accommodating exceptions."    }  ],  "relatedConcepts": [],  "createdDate": "2025-04-17",  "modifiedDate": "2025-04-17"}

json/core-concepts/structure-memory-interaction.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.structure-memory-interaction",  "@type": "ci:Concept",  "version": "1.0",  "category": "concept",  "author": "Rashid Azarang",  "canonicalDate": "2024-04-10",  "label": {    "en": "Structure–Memory–Interaction Triad"  },  "description": {    "en": "The fundamental triad for usable intelligence—the architectural foundation enabling knowledge to remain clear, persistent over time, and capable of evolution."  },  "definition": {    "en": "The SMI Triad defines how usable intelligence emerges from three essential components: organization of information (Structure), ability to access past states (Memory), and systems that continuously refine understanding through usage patterns (Interaction). Together, these create the necessary conditions for knowledge systems that retain clarity, learn, and evolve coherently over time."  },  "principles": [    {      "name": "Structural Alignment",      "description": "Information architecture must reflect underlying reality to prevent semantic drift."    },    {      "name": "Return Accessibility",      "description": "Memory systems must make previous states accessible with minimal friction."    },    {      "name": "Integrative Interaction",      "description": "Usage patterns should recursively refine both structure and memory through closed feedback loops."    },    {      "name": "Coherence Conservation",      "description": "The three elements must maintain alignment to prevent information entropy."    },    {      "name": "Modal Separation",      "description": "Each component requires distinct design patterns yet must integrate seamlessly at boundaries."    }  ],  "relatedConcepts": [    "ci:concept.modal-layer-architecture",    "ci:concept.return-as-intelligence",    "ci:concept.structural-debt",    "ci:antipattern.semantic-drift"  ],  "tags": [    "foundational",    "architecture",    "intelligence"  ],  "createdDate": "2024-04-10",  "modifiedDate": "2024-04-16"}

json/core-concepts/test-concept.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.test-concept",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Test Concept"  },  "description": {    "en": "A demonstration of the CI-Writer workflow in the Cognitive Infrastructure framework, showing how knowledge can be efficiently generated, structured, and interconnected."  },  "definition": {    "en": "Test Concept represents a paradigm shift in how we create, maintain, and evolve documentation, serving as a bridge between human expertise and machine capabilities."  },  "principles": [    {      "en": "Automation: Using AI to accelerate content creation without sacrificing quality"    },    {      "en": "Structured Knowledge: Maintaining consistent formats across all documentation"    },    {      "en": "Interconnection: Ensuring concepts are properly linked and related"    }  ],  "relatedConcepts": [],  "canonicalDate": "2024-04-16",  "author": "Rashid Azarang",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/core-concepts/universal-evolutionary-stages.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.universal-evolutionary-stages",  "@type": "ci:Concept",  "version": "1.0",  "label": {    "en": "Universal Evolutionary Stages"  },  "description": {    "en": "Eight-stage ladder from fragmentation to integrated intelligence."  },  "definition": {    "en": "Universal Evolutionary Stages identify a recurring developmental sequence from pre-structural fragmentation through architectural standardization, semantic coherence, contextual adaptation, and ultimately to integrated intelligence—common across different domains of complexity."  },  "principles": [    {      "name": "Stage 0-2: Foundation Building",      "description": "Initially progressing from operational fog (fragmented, undocumented activity) through basic digitization to simple workflow automation, with emphasis on capturing and connecting information."    },    {      "name": "Stage 3-5: Architectural Coherence",      "description": "Advancing from scripted integration to structured data modeling and then semantic business logic, with focus on standardization, unified modeling, and consistent interpretation."    },    {      "name": "Stage 6-8: Adaptive Intelligence",      "description": "Evolving from composable services through contextual intelligence to adaptive systems, enabling flexible recombination, context-aware operation, and continuous learning."    },    {      "name": "Implementation Focus Shift",      "description": "As organizations progress through stages, emphasis shifts from component improvements to interface standardization and ultimately to architectural evolution."    }  ],  "relatedConcepts": [    "ci:concept.continuity-disruption-balance",    "ci:concept.modal-layer-architecture"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/ballup-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.ballup",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Ballup: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Ballup Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Ballup concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.ballup"  ],  "sourceFile": "docs/canonical-source-documents/ballup-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/cognitive-amnesia-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.cognitive-amnesia",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Cognitive Amnesia: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Cognitive Amnesia Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Cognitive Amnesia concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.cognitive-amnesia"  ],  "sourceFile": "docs/canonical-source-documents/cognitive-amnesia-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/coherence-debt-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.coherence-debt",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Coherence Debt: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Coherence Debt Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Coherence Debt concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.coherence-debt"  ],  "sourceFile": "docs/canonical-source-documents/coherence-debt-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/epistemic-substrate-theory-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.epistemic-substrate-theory",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Epistemic Substrate Theory: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Epistemic Substrate Theory Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Epistemic Substrate Theory concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.epistemic-substrate-theory"  ],  "sourceFile": "docs/canonical-source-documents/epistemic-substrate-theory-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/epistemophany-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.epistemophany",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Epistemophany: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Epistemophany Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Epistemophany concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.epistemophany"  ],  "sourceFile": "docs/canonical-source-documents/epistemophany-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/hero-structure-inverse-correlation-law-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.hero-structure-inverse-correlation-law",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Hero Structure Inverse Correlation Law: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Hero Structure Inverse Correlation Law Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Hero Structure Inverse Correlation Law concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.hero-structure-inverse-correlation-law"  ],  "sourceFile": "docs/canonical-source-documents/hero-structure-inverse-correlation-law-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/hero-syndrome-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.hero-syndrome",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Hero Syndrome: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Hero Syndrome Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Hero Syndrome concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.hero-syndrome"  ],  "sourceFile": "docs/canonical-source-documents/hero-syndrome-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/metastable-intelligence-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.metastable-intelligence",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Metastable Intelligence: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Metastable Intelligence Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Metastable Intelligence anti-pattern, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:antipattern.metastable-intelligence",    "ci:concept.hero-structure-inverse-correlation-law",    "ci:concept.epistemic-substrate-theory",    "ci:concept.structural-receptivity"  ],  "sourceFile": "docs/canonical-source-documents/metastable-intelligence-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/metric-mirage-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.metric-mirage",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Metric Mirage: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Metric Mirage Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Metric Mirage concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.metric-mirage"  ],  "sourceFile": "docs/canonical-source-documents/metric-mirage-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/semantic-friction-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.semantic-friction",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Semantic Friction: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Semantic Friction Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Semantic Friction concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.semantic-friction"  ],  "sourceFile": "docs/canonical-source-documents/semantic-friction-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/structural-receptivity-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.structural-receptivity",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Structural Receptivity: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Structural Receptivity Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Structural Receptivity concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.structural-receptivity"  ],  "sourceFile": "docs/canonical-source-documents/structural-receptivity-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/structure-debt-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.structure-debt",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Structure Debt: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Structure Debt Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Structure Debt concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.structure-debt"  ],  "sourceFile": "docs/canonical-source-documents/structure-debt-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/toolification-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.toolification",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Toolification: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Toolification Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Toolification concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.toolification"  ],  "sourceFile": "docs/canonical-source-documents/toolification-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/trigger-chaos-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.trigger-chaos",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Trigger Chaos: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Trigger Chaos Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Trigger Chaos concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.trigger-chaos"  ],  "sourceFile": "docs/canonical-source-documents/trigger-chaos-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/canonical-source-documents/universal-evolutionary-stages-canonical-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:canonical-source.universal-evolutionary-stages",  "@type": "ci:CanonicalSource",  "version": "1.0",  "title": "Universal Evolutionary Stages: Canonical Source",  "category": "canonical-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Universal Evolutionary Stages Canonical Source"  },  "description": {    "en": "Comprehensive exploration of the Universal Evolutionary Stages concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples."  },  "relatedConcepts": [    "ci:concept.universal-evolutionary-stages"  ],  "sourceFile": "docs/canonical-source-documents/universal-evolutionary-stages-canonical-source.md",  "documentStructure": {    "conceptualLayer": [      "Canonical Definition",      "One-line Summary",      "Contrast Map"    ],    "theoreticalLayer": [      "Foundational Thinkers",      "Epistemological Implications",      "OIF Placement"    ],    "diagnosticLayer": [      "Quick-scan Checklist",      "Severity Gradient",      "Example Vignettes"    ],    "linguisticLayer": [      "Various Forms",      "Cross-lingual Analogues",      "Subtype Taxonomy"    ],    "narrativeLayer": [      "Metaphors",      "Illustrative Scenes",      "Taglines"    ],    "culturalEconomicLayer": [      "Trend Dynamics",      "Cultural Narratives",      "Economic Mechanisms"    ]  },  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16"}

json/docs/source-documents/toolification-epistemological-source.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:epistemological-source.toolification",  "@type": "ci:EpistemologicalSource",  "version": "1.0",  "title": "Toolification: Epistemological Source",  "category": "epistemological-source",  "author": "Rashid Azarang",  "language": "en",  "label": {    "en": "Toolification Epistemological Source"  },  "description": {    "en": "Exploration of the epistemological foundations and implications of the Toolification anti-pattern, including research, external references, and broader context."  },  "relatedConcepts": [    "ci:antipattern.toolification",    "ci:concept.structural-debt",    "ci:concept.clarity-laws"  ],  "sourceFile": "docs/source-documents/toolification-epistemological-source.md",  "documentType": "epistemological",  "researchAreas": [    "Organizational Psychology",    "System Architecture",    "Knowledge Management"  ],  "externalReferences": [    {      "author": "Various researchers",      "title": "Studies on tool adoption patterns in organizations",      "year": "2015-2023",      "url": "https://example.com/tool-adoption-research"    }  ],  "canonicalDate": "2024-04-10",  "createdDate": "2024-04-10",  "modifiedDate": "2024-04-10"}

json/meta/ci-document-schema.json

{  "$schema": "http://json-schema.org/draft-07/schema#",  "title": "CI Document Schema",  "oneOf": [    { "$ref": "#/definitions/canonicalSource" },    { "$ref": "#/definitions/epistemologicalSource" }  ],  "definitions": {    "canonicalSource": {      "type": "object",      "required": ["@id", "@type", "title", "version", "author", "canonicalDate", "sourceFile"],      "properties": {        "@context": {          "type": "object",          "properties": {            "ci": { "type": "string" },            "rdfs": { "type": "string" },            "schema": { "type": "string" }          }        },        "@id": { "type": "string" },        "@type": { "type": "string", "enum": ["ci:CanonicalSource"] },        "version": { "type": "string" },        "title": { "type": "string" },        "category": { "type": "string", "enum": ["canonical-source"] },        "author": { "type": "string" },        "language": { "type": "string" },        "label": {          "type": "object",          "additionalProperties": { "type": "string" }        },        "description": {          "type": "object",          "additionalProperties": { "type": "string" }        },        "relatedConcepts": {          "type": "array",          "items": { "type": "string" }        },        "sourceFile": { "type": "string" },        "documentStructure": {          "type": "object",          "properties": {            "conceptualLayer": {              "type": "array",              "items": { "type": "string" }            },            "theoreticalLayer": {              "type": "array",              "items": { "type": "string" }            },            "diagnosticLayer": {              "type": "array",              "items": { "type": "string" }            },            "linguisticLayer": {              "type": "array",              "items": { "type": "string" }            },            "narrativeLayer": {              "type": "array",              "items": { "type": "string" }            },            "culturalEconomicLayer": {              "type": "array",              "items": { "type": "string" }            }          }        },        "canonicalDate": { "type": "string", "format": "date" },        "createdDate": { "type": "string", "format": "date" },        "modifiedDate": { "type": "string", "format": "date" }      }    },    "epistemologicalSource": {      "type": "object",      "required": ["@id", "@type", "title", "version", "author", "canonicalDate", "sourceFile"],      "properties": {        "@context": {          "type": "object",          "properties": {            "ci": { "type": "string" },            "rdfs": { "type": "string" },            "schema": { "type": "string" }          }        },        "@id": { "type": "string" },        "@type": { "type": "string", "enum": ["ci:EpistemologicalSource"] },        "version": { "type": "string" },        "title": { "type": "string" },        "category": { "type": "string", "enum": ["epistemological-source"] },        "author": { "type": "string" },        "language": { "type": "string" },        "label": {          "type": "object",          "additionalProperties": { "type": "string" }        },        "description": {          "type": "object",          "additionalProperties": { "type": "string" }        },        "relatedConcepts": {          "type": "array",          "items": { "type": "string" }        },        "sourceFile": { "type": "string" },        "documentType": { "type": "string", "enum": ["epistemological"] },        "researchAreas": {          "type": "array",          "items": { "type": "string" }        },        "externalReferences": {          "type": "array",          "items": {            "type": "object",            "required": ["author", "title"],            "properties": {              "author": { "type": "string" },              "title": { "type": "string" },              "year": { "type": "string" },              "url": { "type": "string" },              "doi": { "type": "string" }            }          }        },        "canonicalDate": { "type": "string", "format": "date" },        "createdDate": { "type": "string", "format": "date" },        "modifiedDate": { "type": "string", "format": "date" }      }    }  }}

json/meta/ci-schema.json

{    "$schema": "http://json-schema.org/draft-07/schema#",    "title": "CI Core Schema",    "oneOf": [      { "$ref": "#/definitions/concept" },      { "$ref": "#/definitions/pattern" },      { "$ref": "#/definitions/antiPattern" }    ],    "definitions": {      "concept": {        "type": "object",        "required": ["@id", "@type", "label", "version"],        "properties": {          "@context": {            "type": "object",            "properties": {              "ci": { "type": "string" },              "rdfs": { "type": "string" },              "schema": { "type": "string" }            }          },          "@id": { "type": "string" },          "@type": { "type": "string", "enum": ["ci:Concept"] },          "version": { "type": "string" },          "title": { "type": "string" },          "category": { "type": "string", "enum": ["concept"] },          "author": { "type": "string" },          "language": { "type": "string" },          "label": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "description": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "definition": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "principles": {            "type": "array",            "items": {              "type": "object",              "required": ["name", "description"],              "properties": {                "name": { "type": "string" },                "description": { "type": "string" }              }            }          },          "tags": {            "type": "array",            "items": { "type": "string" }          },          "relatedConcepts": {            "type": "array",            "items": { "type": "string" }          },          "related_documents": {            "type": "array",            "items": { "type": "string" }          },          "canonicalDate": { "type": "string", "format": "date" },          "canonical_date": { "type": "string", "format": "date" },          "createdDate": { "type": "string", "format": "date" },          "modifiedDate": { "type": "string", "format": "date" },          "pdf_version": { "type": "boolean" }        }      },      "pattern": {        "type": "object",        "required": ["@id", "@type", "label", "version"],        "properties": {          "@context": {            "type": "object",            "properties": {              "ci": { "type": "string" },              "rdfs": { "type": "string" },              "schema": { "type": "string" }            }          },          "@id": { "type": "string" },          "@type": { "type": "string", "enum": ["ci:Pattern"] },          "version": { "type": "string" },          "title": { "type": "string" },          "category": { "type": "string", "enum": ["pattern"] },          "author": { "type": "string" },          "language": { "type": "string" },          "label": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "description": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "definition": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "principles": {            "type": "array",            "items": {              "type": "object",              "required": ["name", "description"],              "properties": {                "name": { "type": "string" },                "description": { "type": "string" }              }            }          },          "tags": {            "type": "array",            "items": { "type": "string" }          },          "relatedConcepts": {            "type": "array",            "items": { "type": "string" }          },          "related_documents": {            "type": "array",            "items": { "type": "string" }          },          "canonicalDate": { "type": "string", "format": "date" },          "canonical_date": { "type": "string", "format": "date" },          "createdDate": { "type": "string", "format": "date" },          "modifiedDate": { "type": "string", "format": "date" },          "pdf_version": { "type": "boolean" }        }      },      "antiPattern": {        "type": "object",        "required": ["@id", "@type", "label", "version"],        "properties": {          "@context": {            "type": "object",            "properties": {              "ci": { "type": "string" },              "rdfs": { "type": "string" },              "schema": { "type": "string" }            }          },          "@id": { "type": "string" },          "@type": { "type": "string", "enum": ["ci:AntiPattern"] },          "version": { "type": "string" },          "title": { "type": "string" },          "category": { "type": "string", "enum": ["antipattern"] },          "author": { "type": "string" },          "language": { "type": "string" },          "label": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "description": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "definition": {            "type": "object",            "additionalProperties": { "type": "string" }          },          "principles": {            "type": "array",            "items": {              "type": "object",              "required": ["name", "description"],              "properties": {                "name": { "type": "string" },                "description": { "type": "string" }              }            }          },          "tags": {            "type": "array",            "items": { "type": "string" }          },          "relatedConcepts": {            "type": "array",            "items": { "type": "string" }          },          "related_documents": {            "type": "array",            "items": { "type": "string" }          },          "canonicalDate": { "type": "string", "format": "date" },          "canonical_date": { "type": "string", "format": "date" },          "createdDate": { "type": "string", "format": "date" },          "modifiedDate": { "type": "string", "format": "date" },          "pdf_version": { "type": "boolean" }        }      }    }  }

json/patterns/canonical-ids.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.canonical-ids",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Canonical IDs"  },  "description": {    "en": "Create stable, globally unique identifiers for entities and concepts that transcend specific systems."  },  "intent": {    "en": "Create stable, globally unique identifiers for entities and concepts that transcend specific systems."  },  "context": {    "en": "Multi-system environments, data integration requirements, entity disambiguation needs, long-lived digital records."  },  "problem": {    "en": "Entities are identified differently across systems, creating reconciliation challenges, potential duplicates, and an inability to track items across their lifecycle."  },  "forces": {    "en": "System-specific ID requirements, legacy identification schemes, performance considerations for lookups, governance complexity."  },  "solution": {    "en": "Implement a stable ID architecture with: 1) system-agnostic IDs managed in a central registry, 2) structured format with namespaces and entity types, 3) immutable assignment policy, and 4) bidirectional mappings to local system identifiers. Publish ID resolution services accessible across organizational boundaries."  },  "resultingContext": {    "en": "Reliable entity tracking across system boundaries; foundation for comprehensive entity timelines; reduced integration complexity; elimination of identity resolution as a recurring challenge."  },  "successSignals": [    "Decreasing entity resolution exceptions",    "Stable references in long-running processes",    "Elimination of 'which customer is this?' type questions",    "Ability to track entity state changes across system boundaries"  ],  "preventedAntiPatterns": [    "ci:antipattern.semantic-drift",    "ci:antipattern.dashboard-theater"  ],  "relatedPatterns": [    "ci:pattern.single-source-of-truth",    "ci:pattern.semantic-foundation"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:pattern.semantic-foundation",    "ci:pattern.single-source-of-truth",    "ci:antipattern.dashboard-theater",    "ci:antipattern.semantic-drift"  ]}

json/patterns/closed-loop-feedback.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.closed-loop-feedback",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Closed-Loop Feedback"  },  "description": {    "en": "Design measurement systems that immediately inform adjustments through clear action pathways."  },  "intent": {    "en": "Design measurement systems that immediately inform adjustments through clear action pathways."  },  "context": {    "en": "Complex operational environments; continuous improvement programs; autonomous or semi-autonomous systems; dynamic market conditions."  },  "problem": {    "en": "Measurements exist but don't influence behavior; metrics are collected but not actioned; feedback cycles are too slow to prevent recurring issues."  },  "forces": {    "en": "Measurement vs. action orientation, lag time in traditional reporting, organizational silos, unclear ownership of response protocols, incentive misalignment."  },  "solution": {    "en": "For each critical metric, establish: 1) clear intervention thresholds, 2) predefined response protocols, 3) explicit ownership of action, and 4) verification mechanisms to confirm intervention effectiveness. Design feedback visualizations that incorporate both measure and response as a unified view."  },  "resultingContext": {    "en": "Self-regulating operational systems that respond to changes without manual coordination; continuous improvement driven by actual outcomes rather than planned initiatives; reduced firefighting as issues are addressed at earlier stages."  },  "successSignals": [    "Declining time-to-correction for detected issues",    "Increasing percentage of corrections made without escalation",    "Declining variance in key performance metrics",    "Feedback mechanisms evolve based on effectiveness measurement"  ],  "preventedAntiPatterns": [    "ci:antipattern.metric-mirage",    "ci:antipattern.cognitive-amnesia"  ],  "relatedPatterns": [    "ci:concept.friction-ontology",    "ci:concept.modal-layer-architecture"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.friction-ontology",    "ci:concept.modal-layer-architecture",    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.metric-mirage"  ]}

json/patterns/hero-structure-inverse-correlation-law.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:concept.hero-structure-inverse-correlation-law",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Hero-Structure Inverse Correlation Law"  },  "description": {    "en": "The more your system depends on heroes, the weaker your underlying structure—and vice versa."  },  "definition": {    "en": "The fundamental relationship where the operational dependence on individual heroism within a system is inversely proportional to the structural maturity of that system (H = k/S), creating a mathematically expressible pattern in which heroic intervention decreases as structural integrity increases across diverse contexts from small teams to large organizations, from simple workflows to complex technological ecosystems."  },  "author": "Rashid Azarang",  "language": "en",  "tags": [    "patterns",    "architecture",    "organizational-design",    "system-maturity",    "hero-dependency"  ],  "canonicalDate": "2024-04-16",  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-17",  "principles": [    {      "name": "Knowledge Externalization Deficit",      "description": "When operational knowledge exists primarily in individuals' minds rather than in explicit structures, those individuals become irreplaceable heroes whose absence creates system fragility."    },    {      "name": "Process Formalization Gap",      "description": "Where formal processes are inadequate, incomplete, or poorly designed, heroes emerge to bridge gaps through improvisation, institutional memory, and exceptional effort."    },    {      "name": "Exception Handling Displacement",      "description": "Immature systems lack robust exception handling mechanisms, requiring heroes to manage anomalies, edge cases, and unexpected situations through personal intervention."    },    {      "name": "Coordination Overhead Absorption",      "description": "In the absence of structural coordination mechanisms, heroes absorb the cognitive and operational burden of maintaining connections between system components."    },    {      "name": "Quality Control Compensation",      "description": "When structural quality assurance is insufficient, heroes compensate through vigilance, manual checking, and remedial interventions."    }  ],  "relatedConcepts": []}

json/patterns/layered-modularity.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.layered-modularity",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Layered Modularity"  },  "description": {    "en": "Align system boundaries with the five Modal Layers for independent evolution."  },  "intent": {    "en": "Align system boundaries with the five Modal Layers so each can evolve independently."  },  "context": {    "en": "Complex systems with rapid change requirements, cross-functional teams, growing technical debt."  },  "problem": {    "en": "Interleaved concerns make safe refactoring impossible; changes to interfaces require rebuilding business logic; data structure changes break visualizations."  },  "forces": {    "en": "Time-to-market pressure vs. architectural integrity, team specialization, legacy system constraints, incremental funding models."  },  "solution": {    "en": "Enforce clear ownership boundaries around each Modal Layer. Ensure interfaces only cross adjacent layers through well-defined contracts. Allow specialized teams to optimize within layers while maintaining strict cross-layer protocols."  },  "resultingContext": {    "en": "Predictable change surface with isolated impacts; simpler mental models for each layer; reduced cross-team dependencies; foundation for continuous evolution without system-wide rewrites."  },  "successSignals": [    "Deployment diffs rarely touch more than one layer",    "Reduced integration testing time",    "Ability to replace components within layers without disrupting others",    "Declining emergency fix frequency"  ],  "preventedAntiPatterns": [    "ci:antipattern.over-layering",    "ci:antipattern.trigger-chaos"  ],  "relatedPatterns": [    "ci:concept.modal-layer-architecture"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.modal-layer-architecture",    "ci:antipattern.trigger-chaos"  ]}

json/patterns/progressive-typing.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.progressive-typing",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Progressive Typing"  },  "description": {    "en": "Begin with flexible data structures that tighten as understanding grows, balancing exploration with eventual consistency."  },  "intent": {    "en": "Begin with flexible data structures that tighten as understanding grows, balancing exploration with eventual consistency."  },  "context": {    "en": "Emerging domains with evolving understanding; initial implementations of data models; knowledge work systems; exploration-oriented tools."  },  "problem": {    "en": "Premature type rigidity prevents discovery and adaptation, while permanent looseness creates inconsistency and unreliability."  },  "forces": {    "en": "Exploration needs vs. consistency requirements, unknown future use cases, varying skill levels among contributors, knowledge emergence patterns."  },  "solution": {    "en": "Design data structures with explicit evolutionary stages: 1) start with schema-flexible formats that capture raw information, 2) identify recurring patterns through regular analysis, 3) formalize schema elements as patterns stabilize, 4) gradually increase validation requirements as understanding solidifies."  },  "resultingContext": {    "en": "Balance between exploration freedom and structural reliability; data models that evolve with understanding rather than constraining it; reduced need for disruptive migrations; natural knowledge formalization paths."  },  "successSignals": [    "Decreasing schema change frequency over time",    "Data validation exceptions cluster around emerging concepts rather than established ones",    "Reduced friction in both early exploration and mature usage",    "Clear evolutionary history visible in data structures"  ],  "preventedAntiPatterns": [    "ci:antipattern.ballup",    "ci:antipattern.over-layering"  ],  "relatedPatterns": [    "ci:concept.universal-evolutionary-stages",    "ci:concept.continuity-disruption-balance"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.continuity-disruption-balance",    "ci:concept.universal-evolutionary-stages",    "ci:antipattern.ballup"  ]}

json/patterns/return-path-engineering.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.return-path-engineering",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Return Path Engineering"  },  "description": {    "en": "Design explicit routes back to previous knowledge and contexts, enabling compound intelligence through revisitation."  },  "intent": {    "en": "Design explicit routes back to previous knowledge and contexts, enabling compound intelligence through revisitation."  },  "context": {    "en": "Knowledge management systems, documentation repositories, organizational learning initiatives, complex collaborative environments."  },  "problem": {    "en": "Information is captured but rarely revisited meaningfully; context gets lost between sessions; teams solve the same problems repeatedly without building on previous solutions."  },  "forces": {    "en": "Recency bias in tool design, initial capture orientation, weak contextual restoration mechanisms, time pressure favoring new creation over revisitation."  },  "solution": {    "en": "Create deliberate return infrastructure: 1) contextual bookmarks that preserve full work state, 2) spaced review triggers based on knowledge lifecycle, 3) entry point designs that restore intention not just content, and 4) revisitation metrics that make return pathways visible and improvable."  },  "resultingContext": {    "en": "Knowledge that compounds rather than just accumulates; reduced solution reinvention; increased depth of understanding through recursive engagement; continuity of thinking across time gaps."  },  "successSignals": [    "Increasing revisitation/creation ratio",    "Declining 'rediscovery time' for previous work",    "Reduced duplication of solutions",    "Growing interconnection density in knowledge repositories",    "Evidence of ideas evolving through multiple revisitation cycles"  ],  "preventedAntiPatterns": [    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.metric-mirage"  ],  "relatedPatterns": [    "ci:concept.return-as-intelligence",    "ci:concept.structure-memory-interaction"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:concept.return-as-intelligence",    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.metric-mirage"  ]}

json/patterns/semantic-foundation.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.semantic-foundation",  "@type": "ci:Pattern",  "version": "1.0",  "category": "pattern",  "author": "Rashid Azarang",  "canonicalDate": "2024-04-10",  "label": {    "en": "Semantic Foundation"  },  "description": {    "en": "Establishes shared definitions and conceptual models before automating processes or building systems."  },  "definition": {    "en": "The Semantic Foundation pattern establishes shared definitions and conceptual models before automating processes or building systems. It ensures all stakeholders operate from common understanding, preventing misalignment and semantic drift as complexity increases. This pattern prioritizes definitional clarity as infrastructure rather than as documentation added later."  },  "principles": [    {      "name": "Core Concept Identification",      "description": "Map the essential entities and relationships that form your domain."    },    {      "name": "Canonical Definition Creation",      "description": "Establish precise, stable definitions with examples and counterexamples."    },    {      "name": "Relationship Modeling",      "description": "Define how concepts relate to each other through hierarchies and dependencies."    },    {      "name": "Governance Process Establishment",      "description": "Define how definitions evolve and who maintains semantic authority."    },    {      "name": "Visibility Emphasis",      "description": "Make this foundation accessible and visible, not buried in documentation."    }  ],  "relatedConcepts": [    "ci:pattern.canonical-ids",    "ci:pattern.single-source-of-truth",    "ci:antipattern.semantic-drift"  ],  "tags": [    "semantic",    "foundation",    "definitions",    "clarity"  ],  "createdDate": "2024-04-10",  "modifiedDate": "2024-04-16"}

json/patterns/single-source-of-truth.json

{  "@context": {    "ci": "https://cognitiveinfrastructure.org/schema#",    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",    "schema": "http://schema.org/"  },  "@id": "ci:pattern.single-source-of-truth",  "@type": "ci:Pattern",  "version": "1.0",  "label": {    "en": "Single Source of Truth"  },  "description": {    "en": "Establish authoritative entity records from which all others derive."  },  "intent": {    "en": "Establish authoritative entity records from which all other representations derive."  },  "context": {    "en": "Multiple systems tracking the same entities; distributed teams; reporting inconsistencies; high data reconciliation costs."  },  "problem": {    "en": "Same entity exists in multiple systems with conflicting attributes, creating reconciliation burdens and eroding trust in operational data."  },  "forces": {    "en": "System specialization needs vs. data integrity, distributed ownership models, history of siloed development, performance requirements for local data."  },  "solution": {    "en": "Designate one system as the authoritative record for each entity type. Create clear data ownership model with published SLAs. Implement synchronization mechanisms where other systems need local copies, with explicit freshness metadata and lineage tracking."  },  "resultingContext": {    "en": "Clear resolution path for data conflicts; reduced reconciliation effort; foundation for reliable analytics; trust in system data improves operational decision quality."  },  "successSignals": [    "Entity lookups converge to same result regardless of starting system",    "Reduced time spent reconciling conflicting records",    "Declining duplicate entity counts",    "Increased reference to canonical sources in reporting"  ],  "preventedAntiPatterns": [    "ci:antipattern.semantic-drift",    "ci:antipattern.cognitive-amnesia"  ],  "relatedPatterns": [    "ci:pattern.canonical-ids",    "ci:pattern.semantic-foundation"  ],  "createdDate": "2024-04-16",  "modifiedDate": "2024-04-16",  "relatedConcepts": [    "ci:pattern.canonical-ids",    "ci:pattern.semantic-foundation",    "ci:antipattern.cognitive-amnesia",    "ci:antipattern.semantic-drift"  ]}

ontology.json

{  "concepts": [    {      "@id": "ci:concept.structural-debt",      "category": "Diagnostic Concept",      "layer": ["Interface", "Orchestration", "Feedback"],      "maturity": ["Level 3", "Level 4"],      "description": "Accumulated cost of misaligned operational architecture",      "canonicalSource": "docs/canonical-source-documents/structure-debt-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.structure-memory-interaction",      "category": "Architectural Pattern",      "layer": ["Data", "Logic", "Interface"],      "maturity": ["Level 2", "Level 3", "Level 4"],      "description": "Fundamental triad enabling persistent, evolvable intelligence",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.role-structure-coherence",      "category": "Architectural Pattern",      "layer": ["Logic", "Orchestration"],      "maturity": ["Level 3", "Level 4"],      "description": "Alignment of responsibility with supporting scaffolding",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.friction-ontology",      "category": "Diagnostic Framework",      "layer": ["Logic", "Interface", "Feedback"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "Taxonomy of recurring clarity frictions and their signals",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.return-as-intelligence",      "category": "Epistemological Construct",      "layer": ["Logic", "Interface", "Feedback"],      "maturity": ["Level 4", "Level 5"],      "description": "Revisiting understanding is itself a generative cognitive act",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.universal-evolutionary-stages",      "category": "Developmental Framework",      "layer": ["Data", "Logic", "Interface", "Orchestration", "Feedback"],      "maturity": ["Level 0", "Level 1", "Level 2", "Level 3", "Level 4", "Level 5", "Level 6", "Level 7", "Level 8"],      "description": "Eight-stage ladder from fragmentation to integrated intelligence",      "canonicalSource": "docs/canonical-source-documents/universal-evolutionary-stages-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.multi-axis-integration",      "category": "Architectural Pattern",      "layer": ["Data", "Logic", "Orchestration"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "Vertical, horizontal, end-to-end coherence across structures",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.continuity-disruption-balance",      "category": "Developmental Framework",      "layer": ["Logic", "Orchestration", "Feedback"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "Framework for safe evolution without breaking trust",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.clarity-laws",      "category": "Epistemological Construct",      "layer": ["Data", "Logic", "Interface", "Orchestration", "Feedback"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "Empirical rules showing how weak layers cap capability",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.modal-layer-architecture",      "category": "Architectural Pattern",      "layer": ["Data", "Logic", "Interface", "Orchestration", "Feedback"],      "maturity": ["Level 2", "Level 3", "Level 4"],      "description": "Five‑layer model that keeps operational intelligence evolvable",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.hero-structure-inverse-correlation-law",      "category": "Architectural Pattern",      "layer": ["Logic", "Orchestration"],      "maturity": ["Level 3", "Level 4"],      "description": "Operational dependence on heroism inversely proportional to structural maturity",      "canonicalSource": "docs/canonical-source-documents/hero-structure-inverse-correlation-law-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.coherence-debt",      "category": "Diagnostic Concept",      "layer": ["Logic", "Interface", "Feedback"],      "maturity": ["Level 3", "Level 4"],      "description": "Cumulative deficit in shared meaning and interpretive trust",      "canonicalSource": "docs/canonical-source-documents/coherence-debt-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.epistemophany",      "category": "Diagnostic Concept",      "layer": ["Logic", "Feedback"],      "maturity": ["Level 4", "Level 5"],      "description": "Moment when a system perceives the architecture shaping its understanding",      "canonicalSource": "docs/canonical-source-documents/epistemophany-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.epistemic-substrate-theory",      "category": "Diagnostic Framework",      "layer": ["Data", "Logic", "Interface"],      "maturity": ["Level 4", "Level 5"],      "description": "Foundational architecture determining possible forms of knowledge",      "canonicalSource": "docs/canonical-source-documents/epistemic-substrate-theory-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.structural-receptivity",      "category": "Diagnostic Concept",      "layer": ["Data", "Logic"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "System's capacity to incorporate new knowledge without fragmentation",      "canonicalSource": "docs/canonical-source-documents/structural-receptivity-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.canonical-ids",      "category": "Implementation Pattern",      "layer": ["Data", "Logic"],      "maturity": ["Level 3", "Level 4"],      "description": "Stable, globally unique identifiers that transcend specific systems",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.closed-loop-feedback",      "category": "Implementation Pattern",      "layer": ["Logic", "Feedback"],      "maturity": ["Level 4", "Level 5"],      "description": "Measurement systems that immediately inform adjustments",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.layered-modularity",      "category": "Implementation Pattern",      "layer": ["Data", "Logic", "Interface", "Orchestration", "Feedback"],      "maturity": ["Level 3", "Level 4"],      "description": "System boundaries aligned with Modal Layers for independent evolution",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.progressive-typing",      "category": "Implementation Pattern",      "layer": ["Data", "Logic"],      "maturity": ["Level 2", "Level 3", "Level 4"],      "description": "Flexible data structures that tighten as understanding grows",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.return-path-engineering",      "category": "Implementation Pattern",      "layer": ["Logic", "Interface", "Feedback"],      "maturity": ["Level 3", "Level 4", "Level 5"],      "description": "Explicit routes back to previous knowledge enabling compound intelligence",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.semantic-foundation",      "category": "Implementation Pattern",      "layer": ["Data", "Logic"],      "maturity": ["Level 3", "Level 4"],      "description": "Unified definitions creating consistent meaning across systems",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:pattern.single-source-of-truth",      "category": "Implementation Pattern",      "layer": ["Data", "Logic"],      "maturity": ["Level 3", "Level 4"],      "description": "Authoritative entity records from which all others derive",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.ballup",      "category": "Anti-Pattern",      "layer": ["Orchestration", "Feedback"],      "maturity": ["Level 2", "Level 3"],      "description": "Chronic recurring issues despite repeated attempts to fix them",      "canonicalSource": "docs/canonical-source-documents/ballup-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.cognitive-amnesia",      "category": "Anti-Pattern",      "layer": ["Logic", "Feedback"],      "maturity": ["Level 2", "Level 3"],      "description": "Organizations repeatedly solving the same problems",      "canonicalSource": "docs/canonical-source-documents/cognitive-amnesia-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.dashboard-theater",      "category": "Anti-Pattern",      "layer": ["Interface", "Feedback"],      "maturity": ["Level 2", "Level 3"],      "description": "Impressive visualizations masking underlying data weakness",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.hero-syndrome",      "category": "Anti-Pattern",      "layer": ["Logic", "Orchestration"],      "maturity": ["Level 2", "Level 3"],      "description": "Operations dependent on specific individuals rather than structure",      "canonicalSource": "docs/canonical-source-documents/hero-syndrome-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.metastable-intelligence",      "category": "Anti-Pattern",      "layer": ["Data", "Logic", "Interface", "Orchestration"],      "maturity": ["Level 2", "Level 3", "Level 4"],      "description": "Systems appearing functional until stress reveals structural fragilities",      "canonicalSource": "docs/canonical-source-documents/metastable-intelligence-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.semantic-drift",      "category": "Anti-Pattern",      "layer": ["Data", "Logic"],      "maturity": ["Level 2", "Level 3"],      "description": "Divergence of terminology meaning across teams and systems",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.toolification",      "category": "Anti-Pattern",      "layer": ["Interface", "Orchestration"],      "maturity": ["Level 2", "Level 3"],      "description": "Adopting tools instead of addressing architectural issues",      "canonicalSource": "docs/canonical-source-documents/toolification-canonical-source.md",      "epistemologicalSource": "docs/source-documents/toolification-epistemological-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.trigger-chaos",      "category": "Anti-Pattern",      "layer": ["Orchestration", "Feedback"],      "maturity": ["Level 2", "Level 3"],      "description": "Complex automations with invisible logic creating unpredictable outcomes",      "canonicalSource": "docs/canonical-source-documents/trigger-chaos-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:concept.semantic-friction",      "category": "Concept",      "layer": ["Logic", "Interface"],      "maturity": ["Level 3", "Level 4"],      "description": "Resistance encountered when translating meaning across boundaries",      "canonicalSource": "docs/canonical-source-documents/semantic-friction-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    },    {      "@id": "ci:antipattern.metric-mirage",      "category": "Anti-Pattern",      "layer": ["Interface", "Feedback"],      "maturity": ["Level 3", "Level 4"],      "description": "Measurements proliferate without influencing behavior or driving adaptation",      "canonicalSource": "docs/canonical-source-documents/metric-mirage-canonical-source.md",      "author": "Rashid Azarang",      "canonicalDate": "2024-04-16"    }  ],  "documentTypes": [    {      "type": "canonicalSource",      "description": "Comprehensive, definitive treatment of a concept providing full context, theoretical underpinnings, and detailed examples",      "location": "docs/canonical-source-documents/"    },    {      "type": "epistemologicalSource",      "description": "Research documents with external references rather than definitive concept descriptions",      "location": "docs/source-documents/"    }  ]}

scripts/ensure-json-files.js

#!/usr/bin/env node/** * Script to ensure all canonical source documents and epistemological source documents * have corresponding JSON files. * * Usage: node scripts/ensure-json-files.js */const fs = require('fs');const path = require('path');// Directories to checkconst CANONICAL_DOC_DIR = 'docs/canonical-source-documents';const EPISTEMOLOGICAL_DOC_DIR = 'docs/source-documents';const JSON_CANONICAL_DIR = 'json/docs/canonical-source-documents';const JSON_EPISTEMOLOGICAL_DIR = 'json/docs/source-documents';// Create directories if they don't exist[JSON_CANONICAL_DIR, JSON_EPISTEMOLOGICAL_DIR].forEach(dir => {
  if (!fs.existsSync(dir)) {
    fs.mkdirSync(dir, { recursive: true });    console.log(`Created directory: ${dir}`);  }
});// Template for canonical source JSONfunction createCanonicalSourceJSON(filename, docPath) {
  // Extract the concept name from the filename  const baseName = path.basename(filename, '-canonical-source.md');  return {
    "@context": {
      "ci": "https://cognitiveinfrastructure.org/schema#",      "rdfs": "http://www.w3.org/2000/01/rdf-schema#",      "schema": "http://schema.org/"    },    "@id": `ci:canonical-source.${baseName}`,    "@type": "ci:CanonicalSource",    "version": "1.0",    "title": `${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')}: Canonical Source`,    "category": "canonical-source",    "author": "Rashid Azarang",    "language": "en",    "label": {
      "en": `${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')} Canonical Source`    },    "description": {
      "en": `Comprehensive exploration of the ${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')} concept, including theoretical underpinnings, diagnostic frameworks, and real-world examples.`    },    "relatedConcepts": [
      `ci:concept.${baseName}`    ],    "sourceFile": docPath,    "documentStructure": {
      "conceptualLayer": [
        "Canonical Definition",        "One-line Summary",        "Contrast Map"      ],      "theoreticalLayer": [
        "Foundational Thinkers",        "Epistemological Implications",        "OIF Placement"      ],      "diagnosticLayer": [
        "Quick-scan Checklist",        "Severity Gradient",        "Example Vignettes"      ],      "linguisticLayer": [
        "Various Forms",        "Cross-lingual Analogues",        "Subtype Taxonomy"      ],      "narrativeLayer": [
        "Metaphors",        "Illustrative Scenes",        "Taglines"      ],      "culturalEconomicLayer": [
        "Trend Dynamics",        "Cultural Narratives",        "Economic Mechanisms"      ]
    },    "canonicalDate": "2024-04-16",    "createdDate": "2024-04-16",    "modifiedDate": "2024-04-16"  };}
// Template for epistemological source JSONfunction createEpistemologicalSourceJSON(filename, docPath) {
  // Extract the concept name from the filename  const baseName = path.basename(filename, '-epistemological-source.md');  return {
    "@context": {
      "ci": "https://cognitiveinfrastructure.org/schema#",      "rdfs": "http://www.w3.org/2000/01/rdf-schema#",      "schema": "http://schema.org/"    },    "@id": `ci:epistemological-source.${baseName}`,    "@type": "ci:EpistemologicalSource",    "version": "1.0",    "title": `${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')}: Epistemological Source`,    "category": "epistemological-source",    "author": "Rashid Azarang",    "language": "en",    "label": {
      "en": `${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')} Epistemological Source`    },    "description": {
      "en": `Exploration of the epistemological foundations and implications of the ${baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')} concept, including research, external references, and broader context.`    },    "relatedConcepts": [
      `ci:concept.${baseName}`    ],    "sourceFile": docPath,    "documentType": "epistemological",    "researchAreas": [
      "Organizational Psychology",      "System Architecture",      "Knowledge Management"    ],    "externalReferences": [],    "canonicalDate": "2024-04-16",    "createdDate": "2024-04-16",    "modifiedDate": "2024-04-16"  };}
// Process canonical source documentsfunction processCanonicalDocs() {
  if (!fs.existsSync(CANONICAL_DOC_DIR)) {
    console.log(`Directory ${CANONICAL_DOC_DIR} does not exist. Skipping canonical source documents.`);    return;  }
  const canonicalFiles = fs.readdirSync(CANONICAL_DOC_DIR)
    .filter(file => file.endsWith('-canonical-source.md'));  console.log(`Found ${canonicalFiles.length} canonical source documents.`);  let missingCount = 0;  canonicalFiles.forEach(file => {
    const jsonFilename = file.replace('.md', '.json');    const jsonPath = path.join(JSON_CANONICAL_DIR, jsonFilename);    if (!fs.existsSync(jsonPath)) {
      console.log(`Creating JSON file for ${file}`);      const docPath = path.join(CANONICAL_DOC_DIR, file);      const jsonContent = createCanonicalSourceJSON(file, docPath);      fs.writeFileSync(jsonPath, JSON.stringify(jsonContent, null, 2));      missingCount++;    }
  });  console.log(`Created ${missingCount} missing canonical source JSON files.`);}
// Process epistemological source documentsfunction processEpistemologicalDocs() {
  if (!fs.existsSync(EPISTEMOLOGICAL_DOC_DIR)) {
    console.log(`Directory ${EPISTEMOLOGICAL_DOC_DIR} does not exist. Skipping epistemological source documents.`);    return;  }
  const epistemologicalFiles = fs.readdirSync(EPISTEMOLOGICAL_DOC_DIR)
    .filter(file => file.endsWith('-epistemological-source.md'));  console.log(`Found ${epistemologicalFiles.length} epistemological source documents.`);  let missingCount = 0;  epistemologicalFiles.forEach(file => {
    const jsonFilename = file.replace('.md', '.json');    const jsonPath = path.join(JSON_EPISTEMOLOGICAL_DIR, jsonFilename);    if (!fs.existsSync(jsonPath)) {
      console.log(`Creating JSON file for ${file}`);      const docPath = path.join(EPISTEMOLOGICAL_DOC_DIR, file);      const jsonContent = createEpistemologicalSourceJSON(file, docPath);      fs.writeFileSync(jsonPath, JSON.stringify(jsonContent, null, 2));      missingCount++;    }
  });  console.log(`Created ${missingCount} missing epistemological source JSON files.`);}
// Main executionconsole.log('Ensuring all source documents have corresponding JSON files...');processCanonicalDocs();processEpistemologicalDocs();console.log('Done!');

scripts/update-related-sections.js

#!/usr/bin/env node/** * Script to update the "## Related" sections in all markdown files * and update corresponding JSON files with consistent relatedConcepts data. * * Usage: node scripts/update-related-sections.js */const fs = require('fs');const path = require('path');// Directories to processconst CORE_CONCEPTS_DIR = 'core-concepts';const PATTERNS_DIR = 'patterns-and-anti-patterns/patterns';const ANTI_PATTERNS_DIR = 'patterns-and-anti-patterns/anti-patterns';// JSON file directoriesconst JSON_CORE_CONCEPTS_DIR = 'json/core-concepts';const JSON_PATTERNS_DIR = 'json/patterns';const JSON_ANTI_PATTERNS_DIR = 'json/anti-patterns';// Map of directories to help with navigation and relationship buildingconst directoryMap = {
  'core-concepts': {
    markdownDir: CORE_CONCEPTS_DIR,    jsonDir: JSON_CORE_CONCEPTS_DIR,    idPrefix: 'ci:concept.',    linkPrefix: '', // Will be calculated based on source file    displayName: 'Core Concept',    type: 'concept'  },  'patterns': {
    markdownDir: PATTERNS_DIR,    jsonDir: JSON_PATTERNS_DIR,    idPrefix: 'ci:pattern.',    linkPrefix: '', // Will be calculated based on source file    displayName: 'Pattern',    type: 'pattern'  },  'anti-patterns': {
    markdownDir: ANTI_PATTERNS_DIR,    jsonDir: JSON_ANTI_PATTERNS_DIR,    idPrefix: 'ci:antipattern.',    linkPrefix: '', // Will be calculated based on source file    displayName: 'Anti-Pattern',    type: 'antipattern'  }
};// Mapping of filenames to titlesconst conceptMap = {};// Calculate relative path between two filesfunction getRelativePath(fromPath, toPath) {
  const fromDir = path.dirname(fromPath);  const toDir = path.dirname(toPath);  const relativePath = path.relative(fromDir, toDir);  if (relativePath) {
    return path.join(relativePath, path.basename(toPath));  } else {
    return path.basename(toPath);  }
}
// Read all files and build concept mapfunction buildConceptMap() {
  for (const key in directoryMap) {
    const dirInfo = directoryMap[key];    if (!fs.existsSync(dirInfo.markdownDir)) {
      console.log(`Directory ${dirInfo.markdownDir} does not exist. Skipping.`);      continue;    }
    const files = fs.readdirSync(dirInfo.markdownDir)
      .filter(file => file.endsWith('.md') && !file.startsWith('README'));    files.forEach(file => {
      const baseName = path.basename(file, '.md');      const filePath = path.join(dirInfo.markdownDir, file);      const fileContent = fs.readFileSync(filePath, 'utf8');      // Extract title from the first heading or use the filename      let title = baseName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ');      const titleMatch = fileContent.match(/^# (.*)/m);      if (titleMatch) {
        title = titleMatch[1].trim();      }
      conceptMap[baseName] = {
        title,        file,        path: filePath,        jsonPath: path.join(dirInfo.jsonDir, baseName + '.json'),        type: dirInfo.type,        idPrefix: dirInfo.idPrefix,        displayName: dirInfo.displayName      };    });  }
  console.log(`Built concept map with ${Object.keys(conceptMap).length} entries.`);}
// Find related concepts based on content similarity and mentionsfunction findRelatedConcepts(conceptKey) {
  const concept = conceptMap[conceptKey];  if (!concept) return [];  // Read the content of the concept file  const content = fs.readFileSync(concept.path, 'utf8');  // Build a list of related concepts by checking mentions  const related = [];  for (const otherKey in conceptMap) {
    if (otherKey === conceptKey) continue; // Skip self    const otherConcept = conceptMap[otherKey];    // Check if this concept is mentioned in the content    const regex = new RegExp(otherConcept.title.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, '\\$&'), 'i');    if (regex.test(content)) {
      related.push(otherKey);    }
  }
  // Limit to max 5 related concepts  return related.slice(0, 5);}
// Update the Related section in a markdown filefunction updateMarkdownRelatedSection(conceptKey, relatedKeys) {
  const concept = conceptMap[conceptKey];  let content = fs.readFileSync(concept.path, 'utf8');  // Generate the new related section content  let relatedSection = '## Related\n\n';  if (relatedKeys.length === 0) {
    relatedSection += 'No directly related concepts identified yet.\n';  } else {
    relatedKeys.forEach(relKey => {
      const relConcept = conceptMap[relKey];      if (relConcept) {
        // Calculate the relative path from this file to the related file        const relativePath = getRelativePath(concept.path, relConcept.path);        relatedSection += `- [${relConcept.title}](${relativePath}) (${relConcept.displayName})\n`;      }
    });  }
  // Remove all existing Related sections to avoid duplicates  // First, check if there are any ## Related sections  const relatedSectionRegex = /## Related[\s\S]*?(?=##|$)/g;  const relatedMatches = content.match(relatedSectionRegex);  if (relatedMatches && relatedMatches.length > 0) {
    // Remove all existing Related sections    content = content.replace(relatedSectionRegex, '');    // Add a new Related section just before the end or before any <details> section    const detailsPosition = content.indexOf('<details>');    if (detailsPosition !== -1) {
      // Add before <details>      content = content.slice(0, detailsPosition) + '\n' + relatedSection + '\n' + content.slice(detailsPosition);    } else {
      // Add at the end      content = content + '\n\n' + relatedSection;    }
  } else {
    // No Related section exists, add at the end    content = content + '\n\n' + relatedSection;  }
  fs.writeFileSync(concept.path, content);  console.log(`Updated Related section in ${concept.path}`);}
// Update the relatedConcepts field in a JSON filefunction updateJsonRelatedConcepts(conceptKey, relatedKeys) {
  const concept = conceptMap[conceptKey];  if (!fs.existsSync(concept.jsonPath)) {
    console.log(`JSON file ${concept.jsonPath} does not exist. Skipping.`);    return;  }
  try {
    const jsonContent = JSON.parse(fs.readFileSync(concept.jsonPath, 'utf8'));    // Update relatedConcepts with full IDs    jsonContent.relatedConcepts = relatedKeys.map(relKey => {
      const relConcept = conceptMap[relKey];      return relConcept ? relConcept.idPrefix + relKey : '';    }).filter(Boolean);    fs.writeFileSync(concept.jsonPath, JSON.stringify(jsonContent, null, 2));    console.log(`Updated relatedConcepts in ${concept.jsonPath}`);  } catch (error) {
    console.error(`Error updating JSON for ${conceptKey}:`, error.message);  }
}
// Process all conceptsfunction processAllConcepts() {
  for (const conceptKey in conceptMap) {
    console.log(`Processing ${conceptKey}...`);    const relatedKeys = findRelatedConcepts(conceptKey);    console.log(`  Found ${relatedKeys.length} related concepts for ${conceptKey}`);    updateMarkdownRelatedSection(conceptKey, relatedKeys);    updateJsonRelatedConcepts(conceptKey, relatedKeys);  }
}
// Main executionconsole.log('Updating Related sections in markdown files and relatedConcepts in JSON files...');buildConceptMap();processAllConcepts();console.log('Done!');

scripts/validate-all.js

#!/usr/bin/env node/** * Script to validate all JSON files against their respective schemas. * * Usage: node scripts/validate-all.js */const { exec } = require('child_process');const path = require('path');console.log('Validating all JSON files against their schemas...');// Validate concept, pattern, and anti-pattern JSON filesconst validateCoreCmd = 'npx ajv validate -s json/meta/ci-schema.json -r "json/meta/*.json" -d "json/{core-concepts,patterns,anti-patterns}/*.json"';// Validate document JSON filesconst validateDocsCmd = 'npx ajv validate -s json/meta/ci-document-schema.json -r "json/meta/*.json" -d "json/docs/**/*.json"';// Execute validation commandsconsole.log('\n1. Validating core concepts, patterns, and anti-patterns:');exec(validateCoreCmd, (error, stdout, stderr) => {
  if (error) {
    console.error(`Error validating core files: ${error.message}`);    console.log(stderr);    return;  }
  console.log(stdout || 'All core JSON files are valid!');  console.log('\n2. Validating document JSON files:');  exec(validateDocsCmd, (error, stdout, stderr) => {
    if (error) {
      console.error(`Error validating document files: ${error.message}`);      console.log(stderr);      return;    }
    console.log(stdout || 'All document JSON files are valid!');    console.log('\nValidation complete! All JSON files conform to their schemas.');  });});

tools/add-source.js

#!/usr/bin/env node/** * Add Source Document Tool * * This script helps add a new source document to the repository. * It will: * 1. Copy the source document to sources/manuscripts/ * 2. Add an entry to sources/index.yaml * 3. Create an excerpts directory * 4. Create a template for the first excerpt * * Usage: *   npm run source:add -- path/to/document.md LOGICAL_ID *   npm run source:add -- path/to/document.pdf LOGICAL_ID */const fs = require('fs');const path = require('path');const yaml = require('js-yaml');const { execSync } = require('child_process');// Colors for console outputconst COLORS = {
  reset: '\x1b[0m',  red: '\x1b[31m',  green: '\x1b[32m',  yellow: '\x1b[33m',  blue: '\x1b[34m',  magenta: '\x1b[35m'};// Check command line argumentsif (process.argv.length < 4) {
  console.error(`${COLORS.red}Error: Missing required arguments${COLORS.reset}`);  console.log(`Usage:  npm run source:add -- path/to/document.md LOGICAL_ID  npm run source:add -- path/to/document.pdf LOGICAL_IDExample:  npm run source:add -- ~/Downloads/cognitive-field-guide.md FIELD_GUIDE_2024  `);  process.exit(1);}
// Get argumentsconst sourcePath = path.resolve(process.argv[2]);const logicalId = process.argv[3];// Validate logical ID formatconst logicalIdRegex = /^[A-Z0-9_]+$/;const yearRegex = /[0-9]{4}/;if (!logicalIdRegex.test(logicalId)) {
  console.error(`${COLORS.red}Error: Logical ID must be ALL_CAPS with underscores${COLORS.reset}`);  process.exit(1);}
if (!yearRegex.test(logicalId)) {
  console.warn(`${COLORS.yellow}Warning: Logical ID should include a year (e.g., FIELD_GUIDE_2024)${COLORS.reset}`);}
// Check if the source file existsif (!fs.existsSync(sourcePath)) {
  console.error(`${COLORS.red}Error: Source file does not exist: ${sourcePath}${COLORS.reset}`);  process.exit(1);}
// Directoriesconst repoRoot = path.join(__dirname, '..');const manuscriptsDir = path.join(repoRoot, 'sources', 'manuscripts');const rawPdfDir = path.join(repoRoot, 'sources', 'raw-pdf');const excerptsDir = path.join(repoRoot, 'sources', 'excerpts', logicalId);const indexPath = path.join(repoRoot, 'sources', 'index.yaml');// Create directories if they don't exist[manuscriptsDir, rawPdfDir, excerptsDir].forEach(dir => {
  if (!fs.existsSync(dir)) {
    fs.mkdirSync(dir, { recursive: true });    console.log(`${COLORS.green}Created directory: ${dir}${COLORS.reset}`);  }
});// Determine file type and copy to appropriate locationconst fileExt = path.extname(sourcePath).toLowerCase();let targetPath;let indexEntry;if (fileExt === '.md') {
  // Markdown file  const filename = `${path.basename(sourcePath, '.md').toLowerCase().replace(/\s+/g, '-')}.md`;  targetPath = path.join(manuscriptsDir, filename);  indexEntry = `manuscripts/${filename}`;  // Copy the file  fs.copyFileSync(sourcePath, targetPath);  console.log(`${COLORS.green}Copied Markdown file to: ${targetPath}${COLORS.reset}`);} else if (fileExt === '.pdf') {
  // PDF file  const filename = `${path.basename(sourcePath, '.pdf').toLowerCase().replace(/\s+/g, '-')}.pdf`;  targetPath = path.join(rawPdfDir, filename);  // Create a stub markdown file  const mdFilename = `${path.basename(sourcePath, '.pdf').toLowerCase().replace(/\s+/g, '-')}.md`;  const mdTargetPath = path.join(manuscriptsDir, mdFilename);  indexEntry = `manuscripts/${mdFilename}`;  // Copy PDF using git-lfs  try {
    // Check if git-lfs is installed    execSync('git lfs version', { stdio: 'ignore' });    // Ensure PDF files are tracked    execSync('git lfs track "*.pdf"', { cwd: repoRoot });    execSync(`git add .gitattributes`, { cwd: repoRoot });    // Copy the file    fs.copyFileSync(sourcePath, targetPath);    console.log(`${COLORS.green}Copied PDF file to: ${targetPath}${COLORS.reset}`);    // Create stub markdown file with reference to PDF    const pdfRelativePath = path.relative(repoRoot, targetPath);    const mdContent = `# ${path.basename(sourcePath, '.pdf')}*This is a placeholder for the PDF document: \`${pdfRelativePath}\`*> Note: The original document is a PDF stored using Git LFS. This markdown file> serves as a reference point for the citation system.## Citation Information- Logical ID: \`${logicalId}\`- Date Added: ${new Date().toISOString().split('T')[0]}See the PDF document for the full content.`;    fs.writeFileSync(mdTargetPath, mdContent);    console.log(`${COLORS.green}Created stub Markdown file: ${mdTargetPath}${COLORS.reset}`);  } catch (error) {
    console.error(`${COLORS.red}Error: Failed to handle PDF file${COLORS.reset}`);    console.error(error.message);    process.exit(1);  }
} else {
  console.error(`${COLORS.red}Error: Unsupported file type: ${fileExt}${COLORS.reset}`);  console.log(`Supported file types: .md, .pdf`);  process.exit(1);}
// Update index.yamltry {
  // Read existing content with comments preserved  const indexContent = fs.readFileSync(indexPath, 'utf8');  const lines = indexContent.split('\n');  // Find where to insert the new entry  const entryLines = lines.filter(line => !line.trim().startsWith('#') && line.includes(':'));  if (entryLines.some(line => line.startsWith(`${logicalId}:`))) {
    console.error(`${COLORS.red}Error: Logical ID "${logicalId}" already exists in index.yaml${COLORS.reset}`);    process.exit(1);  }
  // Find the last entry and add the new one after it  let lastEntryIndex = -1;  for (let i = 0; i < lines.length; i++) {
    if (!lines[i].trim().startsWith('#') && lines[i].includes(':')) {
      lastEntryIndex = i;    }
  }
  const newEntry = `${logicalId}: ${indexEntry}`;  if (lastEntryIndex >= 0) {
    lines.splice(lastEntryIndex + 1, 0, newEntry);  } else {
    // If no entries found, add after any header comments    let insertIndex = lines.findIndex(line => !line.trim().startsWith('#'));    if (insertIndex === -1) insertIndex = lines.length;    lines.splice(insertIndex, 0, newEntry);  }
  fs.writeFileSync(indexPath, lines.join('\n'));  console.log(`${COLORS.green}Added entry to index.yaml: ${newEntry}${COLORS.reset}`);} catch (error) {
  console.error(`${COLORS.red}Error updating index.yaml:${COLORS.reset}`, error.message);  process.exit(1);}
// Create a template for the first excerptconst excerptPath = path.join(excerptsDir, '001-introduction.md');const excerptContent = `---source: ${logicalId}title: "Introduction"pages: "1-3"context: "Introduction to the document"---# Introduction> This is a template for the first excerpt of this source document.> Replace this content with the actual introduction from the source document.## Document Overview(Add a brief overview of the document here)## Key Points- First key point- Second key point- Third key point`;fs.writeFileSync(excerptPath, excerptContent);console.log(`${COLORS.green}Created excerpt template: ${excerptPath}${COLORS.reset}`);// Success messageconsole.log(`${COLORS.magenta}Successfully added source document:${COLORS.reset}- Logical ID: ${logicalId}- Source path: ${indexEntry}- Excerpt directory: sources/excerpts/${logicalId}/${COLORS.yellow}Next steps:${COLORS.reset}1. Edit the excerpt template: ${excerptPath}2. Add more excerpts as needed3. Reference in documentation using: <!--cite:${logicalId} p.XX-->4. Validate citations with: npm run validate:citations`);// Run validationtry {
  console.log(`${COLORS.blue}Running validation...${COLORS.reset}`);  execSync('npm run validate:index', { stdio: 'inherit', cwd: repoRoot });} catch (error) {
  // Validation errors are already printed by the validation script  process.exit(1);}

tools/ci-coder.js

tools/ci-writer.js

#!/usr/bin/env node/** * CI-Writer - AI assistant for Cognitive Infrastructure documentation * * This script: * 1. Scans the repository for TODO markers in Markdown files * 2. Pulls in relevant source text from manuscripts * 3. Processes the TODOs and generates appropriate content * 4. Updates the Markdown files with the generated content * * Usage: node tools/ci-writer.js [--dry-run] [--path <specific-file-or-dir>] */const fs = require('fs');const path = require('path');const { execSync } = require('child_process');const { OpenAI } = require('openai');// Initialize OpenAI (requires OPENAI_API_KEY environment variable)const openai = new OpenAI();// Directories to search for TODOsconst DIRECTORIES = [
  'core-concepts',  'patterns-and-anti-patterns/patterns',  'patterns-and-anti-patterns/anti-patterns',  'docs'];// Source directoriesconst SOURCES_DIR = path.join(process.cwd(), 'sources');const MANUSCRIPTS_DIR = path.join(SOURCES_DIR, 'manuscripts');const RAW_PDF_DIR = path.join(SOURCES_DIR, 'raw-pdf');const EXCERPTS_DIR = path.join(SOURCES_DIR, 'excerpts');// Command line argumentsconst args = process.argv.slice(2);const isDryRun = args.includes('--dry-run');const pathIndex = args.indexOf('--path');const specificPath = pathIndex !== -1 ? args[pathIndex + 1] : null;// TODO regex patternsconst TODO_PATTERN = /<!--\s*TODO:\s*(.*?)\s*-->/g;const TODO_SECTION_PATTERN = /<!--\s*TODO:\s*(.*?)\s*-->\n(.*?)(\n##|\n<details>|$)/gs;// Function to find all markdown files in directoriesfunction findMarkdownFiles(directories) {
  let mdFiles = [];  if (specificPath) {
    if (fs.existsSync(specificPath)) {
      const stats = fs.statSync(specificPath);      if (stats.isDirectory()) {
        // Find all markdown files in the specified directory        const files = fs.readdirSync(specificPath)
          .filter(file => file.endsWith('.md'))
          .map(file => path.join(specificPath, file));        mdFiles = [...mdFiles, ...files];      } else if (specificPath.endsWith('.md')) {
        // Single markdown file        mdFiles.push(specificPath);      }
    }
  } else {
    // Process all specified directories    directories.forEach(dir => {
      if (fs.existsSync(dir)) {
        const walk = (currentPath) => {
          const files = fs.readdirSync(currentPath);          files.forEach(file => {
            const filePath = path.join(currentPath, file);            const stats = fs.statSync(filePath);            if (stats.isDirectory()) {
              walk(filePath);            } else if (file.endsWith('.md')) {
              mdFiles.push(filePath);            }
          });        };        walk(dir);      }
    });  }
  return mdFiles;}
// Function to find manuscripts relevant to a conceptfunction findRelevantManuscripts(concept) {
  const conceptKeywords = concept.toLowerCase().split(/[- .]/);  const manuscriptFiles = [];  // Find manuscript files  if (fs.existsSync(MANUSCRIPTS_DIR)) {
    const files = fs.readdirSync(MANUSCRIPTS_DIR);    files.forEach(file => {
      const filePath = path.join(MANUSCRIPTS_DIR, file);      if (fs.statSync(filePath).isFile()) {
        const content = fs.readFileSync(filePath, 'utf8');        // Check if the manuscript contains keywords related to the concept        const relevance = conceptKeywords.filter(keyword =>
          keyword.length > 3 && content.toLowerCase().includes(keyword)
        ).length;        if (relevance > 0) {
          manuscriptFiles.push({
            path: filePath,            relevance
          });        }
      }
    });  }
  // Find excerpt files  if (fs.existsSync(EXCERPTS_DIR)) {
    const walk = (currentPath) => {
      const files = fs.readdirSync(currentPath);      files.forEach(file => {
        const filePath = path.join(currentPath, file);        const stats = fs.statSync(filePath);        if (stats.isDirectory()) {
          walk(filePath);        } else if (file.endsWith('.md')) {
          const content = fs.readFileSync(filePath, 'utf8');          // Check if the excerpt contains keywords related to the concept          const relevance = conceptKeywords.filter(keyword =>
            keyword.length > 3 && content.toLowerCase().includes(keyword)
          ).length;          if (relevance > 0) {
            manuscriptFiles.push({
              path: filePath,              relevance
            });          }
        }
      });    };    walk(EXCERPTS_DIR);  }
  // Sort by relevance and return paths  return manuscriptFiles
    .sort((a, b) => b.relevance - a.relevance)
    .map(item => item.path);}
// Function to extract relevant content from manuscriptsfunction extractRelevantContent(manuscripts, todo) {
  let relevantContent = '';  for (const manuscript of manuscripts) {
    const content = fs.readFileSync(manuscript, 'utf8');    const paragraphs = content.split(/\n\n/);    // Extract paragraphs that might be relevant to the TODO    const todoKeywords = todo.toLowerCase().split(/\s+/);    const relevantParagraphs = paragraphs.filter(paragraph => {
      const paragraphLower = paragraph.toLowerCase();      return todoKeywords.some(keyword =>
        keyword.length > 4 && paragraphLower.includes(keyword)
      );    });    if (relevantParagraphs.length > 0) {
      relevantContent += relevantParagraphs.join('\n\n') + '\n\n';      // Limit the amount of content to avoid large API requests      if (relevantContent.length > 5000) {
        relevantContent = relevantContent.substring(0, 5000) + '...';        break;      }
    }
  }
  return relevantContent.trim();}
// Function to generate content using OpenAIasync function generateContent(todo, fileContent, relevantContent, filePath) {
  console.log(`Generating content for TODO: ${todo}`);  const filename = path.basename(filePath);  const conceptName = filename.replace('.md', '');  const conceptType = filePath.includes('patterns-and-anti-patterns/patterns') ? 'pattern' :                     filePath.includes('patterns-and-anti-patterns/anti-patterns') ? 'anti-pattern' :                     'core concept';  try {
    const response = await openai.chat.completions.create({
      model: 'gpt-4',      messages: [
        {
          role: 'system',          content: `You are CI-Writer, an AI assistant specialized in writing documentation for the Cognitive Infrastructure project.          Your task is to fill in TODO sections in Markdown files with high-quality, concept-driven explanations.          Follow these guidelines:          1. Write clear, concise, and technically accurate content          2. Maintain the style and terminology consistent with the rest of the document          3. Use formal but accessible language          4. Include practical examples where appropriate          5. Do not add personal opinions or unnecessary embellishments          6. Do not include any markers like "TODO" in your response          7. Output only the content that should replace the TODO section          The document follows these structural principles:          - Core concepts have canonical definitions, principles, and implementation details          - Patterns describe solutions to recurring problems          - Anti-patterns describe common pitfalls and their remedies`        },        {
          role: 'user',          content: `Please fill in the following TODO section from a Cognitive Infrastructure document:          Document file: ${filename}          Concept type: ${conceptType}          Concept name: ${conceptName.split('-').map(word => word.charAt(0).toUpperCase() + word.slice(1)).join(' ')}          TODO task: ${todo}          Context from the document:          ${fileContent.substring(0, 1500)}          Relevant content from source manuscripts:          ${relevantContent || "No directly relevant content found in manuscripts."}          Please provide only the content that should replace the TODO section.`        }
      ],      temperature: 0.7,      max_tokens: 1000    });    return response.choices[0].message.content.trim();  } catch (error) {
    console.error('Error generating content:', error);    return `<!-- Failed to generate content: ${error.message} -->`;  }
}
// Function to process TODOs in a fileasync function processTODOs(filePath) {
  console.log(`Processing ${filePath}`);  const content = fs.readFileSync(filePath, 'utf8');  const conceptName = path.basename(filePath, '.md');  // Find all TODOs in the file  const todos = [];  let match;  while ((match = TODO_PATTERN.exec(content)) !== null) {
    todos.push({
      todo: match[1],      index: match.index    });  }
  console.log(`Found ${todos.length} TODOs in ${filePath}`);  if (todos.length === 0) {
    return;  }
  // Find relevant manuscripts for this concept  const manuscripts = findRelevantManuscripts(conceptName);  console.log(`Found ${manuscripts.length} relevant manuscripts`);  // Process each TODO  let newContent = content;  let offset = 0;  // Reset regex lastIndex  TODO_SECTION_PATTERN.lastIndex = 0;  while ((match = TODO_SECTION_PATTERN.exec(content)) !== null) {
    const todo = match[1];    const fullMatch = match[0];    const matchIndex = match.index;    // Extract relevant content from manuscripts    const relevantContent = extractRelevantContent(manuscripts, todo);    // Generate content    const generatedContent = await generateContent(todo, content, relevantContent, filePath);    // Replace the TODO section    const beforeMatch = newContent.substring(0, matchIndex + offset);    const afterMatch = newContent.substring(matchIndex + offset + fullMatch.length);    newContent = beforeMatch + generatedContent + afterMatch;    // Update offset for subsequent replacements    offset += generatedContent.length - fullMatch.length;    console.log(`Replaced TODO: ${todo.substring(0, 50)}...`);  }
  // Save the updated content  if (newContent !== content) {
    if (isDryRun) {
      console.log(`[DRY RUN] Would update ${filePath}`);    } else {
      fs.writeFileSync(filePath, newContent);      console.log(`Updated ${filePath}`);    }
  }
}
// Main functionasync function main() {
  console.log('CI-Writer starting...');  console.log(`Mode: ${isDryRun ? 'DRY RUN' : 'WRITE'}`);  if (specificPath) {
    console.log(`Looking for TODOs in: ${specificPath}`);  } else {
    console.log(`Looking for TODOs in: ${DIRECTORIES.join(', ')}`);  }
  const mdFiles = findMarkdownFiles(DIRECTORIES);  console.log(`Found ${mdFiles.length} Markdown files`);  for (const file of mdFiles) {
    await processTODOs(file);  }
  console.log('CI-Writer finished');}
// Run the main functionmain().catch(error => {
  console.error('Error:', error);  process.exit(1);});

tools/create-excerpt.js

#!/usr/bin/env node/** * Create Excerpt Tool * * This script helps create a new excerpt from a source document. * It will: * 1. Create a new excerpt file in the appropriate directory * 2. Populate it with a template * * Usage: *   npm run source:excerpt -- LOGICAL_ID "Excerpt Title" 10-15 */const fs = require('fs');const path = require('path');const yaml = require('js-yaml');const { execSync } = require('child_process');const { promisify } = require('util');const readline = require('readline');// Colors for console outputconst COLORS = {
  reset: '\x1b[0m',  red: '\x1b[31m',  green: '\x1b[32m',  yellow: '\x1b[33m',  blue: '\x1b[34m',  magenta: '\x1b[35m',  cyan: '\x1b[36m'};// Check command line argumentsif (process.argv.length < 5) {
  console.error(`${COLORS.red}Error: Missing required arguments${COLORS.reset}`);  console.log(`Usage:  npm run source:excerpt -- LOGICAL_ID "Excerpt Title" 10-15Example:  npm run source:excerpt -- FIELD_GUIDE_2024 "Cognitive Infrastructure Definition" 15-18  `);  process.exit(1);}
// Get argumentsconst logicalId = process.argv[2];const excerptTitle = process.argv[3];const pages = process.argv[4];// Validate logical ID formatconst logicalIdRegex = /^[A-Z0-9_]+$/;if (!logicalIdRegex.test(logicalId)) {
  console.error(`${COLORS.red}Error: Logical ID must be ALL_CAPS with underscores${COLORS.reset}`);  process.exit(1);}
// Validate pages formatconst pagesRegex = /^\d+(-\d+)?$/;if (!pagesRegex.test(pages)) {
  console.error(`${COLORS.red}Error: Pages must be in format 'X' or 'X-Y'${COLORS.reset}`);  process.exit(1);}
// Directoriesconst repoRoot = path.join(__dirname, '..');const indexPath = path.join(repoRoot, 'sources', 'index.yaml');const excerptsDir = path.join(repoRoot, 'sources', 'excerpts', logicalId);// Check if index.yaml existsif (!fs.existsSync(indexPath)) {
  console.error(`${COLORS.red}Error: index.yaml does not exist at ${indexPath}${COLORS.reset}`);  process.exit(1);}
// Check if the logical ID exists in index.yamlconst indexContent = fs.readFileSync(indexPath, 'utf8');const lines = indexContent.split('\n');const logicalIdLine = lines.find(line => line.startsWith(`${logicalId}:`));if (!logicalIdLine) {
  console.error(`${COLORS.red}Error: Logical ID "${logicalId}" not found in index.yaml${COLORS.reset}`);  process.exit(1);}
// Create excerpts directory if it doesn't existif (!fs.existsSync(excerptsDir)) {
  fs.mkdirSync(excerptsDir, { recursive: true });  console.log(`${COLORS.green}Created directory: ${excerptsDir}${COLORS.reset}`);}
// Get the next available excerpt numberconst existingExcerpts = fs.readdirSync(excerptsDir)
  .filter(file => file.endsWith('.md'))
  .map(file => parseInt(file.match(/^(\d+)/)?.[1] || '0'))
  .filter(num => !isNaN(num));const nextNumber = (existingExcerpts.length > 0 ? Math.max(...existingExcerpts) : 0) + 1;const excerptFilename = `${String(nextNumber).padStart(3, '0')}-${excerptTitle.toLowerCase().replace(/\s+/g, '-')}.md`;const excerptPath = path.join(excerptsDir, excerptFilename);// Ask for contextconst rl = readline.createInterface({
  input: process.stdin,  output: process.stdout});console.log(`${COLORS.cyan}Please provide context for this excerpt (Press Enter to skip):${COLORS.reset}`);rl.question('> ', (context) => {
  rl.close();  // Create the excerpt file  const safeTitle = excerptTitle.replace(/"/g, '\\"');  const safeContext = context.replace(/"/g, '\\"');  const excerptContent = `---source: ${logicalId}title: "${safeTitle}"pages: "${pages}"context: "${safeContext || 'No context provided'}"---# ${excerptTitle}> Replace this content with the excerpt from page${pages.includes('-') ? 's' : ''} ${pages} of the source document.## Key Points- First key point from this excerpt- Second key point from this excerpt- Third key point from this excerpt## Relationships to ConceptsThis excerpt relates to the following concepts:- [Concept 1]: How this excerpt relates to the concept- [Concept 2]: How this excerpt relates to the concept`;  fs.writeFileSync(excerptPath, excerptContent);  console.log(`${COLORS.green}Created excerpt: ${excerptPath}${COLORS.reset}`);  // Success message  console.log(`${COLORS.magenta}Successfully created excerpt:${COLORS.reset}- Source: ${logicalId}- Title: ${excerptTitle}- Pages: ${pages}- File: ${excerptFilename}${COLORS.yellow}Next steps:${COLORS.reset}1. Edit the excerpt file to add the actual content2. Reference in documentation using: <!--cite:${logicalId} p.${pages}-->  `);  // Open the file in the default editor if on a desktop environment  try {
    console.log(`${COLORS.blue}Opening file in editor...${COLORS.reset}`);    // Determine the platform and use the appropriate open command    const platform = process.platform;    if (platform === 'darwin') {  // macOS      execSync(`open "${excerptPath}"`, { stdio: 'ignore' });    } else if (platform === 'win32') {  // Windows      execSync(`start "" "${excerptPath}"`, { stdio: 'ignore' });    } else if (platform === 'linux') {  // Linux      execSync(`xdg-open "${excerptPath}"`, { stdio: 'ignore' });    } else {
      console.log(`${COLORS.yellow}Note: Could not automatically open the file. Please open it manually.${COLORS.reset}`);    }
  } catch (error) {
    console.log(`${COLORS.yellow}Note: Could not automatically open the file. Please open it manually.${COLORS.reset}`);  }
});

tools/cursor-rules.json

{  "version": "1.0",  "rules": [    {      "id": "protect-index-yaml",      "description": "Ensure index.yaml follows the required format",      "pattern": "sources/index.yaml",      "checks": [        {          "type": "regex",          "match": "^[A-Z0-9_]+: manuscripts/[\\w\\-\\.]+\\.md$",          "message": "Logical IDs must be ALL_CAPS with underscores, and point to a file in the manuscripts directory",          "level": "error"        },        {          "type": "structure",          "ensure": "Each logical ID must include a publication year (e.g., FIELD_GUIDE_2024)",          "message": "All logical IDs must include a publication year in the format YYYY",          "level": "warning"        }      ]    },    {      "id": "protect-source-documents",      "description": "Prevent modification of committed source documents",      "pattern": "sources/manuscripts/*.md",      "checks": [        {          "type": "history",          "condition": "file exists in previous commit",          "action": "read-only",          "message": "Source documents are immutable once committed. Create a new version instead.",          "level": "error"        }      ]    },    {      "id": "validate-citation-format",      "description": "Ensure citations follow the proper format",      "pattern": "**/*.md",      "exclude": ["sources/manuscripts/*.md", "sources/raw-pdf/*"],      "checks": [        {          "type": "regex",          "match": "<!--\\s*cite:([A-Z0-9_]+).*?-->",          "validate": "Run tools/validate_citations.py to verify the citation ID exists",          "message": "Citation IDs must exist in sources/index.yaml",          "level": "warning"        }      ]    },    {      "id": "validate-excerpt-structure",      "description": "Ensure excerpts have the required frontmatter",      "pattern": "sources/excerpts/**/*.md",      "checks": [        {          "type": "structure",          "require": [            "---",            "source: LOGICAL_ID",            "title:",            "pages:",            "context:",            "---"          ],          "message": "Excerpts must include complete frontmatter with source, title, pages, and context",          "level": "error"        },        {          "type": "regex",          "match": "^\\d{3}\\-.*\\.md$",          "message": "Excerpt files must be numbered with a 3-digit prefix (e.g., 001-introduction.md)",          "level": "warning"        }      ]    },    {      "id": "protect-tools",      "description": "Protect critical source management tools",      "pattern": ["tools/validate_citations.py", "tools/excerpt.py"],      "checks": [        {          "type": "review",          "require": "code-owner-approval",          "message": "Changes to core source management tools require approval from a code owner",          "level": "error"        }      ]    },    {      "id": "enforce-git-lfs",      "description": "Ensure PDF files are tracked by Git LFS",      "pattern": ["**/*.pdf", "sources/raw-pdf/*"],      "checks": [        {          "type": "git-attributes",          "require": "filter=lfs diff=lfs merge=lfs -text",          "message": "PDF files must be tracked using Git LFS. Run 'git lfs track \"*.pdf\"' to set up.",          "level": "error"        }      ]    },    {      "id": "package-json-protection",      "description": "Protect package.json scripts for source management",      "pattern": "package.json",      "checks": [        {          "type": "json-path",          "path": "$.scripts.validate:citations",          "ensure": "contains 'validate_citations.py'",          "message": "Do not remove or modify the citation validation script",          "level": "error"        },        {          "type": "json-path",          "path": "$.scripts.excerpt",          "ensure": "contains 'excerpt.py'",          "message": "Do not remove or modify the excerpt utility script",          "level": "error"        }      ]    },    {      "id": "summary-md-protection",      "description": "Ensure source library appears in SUMMARY.md",      "pattern": "SUMMARY.md",      "checks": [        {          "type": "content",          "ensure": "contains '## Source Library'",          "message": "SUMMARY.md must include the Source Library section",          "level": "warning"        }      ]    },    {      "id": "pre-commit-validation",      "description": "Run validation before commits",      "pattern": "**/*.md",      "checks": [        {          "type": "pre-commit",          "run": "npm run validate:citations",          "message": "Citation validation failed. Run 'npm run validate:citations' to see details.",          "level": "error"        }      ]    },    {      "id": "ci-writer-integration",      "description": "Protect CI-Writer integration",      "pattern": ["**/CI-Writer*.md", "docs/**/ci-writer*.md"],      "checks": [        {          "type": "regex",          "match": "@ci-writer.*?<!--\\s*cite:([A-Z0-9_]+).*?-->",          "message": "CI-Writer instructions with citations must be validated",          "action": "run validate:citations",          "level": "warning"        }      ]    }  ],  "exceptions": [    {      "pattern": "sources/CITATION_EXAMPLES.md",      "rules": ["validate-citation-format"],      "reason": "Example file may contain invalid citations for demonstration purposes"    }  ],  "governance": {    "owner": "Core Engineering Guild",    "review_required": true,    "documentation": "docs/PRD-ci-coder.md#10-·-appendix-b-—-source-management-system-guide-for-llm"  }}

tools/excerpt.py

#!/usr/bin/env python3"""Excerpt Extractor for Cognitive InfrastructureThis script retrieves excerpts from source documents based on their logical IDs.It can either print an excerpt to stdout or be imported and used programmatically.Usage:  python tools/excerpt.py LOGICAL_ID EXCERPT_NUMBER [--output OUTPUT_FILE]Examples:  # Print excerpt to stdout  python tools/excerpt.py INT_STACK_2024 003  # Save excerpt to file  python tools/excerpt.py FIELD_GUIDE_2024 002 --output temp/excerpt.md"""import os
import sys
import yaml
import argparse
from pathlib import Path
def load_index(index_file="sources/index.yaml"):
    """Load the source index YAML file"""    try:
        with open(index_file, 'r') as f:
            # Skip comment lines that start with #            yaml_content = "\n".join([line for line in f if not line.strip().startswith('#')])
            return yaml.safe_load(yaml_content) or {}
    except Exception as e:
        print(f"Error loading index file {index_file}: {e}", file=sys.stderr)
        return {}
def get_excerpt_path(logical_id, excerpt_number):
    """Get the path to an excerpt file"""    # Ensure excerpt_number is a 3-digit string (e.g., '001', '042')    if isinstance(excerpt_number, int):
        excerpt_number = f"{excerpt_number:03d}"    elif len(excerpt_number) < 3:
        excerpt_number = excerpt_number.zfill(3)
    # Look for files starting with the excerpt number    excerpt_dir = Path("sources/excerpts") / logical_id
    # Check if directory exists    if not excerpt_dir.exists():
        print(f"Error: No excerpts directory found for {logical_id}", file=sys.stderr)
        return None    # Find files matching the pattern    matches = list(excerpt_dir.glob(f"{excerpt_number}*.md"))
    if not matches:
        print(f"Error: No excerpt found with number {excerpt_number} for {logical_id}", file=sys.stderr)
        return None    return matches[0]
def get_document_path(logical_id):
    """Get the path to the full document based on logical ID"""    index_data = load_index()
    if logical_id not in index_data:
        print(f"Error: Unknown logical ID {logical_id}", file=sys.stderr)
        return None    # Get the relative path from the index    rel_path = index_data[logical_id]
    full_path = Path("sources") / rel_path
    if not full_path.exists():
        print(f"Error: Document file not found at {full_path}", file=sys.stderr)
        return None    return full_path
def extract_excerpt(logical_id, excerpt_number):
    """Extract an excerpt from a source document"""    excerpt_path = get_excerpt_path(logical_id, excerpt_number)
    if not excerpt_path:
        return None    try:
        with open(excerpt_path, 'r') as f:
            content = f.read()
            return content
    except Exception as e:
        print(f"Error reading excerpt file {excerpt_path}: {e}", file=sys.stderr)
        return Nonedef main():
    """Main entry point"""    parser = argparse.ArgumentParser(description="Extract excerpts from source documents")
    parser.add_argument("logical_id", help="Logical ID of the source document")
    parser.add_argument("excerpt_number", help="Number of the excerpt to extract")
    parser.add_argument("--output", help="Output file (default: stdout)")
    args = parser.parse_args()
    content = extract_excerpt(args.logical_id, args.excerpt_number)
    if content:
        if args.output:
            try:
                with open(args.output, 'w') as f:
                    f.write(content)
                print(f"Excerpt written to {args.output}")
            except Exception as e:
                print(f"Error writing to output file: {e}", file=sys.stderr)
                sys.exit(1)
        else:
            print(content)
    else:
        sys.exit(1)
if __name__ == "__main__":
    main()

tools/validate-index-yaml.js

#!/usr/bin/env node/** * Index YAML Validator * * This script validates that the sources/index.yaml file follows the required format: * - Logical IDs must be ALL_CAPS with underscores * - Logical IDs must include a year (YYYY) * - Paths must point to files in the manuscripts directory */const fs = require('fs');const path = require('path');const yaml = require('js-yaml');const INDEX_PATH = path.join(__dirname, '..', 'sources', 'index.yaml');// Colors for console outputconst COLORS = {
  reset: '\x1b[0m',  red: '\x1b[31m',  green: '\x1b[32m',  yellow: '\x1b[33m',  blue: '\x1b[34m'};/** * Load and parse the index.yaml file, skipping comment lines * @returns {Object} The parsed YAML content */function loadIndexYaml() {
  try {
    const content = fs.readFileSync(INDEX_PATH, 'utf8');    // Skip lines that start with #    const contentWithoutComments = content
      .split('\n')
      .filter(line => !line.trim().startsWith('#'))
      .join('\n');    return yaml.load(contentWithoutComments) || {};  } catch (error) {
    console.error(`${COLORS.red}Error loading index.yaml:${COLORS.reset}`, error.message);    process.exit(1);  }
}
/** * Validate the format of logical IDs and paths * @param {Object} indexData The parsed index.yaml content * @returns {boolean} Whether the validation passed */function validateFormat(indexData) {
  let isValid = true;  const errors = [];  const warnings = [];  // Regular expressions for validation  const logicalIdRegex = /^[A-Z0-9_]+$/;  const yearRegex = /[0-9]{4}/;  const pathRegex = /^manuscripts\/[\w\-\.]+\.md$/;  Object.entries(indexData).forEach(([id, path]) => {
    // Check logical ID format    if (!logicalIdRegex.test(id)) {
      errors.push(`Logical ID "${id}" must be ALL_CAPS with underscores`);      isValid = false;    }
    // Check year in logical ID    if (!yearRegex.test(id)) {
      warnings.push(`Logical ID "${id}" should include a year (e.g., FIELD_GUIDE_2024)`);    }
    // Check path format    if (!pathRegex.test(path)) {
      errors.push(`Path "${path}" for ID "${id}" must be in manuscripts/ directory with .md extension`);      isValid = false;    }
    // Check if the file exists    const fullPath = `${path.join(__dirname, '..', 'sources', path)}`;    if (!fs.existsSync(fullPath)) {
      warnings.push(`File not found: ${path}`);    }
  });  // Print errors and warnings  if (errors.length > 0) {
    console.error(`${COLORS.red}Errors:${COLORS.reset}`);    errors.forEach(error => console.error(`  - ${error}`));  }
  if (warnings.length > 0) {
    console.warn(`${COLORS.yellow}Warnings:${COLORS.reset}`);    warnings.forEach(warning => console.warn(`  - ${warning}`));  }
  return isValid;}
/** * Main function */function main() {
  console.log(`${COLORS.blue}Validating index.yaml...${COLORS.reset}`);  const indexData = loadIndexYaml();  const isValid = validateFormat(indexData);  if (isValid) {
    console.log(`${COLORS.green}index.yaml format is valid!${COLORS.reset}`);    process.exit(0);  } else {
    console.error(`${COLORS.red}index.yaml format is invalid. Please fix the errors above.${COLORS.reset}`);    process.exit(1);  }
}
// Run the scriptmain();

tools/validate_citations.py

#!/usr/bin/env python3"""Citation Validator for Cognitive InfrastructureThis script validates that all citations in Markdown files referencevalid logical IDs defined in the index.yaml file.Usage:  python tools/validate_citations.py sources/index.yaml path/to/file1.md path/to/file2.md ...  Or use with git ls-files to check all Markdown files:  python tools/validate_citations.py sources/index.yaml $(git ls-files '*.md')"""import re
import sys
import os
import yaml
from pathlib import Path
# Regular expression to match citation formatCITE_PATTERN = re.compile(r'<!--\s*cite:([A-Z0-9_]+).*?-->')
def load_index(index_file):
    """Load the source index YAML file"""    try:
        with open(index_file, 'r') as f:
            # Skip comment lines that start with #            yaml_content = "\n".join([line for line in f if not line.strip().startswith('#')])
            return yaml.safe_load(yaml_content) or {}
    except Exception as e:
        print(f"Error loading index file {index_file}: {e}")
        sys.exit(1)
def validate_citations(index_data, markdown_files):
    """Validate citations in markdown files against the index"""    valid = True    unknown_ids = set()
    for md_file in markdown_files:
        try:
            with open(md_file, 'r') as f:
                content = f.read()
            # Find all citations            citations = CITE_PATTERN.findall(content)
            for citation_id in citations:
                if citation_id not in index_data:
                    unknown_ids.add(citation_id)
                    print(f"Error: Unknown citation ID '{citation_id}' in {md_file}")
                    valid = False        except Exception as e:
            print(f"Error processing file {md_file}: {e}")
            valid = False    if unknown_ids:
        print("\nMissing citation IDs in index.yaml:")
        for missing_id in sorted(unknown_ids):
            print(f"  {missing_id}: manuscripts/your-file-name.md")
    return valid
def main():
    """Main entry point"""    if len(sys.argv) < 3:
        print(f"Usage: {sys.argv[0]} index.yaml file1.md [file2.md ...]")
        sys.exit(1)
    index_file = sys.argv[1]
    markdown_files = sys.argv[2:]
    # Filter out non-existent files    markdown_files = [f for f in markdown_files if os.path.isfile(f)]
    if not markdown_files:
        print("No valid markdown files provided")
        sys.exit(0)
    index_data = load_index(index_file)
    print(f"Checking {len(markdown_files)} files for citations...")
    if validate_citations(index_data, markdown_files):
        print("All citations are valid!")
        sys.exit(0)
    else:
        sys.exit(1)
if __name__ == "__main__":
    main()