'Closing the Loop' Isn't Closed When the Action Runs in Your PLC

Give the category its due, because the engineering is real. The newest manufacturing computer-vision platforms are genuinely more end-to-end than a bare detector that returns a bounding box and stops. They don't just classify — they write the detection into a PLC tag over an industrial protocol, or pipe extracted fields straight into an MES, an ERP, or an RPA bot. That is a legitimate step past "here's a dashboard, watch it yourself."

And the surrounding capabilities deserve the same honesty. Expert-guided labeling and rapid model training have genuinely put computer vision within reach — a line engineer can stand up a defect model without a research team. Pixel-level grounding and source citations make the read verifiable and materially cut confidently-wrong reads: you can see the pixels the model keyed on. Confidence scores plus human-in-the-loop review are a real, pragmatic middle path, not a fig leaf. And edge deployment with SOC 2, HIPAA, and zero-data-retention postures is real assurance for real security teams.

All of that is true, and none of it is the point. Because every one of those strengths governs the model and the read — accuracy, drift, provenance of the pixel, the perimeter around the endpoint. "Closing the loop," though, is a claim about the action. And the action is precisely where this architecture quietly hands off.

When a detection becomes a tag value on OPC-UA, Modbus, or EtherNet/IP — or a structured record dropped into an MES queue for an RPA bot to pick up — what travels across that wire is data, not decision authority. A boolean. A class label. A confidence float. The logic that decides what to do with it lives somewhere else entirely.

Consider what "what to do with it" actually contains: the acceptance threshold for this product and this customer's spec; whether the current batch is under a quality hold; who is allowed to override a disposition; whether a borderline score should pause for a human rather than actuate. That logic is authored by different people — controls engineers in ladder logic, integrators in MES workflows — on a different release cycle, in a different tool, under a different change process. The vision platform governs the model. The second system governs nothing about the detection; it simply reacts to a value it received.

This is structural, and it stays true no matter what any roadmap adds: the moment the consequential action executes in a system that only received a value, the governance that made the read trustworthy stops at the network boundary. No policy is attached to the number on the wire. The most carefully governed detection in the world becomes an ungoverned actuation the instant it crosses into the PLC.

Now trace the evidence, because this is where a CISO or a quality director should get uncomfortable. Two systems act, so two systems log — and they log different halves of the same event.

The vision platform records what the camera saw: the image, the score, the grounding overlay, the model version. The PLC historian or MES records what the actuator did: reject arm energized, batch dispositioned, reject counter incremented. Two logs. Two clocks. Two identity models. No cryptographic binding between the "saw" and the "did."

So when a recall, a safety incident, or an auditor arrives and asks the only question that matters — "prove this action followed from that detection, under the policy in force at that timestamp, with the right approval" — you are joining across two systems after the fact, and the join is lossy. You can show the camera saw a defect. You can show a reject fired forty milliseconds later. What you cannot produce is a single tamper-evident record that binds this action to that detection under that policy with that authorization. That is not an integration bug you can patch. It is the native shape of a detect-and-write-back architecture: the audit is split-brained by construction.

Make it concrete. Picture a hypothetical seal-weld inspection on a packaging line — illustrative, not a delivered deployment. A borderline weld comes through.

The endpoint pattern. The model returns "defect, high confidence" and writes it to a data block. Ladder logic reads the tag and energizes a reject solenoid. The part diverts. What never happened: no reason code was bound to the disposition; no segregation of duties was enforced, so the same identity that runs the line is the one who could later clear anything; no gate held the borderline score for a quality inspector; and no single record ties the pixel evidence to the actuation. If the acceptance threshold was wrong for this customer's spec, nobody authored that as reviewable policy — it's buried in ladder logic that the vision team never sees and the auditor can't read.

The fabric pattern. In Entroid the same vision model runs as a governed Function inside a Deterministic Workflow — and this is an architectural property of the design, not a claimed result. The detection is consumed inline. A policy gate evaluates it: a high-confidence defect opens a governed quarantine automatically; a borderline band routes to a human-in-the-loop step where a quality inspector — an Atomic Agent with HITL as a first-class primitive — adjudicates before anything actuates; a clean read passes with sampled logging. The quarantine or rework action still reaches your MES or PLC, but it reaches them through a Connector — the only primitive that touches external systems. ES runs over your existing estate; it does not rip out your controls.

The difference is what rides with the action. That actuation is permissioned. It enforces segregation of duties by construction — the operator who ran the line cannot also clear the hold. It carries a reason code. And the entire detect → decide → act sequence is written as one immutable per-action audit entry that binds the grounded pixel evidence, the policy version, the human approver if there was one, and the actuation itself. Not two logs to reconcile. One accountable transaction on one runtime.

Here's the uncomfortable part for anyone about to sign a manufacturing-vision contract on the strength of a slick "closed loop" demo: you are not choosing between a good detector and a bad one. The read may be excellent. Demand the grounding, demand the confidence scoring, demand the edge security certifications — those are table stakes and the leaders deliver them. The real question is architectural, and the demo won't answer it: where do the decision and the action live, relative to the governance?

In the detect-and-write-back pattern, the loop closes inside a second system that acts on a value it cannot govern, and reports its half of the story into a separate log. In ES, the loop closes inside the workflow itself. Five primitives carry it: Deterministic Workflows with governance enforced inline, Intelligence Orchestration, Atomic Agents with HITL first-class, Functions (where your vision model lives), and Connectors (the only primitive that ever touches the PLC or MES) — all on a Semantic Ontology, one runtime, one immutable per-action audit.

• Detect, decide, act, and audit stop being four systems and become four steps of one transaction.
• Policy travels with the action because there is no wire to cross — the decision executes on the same runtime as the read.
• The audit is single-brained by construction, so "prove it was authorized" is a query, not a forensic reconstruction across two historians.

That last point is the whole argument compressed. A signal thrown over a wall can be fast, cheap, and even accurate. What it can never be, on its own, is accountable — and on a regulated factory floor, accountability is the product.