Define the collection contract
A Qdrant collection needs a named embedding model, vector dimensions, distance metric, payload schema, source identifiers, permission fields, and owner. Changing the model or dimensions is a migration concern, not a casual setting change.
Map ingestion and deletion
Map source extraction, chunking, embedding, payload writes, retries, update detection, and deletes. Keep provenance so operators can trace a result and rebuild a defined source set.
Protect the query path
Use controlled network and API access. Build tenant and document filters from trusted application identity. Do not let callers broaden their own payload filter or use a collection key as end-user authorisation.
Measure storage and recovery
Capacity depends on vectors, dimensions, payload, indexing, replication, updates, and queries. Test representative corpus and filters. Restore proves persistence; a reindex plan proves how to return to current source permissions.
Planning record
Keep decisions versioned.
| Area | Decision | Evidence |
|---|---|---|
| Collection | Model and schema | Write/query test. |
| Permissions | Filter construction | Cross-tenant denial. |
| Capacity | Workload envelope | Measured load. |
| Recovery | Restore or rebuild | Dated exercise. |
Questions
Can embeddings be reused after a model change?
Check dimensional and quality compatibility; reindex where needed.
Is restore enough after permissions change?
No; update or rebuild affected payload metadata.
What proves access?
Allowed, denied, and revoked-document tests.
Deployment stages
Set source, schema, permissions, and owners.
Exercise relevance, access, and recovery.
Review growth, errors, and source changes.
Handover checks
Keep evidence with the retrieval service.
Collection register
Contracts and owners are known.
Permission test
Unauthorised retrieval is denied.
Rebuild test
Authoritative sources can reindex the service.
