# Retrieval Status: settled semantic contract, 2026-09-11; physical queries and indexes are specified separately and remain unbuilt. Owner: platform-wide structured retrieval, optional constrained semantic retrieval, and authorised context assembly. Examples are conceptual acceptance cases, not query-language or database commitments. ## Canonical Prerequisites - [Objects and types](objects-and-types.md) owns `{id,type,value}`, addressable type definitions, type validity, and type-family decisions. - [Business model](business-model.md) owns the connected graph, relationship meaning, and same-model Business DNA. - [Semantics](semantics.md) owns business meanings, including rules and policies used to interpret requests. - [Time and events](time-and-events.md) owns current/historical and effective/recorded-time interpretation. - [Identity and governance](identity-and-governance.md) owns visibility, permissions, and access context. - [Knowledge](knowledge.md) owns provenance and epistemic distinctions for knowledge, not the retrieval of all platform data. ## Scope and Invariants Retrieval is a platform capability for ordinary application screens, reports, workflows, integrations, human search, and optional AI. It is neither knowledge-only nor AI-only, and must remain useful with no AI provider configured. Orders, people, configuration, types, relationships, events, workflows, content, and knowledge can all be retrieval subjects. Every persistent/addressable subject uses the universal model, including saved query definitions and retrieval configuration when addressable. Type definitions themselves are addressable and retrievable under the same access requirements. The Business Graph is connected same-model data, not a corpus flattened into text for search. Business DNA is not a privileged parallel index or hidden provider memory. Retrieval uses declared structure before expensive semantic/vector techniques, reducing candidates progressively. A new business type must participate without requiring a new foundational schema or a bespoke capability-specific search universe. This responsibility does not mandate a separate service, search engine product, graph database, or vector store. ## Request and Result Contract A request identifies the acting User (or the User whose delegated authority an automation operates under) and permitted business context as well as the information need. Structured requests may directly supply types, relationships, properties, time, ordering, and a result projection. Natural-language interpretation may propose those constraints but cannot grant access or redefine business meanings. Ambiguous entity names, type families, "outstanding", or "this quarter" require an explicit interpretation or clarification. An interpretation must not quietly broaden scope until something is found. Results provide authorised object references and relevant values with enough context to explain their inclusion. Where material to the answer, preserve source, applicability, confidence, authority, time basis, and completeness limitations. Existence, epistemic standing, contextual applicability and authority are separate retrieval dimensions. Connectivity alone grants neither access nor inference. A permitted historical query can return a challenged or superseded Assertion with its standing intact; it must not present that result as currently operative knowledge. An empty result, denied access, ambiguous request, incomplete index, and unavailable source are not interchangeable outcomes. Explanations themselves must not disclose the existence or attributes of inaccessible objects. ## Structured-First Pipeline 1. Interpret the request in the authorised business context, using explicit model terminology where available. 2. Identify relevant object types or type families from addressable definitions and declared classifications. 3. Constrain by graph relationships and endpoints, not only by text matching or coincidental property names. 4. Apply relevant state, properties, time, ownership, responsibility, provenance, authority/confidence, and permissions. 5. Use semantic/vector retrieval only where it adds value within the authorised, structurally constrained candidate set. 6. Assemble authorised context or a structured answer, retaining source references and material qualifications. This is a conceptual narrowing strategy, not a mandated database execution-plan order. Permission constraints apply throughout; the numbered sequence never authorises exposing broad candidates before access checks. If structure answers the question fully, stop without a semantic stage. If semantic retrieval is unavailable, return supported structured results or explain the limitation; do not disable ordinary retrieval. ## Deterministic Retrieval Dimensions | Dimension | Expected use | | --- | --- | | Type | Primary indexing and narrowing dimension guaranteed by every object's primitive. | | Type family and relationships | Use declared families, composition, and semantic classifications as supported by canonical type decisions. | | Graph relationships | Traverse meaningful connections with identified endpoints, direction, and permitted relationship context. | | State/status | Use the subject type's declared business state rather than imposing one lifecycle across objects. | | Properties | Filter exact values, ranges, identifiers, and other deterministic properties suitable for indexing. | | Time | Distinguish creation, update, occurrence, and effective dates as applicable to the request. | | Ownership/responsibility | Narrow to the relevant business owner or assignee without equating ownership with universal permission. | | Provenance/source | Find imported, observed, user-authored, or otherwise sourced material and preserve its origins. | | Authority/confidence | Distinguish applicability and approval standing from certainty or semantic similarity. | | Scope/applicability/standing | Match the Business, object, workflow/action, time and conditions; preserve accepted, challenged, rejected or superseded standing without treating acceptance as universal scope. | | Permissions | Constrain objects, relationships, fields, projections, and access context under governance. | These dimensions apply across the platform, not only to documents with metadata. For example, an imported Order can have provenance, a workflow can have ownership, and a Policy can have effective dates. No type-family inheritance rule or authority precedence is invented by the retrieval layer. ## Acme Outstanding Orders Example Request: "Which outstanding orders does Acme have from this quarter?" Identify the relevant Customer and Order types or declared families in the authorised business model. Locate Acme's Customer object; if multiple permitted matches exist, disambiguate using relevant context. Traverse the relationship that connects that customer to its orders rather than searching all text for "Acme". Interpret "outstanding" from the Order model's state/properties, not an AI guess at a universal status vocabulary. Resolve the intended quarter and relevant order date using business context and Time and Events; make ambiguity visible. Constrain related Orders by that state and time interval, plus applicable ownership, provenance, and access requirements. Return the authorised order projection with its interpretation and material limitations. Semantic retrieval is unnecessary if those structural constraints answer the request. If the user additionally asks for "orders affected by the packaging problem", a constrained search of related authorised notes may help. That extension does not permit a broad vector search across unrelated tenants, orders, policies, and documents. ## Indexes and Consistency Indexes are derived retrieval infrastructure, not alternative foundations or the authoritative business representation. Type, relationship endpoint, state, date, ownership, and permission-aware indexes should exploit deterministic structure where useful. Choosing which properties to index and how to maintain indexes belongs to physical implementation design. Semantic embeddings are optional derived representations and must preserve association with their source objects and context. A retrieved fragment cannot gain broader visibility than its source because it was copied into an index. Changes to objects, relationships, types, source applicability, and permissions can affect candidate validity. The implementation must address stale indexes, permission changes, and deletion/correction propagation explicitly before claiming correctness. Index lag must not become permission to disclose revoked information or to assert complete results without evidence. The initial implementation queries durable typed objects/revisions and relationship indexes directly, rechecking visibility and applicability against current authoritative records. Optional asynchronous or vector indexes are deferred; neither their absence nor later lag can weaken access checks or commit-time validation. ## Context Assembly and Historical Retrieval Context assembly serves a human view, deterministic action, report, or optional AI request; it is not synonymous with prompt construction. It retains object identity and meaningful relationships instead of presenting disconnected snippets as equivalent facts. Knowledge passages retain source/provenance and authority distinctions from the Knowledge contract. An answer about last quarter must not silently substitute today's policy or current owner for historically relevant context. Historical reconstruction and visibility follow Time and Events and Governance; this document does not promise replay or event sourcing. Aggregates, counts, related-object labels, and explanations must respect access boundaries as well as primary results. AI receives only controlled context through [AI](ai.md); authorisation cannot be delegated to a model's decision about relevance. Consumers must not treat retrieved configuration or source prose as permission to execute it. ## Positive and Negative Examples Positive: a no-AI order list and an AI assistant use the same authorised structural constraints to find Acme's outstanding orders. Positive: a technician filters Equipment by service relationship and due date before searching associated procedural knowledge. Positive: a policy answer identifies the applicable source and date and distinguishes an approved policy from a related inference. Negative: embedding every object and searching the entire platform first ignores guaranteed type and relationship structure. Negative: restricting Retrieval to a knowledge-base screen forces workflows and reports to invent competing retrieval rules. Negative: returning restricted document titles in "excluded sources" leaks information despite hiding document contents. Negative: using a similarity score to decide policy authority confuses relevance with business governance. ## Implementation and Acceptance [D01-D10 are settled](../governance/decisions.md). The [initial storage/query mechanism](../implementation/architecture.md#physical-model-mapping) implements these boundaries with deterministic queries and stable pagination. [Roadmap](../product/roadmap.md) prioritises authorised Business-context object inspection; the wider Acme example remains a reusable conformance case, not a generic CRM requirement. Acceptance checks: answer the Acme example without AI; narrow by all relevant deterministic dimensions; test relationship/field access; preserve authority distinctions; expose incomplete results honestly; show new types joining retrieval without a new foundational model. [Implementation architecture](../implementation/architecture.md) owns physical queries/indexes; [Development](../implementation/development.md) owns checks and [Implementation status](../implementation/status.md) owns verified evidence. ## Source Lineage [Source map](../governance/source-map.md) tracks preservation; [documentation ownership](../governance/documentation.md) governs ownership changes. [01 product and principles](../archive/architecture-sources/01-idiosyncrasy-product-and-principles.md), structured retrieval; [02 technical architecture](../archive/architecture-sources/02-idiosyncrasy-technical-architecture-and-data.md), section 3.2 and Acme example; [03 engines and MVP](../archive/architecture-sources/03-idiosyncrasy-engines-workflows-and-mvp.md), section 2.1 establish the contract. [00 combined handoff](../archive/architecture-sources/00-idiosyncrasy-combined-handoff.md) preserves their combined presentation; no separate knowledge-search authority is carried forward.