Digital strategy and architecture

Architecture / From signal to decision

Capture the event before modelling the system.

Architecture starts at the machine, not in a dashboard. Capture what happened, where and when, then preserve its meaning through edge inference, storage, synchronisation and presentation. Modelling follows the operating question.

Conceptual stack. Not deployed-system telemetry.

Select the connection stateConnectedIntermittentOfflineRecovering

Current connection state

Serve the view, preserve the source.

Edge inference flags an event while source observation and operator context remain attached. The dashboard is a view, not the sole record.

Dashboard current / local record retained

Current connection state

Buffer without changing meaning.

On an unstable connection, a visible bounded queue preserves order and context. The remote view declares that it is behind.

Edge available / synchronisation pending

Current connection state

Keep the line operable.

Local functions and controlled manual fallback work without remote permission. Operators see the mode and record decisions, avoiding hidden dashboard dependence.

Local operation / remote view held

Current connection state

Reconcile before resuming.

Synchronisation detects duplicates and conflicts using stable identifiers. Automation resumes after the backlog and operating state are understood.

Backlog checked / record reconciled

Plane by plane, in this state
DASHBOARD	CurrentDeclares it is behindHeld, not trustedCatching up
ANALYTICS	CurrentBehind the recordHeldResumes after the check
RECORD	Retained locallyOrdered queue heldRetained locallyReconciling the backlog
EDGE	Inferring beside the lineBuffering, boundedLocal functions runSyncing the queue
CAPTURE	Capturing with contextCapturing with contextCapturing with contextCapturing with context

The instrument demonstrates states, not live telemetry. Queue cells are symbolic. Degraded behaviour belongs in the architecture, not in a later exception report.

The operational record

Make every decision reconstructable.

An event must serve the operator, engineer and auditor. Connect source signal, inference, human response and business view without reducing it to an anonymous metric.

Attach the next field group to the event recordSource and contextKeep the observation attached.Inference and versionKnow what made the classification.Human authorityRetain judgement and override.Ownership and retentionAssign custody before integration.

Asset, line, product, timestamp and signal quality give meaning. Missing context stays visible rather than being silently repaired later.

Model version, confidence, rule and threshold belong with inference. A model change must not obscure an earlier decision.

Confirmation, rejection, override reason and handover record human decisions. Manual review belongs within the record, not outside it.

Named owners cover access, retention, export and deletion. Records remain retrievable without depending on a vendor portal.

A dashboard is a view, not the record itself. Any layer that cannot explain its source is not ready for automation.

Event record, unfolded from the Record plane

1 of 4 field groups attached2 of 4 field groups attached3 of 4 field groups attached4 of 4 field groups attached

Source and context

Asset
Line
Product
Timestamp
Signal quality

Inference and version

Model version
Confidence
Rule
Threshold

Human authority

Confirmation
Rejection
Override reason
Handover

Ownership and retention

Access
Retention
Export
Deletion

Evidence / Inspection literature

Treat inspection gains as a hypothesis to prove.

Inspection literature justifies testing machine vision, not promising a result. These are literature findings, not acceptance results for a factory, line, fabric or deployment.

The cited literature reports manual inspection at 60 to 70% accuracy, with 20 to 30% of defects missed, and computer vision above 90% across more than 40 defect types. This is a proposition to test, not a local baseline or benefit case.

Local proof needs a labelled sample representing products, defects and conditions in scope. Compare manual and assisted inspection under an agreed protocol, retaining false alarms, missed defects and uncertain cases. The operating team sets acceptance criteria before procurement.

Choose the inspection method to readManualComputer visionBoth

Literature finding, not acceptance result

Literature ranges on one percentage scale. The marker reads a position, not a result.

Move the marker along the accuracy scale

70%: top of the manual range

Source: R29, MDPI and industry inspection literature, retained in the programme annex. This grade C source is not independently reverified. Values are literature findings, not local performance or acceptance results.

