How a Machineforce unit learns
Learning is a workflow, not a weight update.
No retraining and no fine-tuning. What changes is what the unit reads, and what it is allowed to do — the way a good team brings on a new hire: corrected by a person, approved by someone with authority, written into the procedure, and read the next time the job comes up.
- A question. Someone asks the unit to do its job — approve an invoice, answer a customer, file a record.
- A decision. The unit answers inside its bounds, and the decision is recorded with an id.
- A verdict. A person marks it right or wrong — "No, rush fees need approval" counts.
- A rule. One tap turns the correction into a standing rule; above the operator's authority it goes to an approver.
- A procedure step. Approved, it is written into the versioned procedure — who proposed it, who approved it, and why.
- Next time. The next decision of that kind reads the step, and cites it.
01 · Feedback binding
Every verdict names a real decision.
Right, Wrong or Adjust is stored against an audited decision id. No decision, no learning.
02 · Playbook promotion
A correction becomes a rule.
Approved, it becomes a numbered step under "Learned on the job", in a new version of the procedure.
03 · Context recall
The next decision reads what was learned.
Every turn loads the unit's rules and recent corrections, and the reply cites the step it used.
04 · Threshold tuning
Autonomy is earned, with a clock.
Approved decisions spread over different days let a unit ask for autonomy. A person grants it, it expires, and one wrong takes it away.