Skip to content

What Edmund Lee's 1745 windmill patent teaches about feedback control

A windmill fantail sensed a change in wind direction and powered its own correction. The useful history is not an invention myth, but a compact study of feedback, failure modes, and system boundaries.

By Leadbase Team12 Min. reading time
A windmill fantail converting a change in wind direction into mechanical correction

The most defensible historical claim is narrower than “Edmund Lee invented the self-orienting windmill in 1745.” Modern authorities consistently connect Lee to a British patent or patent application dated 1745 that described a fantail: a small auxiliary wind wheel that turned a mill back into the wind. That establishes a documented patent attribution. It does not, by itself, prove that Lee was the first person to conceive or build every part of the mechanism, or that a working mill entered service in precisely that year.

That qualification makes the story more useful, not less. The fantail is a clear mechanical example of a system that detects a deviation, acts on it, and reduces the deviation through its own response. It also shows why automation must be judged by its boundaries and failure modes, not merely by whether it can run without a person touching it.

Four questions to keep in view

As you follow the mechanism, ask: What changed in the environment? What part of the mill detected that change? Did the resulting movement reduce the original error? What important conditions remained outside the loop?

Those questions separate feedback from a timed sequence and bounded automation from claims of autonomy. The article establishes the historical record first, labels later engineering deductions as deductions, and only then applies the design test to modern automation.

What the historical record supports

The Mills Archive's technical glossary describes a fantail as a set of typically six to eight wooden vanes mounted at right angles to the main sails, connected by shafts and gears to the mill's winding mechanism. It attributes a 1745 patent to Edmund Lee. Control engineer Dennis S. Bernstein uses slightly more cautious wording in his 2002 IEEE article, “Feedback Control: An Invisible Thread in the History of Technology”: he refers to a British patent application dated 1745 and identifies Lee as a blacksmith.

Those sources agree on the year, attribution, and operating idea, but “patent” and “patent application” are not identical claims. We have not inspected the original enrolled specification. The UK's National Archives guidance on pre-1852 invention patents explains that early patent records are only partly available online and often require historical indexes and parchment records. A specialist SPAB study catalogued by the Mills Archive is titled “Lee's patent windmill 1744–1747”, which also points to a development history broader than one isolated date.

The safe formulation is therefore:

A British patent record associated with Edmund Lee in 1745 documented a fantail mechanism for automatically winding a mill into the wind. The available secondary authorities support that attribution, but they do not settle every question of first conception, construction, or sole inventorship.

The problem existed before the fantail

Wind direction changes. A traditional mill only extracts useful power when its main sails are presented correctly to the wind. In a post mill, the whole body could be turned; in later smock and tower mills, a rotating cap carried the windshaft and sails. Bernstein's history places vertical windmills in western Europe by the 12th century and rotating caps by the 15th, with orientation still performed manually.

<img src="/assets/blog/fruehe-automatisierung-4.jpg" alt="Early European post mills whose bodies could be turned toward the wind" />

Manual winding was not merely a single setup action. When the wind changed, someone had to notice the misalignment and turn the structure or cap again. The fantail transferred that repeated correction into the mechanism itself.

How the fantail closes the loop

The physical arrangement is compact. The fantail sits at right angles to the main sails. When the mill is correctly aligned, the fantail lies approximately parallel to the wind and produces little turning force. When the wind direction changes, it strikes the fantail at an angle. The fantail rotates, its gearing turns the cap or mill body, and that movement changes the angle seen by the fantail. As alignment is restored, the force driving the correction falls away.

English Heritage's description of Sibsey Trader Windmill shows the mechanism in a surviving tower mill: the fantail turns the cap on a circular iron curb until the main sails face the wind again.

<img src="/assets/blog/fruehe-automatisierung-3.jpg" alt="Tower windmill with a small fantail mounted behind and at right angles to the main sails" />

In control terms, the same assembly performs several jobs:

Control elementPhysical implementationWhat happens
DisturbanceA change in wind directionThe main sails are no longer correctly oriented
Error-sensitive elementThe angle between the wind and the fantailMisalignment creates aerodynamic force on the fantail
Actuator and transmissionFantail torque, shafts, reduction gears, and a rack or travelling wheelsThe cap or mill body turns
Controlled stateOrientation of the main sails relative to the windThe correction changes the condition being sensed
Null conditionFantail approximately parallel to the windCorrective torque drops as alignment returns

This is feedback because the action changes the input that caused the action. It is not a programmed sequence that says “turn five degrees every ten minutes.” The geometry continuously couples environmental change to a corrective movement.

The fantail is also a useful reminder that “sensor,” “controller,” and “actuator” need not be separate devices. Here, aerodynamic loading both reveals the directional error and supplies energy for the correction. The target state is embodied in the right-angle geometry rather than stored as a number.

What the mechanism did not control

The fantail controlled orientation. It did not by itself regulate wind speed, sail loading, millstone pressure, flour quality, lubrication, structural stress, or safe operation in a storm. Bernstein notes that Lee's 1745 proposal also addressed wind-speed variation with a counterweighted arrangement that rotated the main sails about their long axes. That was a distinct control problem and should not be credited to the fantail itself.

It is equally unsafe to describe the fantail as making a mill “fully autonomous.” A closed loop can handle one disturbance while leaving the rest of the system dependent on inspection, maintenance, judgement, and shutdown procedures.

