Data Foundations Quality Checklist (Tags, Naming, Ownership)

1 — Tag inventory completeness

Goal: All critical systems and assets have tags recorded in a single inventory with essential metadata.

• Check: Inventory exists that includes tag name, source system, data type, units, sample rate, last update, owner, and quality flag.
• Acceptance: Inventory covers 95%+ of tags used in production dashboards, MES feeds, and control logic (or a clear documented list of excluded tags with rationale).
• Evidence: Exported inventory CSV or database query.
• Remediation: Add missing tags to inventory; document exclusions; schedule a follow‑up audit.

2 — Naming standard compliance

Goal: Tag names follow a predictable, documented pattern so people and tools can find and interpret signals reliably.

• Check: There is a written naming convention with examples and a small set of enforced rules (mandatory segments, delimiters, unit suffixes where applicable).
• Example pattern: PLANT.LINE.EQP.SIGNALTYPE.SIGNALNAME[.UNIT]
  Example: PL01.LN02.PUMP03.STATUS or PL01.LN02.TEMP01.VALUE.C
• Acceptance: ≥ 90% of critical tags match the naming convention or are in an approved exceptions list.
• Evidence: Sample of 100 tags or automated regex check against inventory.
• Remediation: Create mapping for legacy names; plan renaming or aliasing; add validation rule on new tag creation.

3 — Timestamps & time synchronization

Goal: All time fields use a consistent timezone and format; event times reflect the source time or normalized UTC; latency is understood.

• Check: Timestamps are present, in ISO‑8601 or documented format, and the timezone handling is defined (source timezone vs. normalized UTC).
• Acceptance: No conflicting timestamp formats in production data; clock drift < acceptable threshold (e.g., < 5s for event tracking) or documented reconciliation strategy.
• Evidence: Time range query showing consistent formats; sampling of concurrent device events to verify order/latency.
• Remediation: Implement NTP on devices/gateways, normalize timestamps in ingestion, or add ingest transformation that writes a normalized timestamp and source timestamp.

4 — Sampling rates, update frequency & data freshness

Goal: Sampling rates are documented and appropriate for the use case (real‑time monitoring vs. trend analytics).

• Check: Each tag has a documented sample rate and acceptable latency (e.g., 1s for PLC status, 1min for process trend).
• Acceptance: For critical control/visibility tags, 95% of records meet the expected update frequency over an audit window.
• Evidence: Histogram of inter‑arrival times, or percentage of timestamps within expected interval for a 24–72 hour window.
• Remediation: Adjust polling, edge aggregation, or publish frequency; investigate network or gateway bottlenecks.

5 — Missing values and data completeness

Goal: Missing data rates are low and explained (planned downtime, sensor maintenance). Missingness is monitored and triggers remediation.

• Check: Calculate % of missing or null values per tag over a recent window; inspect gaps and their causes.
• Acceptance: Missing rate for critical tags < configured threshold (example: < 1% over 7 days) or documented exception with compensating measures.
• Evidence: Missingness report per tag; list of maintenance events correlated with gaps.
• Remediation: Fix sensor/gateway issues, add quality flags, or create strategies for imputation where appropriate for analytics (document imputation method).

6 — Data types, units, and value ranges

Goal: Tags declare data type and units, and expected operational ranges are defined to catch outliers.

• Check: Data type (int, float, bool, enum, string), units (C, psi, mm), and min/max operational ranges are documented per tag.
• Acceptance: Critical tags include unit and range metadata; outliers beyond range are < 0.5% or are explained.
• Evidence: Inventory fields show type/unit/range; query showing outlier events with timestamps and upstream context.
• Remediation: Correct unit mismatches, update type casting in ingestion, and add validation/alerts for values outside expected range.

7 — Quality flags, heartbeat & last good value

Goal: Each tag provides a quality indicator or heartbeat so consumers can decide whether a value is trustworthy.

• Check: Quality flag exists or a heartbeat tag is available; last‑good timestamps are recorded.
• Acceptance: Consumers can distinguish good vs. stale/invalid data; dashboards hide/annotate values with bad quality.
• Evidence: Examples of quality field values and how consumers treat them (dashboard annotation, model input filters).
• Remediation: Implement quality flags at source or annotate during ingestion; train downstream dashboards to respect flags.

8 — Ownership & documentation

Goal: Every tag has a clear owner responsible for definition, correctness, and remediation.

• Check: Owner (person or role), contact, and an authoritative definition (what the signal measures and how it's derived) are recorded for each critical tag.
• Acceptance: ≥ 95% of critical tags have owners and definitions; for exceptions there is a documented escalation path.
• Evidence: Inventory records showing owner metadata and link to definition (wiki page or tech spec).
• Remediation: Assign owners for unclaimed tags; run a knowledge capture session to document definitions; include owner fields in the tag creation workflow.

9 — Baseline metrics and acceptance thresholds

Goal: Define baseline metrics to measure improvements and detect regressions.

• Suggested baselines to capture now:
  • % tags with owner
  • % tags matching naming standard
  • Average missing value rate for critical tags (7d)
  • Average latency / freshness
  • % tags with unit/type/range defined
• Acceptance: Baseline metrics are recorded in a simple dashboard (or CSV) and updated weekly during initial rollout.

10 — Remediation steps & priority matrix

Use this small remediation model to triage issues discovered by the audit:

1. Critical: Affects safety, production stops, or key MES inputs. Action: Immediate owner assignment and hotfix within 24–72 hours.
2. High: Prevents correct KPIs, analytics, or major dashboard visibility. Action: Fix within sprint (1–2 weeks).
3. Medium: Naming, documentation, or non‑blocking missingness. Action: Plan in next improvement cycle.
4. Low: Cosmetic or historical cleanup. Action: Schedule as backlog work.

Record actions in a simple tracking list (tag, problem, priority, owner, due date, status).

Scoring template (quick)

For each section above mark: Pass / Warn / Fail and capture a short evidence link. After finishing, compute percent of Pass items to track readiness over time.

Example audit outcome (short)

Pass: Naming standard documented and applied to 88/100 sampled tags (Warn: legacy aliases present).
Pass: Timestamp format consistent, clocks synced to NTP.
Warn: 6 critical tags show >5% missingness during last 7 days — owner assigned, high priority.
Fail: No quality flag on 3 sensor streams that feed MES — immediate action required.

Next steps & recommended automation

1. Run this checklist as an interactive audit and capture results (owner, evidence, remediation items).
2. Create simple automated checks where possible (regex checks for naming, missingness reports, heartbeat monitors) and publish baselines to a dashboard.
3. Embed tag creation validation into the PI/MT/asset register process so new tags must include owner, unit, type, and naming compliance.

Helpful reminders: Preserve legacy aliases by adding them as alternate names in the inventory; do not delete historical tags without migration. Treat this checklist as a living artifact — update the acceptance thresholds to match your plant’s operational reality.