Building Factory Metadata Without Rip and Replace

Factories do not need to replace every system before they can create useful operating context.

Factory Metadata & Memory can be built progressively around the events and decisions that matter most. The plant can preserve its existing ERP, MES, PLC, SCADA, historian and quality systems while adding the relationships those systems do not provide alone.

The starting point is not a complete data model. It is one operating problem.

Why rip and replace is rarely the first answer

Large replacement programmes create several risks:

• Production disruption
• Long implementation periods
• Loss of local process knowledge
• High integration scope
• Change fatigue
• Delayed proof of value
• Pressure to standardise before the process is understood

Some systems may eventually need replacement, but that decision should follow clear architecture and business need.

A factory operating layer offers a lower risk path.

A six step metadata implementation model

Step 1: Select the operating event

Choose a recurring event with measurable impact.

Examples include:

• Line stoppage
• Quality deviation
• Changeover delay
• Utility anomaly
• Missed preventive maintenance
• Shift handover risk

The event provides a practical boundary for the first metadata model.

Step 2: Map the current decision loop

Document:

• How the event is detected
• Who receives the information
• Which systems are checked
• Who decides the response
• How action is assigned
• How closure is verified

This reveals where context is lost.

Step 3: Connect the minimum sources

Do not integrate every source.

Connect the information needed for the decision. It may include:

• PLC state
• ERP order
• MES batch
• Asset master
• Operator input
• Maintenance status

• Quality result

Step 4: Create common identifiers

The factory needs a consistent way to relate plant, line, machine, product, batch, shift and event.

This does not require one global master data programme before any progress. It requires controlled identifiers within the use case and a plan to expand them.

Step 5: Capture action and outcome

Metadata without response history is incomplete.

Record owner, action, approval, timing, evidence and verification. This is what turns the event into Factory Metadata & Memory.

Step 6: Reuse and expand

After the loop works, identify the next similar asset, line or workflow. Reuse the model, not just the screen.

A practical downtime example

A plant begins with one critical packaging machine.

The existing PLC provides stop state and alarm. MES provides product and order. Df-OS captures operator observation, maintenance response and closure. X-Konnect maps machine events to the asset. The result becomes a connected downtime history.

The plant can now compare stops by product, shift, alarm and response. The same model can be extended to similar machines.

No core system was replaced. The operating relationship was added.

The role of the factory event model

A useful event model should define:

• Event type
• Asset and location
• Product and process
• Time and duration
• Severity
• Trigger
• Responsible role
• Workflow status
• Action and outcome

The model should be small enough to use and consistent enough to compare.

How to manage data quality

Data quality improves when it is connected to work.

An operator is more likely to provide accurate context when the record helps resolve the event. A supervisor is more likely to review a field when it affects escalation. A technician is more likely to capture the action when the history is useful during the next fault.

Governance should therefore include:

• Field ownership
• Validation rules
• Controlled lists where useful
• Free text where judgement matters
• Review responsibility
• Error correction
• Source traceability

Security and architecture boundaries

Brownfield integration must respect OT control boundaries.

Machine connectivity should define:

• Read and write permissions
• Network separation
• Protocols
• Edge buffering
• Identity and access
• Data encryption
• Audit
• Failure behaviour

The operating layer should not create uncontrolled access to machine control.

The path to autonomous operations

Once the event loop is reliable, the factory can introduce:

• Automatic detection
• Priority scoring
• Recommended action
• Workflow routing
• Escalation
• Bounded execution

Each step builds on the same Factory Metadata & Memory foundation.

What to avoid

• Collecting every tag before selecting a use case
• Creating a second uncontrolled master data system
• Copying local terminology without governance
• Ignoring action and outcome
• Treating manual input as failure
• Expanding before adoption is stable

A pilot scope checklist

• One important event
• One business owner
• One measurable baseline
• A defined workflow
• The minimum connected sources
• Common identifiers
• Action and verification fields
• A security review
• A second deployment target

The Df-OS approach

Df-OS digitises the workflow and creates the operating record. X-Konnect connects machine and process data. Vish AI can use the resulting Factory Metadata & Memory to support explanation and recommendation.

The approach follows the Df-OS principle of disrupt without disruption. The plant improves the operating layer around systems that continue to perform their intended roles.

Final perspective

Factory Metadata & Memory does not require a perfect factory architecture on day one.

It requires a clear operating event, connected context and disciplined capture of the response and result.

Build one useful memory loop. Prove it. Then repeat.