Why Notion Chose Typed Blocks Over Flat Text for AI Context
TRIGGER
AI querying user content treats everything as flat text, losing the semantic meaning embedded in the product's data model. A date string 'April 30' in raw text is ambiguous; the AI can't distinguish due dates from mentioned dates from created dates without understanding the schema.
APPROACH
Notion passes block-level structured data to AI rather than flattened text. Each block carries metadata: type (task, paragraph, database entry), properties (due date, assignee, status), and relationships (parent page, linked databases). When a user asks 'Which tasks are late and assigned to marketing?', the AI receives structured context where 'April 30' is typed as a due-date property on a task block with an assignee property—enabling graph-style reasoning rather than keyword search. Input: user query + structured block graph with typed properties and relationships. Output: answers that leverage schema semantics (filtering by property type, traversing relationships).
PATTERN
“"April 30" as flat text is ambiguous—due date, mentioned date, or created date? Serializing to text loses the semantic types your data model already knows. Pass block-level structure with typed properties so the AI can filter and traverse relationships instead of guessing from keywords.”
✓ WORKS WHEN
- Product already has rich structured data (typed fields, relationships, hierarchies) that users create naturally
- User queries require filtering, aggregation, or relationship traversal that benefits from schema awareness
- The same surface text has different meanings based on context (dates, names, status labels)
- AI needs to perform actions that map to product operations (create task, update field, link items)
- Structured representation fits within context window limits or can be selectively retrieved
✗ FAILS WHEN
- Product data is genuinely unstructured (free-form notes, chat logs, prose documents)
- Users don't consistently use structured features so metadata is sparse or unreliable
- Schema complexity exceeds what the model can reason about effectively
- Queries are primarily about content semantics rather than structural relationships
- Serializing structure significantly bloats token count without proportional benefit