Why this Navigator exists: Read the Manifesto
A structured, field-tested design perspective navigator for SaaS architects, developers, and reviewers Now with AI-guided structural reading protocols (Strict / Flexible) to enable hallucination-free
.mddocument reasoning. 50+ perspectives / 12 + 1 categories / 2 structural levels — fully mapped, English-translated, and production-aligned.
This repository is a checklist + knowledge navigator for SaaS architecture design.
It helps teams avoid blind spots and ensure design quality by reviewing critical perspectives across:
- Domain modeling and validation
- Data structure, indexing, lifecycle, and consistency
- API design, schema evolution, and compatibility
- Event-driven and asynchronous workflows
- Performance and scalability
- UI rendering and communication logic
- Release operations and rollback planning
- Availability, failover, and data recovery
- Testing boundaries and load behavior
- Security, authentication, and sensitive data protection
- Logging, observability, and operational resilience
- Common design justification and rationale
In addition, the Human category offers cognitive frameworks for:
- Structuring sustainable personal and team growth
- Designing mentorship models
- Building self-directed learning architectures
(These guides do not strictly follow the technical checklist format; they support long-term capability development across engineering organizations.)
| Category | Description |
|---|---|
domain |
Domain modeling, validation, permission logic |
data |
Schema lifecycle, indexing, consistency, migration |
api |
Contract design, versioning, authorization strategy |
performance |
Latency, indexing, caching, scalability |
async |
Retry behavior, fallout impact, causal issues |
release |
Rollouts, rollback, downtime, impact boundaries |
test |
Acceptance criteria, stress testing, scope checks |
availability |
Failover, data recovery, backup plans |
non-functional |
Logging, monitoring, recovery workflows |
ui |
Display limits, translation, component reuse |
security |
Authentication, authorization, sensitive data protection |
common |
Cross-cutting design rationale, justification |
human |
Growth frameworks, self-reflection templates, mentorship architecture |
| Level | Description | Who Should Read |
|---|---|---|
Structure |
Architectural clarity and separation of concerns | Junior-mid engineers, reviewers |
DeepDive |
High-complexity edge cases (failures, tradeoffs, ops) | Tech leads, SREs, architects |
Use the category list to check for blind spots.
Each .md file gives you examples, failure modes, and questions to answer in your spec.
Mark relevant perspectives in your pull request or spec template.
Link to .md files as shared criteria for structured review.
Browse availability/ or non-functional/ to audit failure handling quality.
This is not a tutorial. It is a navigator.
Designed to help teams ask better questions before they write code.
Each perspective file is intentionally minimal but powerful:
- 🔍 What it asks or reveals
⚠️ Common mistakes or fragilities- ✅ Patterns and recommendations
- 🧠 Design principles
- ❓ FAQ
- 🔗 Links to other views
Explore the live documentation site here:
📘 SaaS Review Navigator Site
This project includes a grammar-based prompt protocol that teaches LLMs how to interpret layered .md files structurally.
Start with the high-level guide here:
For implementation, reuse, or adaptation, see:
This protocol has been tested with GPT-4o across 100+ architectural documents,
achieving >95% structural fidelity with no hallucinated summaries or invented file names.
pip install mkdocs-material mkdocs-awesome-pages-plugin mkdocs-git-revision-date-localized-plugin
mkdocs serve --config-file mkdocs.en.ymlWe're looking for:
- New perspectives from your experience
- FAQ and edge cases
- Translation or adaptation
- Clarification or fixes
AI assistance is welcome — if curated and aligned with the project’s structure and philosophy.
Please see CONTRIBUTING.md for guidelines and the perspective template to get started.
This project was originally authored in Japanese, and translated and refined using AI tools (e.g., ChatGPT).
If you spot awkward expressions or unclear phrasing, feel free to submit a PR or open an issue — your help is always welcome.
docs/
├─ ai-guidance/ # ai guidance
└─ ja/ # Japanese content
└─ en/ # English content
README.md
LICENSE
CONTRIBUTING.md
mkdocs.yml
All contents are released under the MIT License.
Use, fork, share, or extend freely. Attribution is welcome.
This project is MIT licensed, but its value lies in how it is meant to be read and used.
The documentation is structurally authored to support reasoning, reflection, and failure prevention.
If reused or embedded, please retain this structural reading grammar to preserve its design integrity.
Created by kanaria007 (Zenn)
Original articles and use cases:
https://zenn.dev/kanaria007/articles/101e51dbcf2135
This framework is structurally signed by kanaria007.
PGP Fingerprint: EA19 B96B 54BC F071 5E1C 8F23 DBC6 A992 60EB 7D84
Key File: kanaria007-public-key.asc
If you are evaluating this framework for integration into AI systems, educational platforms, or cognitive tools:
- Please be aware that the structural reading protocol is part of the core value.
- This is not a content dump, but a reasoning scaffold.
- If you plan to embed, adapt, or benchmark it, we encourage contacting the author or referencing the AI-guidance documentation to ensure correct application.
📬 Contact: 
(for research, stewardship, or feedback)