Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
See how SIRJ validates source records, tenant scope, metric eligibility, attribution evidence, stale connectors, and unsupported answers before revenue claims appear.
Buyer answers
Buyers do not only ask what data comes in. They ask what SIRJ does with stale sources, partial records, unsupported metrics, weak matches, and uncited answers before those become client-facing reporting.
SIRJ checks that the source is configured, the record is normalized into a supported event type, the record belongs to the active tenant and client, the metric has the required evidence, and the final answer can be cited or safely withheld.
The buyer can trust that ROI is not a decorative chart label. It has to pass source readiness, scope, calculation, attribution, and citation checks before it reaches a client-facing surface.
Follow related proofSIRJ treats stale, failed, disconnected, setup-required, and reauthorization-required sources as operational states that must stay visible before downstream dashboards, weekly reports, or Ask Data answers rely on the source.
A stale source should create a fix path, not a hidden reporting defect. Validation makes the missing freshness signal visible before the client meeting.
Follow related proofYes. A source row can exist while the requested metric is still unsupported. ROAS needs spend and attributed revenue, form conversion needs measured starts or views, and follow-up quality needs communication evidence in the same scoped client workspace.
Validation separates data presence from metric eligibility. That keeps a partial stack from looking complete just because one connector synced successfully.
Follow related proofAsk Data should return a bounded unsupported response that names the supported areas or missing evidence. It should not read unrelated dashboard rows, cache a synthetic answer, or turn a missing source into confident reporting prose.
The assistant earns trust by refusing unsupported questions in plain language, then pointing the user toward the connector, metric, or source evidence required to answer them later.
Follow related proofValidation path
Validation is the difference between a dashboard that looks finished and a dashboard that deserves to be used in a client review.
Validation stages
This table names the checks that stand between raw connector data and a buyer-visible claim in dashboards, Ask Data, reports, alerts, and exports.
| Stage | Evidence checked | Blocked when | User sees |
|---|---|---|---|
| Connector readiness | Authentication method, selected resource, setup fields, sync state, sync cadence, and provider health summary. | Credentials are missing, a required resource is not selected, the provider needs reauthorization, or the most recent sync cannot support a fresh report. | Connector health, setup-required state, reconnect prompts, and integration detail copy before the data becomes a dashboard dependency. |
| Normalized schema | Provider payloads converted into supported spend, lead, deal, payment, and communication event fields with timestamps and source context. | A provider field cannot be mapped into a supported event type, required timestamps are missing, or the value cannot be safely interpreted for reporting. | Integration pages and data routing copy explain what each source imports and which records can feed dashboards, Ask Data, reports, or attribution. |
| Tenant and client scope | Account id, client id, connection id, active request context, workspace permissions, and client-visible access checks. | A record, query, export, invitation, or report request cannot be proven to belong to the active tenant and client workspace. | Client workspaces, role-aware access, report exports, and Ask Data answers remain scoped to the client the user is reviewing. |
| Metric eligibility | Required event types, denominator fields, date range, source filters, attribution matches, and dashboard card capability checks. | A calculation would require evidence the connected stack does not yet provide, such as revenue without payments, conversion rate without starts, or CPL without leads. | Unsupported cards stay absent, null, caveated, or routed to setup guidance instead of filling the page with placeholder certainty. |
| Attribution evidence | Demand event, lead identity, deal or job record, invoice or payment record, match method, confidence, window, and payment precedence. | A revenue event cannot be connected to a supported demand path or the available identifiers are too weak for a deterministic claim. | Lead-to-revenue matching and attribution methodology explain whether revenue is credited, withheld, or treated as statistical context. |
| Cited output | Computed rows, chart rows, report snapshots, source filters, date bounds, metric definitions, and unsupported-answer reasons. | A dashboard, report, weekly insight, export, or Ask Data response cannot show the row, rule, source, or boundary behind the claim. | The answer cites its evidence or says what is missing, which keeps polished reporting from outrunning the source path. |
Refusal rules
Refusal is not a caveat buried in legal copy. It is product behavior: disconnected sources, mixed scope, unsupported ratios, weak attribution, and uncited answers need visible safe states.
| Rule | Reject when | Safe state | Buyer value |
|---|---|---|---|
| Do not use disconnected sources | The connector is disconnected, setup-required, stale, failed, or missing the selected resource needed to support the current report. | Show the source state, explain the reconnect or setup step, and keep downstream metrics from treating the source as current. | The operator fixes the source instead of walking into a client review with silently incomplete performance proof. |
| Do not blend client workspaces | A record, query, export, or invitation path cannot prove that it belongs to the active account and client workspace. | Reject the read or write path, preserve client separation, and keep account-level operators from accidentally mixing proof between clients. | Agency buyers can trust portfolio access without turning multi-client scale into a reporting or privacy risk. |
| Do not calculate unsupported ratios | The denominator is zero, missing, not measured, or outside the selected scope for ROAS, conversion rate, cost per lead, or similar ratio metrics. | Return null, submissions-only, insufficient data, or setup guidance instead of manufacturing a percentage from incomplete evidence. | The dashboard feels stricter and more useful because missing evidence becomes a setup signal instead of a misleading success or failure. |
| Do not credit revenue without a match path | The system has revenue evidence but cannot connect it to spend, lead, deal, job, invoice, or payment records inside the allowed attribution rules. | Leave the revenue uncredited, show the attribution boundary, and route the buyer to matching details instead of forcing campaign credit. | The client conversation stays defensible because unmatched revenue is not quietly assigned to the channel with the best story. |
| Do not answer without citations | A plain-English question asks for a number, ranking, recommendation, or comparison that lacks computed rows, allowed fields, or source context. | Return an unsupported response with the missing evidence and supported question areas, then avoid caching a false result. | Ask Data can stay useful under pressure because the refusal is part of the product contract, not a vague AI caveat. |
Workflow
The workflow is written for buyers, but each step maps back to the product systems that keep revenue reporting bounded by evidence.
| Step | What happens | Visible proof |
|---|---|---|
| Check source health | Before a record supports a dashboard or report, SIRJ checks connection state, setup requirements, selected resources, sync cadence, and provider health so stale or incomplete sources stay visible. | Users see connector health states, recent sync context, setup prompts, and reconnect paths before reports depend on a source. |
| Normalize records | Provider payloads are transformed into typed events with source context, timestamps, amounts, stages, and identities that downstream metrics and attribution logic can evaluate consistently. | Integration pages name imported records, while data routing explains how raw payloads become event types that the platform can safely compare. |
| Apply scope and permissions | Records, queries, reports, exports, invitations, and dashboard reads are checked against account, client, role, and request context before they affect visible proof. | Client workspaces and security pages explain why one agency account can manage many clients without blending their numbers. |
| Evaluate metric support | Dashboard generation and Ask Data compare the requested surface against required source evidence, safe division rules, event types, and date scope before returning a number. | Metric definitions explain which cards, ratios, source tables, and report rows appear, stay null, or need another source before they can be trusted. |
| Validate attribution before output | Revenue claims need a supported path from demand to lead, deal, job, invoice, payment, or statistical context before the number can appear as attributed revenue. | Lead-to-revenue matching and attribution methodology show which rule connected the revenue and which records stayed uncredited. |
| Cite or withhold | The final surface must cite computed rows, chart rows, report snapshots, date bounds, source filters, and metric definitions, or return a supported unsupported-state explanation. | Ask Data answers, reports, and exports show source-backed evidence or explain what is missing before the claim becomes client-facing. |
Proof standards
These standards keep the product honest when a connected stack is partial, stale, hard to match, or missing the evidence a client question needs.
Expose stale, failed, disconnected, setup-required, and reauthorization-required states before the source supports report or Ask Data output.
Carry account, client, permission, and date scope through dashboard config, query specs, exports, notifications, and report snapshots.
Keep unsupported cards absent, null, caveated, or connected to setup guidance until the source evidence required by the metric exists.
Use deterministic matching first, preserve confidence and no-match states, and treat statistical context separately from credited revenue.
Ask Data and report outputs cite supported rows or withhold the answer with a clear missing-evidence explanation.
FAQ
These answers keep validation concrete: what is checked, what is withheld, and why a stricter dashboard protects client reporting.
Yes. Data routing explains the path from connector record to normalized event and visible answer. Data validation explains the checks that decide whether a record, metric, attribution claim, or Ask Data answer is allowed to appear.
Yes, and that is the point. A stricter dashboard may show fewer cards until the right sources are connected, but the visible numbers are more defensible because unsupported metrics stay absent, null, or clearly bounded.
Ask Data validates the requested question against supported query specs, allowed dashboard fields, source filters, date scope, and computed rows before it returns a cited answer or an unsupported-state response.
Validation catches stale sources, blended client scope, unsupported metrics, weak attribution matches, and uncited answers before they become weekly insight copy, PDF exports, or client review talking points.
Ready when the numbers need to hold up
Start with metric definitions, then follow the data route and matching engine to see how source records become report-ready revenue proof.