# Whitepaper Source Register

This directory stores source notes that define the whitepaper narrative, problem framing, and protocol explanation. These notes are reference material for public documentation, not runtime protocol code.

## Source Notes

| File | Whitepaper Role |
| --- | --- |
| `sources/22世界问题.md` | Problem landscape: why current intelligence systems lack continuous structural discovery. |
| `sources/33为什么现有系统无法解.md` | Existing-system gap: why static benchmarks, model scaling, and ordinary reward systems do not solve this problem. |
| `sources/44MazeXChain 提出的协议.md` | Protocol proposal: MazeXChain as a chain proof framework for verifiable structural intelligence. |
| `sources/55协议如何运行.md` | Operating flow: challenge generation, observation, solver modeling, verification, solve block, and state advancement. |
| `sources/66为什么协议不会崩溃.md` | Stability model: why bounded answers, dynamic structure, state inheritance, and resource release rules protect the protocol. |

## Canonical Thesis

The Chinese whitepaper should use this as its primary narrative anchor:

```text
MazeXChain 是一种认知推进协议，目标是推动智能持续突破认知边界。技术上，MazeXChain 是面向可验证结构智能的链式认知协议。它通过连续挑战、行为验证、Solve Block 和链式状态继承，将智能系统的结构发现能力转化为可验证的认知状态推进。
```

All whitepaper sections should support this protocol loop:

```text
continuous challenge pressure
  -> challenge behavior observation
  -> bounded executable model
  -> deterministic behavior verification
  -> Solve Block
  -> cognitive state transition
  -> state root update
  -> MAZEX settlement
  -> next Step commitment
```

## Whitepaper Update Rule

Before editing `public/whitepaper.html`, `public/whitepaper.zh.html`, or generated whitepaper PDFs, read:

```text
1. PROJECT_CONTEXT.md
2. PROJECT_SCOPE.md
3. PROJECT_READING_RULES.md
4. docs/architecture.md
5. docs/security.md
6. docs/whitepaper/README.md
7. docs/whitepaper/sources/*.md
```

After every meaningful whitepaper update:

```text
1. Verify formatting and links.
2. Regenerate downloadable artifacts if the public files changed.
3. Update CHANGELOG.md.
4. Commit the change to Git.
```

## Boundary

The source notes may introduce conceptual language that is broader than the current implementation. Runtime behavior remains governed by `PROJECT_SCOPE.md`, active configuration files, and the Base1 modules listed in `PROJECT_STATUS.md`.