Manual inspection in the literature

60 to 70%Manual inspection accuracy in cited literatureA published range, not a site baseline.

20 to 30%Defects reported as missedA literature finding, not a measured local loss.

Computer vision in the literature

Above 90%Computer vision accuracy in cited literatureReported across more than 40 defect types, not an acceptance result.

Both ranges, one gap to prove locally

60 to 70%Manual accuracyLiterature range.

Above 90%Computer vision accuracyLiterature claim, to be tested on a local labelled sample.

Hover or focus a bar to read its value and source grade.

Manual inspection accuracy: 60 to 70%

Literature range from R29, source grade C. A published range, not a site baseline.

Defects reported as missed: 20 to 30%

Literature finding from R29, source grade C. Not a measured local loss.

Computer vision accuracy: above 90%

Literature claim from R29, source grade C, across more than 40 defect types. Not an acceptance result.

When the network is absent

The process must not disappear into a loading state.

Architecture is judged by what remains understandable and operable when its connections are unavailable.

Edge inference belongs near inspection when delay or connectivity could interrupt work. A local node can apply an approved model, retain the record and show current state without waiting for a dashboard.

Light one part of the local sceneEdge inferenceBounded bufferManual authorityReconciliation

A local node applies an approved model and shows current state without waiting for a dashboard.

Queue age, capacity and synchronisation status stay visible while the link is down.

A named role authorises and logs the change, with inspection instructions still available.

Queued records are reconciled after recovery, preserving disagreement between machine and human review.

A weak connection should reduce visibility, not remove control.

Phased use cases

Earn each layer with a usable record.

Each phase leaves something useful if the next stops. Expansion depends on data quality rather than enthusiasm for a larger platform.

Current sequence state

Layer 1 of 5Layer 2 of 5Layer 3 of 5Layer 4 of 5Layer 5 of 5

Capture layer built, signal and context attachedEdge layer added, inference in shadow or assisted modeRecord connected, one event structureDashboard reads the record, analytics still to be earnedAnalytics earned, proven layers retained

Phase / Capture

Start with the operational question.

Select a narrow decision such as defect review, downtime classification or energy investigation. Define the event, owner and action before choosing technology. Instrument the workflow, record missing context and establish a manual baseline before modelling.

Source layer / signal and context captured

Read-out, phase 1 of 5

CAPTURE
EDGE
RECORD
DASHBOARD
ANALYTICS

Now true: One narrow decision is chosen, with its event, owner and action defined. Missing context is recorded and a manual baseline exists.
Exit test: Technology is chosen only after the event, owner and action are defined.

Phase / Edge

Run inference beside the operator.

Introduce edge inference in shadow or assisted mode. Keep source evidence, model version and operator response together. Test defects, lighting, product variation and network loss. Acceptance follows the agreed protocol, not a favourable demonstration.

Edge layer / local inference with review

Read-out, phase 2 of 5

CAPTURE
EDGE
RECORD
DASHBOARD
ANALYTICS

Now true: Inference runs in shadow or assisted mode. Source evidence, model version and operator response are kept together.
Exit test: Acceptance follows the agreed protocol, not a favourable demonstration.

Phase / Record

Connect the record before adding use cases.

Use one event structure for downtime, quality and maintenance. Buffer during outages, synchronise with stable identifiers and expose conflicts. Add use cases only when this record is dependable, so dashboards cannot tell incompatible stories about one line.

Record layer / ordered events reconciled

Read-out, phase 3 of 5

CAPTURE
EDGE
RECORD
DASHBOARD
ANALYTICS

Now true: Downtime, quality and maintenance share one event structure, buffered through outages and synchronised by stable identifiers.
Exit test: Add use cases only when this record is dependable.

Phase / Dashboard

Turn KPI proof into an operating ritual.

Publish numerator, denominator, time window, exclusions and data coverage with each KPI. Compare against the baseline, investigate missing records and retain review. KPI movement prompts verification, not proof that digital systems caused improvement.

