# Curiosity System Model **The Curiosity Lab** Version: 0.1 Status: Accepted architectural distinction Decision date: 2026-07-23 Path: `/architecture/Curiosity-System-Model.md` --- ## 1. Decision The Curiosity Lab programme will distinguish clearly between three layers: ```text The Curiosity Lab → The Curiosity Engine → Curiosity Applications ``` These layers have different responsibilities. They should not be treated as interchangeable names for the same product. The accepted terminology is: ```text Curiosity Lab The research programme that develops and tests the theory, principles, methods and evaluation of curiosity through meaningful connection. Curiosity Seed The object, place, name, image, concept, question or observation that begins an exploration. Curiosity Engine The architecture that transforms a Curiosity Seed into structured, evidence-aware connected meaning. Curiosity Package The structured output produced by the Curiosity Engine for use by one or more Curiosity Applications. Curiosity App A domain-specific user experience that presents Curiosity Packages to people in a particular context. Meaning Trace A record of how a person explored, selected and combined meaning. ``` --- ## 2. Why This Distinction Is Necessary The programme has developed beyond a single prototype. The same underlying method may be useful in: ```text travel museums static exhibitions education learning materials local history reading cultural interpretation object-led exploration place-based discovery ``` Without a clear separation of responsibilities, the project risks confusing: ```text research theory content generation information architecture user-interface design application-specific features AI implementation ``` That confusion would make it difficult to answer: ```text What belongs to the research programme? What belongs to the connection-generating architecture? What belongs to a particular application? Which findings are general? Which findings are specific to travel, museums or education? ``` The distinction allows the programme to test the same theory through multiple applications without making one application define the whole project. --- ## 3. System Overview ```text THE CURIOSITY LAB Research, theory, principles, methods and evaluation ↓ THE CURIOSITY ENGINE Transforms a seed into structured connected meaning ↓ CURIOSITY APPLICATIONS Deliver the experience in a specific domain and context ↓ USER ACTIONS, OBSERVATIONS AND MEANING TRACES ↓ THE CURIOSITY LAB Evaluates findings and refines theory and methods ``` This is a feedback system. Curiosity Applications do not merely consume the work of the Lab. They also create practical evidence that may refine the Lab’s theories, principles and applied methodologies. --- # 4. The Curiosity Lab ## 4.1 Definition The Curiosity Lab is the research and development programme. Its central question remains: > **Can we intentionally design environments that cultivate curiosity through meaningful connection?** The Curiosity Lab develops and tests: ```text theory principles research findings applied methodologies experience patterns ethical standards evaluation methods research protocols ontologies terminology content-quality standards evidence standards ``` ## 4.2 Primary responsibilities The Curiosity Lab is responsible for determining: ```text what the programme means by curiosity; what makes a connection meaningful; how connected exploration may change understanding; how curiosity should be evaluated; what ethical boundaries apply; how evidence, interpretation and analogy should be distinguished; which experience patterns are supported by research or testing; which claims remain hypotheses; ``` ## 4.3 Outputs Typical Lab outputs include: ```text research papers domain reviews research-register entries product hypotheses experience principles pattern catalogues ontologies terminology test protocols experiment results ethical guidance architecture requirements ``` ## 4.4 The Lab is not The Curiosity Lab is not: ```text a travel guide; a museum application; an AI chatbot; a camera-recognition tool; a content-management system; a user interface; a single commercial product. ``` A particular Curiosity App may fail without invalidating the entire Lab. Equally, a successful application does not by itself prove the general theory. --- # 5. The Curiosity Seed ## 5.1 Definition A Curiosity Seed is the thing that begins exploration. It may be: ```text an object a place a building a street name a photograph a museum label a historical person a concept a lesson topic a quotation a scientific observation a landscape feature a search phrase a user question ``` Examples: ```text a bronze sestertius of Trajan; Qafa e Pazarit; Fletcher Street; a bridge in Berat; a slate roof in Gjirokastër; the word “empire” in a history lesson. ``` ## 5.2 Seed identification A seed may enter the system through: ```text manual selection search camera location QR code museum catalogue lesson content curated exhibition document link application context ``` The entry method does not determine the meaning of the seed. Camera, search and location are recognition mechanisms. They are not the Curiosity Engine itself. --- # 6. The Curiosity Engine ## 6.1 Definition The Curiosity Engine is the architecture that operationalises the theories and methods of the Curiosity Lab. It transforms a Curiosity Seed into structured, evidence-aware connected meaning. A simplified model is: ```text Curiosity Seed → identification → basic context → anchors → associations → relationship explanations → evidence and confidence → motifs and themes → narrative inserts → next questions → Curiosity Package ``` ## 6.2 Primary responsibilities The Curiosity Engine is responsible for: ```text identifying candidate anchors; finding or receiving candidate connections; classifying relationship bases; distinguishing fact, interpretation, hypothesis and analogy; recording evidence and confidence; identifying motifs and themes; generating or selecting Context Sparks; generating or selecting Structural Echoes; producing narrative-ready inserts; recording research debt; producing a consistent Curiosity Package; ``` ## 6.3 The Engine is a connection and meaning architecture The Engine should not be described only as a seed generator. The seed is normally the input. The Engine’s distinctive function is to produce: > **A structured account of what the seed connects to, why those connections matter and how they change the interpretation of the seed.** ## 6.4 The Engine is not necessarily AI The Curiosity Engine may combine: ```text curated content rules ontologies relationship types verified sources retrieval systems geographic context knowledge graphs human editorial judgement AI orchestration ``` AI may become an important component. It is not the definition of the Engine. A manually authored Curiosity Package may still be valid Engine output if it follows the same structure and standards. ## 6.5 Engine boundaries The Curiosity Engine should not decide: ```text screen layout visual hierarchy mobile navigation map presentation offline caching branding animation application-specific onboarding ``` Those belong to Curiosity Applications. The Engine may provide presentation hints, but it should not own the final user experience. --- # 7. Curiosity Package ## 7.1 Definition A Curiosity Package is the structured output produced by the Curiosity Engine. It allows the same connected meaning to be presented in different contexts. A provisional Curiosity Package may contain: ```text seed identity basic information source references identification confidence Base Narrative Narrative Anchors Associations Relationship Basis Why It Matters Evidence Category Confidence Level Narrative Inserts Context Sparks Motifs Themes Structural Echoes Analogy Limits Open Questions Nearby Threads Research Debt ``` ## 7.2 Why the package matters A Curiosity Package separates: ```text meaning architecture from application presentation ``` The same package might be used by: ```text a travel application; a museum touchscreen; a static exhibition; a classroom activity; a reading companion; an accessibility interface; ``` The presentation may differ. The evidence and relationships should remain consistent. ## 7.3 Example package fragment ```text Seed: Fletcher Street Possible interpretation: The name may preserve an occupational association with fletchers, who made arrows. Alternative interpretation: The street may instead be named after a person or family called Fletcher. Relationship basis: etymological occupational historical Evidence status: unverified hypothesis until local records are checked Why it matters: The name may preserve evidence of work, trade or local memory that is no longer visibly present. Narrative Insert: The name may preserve the memory of an occupation—a fletcher made arrows— although local records would be needed to show whether that trade gave this particular street its name. ``` This example illustrates an important rule: ```text a plausible interpretation is a question; a documented origin is an answer; they must not be represented as the same thing. ``` --- # 8. Curiosity Applications ## 8.1 Definition A Curiosity App is a domain-specific user experience that presents Curiosity Packages to users. Applications may include: ```text Curiosity Travel Curiosity Museum Curiosity Exhibition Curiosity Learning Curiosity Classroom Curiosity Reader Curiosity Local History ``` The exact names remain provisional. ## 8.2 Primary responsibilities A Curiosity App is responsible for: ```text entry mechanisms; camera, location or search interfaces; screen layout; navigation; accessibility; visual hierarchy; offline behaviour; maps; saved journeys; application-specific interaction; display of the Living Narrative Canvas; presentation of evidence and confidence; collection of optional Meaning Traces; ``` ## 8.3 App-specific behaviour Different applications may present the same Curiosity Package differently. ### Travel May emphasise: ```text location nearby threads walking context camera input street names physical observation offline use ``` ### Museum May emphasise: ```text object records gallery location material detail collection relationships display context ``` ### Learning May emphasise: ```text concept progression misconceptions examples transfer reflection assessment ``` ### Static exhibition May emphasise: ```text curated routes shared screens QR transitions short dwell time group interaction ``` The application changes. The Engine’s underlying evidence-aware connection model should remain recognisable. ## 8.4 Applications do not own the general theory A Curiosity App may discover new experience patterns. Those patterns should be evaluated by the Curiosity Lab before becoming general principles. Application-specific behaviour should not silently become programme-wide theory. --- # 9. Meaning Trace ## 9.1 Definition A Meaning Trace records how a user explored a Curiosity Package. It may include: ```text seed encountered anchors explored associations previewed associations selected themes revealed Structural Echoes followed narrative changes optional user question optional reflection context of use ``` ## 9.2 Purpose The Meaning Trace has two roles. ### User-facing role It may help the user see how their understanding developed. ### Research role It may help the Curiosity Lab evaluate: ```text which connections were followed; which relationships were understood; which themes emerged; where users became confused; whether the original seed was seen differently; whether a better question emerged. ``` The Meaning Trace should not become hidden behavioural profiling. --- # 10. Responsibility Matrix | Concern | Curiosity Lab | Curiosity Engine | Curiosity App | |---|---:|---:|---:| | Curiosity theory | Owns | Applies | Tests through use | | Research standards | Owns | Must follow | Must follow | | Connection taxonomy | Defines | Uses | Presents selectively | | Evidence categories | Defines | Assigns | Displays | | Seed recognition | Studies requirements | May support | Initiates and presents | | Association generation | Defines quality | Owns | Requests and consumes | | Narrative Inserts | Defines principles | Produces or selects | Presents and weaves | | Interface layout | Evaluates patterns | Does not own | Owns | | Camera and location UX | Evaluates findings | Accepts context | Owns | | Offline behaviour | Does not own | Supports package portability | Owns | | Meaning Trace schema | Defines research need | Structures | Captures and presents | | Experiment results | Owns analysis | Supplies logs | Produces observations | --- # 11. Example: Albania Travel Application The proposed Albania MVP is a Curiosity App. It should not be treated as the Curiosity Engine itself. ## 11.1 Application input ```text camera location search manual city browsing ``` ## 11.2 Curiosity Seeds Examples: ```text Berat Gorica Bridge Mangalem Qafa e Pazarit Gjirokastër Çerçiz Topulli Square a stone roof a street name ``` ## 11.3 Engine output For each seed, the Engine or its curated equivalent produces: ```text basic identity Base Narrative anchors associations relationship explanations evidence and confidence Narrative Inserts themes possible Structural Echoes nearby threads ``` ## 11.4 App output The travel application presents: ```text what is nearby; what the user is looking at; which detail may be explored; why a connection exists; how the story changes; what nearby place continues the thread. ``` The Albania MVP is therefore: > **The first place-based Curiosity App and a practical test client for the Curiosity Engine.** --- # 12. Static and Dynamic Experiences The system model supports both static and dynamic applications. ## 12.1 Static applications Examples: ```text museum exhibitions gallery installations printed learning materials curated websites school resources object labels ``` In static contexts, Curiosity Packages may be: ```text fully curated pre-verified fixed before publication designed for a known sequence or space ``` ## 12.2 Dynamic applications Examples: ```text travel guides camera-led discovery location-aware exploration search-led learning personal reading companions ``` In dynamic contexts, Curiosity Packages may combine: ```text curated foundations retrieval live context AI-assisted connection generation dynamic confidence and source checks ``` The same Lab principles and Engine quality standards should apply to both. --- # 13. Architectural Principles ### CS-001 — Research, generation and delivery are separate concerns Do not collapse the Lab, Engine and App into one system. ### CS-002 — The seed is input, not output The Engine transforms seeds into connected meaning. ### CS-003 — Connections require explanations An association is incomplete until the system can explain why it exists. ### CS-004 — Meaning architecture is reusable Curiosity Packages should be usable by more than one application where appropriate. ### CS-005 — Applications own presentation The Engine should not dictate the final interface. ### CS-006 — Applications return evidence Meaning Traces and observations should inform the Lab. ### CS-007 — AI is a component, not the architecture The Engine must remain understandable without assuming a particular AI model. ### CS-008 — Evidence status survives every layer Facts, interpretations, hypotheses, analogies and uncertainty must not be flattened during delivery. ### CS-009 — Application success does not equal theoretical proof Findings must be evaluated within an explicit research design. ### CS-010 — Theory must retain implementation potential Lab concepts should remain capable of being represented through Engine structures and tested through Applications. --- # 14. Consequences ## Positive consequences ```text The travel MVP no longer defines the whole programme. The same theory can support multiple application domains. AI can be introduced later without becoming the project identity. Curated and generated content can share one structure. User-interface experimentation can proceed without rewriting the ontology. Research findings can be traced back to the layer that produced them. ``` ## Costs ```text The repository will require clearer architecture documentation. Curiosity Package schemas must be designed deliberately. Application-specific features must not leak into the Engine. The Engine may require adapters for different applications. The project must maintain evidence and terminology consistently. ``` --- # 15. Repository Implications This document should live at: ```text /architecture/Curiosity-System-Model.md ``` It should become the primary record of the system distinction. Later documents should reference it from: ```text /README.md /architecture/Ontology.md /architecture/Pattern-Catalogue.md /references/Terminology.md /mvp/Product-Vision.md ``` A short formal decision entry may also be added later to: ```text /governance/Decision-Log.md ``` The architecture document should remain the full explanation. The Decision Log should contain only a concise record and link. --- # 16. Required Terminology Promotions The following terms should be added to `/references/Terminology.md` during Gate 2 consolidation: ```text Curiosity Lab Curiosity Seed Curiosity Engine Curiosity Package Curiosity App Meaning Trace ``` Existing terms such as: ```text Narrative Anchor Association Relationship Basis Context Spark Structural Echo Meaning Weave Meaning Accretion ``` should be defined as elements that may appear inside a Curiosity Package or its presentation. --- # 17. Review Triggers Review this distinction if: ```text the Engine begins to require application-specific presentation logic; different application domains require incompatible package structures; the Lab cannot evaluate findings consistently across applications; AI-generated and curated packages cannot share evidence standards; the term “Curiosity Engine” proves misleading in practical use; the system requires an additional layer such as content governance or source services. ``` The distinction is accepted, but its implementation boundaries should remain testable. --- # 18. Immediate Next Actions ```text 1. Add this file to /architecture/. 2. Add the six accepted terms to Terminology.md during consolidation. 3. Reference this model from Product-Vision.md and README.md. 4. Define a minimal Curiosity Package schema for the Albania MVP. 5. Treat the current HTML Roman coin tester as the first Curiosity App prototype. 6. Treat the Albania travel MVP as the first place-based Curiosity App. 7. Record observations separately for Lab theory, Engine behaviour and App experience. ``` --- # 19. Final Statement > **The Curiosity Lab develops and evaluates the theory. > The Curiosity Engine transforms seeds into evidence-aware connected meaning. > Curiosity Applications deliver that meaning through experiences designed for particular contexts.** This separation allows one research programme and one meaning architecture to support many practical applications without allowing any single application to define the whole project.