Using the Observability View

To navigate to the Observability view:

• In the left navigation, click Data Integrity, then select Observability.

The image above shows the Observability page, with the top table listing active templates and several data columns, including Coverage and Trend.

Every observable template — a template with its Observability toggle turned on — appears in the list, one row per template and object type. Use the Type selector and the filter box to narrow it.

Each row shows:

• Template Name — A link that opens the template directly in the Data Logic module. To open the template's detail report below the list instead, use the checkbox in that row.
• Type — The object the template applies to (Contacts, Companies, and so on).
• In Scope — How many records the template's filters include.
• Coverage — A bar showing how the in-scope records break down: Coverage (matched), Unmatched, and Flagged, with the counts beneath.
• Trend — Coverage direction over recent ingestion cycles.
• Drift — How many records hold values that the Blueprint says should be different. Within a single template, a record counts once even if multiple output fields have drifted.
• Status — One of three badges:
  • Stable — Nothing needs a look right now.
  • Needs Attention — The template has records worth reviewing, or a meaningful portion of its matched records have drifted.
  • Regressed — The template's coverage has dropped below its recent average.

A good place to start is sorting by Status and working through Regressed templates first.

The image above shows the Observability template list, with columns for Template Name, Type, In Scope, Coverage, Trend, Drift, and Status.

To open a template's detail report:

1. In the left navigation, click Data Integrity, then select Observability.
2. In the template list, click the checkbox to open a template report — only observable templates appear in this list.

Selecting a template opens its detail report below the list. This is where diagnosis happens.

The template list above and this detail report read from different moments, on purpose. The metric tiles and template list reflect the daily ingestion cycle — a stable snapshot, consistent with the trend charts and the Overview. This detail report is live: its Coverage breakdown, Coverage Gaps, and Drift by Field reflect the most recent ingestion, including operations run through Insycle. Running a template in update mode re-evaluates the records it corrects, so this report shows your progress as soon as the run completes, while the list and trends catch up at the next daily cycle. A difference between a template's row in the list above and its detail report here is this freshness gap, not an error.

Blueprint Structure

Shows the template's inputs and outputs — which columns in the Blueprint map to which CRM fields, the matching each input uses (Exact, Contains, Regex, a numeric or date range, and so on), and any Match Options applied — refinements like case sensitivity or whitespace handling that adjust how a match is evaluated without changing your data. A field used as both an input and an output is flagged here, since that's a structural risk worth knowing about before it produces a Blueprint Inconsistency. Reading this first tells you what the template is comparing and what it writes.

The image above shows the Blueprint Structure panel, with Inputs mapped to State (Exact) and Country (Exact), Outputs mapped to State/Region and Country/Region, and a warning that a field used as both input and output should be checked against the Blueprint Inconsistencies report below.

Reach and Coverage

The Reach bar shows how many records the template's filters bring into scope, out of all records of that type — for example, "70 of 118 records in scope (59.3%)." If Reach is lower than you expect, review the template's filters.

Coverage presents three numbers for the in-scope records:

• Coverage — records that matched a Blueprint row.
• Unmatched — records the matching couldn't connect to any row. These are your coverage gaps.
• Flagged — records set aside because applying the Blueprint to them would create an inconsistency.

The bar beneath shows the same breakdown proportionally.

The image above shows the Reach bar, indicating 70 of 118 records in scope (59.3%) and the Coverage breakdown for a template: 14 Coverage (20.0%), 39 Unmatched (55.7%), and 17 Flagged (24.3%), with a proportional bar beneath.

Coverage Over Time and Drift Over Time

The template's own trend charts, mirroring Overview's Coverage Trend and Drift Trend but scoped to this one template. A coverage drop usually means new data arrived that the Blueprint doesn't yet match; falling drift means corrections are landing.

The image above shows the template's Coverage over Time and Drift over Time charts.

Coverage Gaps lists the specific input value combinations that didn't match any row in the Blueprint — these are the records behind the template's Unmatched count. Each row shows the input values involved and how many records share them.

To view a template's Coverage Gaps:

1. In the left navigation, click Data Integrity, then select Observability.
2. In the template list, click the checkbox to open a template report — only observable templates appear in this list.
3. In the template's detail report, scroll down to Coverage Gaps.

When you find a gap, there are three likely explanations, worth checking in order:

• The value is legitimately new or valid, and the Blueprint simply doesn't have a row for it yet. Add a row.
• The value should have matched an existing row, but didn't — often a matching criteria or Match Options issue (case sensitivity, extra whitespace, a Contains match that needed to be Exact, and so on). Adjust the existing row's matching rather than adding a duplicate.
• The value is bad or malformed data that doesn't belong in a Blueprint row at all. This may point to a data quality issue upstream, outside of Data Logic.

Select the rows you want to fix and click Export. This produces a CSV in the Blueprint's own column names, with the affected input values already filled in and the output cells left blank for you to complete. Download the current Blueprint version from the Blueprints page, append these rows, fill in the outputs, and upload the result as a new version. Selecting or clearing a row's checkbox doesn't affect what the Export button produces — every visible row is included regardless.

The image above shows the Coverage Gaps table for a template, with Country/Region, State/Region, and  Industry values and their record counts, and an Export button.

