## Design Permission-Aware Retrieval for Design Files Design a search system for a design-editing agent. Users and agents issue short queries, typically one to five words, with optional structured filters. Searchable content includes files, design-system assets, components, styles, and prior designs. Files belong to organizations, teams, and folders, and users have different access roles. Assume a ranking service already exists and can score candidates; focus on indexing, retrieval, authorization, and reliability, including behavior when ranking is unavailable. ### Constraints & Assumptions - A search response must never reveal the existence or metadata of an unauthorized object. - Permission changes and content updates do not arrive atomically. - Queries may mix free text with organization, team, folder, type, or style filters. - The system should degrade usefully when the ranking service fails. ### Clarifying Questions to Ask - Which object fields and derived representations are searchable for each result type? - How quickly must grants and revocations affect search visibility? - Can an agent search only with the initiating user's permissions, or does it have narrower delegated capabilities? - Is cross-organization search ever valid for one principal? ### Part 1 — Define the Index and Query Contract Specify the indexed document shape for files, components, styles, and prior designs. Show how short text and structured filters become a retrieval request. #### What This Part Should Cover - Stable object IDs, object type, searchable fields, hierarchy IDs, version, and deletion state. - Separate exact, lexical, and semantic representations where useful. - Filter validation and a normalized query plan. - Incremental indexing with idempotent updates and tombstones. ```hint Keep identity out of display text Use stable IDs and explicit hierarchy fields so a rename does not require guessing access or ownership from a title. ``` ### Part 2 — Enforce Hierarchical Access Design authorization for organization, team, folder, and file roles. Explain which permission information is indexed, what is checked at query time, and how revocations avoid leakage. #### What This Part Should Cover - Effective permissions derived from hierarchy, direct grants, groups, and denials if supported. - Candidate filtering before sensitive metadata is returned. - A final authoritative check before response assembly. - Versioning or invalidation that handles permission changes and stale index entries. ```hint Optimize without weakening the final check Precomputed access tokens can narrow candidates, but an authoritative policy decision should guard every returned object. ``` ### Part 3 — Retrieve and Rank Candidates Describe candidate generation for short queries and filters, then the call to the existing ranking service. Include deduplication across result types and enough context for the ranker to score candidates. #### What This Part Should Cover - Lexical and semantic candidate sources suited to short, ambiguous queries. - Filter and permission application before an expensive ranking call. - A bounded candidate set with type-aware features. - Deterministic deduplication and pagination semantics. ```hint Retrieve broadly, return narrowly Candidate generation can combine methods, but only authorized, normalized object IDs should enter the ranking stage. ``` ### Part 4 — Degrade Reliably The ranking service becomes unavailable or slow. Define timeout, fallback, freshness, and observability behavior while preserving access controls. #### What This Part Should Cover - A circuit breaker and bounded timeout rather than unbounded retries. - A deterministic fallback ordering over authorized candidates. - Clear distinction between stale content, stale permissions, and ranker failure. - Metrics and traces that reveal recall, latency, filtering, and fallback use. ```hint Fall back before failing open The degraded path may reduce relevance, but it must execute the same authorization checks as the normal path. ``` ### What a Strong Answer Covers - A searchable object model and query plan tailored to short text plus filters. - Defense-in-depth authorization that never trades security for retrieval speed. - A clear boundary around the existing ranker. - A useful, observable fallback that preserves deterministic behavior and permissions. ### Follow-up Questions 1. How would you prevent a revoked file from appearing during an index-update backlog? 2. What fallback order would you choose when semantic ranking is unavailable? 3. How should an agent's delegated access differ from the initiating user's full access? 4. How would you measure whether permission filtering is damaging recall without logging unauthorized result details?