Data model

A shape is the kind of data you query — the scope argument to silo_recall. Shapes replace provider-named scopes: you ask for message, not "Gmail" or "Slack". Call get_scope to see which shapes a connection actually has.

• →memory — Curated knowledge stored in a silo (the only stored shape).
• →message — Communications — chat and email, merged.
• →file — Opaque assets — PDF, image, sheet, binary.
• →note — Structured written content — pages and docs.
• →task — Work items — issues, PRs, tickets, cards.
• →event — Calendar events.
• →transaction — Financial events.
• →account — Standing accounts and balances.
• →contact — People.
• →code — Source code — files and pull requests.
• →space — Collaborative boundaries — channels, repos, teamspaces.

memory is stored — it needs a silo_id (or "default"). Every other shape is live and federated across connected services.

A read returns a slice: a normalized list of items for one shape, with no source attribution. Each item carries a small set of neutral fields plus an opaque handle. Raw provider payloads, provider URLs/IDs, and source names are never included.

A handle (slc_…) is an opaque, encrypted reference to one item, bound to your connection. Pass it back to silo_recall(handle, facet) to open the item or expand a heavy facet (.content, .comments, .diff), or to silo_remember(handle) to persist it into a silo. Handles cannot be decoded by the client and reveal nothing about the underlying service.

Each shape advertises filter dimensions you can pass in filters to narrow a recall — e.g. date, source, space, folder, participant, status. get_scope lists the dimensions available per shape.