Context Authority
Snipara's trust layer answers a different question than retrieval. Retrieval asks whether a source is related. Context authority asks whether a human or agent should trust it enough to act on it.
Keep the terms separate
Context Authority is product trust for source-backed context. Trust Center is security, compliance, and platform protection. They are related, but they are not the same surface.
Why it exists
AI-assisted work breaks when every retrieved fact looks equally valid. Snipara keeps source strength visible so the user can distinguish reviewed decisions from weak inferences, current client files from old examples, and fresh repository state from stale assumptions.
Authority contract
When the source supports it, Snipara attaches the following metadata to briefs, PR Answer Packs, decisions, and business-context health signals.
| Field | Meaning |
|---|---|
| source_type | Where the context came from: PR, commit, issue, review, decision, file, upload, or manual note. |
| source_url | A human-openable URL for the evidence behind the claim. |
| commit_sha | The repository or source state used when the context was collected or validated. |
| collected_at | When Snipara observed or derived the context. |
| freshness | Whether the context is current, aging, stale, or superseded. |
| confidence | How strongly Snipara can support the claim from the available evidence. |
| validated_by | Human review, workflow, check, or system that promoted the context. |
| stale_reason | Why the context should be treated carefully or refreshed before use. |
Where it shows up
Start Work Brief
Before editing, trust metadata tells the developer or agent which assumptions are still safe.
What Changed For Me
When resuming work, authority labels keep fresh repo movement separate from stale mental models.
PR Answer Pack
During review, authority fields stop inferred context from presenting itself as validated project truth.
Project Context Health
For non-code work, source metadata and freshness policies tell teams when to reindex, reupload, or review the source.
Code and business use the same model
In code workflows, authority often comes from GitHub URLs, commit SHAs, reviewed decisions, and stale-branch warnings. In business workflows, authority often comes from source URLs, source snapshots, freshness policies, parser quality, and review state. The model is the same: context should tell you how safe it is to use.
{
"source_url": "github.com/owner/repo/pull/214",
"commit_sha": "8f42c19",
"freshness": "current on main",
"confidence": 0.91,
"validated_by": "reviewed decision",
"stale_reason": null
}{
"source_type": "google_drive",
"source_url": "https://docs.google.com/...",
"collected_at": "2026-05-18T09:00:00Z",
"freshness": "aging",
"confidence": 0.84,
"validated_by": "business upload workflow",
"stale_reason": "source_snapshot_expired"
}How agents should read it
- Prefer higher-authority, fresher, source-backed context over older or inferred context.
- Treat stale warnings as a reason to verify, not as a silent footnote.
- Do not let historical reference material override active current truth without an explicit workflow choice.
- Use confidence as a routing signal, not as a replacement for opening the cited source when precision matters.