Sample manufacturing data catalog entry & governance template (interactive)

An annotated example plus an interactive template you can use to create, store, and govern canonical manufacturing data-catalog entries (tags, signals, and KPIs). Includes naming guidance, ownership rules, lineage, lifecycle states, expected ranges, and review cadence.

Interactive Tool

Manufacturing Data Catalog - Entry Template

Why this matters

Unclear tag names, inconsistent units, and undocumented mappings create duplicate signals, broken dashboards, and lost trust. Use this interactive template to capture a single authoritative entry for each sensor, PLC signal, historian point, or calculated KPI so analytics, MES, and dashboards are reliable and discoverable.

Annotated example

Example entry: siteA_line3_mixerrpm
- description: Mixer 3 rotational speed (RPM) after reducer
- owner: Controls.Engineer@siteA.example (role & contact)
- source system: PLC (Device: AB-1756-1)
- downstream consumers: OEE dashboard, Quality analytics, MES recipe controller
- units: RPM (integer)
- sample rate: 1s
- expected range: 0 - 3600
- retention: 3 years
- lineage: PLC -> PI Historian -> ETL -> Analytics DB -> Dashboards
- lifecycle: Active (last reviewed 2026-06-01)

Fill in the fields below to create a living catalog entry. The platform will store the submission as structured JSON that can later be exported or integrated into your enterprise catalog.

Follow naming convention: site_area_line_equipment_point (lowercase, underscores). Example: siteA_line3_mixerrpm.
What this signal measures and any important context (what part of the process, where it is measured, and why it exists).
Person or role responsible for the signal (include email or team name). Example: Controls.Engineer@siteA.example
Department or team that owns the signal (e.g., Controls, Maintenance, Process Engineering).
Where the value originates.
Vendor/address/point ID if applicable (e.g., AB-1756-1:N7.0).
Where the device or sensor is located (e.g., Building A - Line 3 - Mixer Bay).
Equipment or asset this signal is related to (use asset registry ID if available).
Units of measurement (use canonical units where possible). Example: RPM, °C, kg, m/s.
Primary data type for storage/validation.
Typical sampling interval in seconds. Use 0 for event-driven signals.
How timestamps are recorded and interpreted.
Operational minimum expected value (for automated sanity checks).
Operational maximum expected value (for automated sanity checks).
How long raw data should be retained. Align with site data retention policy.
Classification for access controls and disclosures.
Dashboards, reports, analytics jobs, MES functions, third-party systems that use this signal. Include owners if known.
Short description or diagram text showing data flow (example: PLC -> PI -> ETL -> Data Lake -> Analytics DB -> OEE Dashboard).
If this is a calculated field, include formula, logic, and parameter mappings. If mapped from multiple sources, show mapping table example.
State of the tag to manage discovery and deprecation.
YYYY-MM-DD (auto-populated if possible).
YYYY-MM-DD. Record the latest governance review.
How often the owner must review this entry.
Require downstream consumer confirmation before retiring or changing this tag.
Comma-separated canonical tag names that are related, upstream, or aggregated from this signal.
Keywords to help discovery (e.g., oee, throughput, temperature).
Any decisions, exceptions, or migration plans relevant to the tag.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.

Discussion

Comments and conversation will live here.