The following limitations are engineering deductions from the documented mechanism, not a claim that every historical mill exhibited every fault:

Limit or failure modeLikely effectModern design lesson
Wind too weak to overcome frictionMisalignment may persistA signal can exist without enough authority to act on it
Backlash, wear, or a jam in the gearingDelayed, imprecise, or absent correctionMonitor the actuator and the outcome, not only the trigger
Rapidly varying wind directionRepeated repositioning or huntingAdd a deadband, threshold, or damping when reacting to noise
Gust or storm outside the operating rangeExcessive loads despite correct orientationDefine a safe envelope and a shutdown path
Broken or disconnected transmissionFantail movement without cap movementDetect partial failure between stages
Correct direction but wrong load conditionThe orientation loop succeeds while the mill remains unsafe or ineffectiveDo not confuse one controlled variable with system health

That last distinction is central. A dashboard can show that an automation “ran” while the desired business outcome never occurred. The historical loop is impressive precisely because its output—physical reorientation—feeds back into its own input. Modern workflows often stop at the first action and call that success.

A practical checklist for modern automation

Use the fantail as a design exercise, not as a metaphor pasted onto every software system.

1. Name the state you are trying to control

“Automate lead research” is an activity. “Keep every accepted account attached to current evidence for these five qualification fields” is a state that can be inspected. Write the desired state and who is responsible for it.

2. Define the disturbance

What makes the state wrong again: a job change, a new company signal, an expired verification date, a CRM edit, a failed delivery, or a changed territory rule? If the workflow cannot observe the disturbance, scheduling it more often does not solve the design problem.

3. Preserve the signal and its time

Store the source, observed value, observation time, and confidence or verification status. A derived field without provenance cannot be audited when the environment changes.

4. Separate detection from permission to act

A signal can start research without authorising a CRM overwrite or an outbound message. Define which actions are reversible, which require review, and which must never run automatically.

5. Confirm the actuator changed the real state

Do not stop at “job queued,” “API returned 200,” or “workflow completed.” Check the destination field, owner, suppression state, or downstream record that was supposed to change.

6. Make unknown and failure explicit

No result, conflicting sources, rate limiting, insufficient permission, stale evidence, and a failed write are different states. Do not collapse them into an empty cell or a green completion badge.

7. Prevent hunting and noisy reactions

Use thresholds, cooldowns, deduplication, or human review when signals fluctuate. Repeatedly reversing a decision can be more damaging than waiting for stronger evidence.

8. Keep a manual override and a safe stop

Document how a person pauses the workflow, prevents a write, corrects a value, and resumes safely. Test the stop path before relying on the automation at scale.

9. Draw the system boundary

List what the loop controls and what remains outside it. A workflow may keep a contact field current without deciding whether outreach is lawful, whether the account is commercially relevant, or whether the message is appropriate.

10. Review drift with real outcomes

Compare accepted accounts, corrections, delivery failures, replies, and CRM outcomes over time. Feedback is only useful if it can change the rule, source, threshold, or workflow that produced the result.

How to test the loop in Leadbase

An 18th-century windmill does not validate a sales product, and the fantail is not an early AI agent. The defensible connection is a design test: reliable automation needs explicit inputs, a bounded action, observable outcomes and exceptions, human authority, and a recovery path.

Leadbase's documented behavior makes that test concrete for lead research:

Control questionDocumented Leadbase behaviorWhat to inspect in a sales evaluation
Is the research task bounded?An enrichment column has a target, a focused prompt, and explicitly selected context columns.Can another person explain exactly what one run is meant to establish and which inputs it may use?
Can the team distinguish activity from a usable answer?Cells show active work. A completed result can be reviewed before acceptance, and incomplete inputs or uncertain research can finish without a usable result.Include rows that should return no result; do not judge the system only on easy successes.
Does a schedule expose execution rather than imply success?Scheduled enrichment belongs to one enrichment column in one Sheet. Its history distinguishes completed, skipped, pending, dispatched, and failed runs. A completed run does not promise that every row received a value.Trace one scheduled occurrence from its configured context through run status to the resulting cells.
Who may review, change, or approve the work?Sheet access separates viewer, editor, manager, and owner capabilities. Assistant approval modes can pause before research or edits without bypassing those access boundaries.Name the owner, reviewer, escalation path, and actions that must still wait for approval.
Is evidence reviewable?Enrichment results can expose confidence, a concise summary, and source links for review.Ask a reviewer to challenge an accepted result, an uncertain result, and a no-result case using the underlying sources.
Can the team recover from a bad change?A Sheet keeps immutable history. Managers and owners can compare, name, and restore revisions; recent committed actions may be undone.Deliberately correct a bad value and show how the team can inspect or recover the earlier state.

This scope ends before generic business-process automation, sequencing, or CRM ownership. Leadbase can make a qualification and enrichment loop observable; it does not turn a successful schedule status into proof that the value is correct, commercially useful, or ready for outreach.

If your team cannot currently reconstruct why a researched account was accepted, rejected, or left unresolved, review one live automation loop with Leadbase. Use a small set of representative rows and require the discussion to cover inputs, evidence, no-results, failed runs, reviewer intervention, ownership, and recovery before deciding whether to expand it.

Source note

Sources reviewed: 8 August 2026. The article distinguishes documented attribution from unresolved priority and deployment questions.