Drift by Field lists each output field the template writes to, showing its Update Condition — the rule that governs when that field is allowed to update, such as Always or Field Empty — the percentage of matched records still consistent with what the template last wrote, and the number of records that have drifted. A Drift Summary line beneath the table states the same information in plain language — for example, "Of 14 Coverage records, 0.0% reflect the output they were assigned · 14 total drift."

To view a template's Drift by Field table:

1. In the left navigation, click Data Integrity, then select Observability.
2. In the template list, click the checkbox to open a template report — only observable templates appear in this list.
3. In the template's detail report, scroll down to Drift by Field.
4. To open the template in the Data Logic module for analysis, click Analyze.
5. In the Data Logic module, under Run, click Review, and run the template in Preview mode now. 

The preview CSV report sent to your email shows the before-and-after values for every affected record without changing any data. Drift's root cause is per-record, not aggregate, so Preview Mode is a better troubleshooting tool here than an export would be.

Drift is measured against the Blueprint regardless of a field's Update Condition — the condition governs what a run will write, not what the report counts. Under Always, running the template in update mode corrects every drifted record for that field, and Drift by Field is live: watch the drifted count fall in the same session once the run completes. Under Field Empty, drifted records that already hold a value are reported but deliberately left alone — for these fields, drift is informational, showing where your data has diverged from your standard without implying the template will rewrite it. If a field's drift persists across runs, check its Update Condition first, before assuming another process is involved.

Drift has two origins. It can be the state the data was already in: when a template is first made observable, records that matched a row but were never updated by it hold whatever values they held before — existing data measured against a standard that hasn't been applied to it yet. Or it can be movement after the fact — a manual edit, a one-time import, or an integration writing a different value into a field the Blueprint governs. Both are corrected the same way: running the template in update mode re-applies the Blueprint's values to the drifted records.

A template configured to run automatically applies this correction on every cycle, but automation doesn't prevent drift from recurring: if something else keeps rewriting the same field after Insycle corrects it, the record will simply drift again before the next cycle. For a field set to Always, if its drift stays high even after the template runs, that's the signal — it means another process, such as an integration, a Workflow, or manual edits, is actively rewriting the value, and the fix is identifying and addressing that external process rather than changing the Blueprint or the Data Logic template, since the Blueprint already holds the correct value.

The image above shows the Drift by Field table for a template, with Country/Region and State/Region fields, both using the Field Empty update condition, and a Drift Summary stating 14 total drift.

Blueprint Inconsistencies appear only when the template's Blueprint Structure has a field used as both an input and an output — the condition flagged with a warning icon under Blueprint Structure, above. If a template's Blueprint doesn't use any field both ways, this section doesn't render, since there's nothing for it to check.

When a field is used as both an input and an output, the Blueprint should be able to match the values it writes. This section lists cases where it can't — for example, the Blueprint writes a state name that no input row matches. Each entry describes the exact gap and the number of records that hit it.

Blueprint Inconsistencies and the Coverage Gaps count are the same finding from two angles: the Gaps count tells you how many records are affected; this list tells you why. Until a Blueprint closes this kind of gap, its flagged records sit in neither Coverage nor Unmatched — so your Coverage number understates what the standard actually governs.

These are worth fixing in the Blueprint itself, not the data. Add an input row that matches the missing value, and the flagged records for it clear — run the template to see the effect immediately, or let the next ingestion cycle pick it up. Because each entry names one missing value, one added row typically clears every record flagged for it, so the counts are a useful way to prioritize which gaps to close first.

To view and address a template's Blueprint Inconsistencies:

1. In the left navigation, click Data Integrity, then select Observability.
2. In the template list, click the checkbox to open a template report — only observable templates appear in this list.
3. In the template's detail report, scroll down to Blueprint Inconsistencies.
4. Click Export to download all rows as a CSV in the Blueprint's own column format. For each row in the CSV, the self-mapped field is filled in on both sides — the missing value appears in both its matching input column and its output column. For Blueprints with more than one input/output pair, every column outside the self-mapped pair is left blank. 
5. Go to Data Integrity > Blueprints and download the current Blueprint version, append the rows from the export CSV, and upload the result as a new version. 

The image above shows the Blueprint Inconsistencies table for a template, listing State/Region and Country/Region self-mapping gaps with their affected record counts. The Export button appears at the top.

Insycle ships templates and Blueprints for common standards — country normalization, US postal codes to state and city, state and province normalization, and more — so Data Integrity has something to report on from day one. These are marked with an Insycle tag in the Observability template list, and Insycle maintains them as reference data changes.

The image above shows the Observability template list, with an Insycle tag next to Country Normalization, Lifecycle Stage x Lead Status Consistency, and Job Title → Seniority, distinguishing them from user-created templates like Territory Assignment, Near-Miss Detection, and lead source harmonization, which have no tag.

If a built-in template needs to behave differently for your data, make a copy and customize it. The copy is yours to edit; the original continues receiving Insycle's updates.

Like any template, an Insycle-provided template's observability can be turned off by clicking the shield icon in the Data Logic module, which removes it from Observability's reports without deleting it.

The image above shows the Data Logic module's template toolbar for "US & Canada State/Province..." with the shield icon highlighted, indicating the Observability toggle that makes the template observable and eligible for evaluation and reporting across Data Integrity.