# Perpetuals Knowledge Architecture ## Purpose of This Document Perpetuals has moved from a loose collection of ideas into a research-led product ecosystem. At that stage, the central organizational problem changes. The project no longer needs only more documents, sharper claims, or additional examples. It needs an explicit architecture for knowledge itself. This document defines that architecture. It explains how vision, principles, research, conceptual models, architecture, product documentation, specifications, examples, and historical materials should relate to one another. It is not a repository structure, publishing plan, product roadmap, or implementation proposal. It does not move, delete, or redesign anything. Its purpose is to preserve conceptual integrity as Perpetuals grows. The core recommendation is that Perpetuals should organize knowledge by **abstraction level and canonical authority**, not by file location, authorship, chronology, or product surface. Readers should be able to tell whether a document defines the project, supports a claim, tests an idea, describes a product, specifies an interface, gives an example, or records historical context. ## Part 1 — Why Knowledge Architecture Matters Research-led projects often begin with exploration. Early documents ask open questions, test language, compare alternatives, and search for durable distinctions. That phase is productive precisely because the knowledge is unsettled. Concepts are allowed to overlap, hypotheses can be overstated and then corrected, and different documents may approach the same problem from different angles. Over time, however, the same flexibility can become a liability. As the number of documents grows, the project needs a way to distinguish between exploratory reasoning and canonical definition. Without that distinction, every document can appear equally authoritative, even when some documents are speculative, some are critical, some are evidentiary, some are product-facing, and some have been superseded by later synthesis. ### Document growth A growing document set creates navigational and interpretive pressure. New readers encounter many plausible starting points. Existing contributors may remember why a document was written, but future readers see only the document itself. If the knowledge architecture is implicit, people must infer whether a paper is foundational, provisional, obsolete, adversarial, public-facing, or merely illustrative. This increases the risk that: - older claims are repeated after they have been qualified elsewhere; - product language outruns research confidence; - research documents are mistaken for product specifications; - examples are treated as commitments; - critiques are treated as rejections rather than stress tests; - public-facing summaries compress away important boundaries. A knowledge architecture makes those relationships explicit. ### Multiple abstraction levels Perpetuals operates across several abstraction levels at once. It contains high-level vision, design principles, research hypotheses, conceptual vocabulary, architectural positions, product roles, interface descriptions, examples, and historical analysis. These levels should inform one another, but they should not collapse into one another. For example, a principle such as inspection before trust is more stable than a particular interface pattern. A research question about continuity may remain open even if a product uses continuity language. A case study may reveal a recurring pattern without becoming a universal claim. A specification may define a narrow vocabulary without proving the full infrastructure thesis. Knowledge architecture protects these distinctions. It prevents the project from confusing: - the reason Perpetuals exists with the products that express it; - research evidence with canonical doctrine; - conceptual models with implementation designs; - examples with strategy; - historical artifacts with current commitments. ### Avoiding duplicated concepts When knowledge is not layered, concepts tend to be redefined in many places. That creates subtle drift. A term such as continuity, provenance, inspection, evidence, claim, subject, architecture, or record may begin with one meaning and acquire inconsistent meanings across documents. Duplication is not always bad. Research documents may need to restate concepts in order to test them. Product documents may need simplified explanations. Examples may need local definitions. The problem arises when duplicate definitions compete for canonical authority. A durable knowledge architecture should therefore separate: - **canonical definitions**, which establish project-wide meaning; - **supporting explanations**, which teach or elaborate those definitions; - **research treatments**, which test or qualify them; - **product translations**, which adapt them for a particular audience or interface; - **historical uses**, which preserve earlier language without governing current usage. ### Preserving conceptual clarity over time Perpetuals is concerned with subjects, claims, evidence, provenance, continuity, uncertainty, inspection, and judgment. These are abstract concepts that can easily become vague if every document uses them differently. The project therefore needs a memory discipline: not only remembering what has been written, but remembering what each document is allowed to decide. The goal is not to freeze the project. Research-led work must change when evidence changes. The goal is to make change legible. A reader should be able to understand when a claim is current, when it is contested, when it is illustrative, when it is historical, and when it has been absorbed into a higher-level synthesis. Knowledge architecture matters because it gives Perpetuals a way to evolve without losing its center. ## Part 2 — Knowledge Layers A useful knowledge architecture should be durable enough to survive new documents and additional products, but simple enough that contributors can actually use it. The layering should answer four questions: 1. What kind of knowledge is this? 2. How authoritative is it? 3. How stable should it be? 4. How should it relate to the rest of the project? ### Candidate hierarchy A natural hierarchy is: 1. Vision 2. Principles 3. Research 4. Conceptual Models 5. Architecture 6. Products 7. Specifications 8. Examples 9. Archive This hierarchy is useful because it moves from the most abstract and stable knowledge toward the most concrete, contextual, and historical knowledge. It also reflects how a research-led ecosystem usually matures: vision motivates principles, principles guide research, research produces concepts, concepts inform architecture, architecture constrains products, products require specifications, specifications are clarified through examples, and older work eventually becomes archival context. However, this hierarchy should be evaluated critically before adoption. ### Alternative 1: Chronological organization A chronological structure would organize documents by when they were written. This is useful for understanding intellectual history, but weak as a canonical knowledge architecture. Chronology does not tell a reader whether an older document is still authoritative or whether a newer document is more speculative than an earlier one. Research-led projects often contain later experiments that are less canonical than earlier principles. Chronology belongs in archive and historical notes, not in the primary knowledge structure. ### Alternative 2: Product-first organization A product-first structure would organize knowledge around each product or interface. This is useful once a project has multiple operating products, but it is too narrow for Perpetuals. The project is not defined only by product surfaces. It is grounded in research questions and conceptual distinctions that must remain understandable across products. If product knowledge becomes the highest layer, the project risks allowing product needs to redefine core concepts opportunistically. Products should express the knowledge architecture, not govern it. ### Alternative 3: Research-first organization A research-first structure would put research documents at the top. This respects Perpetuals' origin as a research-led project, but it creates another problem: research is not always canonical. Some research documents argue, some criticize, some test, some synthesize, and some preserve uncertainty. If all research sits above vision and principles, the project may struggle to distinguish durable commitments from active inquiry. Research should remain central, but it should sit beneath vision and principles and above architecture and product translation. ### Alternative 4: Audience-based organization An audience-based structure would separate materials for founders, researchers, product designers, users, partners, auditors, and future contributors. This can be helpful for reading paths, but it is not a knowledge architecture. Audiences overlap, and the same document may serve more than one audience. Audience-based grouping should be a navigation aid layered on top of the knowledge structure, not the structure itself. ### Alternative 5: Canonical versus non-canonical only A simple structure could divide documents into canonical and non-canonical materials. This is attractive because it clarifies authority. But it is too binary. Supporting explanations, examples, critiques, audits, and historical documents may all be non-canonical in different ways. A critique is not an example. A demo profile is not an archive. A methodology document is not a product specification. Perpetuals needs more than an authority flag. It needs a layered map of function. ### Recommended hierarchy Perpetuals should adopt the following hierarchy: 1. **Vision** — why the project exists and what enduring problem it addresses. 2. **Principles** — durable constraints on how the project should reason and communicate. 3. **Research** — inquiry, evidence, critique, synthesis, and open questions. 4. **Conceptual Models** — canonical vocabulary and distinctions derived from research. 5. **Architecture** — relationships among concepts, products, roles, and system-level positions. 6. **Products** — product identities, purposes, boundaries, and user-facing roles. 7. **Specifications** — precise definitions of formats, interfaces, states, fields, or behaviors at the conceptual/specification level. 8. **Examples** — case studies, demo profiles, scenarios, and explanatory applications. 9. **Archive** — historical materials retained for context, lineage, and intellectual memory. This hierarchy should not be interpreted as a waterfall. Ideas may begin in examples, research, critique, or product feedback. The hierarchy defines where claims become authoritative, not where thinking begins. ## Part 3 — Definitions ### 1. Vision **Purpose:** Vision explains why Perpetuals exists at all. It defines the enduring problem space and the project's highest-level orientation. It should answer what the project is ultimately about without depending on any specific product, interface, technology, or market category. **Typical documents:** Foundational vision statements, project definitions, high-level problem framing, long-term direction documents. **Expected stability:** Very high. Vision should change rarely and only when the project has materially changed its understanding of its purpose. **Intended audience:** Everyone: founders, researchers, contributors, product teams, partners, and future readers trying to understand the project from first principles. ### 2. Principles **Purpose:** Principles define enduring constraints on judgment, design, and communication. They translate vision into discipline. They should prevent drift, overclaiming, and conceptual misuse. **Typical documents:** Design principles, interpretive principles, claim-boundary principles, research ethics, communication rules, product doctrine. **Expected stability:** High. Principles may be refined, but they should not change with every product or research cycle. **Intended audience:** Contributors who make decisions, write documents, design products, communicate externally, or interpret research. ### 3. Research **Purpose:** Research investigates whether the project's claims are true, useful, bounded, overextended, or incomplete. It includes positive arguments, skeptical critiques, evidence reviews, applied analysis, and synthesis. **Typical documents:** Research papers, critiques, evidence documents, comparative analyses, literature-style reviews, case evaluations, research synthesis documents, open-question registers. **Expected stability:** Medium. Research should be revisable as evidence improves. Individual research documents may remain historically important even after later synthesis qualifies them. **Intended audience:** Researchers, founders, product strategists, domain experts, and contributors who need to understand the evidentiary basis of the project. ### 4. Conceptual Models **Purpose:** Conceptual models define the project's core vocabulary and relationships. They explain what concepts mean, how they differ from adjacent concepts, and what claims the project can make using them. **Typical documents:** Definitions of subject, claim, evidence, provenance, continuity, uncertainty, inspection, record, transition, graph, attestation, verification decision, and related distinctions. **Expected stability:** Medium-high. Conceptual models should evolve when research requires it, but they should not fluctuate with product copy or examples. **Intended audience:** Researchers, product designers, specification writers, educators, and future contributors who need consistent language. ### 5. Architecture **Purpose:** Architecture explains how major concepts, product roles, research findings, and knowledge domains relate to one another. It is not code architecture or repository structure. It is the conceptual organization of the ecosystem. **Typical documents:** Product architecture, information architecture, knowledge architecture, ecosystem maps, relationship models between research and products. **Expected stability:** Medium. Architecture may evolve as the ecosystem expands, but it should change deliberately and with reference to vision, principles, and research. **Intended audience:** Founders, product leads, researchers, documentation owners, and anyone coordinating work across multiple documents or products. ### 6. Products **Purpose:** Product knowledge explains what each product is for, what problem it addresses, what boundaries it observes, and how it expresses the broader Perpetuals concepts. Product documents should not redefine the project's core concepts unless those changes are elevated back into conceptual models. **Typical documents:** Product descriptions, product role definitions, public-facing product documentation, interface purpose documents, user-facing explanatory material. **Expected stability:** Medium-low. Products may change more often than vision, principles, research, or conceptual models. **Intended audience:** Product teams, users, partners, support contributors, and readers trying to understand a specific Perpetuals expression. ### 7. Specifications **Purpose:** Specifications define precise terms, fields, states, relations, formats, or interface-level expectations. They are narrower than architecture and more formal than product explanation. A specification should state what must be consistent for a concept or product expression to be inspectable and interoperable at the documentation level. **Typical documents:** Minimal vocabulary documents, record definitions, interface documents, state descriptions, field definitions, decision taxonomies, schema-like conceptual specifications. **Expected stability:** Medium. Specifications should change through careful versioning of meaning, because downstream explanations and examples may depend on them. **Intended audience:** Product contributors, researchers, technical writers, interface designers, auditors, and anyone needing precision. ### 8. Examples **Purpose:** Examples make abstract ideas concrete. They show how concepts appear in scenarios, demo profiles, case studies, or applied analyses. Examples should clarify concepts without expanding the project's canonical commitments. **Typical documents:** Case studies, demo profiles, sample subjects, sample continuity records, scenario walkthroughs, applied analyses, illustrative interface content. **Expected stability:** Low-medium. Examples can be updated, retired, or reinterpreted as the project learns. Their authority is illustrative rather than definitional. **Intended audience:** New readers, product users, researchers testing concepts, and contributors who need concrete reference points. ### 9. Archive **Purpose:** Archive preserves historical documents, superseded claims, exploratory drafts, old strategies, prior research stages, planning notes, and intellectual lineage. Archive is not a trash category. It is a memory layer that allows the project to understand how its thinking changed. **Typical documents:** Historical research, superseded positioning, prior plans, outdated product copy, old audits, obsolete examples, retired hypotheses, earlier drafts retained for context. **Expected stability:** High as history, low as current authority. Archived documents should not be rewritten to match current thinking except to add context about status. **Intended audience:** Researchers, future maintainers, historians of the project, and contributors trying to understand why current positions emerged. ## Part 4 — Mapping Existing Work This section classifies existing Perpetuals and Inspect documentation categories. It does not move documents, delete documents, rename documents, or change product scope. ### Vision Vision materials belong at the top of the knowledge architecture. They should include documents that define Perpetuals' enduring purpose: making digital subjects, claims, evidence, provenance, continuity, and uncertainty more inspectable. The current vision and product architecture work belongs partly here, especially where it defines the problem, why Perpetuals exists, and the final project definition. ### Principles Principle material includes the durable design and judgment constraints already articulated in the project: evidence before conclusions, inspection before trust, explicit uncertainty, provenance matters, continuity is inspectable, claims are separable from subjects, context changes meaning, human judgment remains responsible, and contestability should be preserved. These principles should be treated as more stable than product copy and more normative than research findings. ### Research Research includes the continuity thesis, the skeptical critique, evidence testing, historical argument, applied analysis, and synthesis. Major research documents include the work on the Continuity Layer, the critique of the Continuity Layer, evidence about ambiguity after existing infrastructure, the case for why continuity matters now, and the research synthesis. This layer should preserve disagreement. A critique is not a failure of the knowledge architecture; it is part of the research layer's function. ### Conceptual Models Conceptual-model material includes definitions and relationships for continuity, continuity records, subjects, state references, transitions, events, observation graphs, attestations, verification decisions, claims, evidence, provenance, uncertainty, and inspection. The minimum continuity work belongs partly here because it identifies the smallest vocabulary needed to make continuity intelligible. Portions of research synthesis may also become conceptual-model material where it states the strongest supported and unsupported claims. ### Architecture Architecture includes documents that explain how Perpetuals' concepts, research, product roles, and information surfaces relate to one another. The vision and product architecture document belongs partly here, especially where it relates research to products and defines the role of Inspect. The Perpetuals.io information architecture belongs here as a product-facing information architecture document, though its authority should remain subordinate to vision, principles, and research synthesis. The present document also belongs in the architecture layer because it defines the structure of knowledge itself. ### Product Documentation Product documentation includes materials that explain what a product or interface is for, how it should be understood, and what boundaries it observes. Existing public-site documentation belongs here when it describes Perpetuals.io as a concept site and explains its safety and positioning. Inspect-related documentation, where present, should be classified here when it explains Inspect as a product or interface rather than as a research claim. Product documentation should inherit language from vision, principles, conceptual models, and architecture. It should not become the place where core concepts are newly defined. ### Demo Profiles Demo profiles belong in Examples. They help readers understand how an interface or concept might appear in practice. They should not be treated as evidence that a product has committed to a specific domain, future product line, or market category. If a demo profile reveals a recurring conceptual issue, that issue should flow upward into research or conceptual models before becoming canonical. ### Interface Documents Interface documents may belong to Product Documentation, Specifications, or Examples depending on their function: - if they explain the purpose of an interface, they belong to Product Documentation; - if they define required fields, states, labels, or interpretive categories, they belong to Specifications; - if they show a sample screen, sample profile, or scenario, they belong to Examples. The same interface area may therefore generate documents in several layers, but each document should declare its role. ### Methodology Methodology belongs primarily to Research. It explains how the project evaluates claims, compares alternatives, tests ambiguity, or decides whether a concept is supported. Some methodology may also inform Principles if it becomes a durable rule for how Perpetuals reasons. Methodology should not be buried in examples. If a case study depends on a method, that method should be visible as research method rather than implied by the example alone. ### Audits Audits belong primarily to Research when they evaluate conceptual validity, claim support, documentation consistency, or product-positioning accuracy. They may also belong to Archive after the audited condition changes. An audit should state whether it is evaluating current canonical claims, product communication, example quality, or historical drift. ### Planning Planning documents should not be treated as canonical knowledge unless they define an accepted architectural position. Most planning belongs outside the canonical layers or eventually in Archive. Planning may inform products or documentation work, but it should not override vision, principles, research synthesis, or conceptual models. ### Historical Research Historical research belongs either in Research or Archive depending on whether it still actively supports current claims. If it explains why a problem matters now or provides evidence for a current position, it remains Research. If it preserves prior framing that has been superseded, it belongs in Archive. The key question is not age. The key question is current authority. ## Part 5 — Knowledge Flow A knowledge architecture should describe not only where documents belong, but how ideas move. ### Where ideas begin Ideas may begin anywhere: in research questions, product feedback, interface confusion, examples, critiques, audits, conversations, or historical comparisons. The architecture should not force all ideas to begin at the top. In research-led ecosystems, valuable insights often begin as anomalies. A product example may reveal that a concept is unclear. A skeptical critique may reveal an unsupported claim. A demo profile may show that users confuse provenance with continuity. An audit may show that product language is stronger than research evidence permits. The beginning of an idea does not determine its authority. ### From idea to research An idea enters the Research layer when it becomes a question that needs evidence, comparison, critique, or synthesis. At this stage, the project should ask: - What problem does the idea explain? - What existing concepts already cover it? - What evidence supports it? - What would disprove or weaken it? - What adjacent systems or categories must be compared? - What boundaries prevent overclaiming? Research should tolerate uncertainty. Its role is not to make every idea canonical. Its role is to determine what the project can responsibly claim. ### When research becomes conceptual model Research becomes a conceptual model when a distinction proves durable across multiple arguments, critiques, or examples. A concept should not become canonical merely because it is rhetorically useful. It should become canonical when it helps the project preserve clarity and when alternatives have been considered. A research finding is ready to become conceptual-model material when: - the term is needed across multiple documents; - the concept has been compared with adjacent concepts; - its boundaries are understood; - its unsupported claims are known; - examples can be explained without changing the definition each time. ### When conceptual models become architecture Conceptual models become architecture when they need to be related to one another across the ecosystem. Architecture asks how the concepts fit together: how research informs products, how inspection relates to evidence, how continuity relates to provenance, how specifications relate to examples, and how product surfaces should inherit rather than distort core ideas. Architecture should not invent new concepts casually. It should arrange concepts that have already earned their place. ### When architecture becomes product Architecture becomes product when a product expresses a bounded part of the broader knowledge system for a specific use. This does not mean the product implements the entire architecture. It means the product's role can be explained in architectural terms. A product should become authoritative only about itself: its purpose, boundaries, audience, and interface role. It should not silently redefine project-wide terms. If product work reveals that a core term is inadequate, that insight should flow back into research and conceptual modeling. ### When product becomes specification A product need creates specification work when repeated interpretation requires precision. Specifications should define narrow, reusable structures: fields, states, labels, categories, distinctions, or expected meanings. They should reduce ambiguity without pretending to settle broader philosophical or research questions. ### When research should be revised Research should be revised when: - new evidence contradicts or qualifies a claim; - product feedback reveals recurring confusion; - examples fail to fit the conceptual model; - an adjacent field offers a better explanation; - a critique identifies a stronger reduction; - public-facing language begins relying on unsupported claims. Revision should preserve intellectual lineage. When possible, later synthesis should clarify the status of earlier research rather than erase it. ### How product feedback should influence research Product feedback should influence research by revealing where concepts fail under use. It should not directly rewrite canonical concepts without analysis. Feedback should be translated into research questions: - Which terms confused readers? - Which distinctions did users miss? - Which claims seemed stronger than the evidence supports? - Which examples clarified the issue? - Which interface categories created false certainty? - Which product needs expose a missing conceptual distinction? In this way, product feedback becomes evidence for research rather than pressure to simplify the project into marketing language. ### Complete lifecycle The recommended lifecycle is: 1. **Observation:** An idea, confusion, pattern, or problem appears. 2. **Exploration:** The idea is described informally or through examples. 3. **Research:** The idea is tested against evidence, alternatives, critiques, and boundaries. 4. **Synthesis:** Research determines what is supported, unsupported, unresolved, or historically useful. 5. **Conceptualization:** Durable concepts and definitions are extracted. 6. **Architecture:** Concepts are placed in relation to the broader ecosystem. 7. **Product translation:** Products express bounded parts of the architecture. 8. **Specification:** Repeated product or conceptual needs are made precise. 9. **Example:** Scenarios and demo materials clarify use. 10. **Feedback:** Use, critique, and audits reveal gaps. 11. **Revision or archive:** Knowledge is updated, reclassified, or preserved historically. ## Part 6 — Canonical Knowledge Canonical knowledge is the material that governs current project meaning. It should be limited, explicit, and carefully maintained. Not every useful document should be canonical. ### Canonical concepts Canonical concepts are the project's current authoritative definitions and distinctions. They should include only the concepts needed to preserve coherence across research, architecture, products, specifications, and examples. For Perpetuals, canonical concepts are likely to include subjects, claims, evidence, provenance, continuity, uncertainty, inspection, transition, record, attestation, and judgment boundaries. The exact canonical set should remain smaller than the total vocabulary used across all documents. Canonical concepts should answer: - What does this term mean in Perpetuals? - What does it not mean? - Which adjacent terms is it often confused with? - What level of confidence supports it? - Where should readers go for deeper explanation? ### Supporting explanations Supporting explanations teach canonical concepts without governing them. They may use analogies, diagrams, examples, summaries, or audience-specific language. They can be rewritten more freely than canonical definitions because their role is explanatory. A supporting explanation should not introduce a new meaning that conflicts with the canonical concept. If it needs to do so, the canonical concept should be revisited. ### Examples Examples illustrate concepts in context. They are especially useful for showing why a distinction matters. But examples should not become hidden doctrine. A virtual artist, agent migration, DAO fork, demo profile, or sample continuity record may clarify a concept without defining the project around that domain. Examples should remain replaceable. If replacing an example changes the core claim, then the claim was not actually independent of the example. ### Experiments Experiments test possibilities. They may include speculative concepts, exploratory interfaces, provisional taxonomies, or alternative framings. Experiments should be allowed to fail. Their value lies in what they reveal, not in whether they become canonical. Experimental documents should be clearly distinguishable from canonical documents so that readers do not mistake trial language for settled meaning. ### Historical documents Historical documents preserve the path of thought. They may contain outdated claims, stronger language than the project currently supports, or abandoned alternatives. They should not be deleted merely because they are no longer current. They help future readers understand why the current architecture exists. Historical documents should be contextualized rather than silently corrected. Their status should be clear: historical, superseded, partially current, or active. ### How canonical documents should change Canonical documents should change slowly, but not defensively. They should be updated when research, critique, evidence, or product feedback shows that the current definition is misleading or incomplete. A canonical change should generally include: - the reason for the change; - the prior ambiguity or limitation; - the new definition or boundary; - the documents affected by the change; - whether older materials are superseded, partially current, or historical. The purpose is continuity of meaning through change. Perpetuals should practice internally the same interpretive discipline it values externally. ## Part 7 — Future Growth The knowledge architecture should scale without inventing future products or assuming a particular roadmap. The safe assumption is only that the ecosystem may eventually contain multiple products, multiple interfaces, and more research domains. To scale, the architecture should preserve a clear distinction between project-wide knowledge and product-specific knowledge. ### Project-wide layers should remain shared Vision, principles, research synthesis, conceptual models, and ecosystem architecture should remain shared across the project. These layers prevent each product from developing its own incompatible vocabulary. If multiple products exist, they should all inherit the same core meanings of inspection, evidence, provenance, continuity, uncertainty, subjects, and claims unless research explicitly revises those meanings. ### Product layers should remain bounded Each product should have its own product documentation, interface documents, specifications, examples, and feedback loops. Product-specific materials should explain how that product expresses the broader architecture, not redefine the entire ecosystem. This allows products to differ without fragmenting the project's conceptual foundation. ### Specifications should be modular Specifications should be narrow and modular. A specification should define the precise scope it governs and avoid pretending to settle more than it does. This makes the knowledge architecture extensible: future product or interface needs can add specifications without rewriting the vision. ### Examples should multiply without becoming strategy As the ecosystem grows, examples will likely multiply. That is useful, but examples must remain subordinate to concepts. The architecture should allow many examples while preventing any single example category from becoming the implicit definition of Perpetuals. ### Archive should become more important, not less As Perpetuals matures, the archive becomes essential. It records why the project rejected certain claims, softened certain language, adopted certain boundaries, or changed its conceptual model. Without an archive, future contributors may repeat old arguments without knowing they were already tested. A growing ecosystem needs not only a front door, but a memory. ## Part 8 — Final Recommendation If someone joins Perpetuals five years from now, they should not begin by reading every document chronologically. They should navigate by knowledge layer. ### Recommended reading path 1. **Start with Vision.** Understand why Perpetuals exists and what problem it addresses at the highest level. 2. **Read Principles next.** Learn the constraints that govern judgment, claims, product language, and interpretation. 3. **Read Research Synthesis.** Understand what the project believes is supported, what remains unsupported, and what questions remain open. 4. **Read Conceptual Models.** Learn the canonical vocabulary: subjects, claims, evidence, provenance, continuity, uncertainty, inspection, records, transitions, and related distinctions. 5. **Read Architecture.** Understand how research, concepts, products, specifications, examples, and historical materials relate. 6. **Read Product Documentation.** Learn what each product or interface is for and what boundaries it observes. 7. **Read Specifications.** Study precise terms, fields, states, and interface-level meanings only after understanding the broader architecture. 8. **Read Examples.** Use scenarios, demo profiles, and case studies to make abstract concepts concrete. 9. **Read Archive last.** Explore historical materials to understand how the project changed, which claims were superseded, and why current positions are shaped as they are. ### How deeper understanding should unfold Understanding should unfold from purpose to discipline, from discipline to evidence, from evidence to concepts, from concepts to architecture, from architecture to products, from products to specifications, and from specifications to examples. Historical materials should deepen understanding after the reader knows the current map. This order prevents two common failures. First, it prevents readers from mistaking examples or product surfaces for the whole project. Second, it prevents readers from treating early research claims as current doctrine without reading later critique and synthesis. ### Why this supports long-term clarity The recommended knowledge architecture supports long-term clarity because it separates authority from existence. A document can exist without being canonical. A useful example can teach without defining. A critique can challenge without destroying. A product can express the architecture without owning it. A historical document can remain valuable without remaining current. This structure allows Perpetuals to grow while preserving conceptual integrity. It gives future contributors a way to ask not only "What does this document say?" but "What kind of knowledge is this, how authoritative is it, and how should it affect the rest of the project?" That is the central function of the Perpetuals knowledge architecture: to make the project's own knowledge inspectable through time.