# Perpetuals Content Architecture ## Purpose of This Document The research phase of Perpetuals has established the communication model and narrative flow for the ecosystem. The next requirement is a canonical model of the content objects that may exist across perpetuals.io, Inspect, and future Perpetuals products. This document defines that content architecture. It is not an information architecture for pages. It does not describe layouts, navigation, interface behavior, or implementation. It identifies the major kinds of content Perpetuals should maintain, explains how those kinds of content relate, and defines rules for preserving coherence as the ecosystem grows. The central recommendation is that Perpetuals should organize content by **content object type, authority, and relationship to the ecosystem**, not by a single product, publication surface, chronology, or audience path. ## Part 1 — Core Content Types Perpetuals should recognize a small set of durable content types. These types are broad enough to support future products beyond Inspect, but specific enough to prevent every document from becoming an unclassified essay. ### 1. Vision **Purpose:** Vision content explains why Perpetuals exists and what enduring problem it addresses. It establishes the highest-level orientation of the ecosystem: making digital subjects, claims, evidence, provenance, continuity, and uncertainty more inspectable. **Intended audience:** Everyone who needs to understand the project from first principles, including founders, researchers, contributors, partners, product teams, and external readers. **Expected stability:** Very high. Vision should change rarely. It may be clarified, but it should not shift with individual products, examples, campaigns, or research cycles. **Relationship to other categories:** Vision anchors every other content type. Principles interpret vision. Research tests the problem space implied by vision. Products express the vision in bounded forms. Documentation, examples, and specifications should never redefine the vision locally. ### 2. Principles **Purpose:** Principles define the durable rules of judgment, communication, and product discipline for Perpetuals. They translate the vision into constraints such as evidence before conclusions, inspection before trust, explicit uncertainty, respect for provenance, inspectable continuity, and the separation of subjects from claims. **Intended audience:** Contributors who make decisions, write content, conduct research, define products, explain concepts, or evaluate whether new work belongs within the ecosystem. **Expected stability:** High. Principles may be refined when research reveals a better formulation, but they should not be rewritten to accommodate a product shortcut or temporary communication need. **Relationship to other categories:** Principles constrain product content, documentation, examples, specifications, and public claims. Research may challenge or qualify principles, but accepted changes should be elevated deliberately rather than scattered across lower-level documents. ### 3. Research **Purpose:** Research content investigates the project's claims, boundaries, evidence, adjacent systems, risks, and open questions. It includes synthesis, critique, applied analysis, comparisons, evidence review, conceptual stress testing, and uncertainty registers. **Intended audience:** Researchers, founders, product strategists, domain experts, contributors, and readers who need to understand the evidentiary basis for Perpetuals. **Expected stability:** Medium. Research should remain revisable. Individual research documents may retain value as records of inquiry even when later synthesis supersedes some conclusions. **Relationship to other categories:** Research informs principles, conceptual models, architecture, product boundaries, and specifications. It should not be treated as automatically canonical merely because it is thorough. Research becomes canonical only when synthesized into principles, conceptual models, architecture, or specifications. ### 4. Historical Research **Purpose:** Historical research preserves the evolution of ideas, prior assumptions, rejected framings, legacy arguments, and earlier states of the project. It explains how Perpetuals arrived at its current model without forcing older language to remain authoritative. **Intended audience:** Researchers, contributors, future maintainers, and anyone trying to understand lineage, decisions, or changes in terminology. **Expected stability:** Medium-high as record, low as authority. Historical research should remain stable as a record of what was thought at a time, but it should not govern current definitions unless explicitly reaffirmed by canonical content. **Relationship to other categories:** Historical research contextualizes vision, research, and architecture. It can explain why concepts changed, why alternatives were rejected, or why a term now has a narrower meaning. It should be clearly distinguished from current canonical content. ### 5. Concepts **Purpose:** Concept content defines the core vocabulary and distinctions of Perpetuals. It explains terms such as subject, claim, evidence, provenance, continuity, uncertainty, inspection, record, source, transition, and judgment. **Intended audience:** Researchers, product teams, documentation writers, partners, educators, and contributors who need consistent language across the ecosystem. **Expected stability:** Medium-high. Concepts should evolve when research requires it, but they should not vary by product, example, or audience segment. **Relationship to other categories:** Concepts translate research into reusable definitions. Architecture relates concepts to one another. Products apply concepts. Documentation teaches concepts in product-specific contexts. Specifications may formalize concepts for precision. ### 6. Architecture **Purpose:** Architecture content describes the relationships among the ecosystem's concepts, principles, products, roles, boundaries, and content types. It defines how Perpetuals holds together as a system of ideas and products. **Intended audience:** Founders, product leads, researchers, documentation owners, and contributors coordinating work across multiple products or knowledge domains. **Expected stability:** Medium. Architecture should adapt as the ecosystem grows, but it should not be rewritten for each product. It should change only when the relationship model changes. **Relationship to other categories:** Architecture connects principles, concepts, research, products, and specifications. It explains how product content depends on canonical concepts and how research becomes product-relevant without becoming product copy. ### 7. Products **Purpose:** Product content defines each Perpetuals product as a bounded expression of the ecosystem. It explains what the product is for, what problem it addresses, what it does not claim to solve, and how it applies Perpetuals principles. **Intended audience:** Product teams, users, partners, support contributors, researchers, and readers evaluating a specific Perpetuals product. **Expected stability:** Medium-low. Product content may change as products mature, users respond, and the ecosystem adds new products. **Relationship to other categories:** Product content depends on vision, principles, concepts, and architecture. Products should not redefine project-wide terms. If a product reveals that a concept is inadequate, the change should be resolved at the concept or architecture level, not patched locally inside product content. ### 8. Product Documentation **Purpose:** Product documentation explains how a specific product should be understood, used, interpreted, supported, and evaluated. It includes product-specific explanations, operating assumptions, usage guidance, release context, and supportable claims. **Intended audience:** Users, product teams, support contributors, partners, and people integrating or evaluating a product. **Expected stability:** Low-medium. Documentation changes with product behavior, maturity, use cases, and user feedback. **Relationship to other categories:** Product documentation is downstream of product content and specifications. It should teach product-specific usage without creating new ecosystem principles or redefining core concepts. When it needs a definition, it should point back to the canonical concept or specification. ### 9. Specifications **Purpose:** Specifications define precise content objects, fields, states, relationships, vocabularies, decision categories, or interoperability expectations at a formal conceptual level. They are narrower than architecture and more exact than explanation. **Intended audience:** Product contributors, technical writers, researchers, auditors, integrators, and anyone needing precise shared definitions. **Expected stability:** Medium. Specifications should be version-conscious because downstream documentation, examples, integrations, and evaluations may rely on them. **Relationship to other categories:** Specifications formalize concepts and product requirements. They should be constrained by principles and architecture. Examples may illustrate specifications, but examples should not alter them. ### 10. Examples **Purpose:** Examples make abstract ideas concrete. They include scenarios, sample subjects, illustrative records, applied walkthroughs, and concrete demonstrations of how concepts operate in context. **Intended audience:** New readers, users, educators, researchers, product teams, and contributors who need a concrete reference point. **Expected stability:** Low-medium. Examples may be revised or retired as products and concepts mature. **Relationship to other categories:** Examples illustrate concepts, architecture, products, and specifications. They are not canonical definitions. If an example appears to introduce a new rule, the rule should be elevated into the appropriate canonical content type or removed from the example. ### 11. Case Studies **Purpose:** Case studies examine real or plausible domains, subjects, institutions, workflows, or incidents to show how Perpetuals concepts apply under situated conditions. They differ from simple examples because they carry more analytical weight and often reveal constraints, exceptions, or failure modes. **Intended audience:** Researchers, partners, product strategists, domain experts, and advanced readers evaluating Perpetuals in context. **Expected stability:** Medium. The facts or framing of a case study may change, but the case can remain useful as an analytical record. **Relationship to other categories:** Case studies draw from research and examples. They may inform future research, sharpen concepts, expose product requirements, or motivate specifications. They should not create project-wide doctrine on their own. ### 12. Glossary **Purpose:** Glossary content provides concise canonical definitions of important terms. It is a reference layer, not a place for extended argument. **Intended audience:** Everyone, especially new readers, documentation users, writers, product contributors, and external partners. **Expected stability:** Medium-high. Glossary entries should change when canonical concepts change, not when local wording preferences change. **Relationship to other categories:** The glossary should summarize concepts, not replace them. Each glossary term should correspond to a more complete conceptual definition when the term is central to the ecosystem. ### 13. Updates **Purpose:** Updates communicate meaningful changes to products, research status, specifications, ecosystem direction, or public availability. Updates are time-bound and should help readers understand what changed and why. **Intended audience:** Users, contributors, partners, researchers, and external observers who need to follow the evolution of Perpetuals. **Expected stability:** Low as current guidance, high as dated record. Updates become historical after their immediate relevance passes. **Relationship to other categories:** Updates announce changes; they should not be the only place where a new canonical rule exists. If an update changes a principle, concept, product boundary, or specification, the relevant canonical content must also be changed. ### 14. News **Purpose:** News content, if used, should report public events, launches, partnerships, milestones, publications, or external references. It should be factual and dated. **Intended audience:** External readers, partners, users, contributors, and observers following the public development of the ecosystem. **Expected stability:** Low as active relevance, high as historical record. **Relationship to other categories:** News should reference canonical content rather than define it. It may point to products, research, specifications, or updates, but it should not become the authoritative source for concepts or principles. ## Part 2 — Public vs Internal Each content type can be classified by its default publication posture. Public content supports understanding and trust. Internal content supports decision-making and coordination. Mixed content has both public and internal forms. | Content type | Classification | Rationale | | --- | --- | --- | | Vision | Public | The ecosystem's purpose should be externally understandable and stable. Internal drafts may exist, but the canonical vision should be public. | | Principles | Public | Principles govern how Perpetuals makes claims and should be visible to users, partners, and contributors. Internal elaborations may exist for decision-making. | | Research | Mixed | Some research should be public to support accountability and credibility. Some may remain internal while unresolved, sensitive, speculative, or operationally premature. | | Historical Research | Mixed | Public historical research can preserve intellectual lineage, but some internal history may include discarded strategy, private decisions, or incomplete reasoning. | | Concepts | Public | Core vocabulary should be public because product and documentation meaning depends on shared definitions. | | Architecture | Mixed | Ecosystem-level conceptual architecture should be public where it explains relationships and boundaries. Internal architecture may include planning assumptions or coordination details. | | Products | Public | Product purpose, boundaries, and relationship to Perpetuals should be public. Internal product strategy may remain separate. | | Product Documentation | Public | User-facing documentation should be public when the product is public. Internal operational documentation may exist separately. | | Specifications | Mixed | Public specifications support clarity, evaluation, and interoperability. Internal specifications may exist for draft, experimental, or non-public product areas. | | Examples | Public | Examples are useful for teaching and should usually be public. Internal examples may be used for testing sensitive or provisional scenarios. | | Case Studies | Mixed | Public case studies can demonstrate applicability. Internal case studies may involve sensitive domains, partner context, or unfinished analysis. | | Glossary | Public | Shared definitions must be visible to avoid inconsistent interpretation. | | Updates | Public | Updates that affect users, public research, or product understanding should be public. Internal updates may coordinate work before public release. | | News | Public | News is inherently public if used at all. | The default bias should be public for canonical explanatory content and mixed for content that is exploratory, operationally sensitive, partner-specific, or not yet ready to govern public interpretation. ## Part 3 — Content Relationships The Perpetuals content model should be understood as a relationship graph, not a sequence of pages. Content types relate by authority, dependency, and feedback. ### Foundational relationship ```text Vision ↓ Principles ↓ Concepts ↓ Architecture ↓ Products ↓ Product Documentation ``` Vision establishes the ecosystem's reason for existing. Principles translate that reason into durable constraints. Concepts provide shared vocabulary. Architecture explains how the concepts and products relate. Products apply the architecture in bounded forms. Product documentation explains those products to their users. ### Research relationship ```text Research ↔ Concepts Research ↔ Principles Research ↔ Architecture Research ↔ Products ``` Research informs principles, concepts, architecture, and product boundaries. It also receives feedback from product use and case studies. This relationship is bidirectional, but not symmetrical: research may challenge canonical content, while canonical content changes only after synthesis and deliberate adoption. ### Specification relationship ```text Concepts + Architecture + Products ↓ Specifications ↓ Product Documentation + Examples ``` Specifications formalize concepts and product requirements. Documentation and examples should rely on specifications when precision matters. Specifications should not invent ecosystem concepts without alignment to the concept layer. ### Example and case study relationship ```text Concepts + Products + Specifications ↓ Examples ↓ Case Studies ↓ Research Feedback ``` Examples illustrate how the model works. Case studies test how the model behaves in richer contexts. Strong case studies may produce research feedback, identify missing concepts, or motivate new specifications. ### Historical relationship ```text Historical Research ↓ Explains evolution of Vision, Principles, Concepts, Research, and Architecture ``` Historical research records where current positions came from. It should help readers understand why Perpetuals uses its current concepts and boundaries. It should not compete with current canonical definitions. ### Update and news relationship ```text Canonical Content Change ↓ Update or News ↓ Historical Record ``` Updates and news communicate change, but they do not replace canonical content. If something becomes a new rule, definition, product boundary, or specification, the canonical source must change too. ## Part 4 — Growth Model The content architecture should support future products beyond Inspect without requiring a redesign. The key is to keep Perpetuals-level content separate from product-level content while maintaining explicit relationships between them. ### Ecosystem layer remains stable The following content types should remain ecosystem-level: - Vision - Principles - Research - Historical Research - Concepts - Architecture - Glossary These types define the shared frame for all products. They should not be nested under Inspect or any future product. Inspect may draw from them, but it should not own them. ### Product layer repeats per product Each product can have its own bounded set of product-level content: - Product definition - Product documentation - Product-specific specifications - Product examples - Product case studies - Product updates This pattern can repeat for Inspect and for any future product without changing the ecosystem model. New products become additional expressions of Perpetuals rather than new centers of authority. ### Cross-product concepts stay canonical When multiple products use the same concept, that concept belongs at the ecosystem level. For example, if Inspect and a future product both rely on continuity, provenance, evidence, or claims, those terms should be defined once in canonical concept content and then applied in product-specific documentation. ### Product-specific terms remain bounded A product may need terms that do not apply across the whole ecosystem. Those terms can live in product documentation or product specifications. They should not be promoted to the ecosystem glossary unless they become broadly relevant. ### Feedback moves upward deliberately Future products will reveal missing distinctions, weak definitions, and new cases. That feedback should move upward through research and architecture before becoming a changed principle or canonical concept. This prevents product growth from fragmenting the language of Perpetuals. ### The model scales by adding instances, not categories The architecture should not add a new top-level content type for every product or campaign. It should add new instances of existing types. A second product needs product content, documentation, specifications, examples, case studies, and updates; it does not require a new content architecture. ## Part 5 — Canonical Content Principles Future Perpetuals content should follow these rules. ### 1. One canonical source per concept Every core concept should have one canonical definition. Other documents may explain, summarize, or apply the concept, but they should not redefine it independently. ### 2. Separate authority from illustration Examples and case studies may clarify a concept, but they should not become the source of the concept's definition. If an illustration introduces a new rule, the rule must be promoted into the appropriate canonical content type. ### 3. Research can challenge; synthesis governs Research should be allowed to question principles, concepts, and architecture. However, a research document does not automatically change canonical meaning. Canonical change requires synthesis and explicit adoption. ### 4. Products apply principles; they do not redefine them A product may expose limitations in a principle, but it should not locally rewrite the principle. Changes to principles belong at the ecosystem level. ### 5. Documentation should not carry hidden doctrine Product documentation should explain how to use and interpret a product. It should not be the only place where an ecosystem-level claim, rule, or concept is defined. ### 6. Updates announce change; they do not contain the only change If an update communicates a new definition, boundary, or specification, the canonical source must also be revised. Updates should not become buried sources of authority. ### 7. Historical content must be legible as historical Older research and prior framings should remain available where useful, but readers must be able to tell when historical material is no longer current authority. ### 8. Public content should avoid overclaiming Public content should preserve the distinction between evidence and conclusion, claim and subject, provenance and truth, continuity and identity, uncertainty and ignorance, inspection and judgment. ### 9. Product growth should reuse the model Future products should be added as new product instances within the existing content architecture. The project should not create a new content model simply because a new product exists. ## Part 6 — Final Recommendation The smallest coherent content architecture for Perpetuals should contain three layers and fourteen content types. ### Layer 1: Ecosystem Canon This layer defines Perpetuals itself. - Vision - Principles - Concepts - Architecture - Glossary These content types should be public by default and highly controlled. They provide the stable foundation for perpetuals.io, Inspect, future products, documentation, and research. ### Layer 2: Inquiry and Evolution This layer explains how the ecosystem learns and changes. - Research - Historical Research - Case Studies These content types may be public or mixed. They preserve inquiry, evidence, critique, practical learning, and intellectual lineage. They inform the canon but do not automatically override it. ### Layer 3: Product Expression This layer explains bounded product applications of Perpetuals. - Products - Product Documentation - Specifications - Examples - Updates - News These content types allow Inspect and future products to exist without narrowing the meaning of Perpetuals. Product content can grow substantially while the ecosystem canon remains stable. ### Recommended canonical model ```text Ecosystem Canon Vision Principles Concepts Architecture Glossary Inquiry and Evolution Research Historical Research Case Studies Product Expression Products Product Documentation Specifications Examples Updates News ``` This is the smallest model that can support: - perpetuals.io as the public expression of the ecosystem; - Inspect as the first bounded product; - future products without redesigning the content model; - future documentation without duplicating core concepts; - future research without confusing inquiry with canonical authority. The governing idea is simple: Perpetuals should maintain a stable ecosystem canon, a disciplined research layer, and repeatable product-expression patterns. That structure allows the project to grow while preserving conceptual integrity.