Sixth Sense Robotics
All insights

Insights

From a sentence to a rule: how plain language rules work

An operator types what should change. What happens between that sentence and a rule the robot follows, and why a person confirms every step.

Published · 3 min read


“From now on, anything expiring before March goes to reject.” That is a complete instruction for a person. For a robot program it is a change request, a ticket and a week. Sixth Sense treats it as what it is: a rule, to be read, structured, confirmed and applied.

Reading the sentence

The console does not run the sentence. It reads it and proposes a structured rule with four parts.

  • Condition: which items the rule applies to. Here, expiry date before the first of March.
  • Action: what to do with them. Here, reject.
  • Scope: where it applies. All lines, one line, or one product family.
  • Validity: from when, and until when if the rule is temporary.

Anything the sentence leaves open is shown as a question, not filled in silently. “Reject” on this site may mean a reject bin or a hold shelf. The console asks.

Why nothing applies without a confirmation

The proposed rule appears on screen next to the original sentence. A person compares them and confirms, edits or discards. Only a confirmed rule applies. This is not caution for its own sake. Language is ambiguous, and a rule that is wrong by one word can reject a whole shift’s output. The confirmation step costs ten seconds and removes that risk.

Who can confirm is a setting. A line lead can confirm rules for a line. A quality manager can confirm rules for a plant.

What a rule can and cannot do

A rule can narrow the actions the robot may take, add a hold, change a destination, or set a different threshold for a class of items. A rule cannot remove a safety rule, and it cannot enable an action the cell was never configured for. Hard safety rules are code, and the console has no way to edit them. This boundary is what makes plain language safe to use.

Testing a rule before it runs

Before confirmation, the console can replay the proposed rule against the last days of the decision log. It shows how many items would have been affected and lists a sample. A rule meant for one supplier that would have touched half the volume is usually a rule with a scope problem, and it is better found here than on the line.

Versions and rollback

Every rule is versioned. The log records which rule versions were active for every decision, so a question like “why was this item rejected on Tuesday” has an answer that includes the rule, the person who confirmed it and the time. Rolling back is confirming the previous version again.

What changes for the integrator

Nothing in the robot program. Rules change what the decision layer allows and prefers, not how the robot moves. The integrator keeps the program and the safety concept. The plant gains the ability to react to a new product or a new supplier the same day, with a record of who decided what.

See it decide live.

Bring your items and your exceptions. We will show you what the robot does with them.

Book a demo