Provenance is the connective tissue between tool runs and documents. It keeps regulators, partners, and downstream automations aligned.
What gets tagged
Every MCP tool that emits a document, summary, or status update also emits an artifact record. Atlas attaches workspace_id, transaction_id, tool_name, event_id, consent scopes, and hash signatures so you can trace the asset back to the exact run.
Artifacts inherit the chain-of-custody idea from Atlas architecture: Owner → Workspace → Transactions → Items → Files. If a client only has access to Transaction A1, they only see artifacts tagged with that transaction.
- Owner/Admin: all Transactions, Items, Files in Workspace
- Client: only invited Transactions and their Items/Files
Chain-of-custody fields
Use these fields in downstream systems (RAG stores, BI dashboards, regulators). They make it obvious which tool produced a PDF, which consent scopes applied, and which vendor handled the call.
| Field | Why it matters |
|---|---|
| artifact_id | Stable identifier per output |
| event_id | Links artifact to tracker ledger |
| tool_name | Clarifies which workflow ran |
| workspace_id / transaction_id | Keeps multi-tenant boundaries intact |
| consent_scopes | Proves authorized data access |
| vendor_name / model_name | Supports vendor health reviews |
| hash/signature | Detects tampering before sharing externally |
Inside comps PDFs & audit logs
Sales and rental comps PDFs display the provenance footer: tool name, event_id, consent scopes, and timestamps. Audit exports include the same fields plus token/cost data so regulators can replay the exact request.
When you ingest artifacts into a vector store, keep the provenance metadata alongside the text. That lets your RAG agents cite only documents with valid scopes and budgets.