How packs work
The data model and retrieval behind verified knowledge.
A knowledge pack is built so every answer is traceable and current. This is the model underneath — you don't need it to use a pack (start here), but it explains the guarantees.
The model
Pack → Release → Source → Document → Block (each block has a stable canonical id)| Noun | Meaning |
|---|---|
| Pack | A named product, e.g. in.business_compliance.authority. |
| Release | An immutable, versioned snapshot. One is active at runtime. |
| Source | A trusted origin (e.g. CBIC GST notifications) with jurisdiction and binding force. |
| Document | A specific official document from a source. |
| Block | A quotable unit of text with a stable canonical id that survives republishing. |
Hybrid retrieval
A search runs up to three lanes and fuses them with Reciprocal Rank Fusion:
- Exact — canonical-id lookup (the fast path).
- Lexical — Postgres full-text search.
- Semantic — pgvector / HNSW embeddings.
Results are filtered by claim scope (statutory rule, regulatory direction, procedure, policy signal) so you only cite blocks appropriate to your use.
Currentness is fail-closed
Each block carries an amendmentState and an effective window. Superseded or expired blocks are
excluded by default — the runtime will not return a stale rule.
Amendment trails
Blocks are linked by what amended, superseded, or clarified them, with effective dates and the
evidence for each edge. Walk the lineage with KNOWLEDGE_GET_AMENDMENT_TRAIL when an answer depends
on which version is current.
For using a pack — searching, evidence receipts, verifying answers — see Verified Knowledge and Evidence receipts.