Skip to content
VeraFrame Docs

Source groups

A source group is a labeled collection of source material — for example, pricing, contracts-2026, hr-policies, or product-specs. Source groups are how you tell VeraFrame which of your data a given request should verify against.

Every verification in VeraFrame is scoped to one or more source groups. This produces two benefits:

  1. Relevance. The AI works from a narrow, relevant slice of your data instead of searching across the whole corpus as one mass. The verifier also checks claims only against that same slice, so both sides agree on what counts as “the source.”
  2. Auditability. When you later ask “what source material did this answer come from?”, the answer is a concrete list of groups and files, not a black box.

In enterprise JWT/OIDC deployments, source groups can also act as an access-control boundary. A group may be configured with allowed roles, and VeraFrame will then fetch data from that group only when the current user’s identity-provider roles or claims match.

Two types of source groups

VeraFrame supports two source-group types:

S3-backed groups

The most common type for SaaS Cloud. You upload files (PDF, Word, Excel, plain text, URLs) into the group. VeraFrame stores them in an EU-hosted S3 bucket scoped to your tenant, indexes them for fast retrieval, and uses them as the ground truth for any request that selects the group.

Typical use: pricing sheets, contract libraries, product catalogs, policy documents, meeting minutes, regulatory texts.

API-backed groups

For live data that should not be snapshotted. Instead of uploading files, you configure a REST endpoint that VeraFrame will call at request time with parameters you specify. The returned data becomes the source material for that single request.

Typical use: ERP pricing, CRM contact records, ticket systems, internal catalog APIs.

API-backed groups require the Integration tier and cannot be configured from the SaaS Cloud UI.

Source-group access control

In customer-specific enterprise deployments, each source group can optionally declare allowed roles. These are not the same thing as VeraFrame’s own app roles (admin, user, viewer). Instead, they are data-access roles read from your existing JWT/OIDC identity model.

The behavior is:

  • If a source group has no allowed roles configured, it is available to all users in the tenant.
  • If allowed roles are configured, VeraFrame only uses that group when the current user’s data-access roles intersect with the group’s allowed roles.
  • The same restriction is enforced server-side before data retrieval. It is not just a UI filter.

This lets you keep one tenant while still limiting which source systems different users are allowed to query.

That control is intentionally coarse-grained at the source-group level. VeraFrame does not try to model every possible document-level permission rule inside its own configuration. If your environment needs finer-grained access decisions, the standard enterprise design is to expose the documents through a downstream REST API and let that API apply your existing authorization logic per document or record.

Default selection

A group can be marked as default. Default groups are preselected on every request, so routine verifications do not require the user to pick a group manually.

A tenant can have multiple default groups — for example, current-pricing and legal-terms might both be default, while archived-contracts is opt-in.

Per-tenant isolation

Source groups and their files are stored in a tenant-scoped S3 bucket. VeraFrame’s request pipeline never crosses tenant boundaries: a user in tenant A cannot read source material in tenant B, even by accident.

Next steps