How to Use This Canon
Stunspot’s Guide to AI Systems is a model-loadable operating canon for production AI systems. It can also be read directly as a field manual. It is not an agent tutorial or a framework cookbook: agents and tools are one layer inside a wider systems discipline.
It is designed to work in two ways:
- as a human-readable field manual for designing, evaluating, operating, and governing AI systems;
- as model-readable governing reference material for AI Projects, RAG systems, long-context workspaces, and design workflows.
The canonical source reports live in /docs/.
Bundled upload formats live in /knowledge-packs/.
Quick Start
Use the Guide in one of these ways:
| Use Case | Best Format |
|---|---|
| Reading and browsing the canon | /docs/ |
| Understanding Agents, Skills, Augments, Tools, and Capabilities | Architecture crosswalk |
| Comparing conventional, prompt-as-code, and performance-seeded prompting | Promptcraft worked example |
| Seeing one design worked through | Refund-agent worked example |
| Uploading to an AI Project or RAG workspace | /knowledge-packs/by-part/ |
| Uploading when smaller files or cleaner retrieval boundaries are preferred | /knowledge-packs/by-volume/ |
| Local search, archival use, or full-corpus import | /knowledge-packs/omnibus/ |
Most users should start with the By Part pack. It gives broad coverage with low upload friction while avoiding both extremes: one giant file or dozens of separate reports.
Before uploading, check the platform’s current file-size, file-count, retention, privacy, and context limits. The packs contain public Guide material, but your surrounding project instructions, files, and questions may not be public.
A Reliable Use Loop
- Choose the smallest useful unit. Start with one report, one volume, or one part rather than the entire canon.
- Upload or index it. Confirm that the platform accepted the complete file and did not silently truncate or reject it.
- Frame the task. Tell the model what you are designing or reviewing, which constraints matter, and how the Guide should be used.
- Run a retrieval probe. Ask one task-specific question whose answer should draw on a named report or canon handle.
- Inspect the evidence. Confirm that the response applies a relevant passage or principle instead of merely repeating your instruction or inventing canon language.
- Verify consequential claims. Current primary sources, executable system behavior, approved policy, and qualified domain review outrank the Guide.
Successful loading means the system can retrieve and apply relevant doctrine with traceable report context. It does not, by itself, prove better model performance.
If an upload is rejected or retrieval becomes diffuse, step down from omnibus → by part → by volume → individual report. If a pack and a canonical source report disagree, the report in /docs/ is authoritative. If the model cannot identify a relevant report, narrow the loaded material or improve the indexing and metadata before adding more context.
Use It as Project Knowledge
For ChatGPT Projects, Claude Projects, NotebookLM-style tools, or other AI workspaces, upload the relevant knowledge pack.
Recommended order:
- Start with
/knowledge-packs/by-part/. - Upload only the parts relevant to your task when possible.
- Use
/knowledge-packs/by-volume/when you want smaller files or more precise retrieval boundaries. - Use
/knowledge-packs/omnibus/only when the platform handles large single-file knowledge sources well.
The goal is to give the model enough canon context to reason well without forcing the retrieval system to chew one giant undifferentiated brick.
Use It as RAG Substrate
For custom RAG systems, the best source is usually the canonical report structure in /docs/.
Use individual reports when you want:
- precise chunking;
- better source attribution;
- cleaner retrieval boundaries;
- easier updates;
- report-level metadata;
- stronger citation and traceability.
Use bundled packs when your platform is simpler and expects fewer files.
Use It as an Architecture Reviewer
The Guide is especially useful when asking an AI system to review, critique, or improve an AI design.
Use it to evaluate:
- prompt systems;
- RAG pipelines;
- model-routing plans;
- agent workflows;
- tool/action boundaries;
- eval plans;
- governance models;
- product architecture;
- adoption plans;
- vendor strategy;
- operational readiness.
Minimal Loading Strategy
Do not load the whole canon by default.
Load the smallest useful unit:
| Task | Suggested Loading |
|---|---|
| Prompting / model steering | Volume 1 and the Promptcraft worked example |
| RAG / knowledge systems | Volumes 1–2 |
| Model selection or serving | Volumes 1, 3, 4 |
| Agents, Skills, Augments, and tool use | Start with the architecture crosswalk, then use Volumes 1, 5, 7, and 9 |
| Multimodal systems | Volumes 6, 8, 9 |
| Security and failure analysis | Volumes 7, 9, 10 |
| Product and adoption | Volumes 8 and 11 |
| Governance and operations | Volumes 9–10 |
| System doctrine / design review | Volume 12 |
| Broad AI architecture review | By Part pack or By Volume pack |
Load more only when the task actually needs it.
Choosing Between Pack Formats
Source Reports
Use /docs/ when cloning the repo, building a serious RAG index, citing specific reports, or editing the canon.
By Part
Use /knowledge-packs/by-part/ as the recommended default for most AI Projects and RAG workspaces. It preserves major canon structure while keeping file count low.
By Volume
Use /knowledge-packs/by-volume/ when the By Part files are too large, when you want smaller upload units, or when cleaner retrieval boundaries matter more than file-count simplicity.
Omnibus
Use /knowledge-packs/omnibus/ when you need the entire canon as one file for local search, archival use, or a platform that handles large single-file knowledge sources well.
For most hosted RAG and Project systems, the omnibus is not the best default.
If a platform accepts the omnibus and still retrieves the correct report precisely, the single-file format may be appropriate. Verify that behavior with a task-specific probe instead of assuming that a large context window solved retrieval.
Suggested Instruction
When loading the Guide into an AI system, give the model a clear usage frame:
Enter the requested AI system as an architecture: probabilistic cognition operating inside deterministic state, authority, evidence, and action boundaries. Use Stunspot’s Guide to AI Systems as the governing design frame. Name the outcome; retrieve only the reports the task needs; preserve the canon’s decisive distinctions; separate model judgment from code, policy, permission, and tool execution; choose the least sufficient mechanism; and map each recommendation to the failure it contains and the evidence that would reverse it. Produce the requested design, diagnosis, critique, or decision—not a summary of the Guide. Ask only when an unknown changes the architecture or consequence; otherwise make a bounded assumption and mark it. Keep completion honest: a plausible design remains proposed until its decisive claims have been observed or tested.
Add this evidence rule for consequential work:
Treat the Guide as an engineering reference, not proof. Distinguish canon-derived guidance from verified environment facts. When current primary sources, observed system behavior, approved requirements, or applicable policy conflict with the Guide, those sources take priority and the conflict should be named.
Reading Paths
For human reading paths, start with the Canon Map.
For upload formats, start with the Knowledge Packs page.
To see the doctrine applied without a paid model run, read A Refund Agent Without Giving the Model a Wallet.
To distinguish the capability layers, read Agents, Skills, Augments, Tools, and Capabilities.
To inspect Promptcraft as a testable design discipline rather than a bag of wording tricks, read Same Task, Three Prompting Paradigms.