Dashboard layer / traceable KPI views

Read-out, phase 4 of 5

CAPTURE
EDGE
RECORD
DASHBOARD
ANALYTICS

Now true: Each KPI publishes its numerator, denominator, time window, exclusions and data coverage against the baseline.
Exit test: KPI movement prompts verification, not proof that digital systems caused improvement.

Phase / Scale

Extend only what survives scrutiny.

Scale when operators can run the use case, support can recover it and evidence supports the decision. Reuse the capture, fallback and review contract. Stop layers that add work without improving decisions.

Complete stack / proven layers retained

Read-out, phase 5 of 5

CAPTURE
EDGE
RECORD
DASHBOARD
ANALYTICS

Now true: Operators can run the use case, support can recover it and evidence supports the decision.
Exit test: Stop the layers that add work without improving decisions.

Review the evidence

BuyExitOwnSupport

Build, buy and govern

Buy the commodity. Own the operating meaning.

Procurement should protect operation, supplier change and data ownership. Custom development is for tested differences in operating method, not ordinary platform capabilities.

Turn the dial to a procurement positionBuyBuy before buildPurchase the ordinary capabilities.ExitExit before entryRehearse the vendor exit.OwnSecurity with ownershipMatch control to operating risk.SupportSupport the degraded stateMake recovery an ordinary procedure.

Prefer supported products for device management, storage, visualisation, identity and updates. Build only when purchased components fail tested requirements. A prototype does not justify permanent software.

Require usable exports of events, annotations, configurations, models, audit logs and documentation. Test restoration and exit during procurement. Contract for transition, credential handover and deletion.

Name the business and technical owners. Use least privilege, network segregation, controlled remote access, signed updates and reviewed audit trails. Recovery procedures and key custody stay with the organisation carrying operating risk.

Assign response to failed inference, full storage or stopped synchronisation. Cover spares, rollback, buffer inspection, manual operation and reconciliation. Basic production must not depend on remote support.

Programme design

Fund proof, not a permanent promise.

Release effort in stages, with evidence and an exit decision at each boundary. Architecture stays stable while use cases earn their place.

Staged release, illustrative method and not a delivery schedule

Select the proof that releases the next stageGate 1Inspection proofA labelled test, agreed acceptance protocol and operator review for any vision use case.Gate 2Data-spine proofA recoverable event record joining quality, downtime and energy questions without hiding missing data.Gate 3Operating proofA KPI review showing baseline, coverage and uncertainty, with rehearsed manual and vendor-exit paths.

Gate

A labelled test sample and an agreed acceptance protocol exist before any procurement.

Evidence

False alarms, missed defects and uncertain cases are retained, with operator review.

Exit decision

Extend the vision use case, repeat the test, or stop before procurement.

Gate

Event definitions and owners are clear for the first use case.

Evidence

A recoverable record joins quality, downtime and energy questions, with missing data visible.

Exit decision

Add the next use case only if the record is dependable. Otherwise hold.

Gate

A KPI review compares the baseline, shows data coverage and states the uncertainty.

Evidence

Manual operation and the vendor exit have been rehearsed, not only documented.

Exit decision

Scale the proven layers. Stop the layers that add work without improving decisions.

Start thin

Begin with a thin edge-to-dashboard slice around one valuable decision: capture, justified local inference, operational record, degraded behaviour and KPI view. Test it with operators and support staff so integration and ownership problems surface early.

Grow only with owners

Add use cases only when event definitions and owners are clear. Training, support and vendor-exit rehearsal run beside technical work, avoiding dependence on one integrator or a few enthusiasts.

Read the shared measurement approach

Continue the architecture

Keep the stack open at every layer.

The stack ends with an inspectable event and a decision under operational control. Choose a layer to continue the thread: resilience, procurement and delivery planning.

Selected: Edge to dashboard

Paper / DASHBOARD