The Human Learning Reinforcement Framework (HLRF)
By Jay Titus — Left Hand Security
Human Learning Reinforcement Framework (HLRF)
Early Preview
This is an early look at an evolving body of work. Some concepts are still being refined, and feedback is welcome. Velocity Architecture identifies where human capability is a limit on safe velocity and what knowledge, judgment and engagement the work still depends on. Velocity Engineering turns those findings into concrete requirements.
HLRF is the human-facing outcome: a personalized plan and feedback loop for each person. It establishes what they need to know, assesses what they can demonstrate, reinforces gaps through relevant practice and reassesses whether their capability is being maintained or improved. The full HLRF paper is coming soon.
Who Moved My Human?
Ask most AI proponents or an AI itself where people fit once AI takes on the work, and you’ll hear the similar answers:
“The human will just move to the outer layer and review what the AI produces!”
This is a very shallow answer and it does nothing to address the Decay or the sheer velocity that a new general purpose technology introduces for the business or the human. In our other posts I proposed that harnessing electricity was a general purpose technology for machines. It replaced muscle and steam allowing machines to run virtually anywhere. Did our bodies decay from this advancement? I would argue yes. Today, there is at least one gym within 15 miles of most homes today, but what about intelligence, expertise, creativity, and ethics?
I cannot begin to quantify or claim that there is something like a gymnasium to maintain all of these things. What we hope to do is bring awareness to the process of implementing AI and what impact it may have as part of a measurable and adaptable strategy. Velocity Architecture does this by including people which in turn defines a process of measuring and maintaining the areas that we can anticipate or have already experienced.
Example: When Automation Outpaces Human Practice
On 1 June 2009, Air France Flight 447 was flying from Rio de Janeiro to Paris when ice briefly blocked the aircraft’s airspeed sensors over the Atlantic. The autopilot disconnected and handed control back to the pilots. They were highly trained, but they were accustomed to an aircraft that largely flew itself. Now they had to fly manually at high altitude, a task they rarely performed. They misread what was happening, the aircraft stalled and fell into the ocean, and all 228 people on board died. The investigation identified, among other contributing factors, insufficient training for manual flight in those conditions.
The lesson is not that automation is inherently unsafe or that the pilots did not care. It is that automation can quietly remove the very practice that keeps a human skill ready for the moment it is needed. The system had performed reliably for years. Meanwhile, the people expected to take over when it failed had fewer opportunities to exercise and maintain the underlying skill.
The engineer Lisanne Bainbridge described this problem in 1983: the more a system automates, the more it can leave the human operator responsible for the situations that automation cannot handle, while depriving that operator of the routine practice needed to handle them. The result is a dangerous paradox. The person is still accountable, but increasingly removed from the work that builds expertise.
That problem is no longer confined to aircraft cockpits. AI is creating the same condition in offices, engineering teams, customer service, research, marketing and software development. People may remain responsible for the outcome while doing less of the work that teaches them how to recognize when the system is wrong. Reading a summary is not the same as building the knowledge that comes from doing the work.
Social media and marketing learned to exploit human nature: content built to trigger fear and outrage keeps people scrolling. That became Doomscrolling, and it costs people control of their emotions. AI is now doing something to how people think. When people build something themselves, the effort of researching, designing, debugging and fixing it is what commits the details to long-term memory. AI removes a lot of that effort. Instead of working a problem through, people ask the AI, scan what comes back and accept it. It’s much faster, but scanning rarely makes it into long-term memory, so understanding quietly fades while the work keeps getting approved.
I absolutely love technology and I’ve seen it create a hacker culture of curiosity and endless learning, but we have also seen it have extremely negative effects. Increasing our access to information does not increase our ability to learn or think. These are defined by behaviors.
Measure this yourselves. How often are you doing this? Your colleagues?

An Example: Nancy and Tom
Say your marketing team is Nancy and Tom. Between them, they write six or so articles a week. They know the business, they know the customers, and they love the work. They research the subject, talk to people, connect ideas, find the story, decide what matters and shape it into something worth reading.
Now imagine the company wants to use AI to change their jobs. The system is trained on hundreds of articles Nancy and Tom have written. It produces the drafts, and Nancy and Tom are asked to review them. On a productivity spreadsheet, this looks like a clear win: more content, less time, lower cost.
But what has actually changed for Nancy and Tom?
Did Nancy and Tom enjoy the process of writing? They have lost a major part of the work they enjoyed and a source of motivation. They are no longer doing as much of the research, discovery and creative construction that made the job meaningful. Over time, they may have fewer opportunities to develop new ideas or exercise their own creativity. The company may have increased the volume of published content while reducing the amount of original thinking taking place inside the team.
The new work may move from creative to tedious. AI drafts can require so much correction that Nancy and Tom start saying, “It would have been faster to write it ourselves.” Instead of creating something from the beginning, they spend their time fixing awkward language, correcting facts, restoring the company’s voice and removing generic material. They have traded authorship for quality control, but without necessarily getting the efficiency or productivity that justified the change. You have traded efficiency in one measure (total output of articles), but at what cost and what is the rate of decay across this estate.
These are not just morale concerns. They can become business harms and they are actually things that you need to measure or quantify to define the actual vs perceived effectiveness of AI:
- Loss of creative practice. If Nancy and Tom stop researching, developing ideas and writing, the company may gradually lose the very skills that made their work distinctive.
- Loss of motivation and identity. Work is not only a list of tasks. People often care about the craft, expertise and contribution that those tasks represent. Removing the craft can make the remaining job feel smaller, even if the output target gets bigger.
- Review fatigue. Correcting large volumes of mediocre or inaccurate drafts can become repetitive, frustrating work. Reviewers can become less attentive, and the organization can mistake the presence of a human reviewer for meaningful human judgment.
- Loss of authorship and trust. Using someone’s work to imitate their style without involving them in the new process can feel like appropriation. That can damage the relationship between employees and the organization.
- Skill and knowledge decay. If the team no longer does the research and writing, it may become less able to recognize weak arguments, missing context, factual errors or an inappropriate tone.
- A narrower view of value. The company may optimize for the number of articles produced and overlook the relationships, insights and new opportunities that the original work created.
- Can you even measure Tom & Nancy’s performance? How? The measurements change. Tom has no problem taking credit for a successful article that he lightly edited through luck and on his review he says “His article improved customer engagement by 10%”. Nancy on the other hand has a hard time with this. She had superior engagement numbers, but never said anything because she didn’t feel comfortable taking credit for something she didn’t fully do. What would happen in your organization.
The important point is that the company has not simply automated writing. It has redesigned the work, the roles, the incentives and the relationship between the people and the output. Those changes have consequences that a simple productivity calculation will not capture.
What Would Keep Nancy and Tom Engaged?
In 1854, at the Crystal Palace exhibition in New York, a mechanic named Elisha Otis stood on an open elevator platform high above the crowd and ordered the only rope holding it to be cut. The platform dropped a few inches and stopped. Otis’s safety brake had caught it. [5] Elevators already existed; what they lacked was trust. Otis’s brake supplied it, and with it came the skyscraper.
Half a century later the story repeated itself. By around 1900 the elevator industry had built an elevator that needed no operator at all. It was ready, and people refused it. Passengers stepped in, looked around, stepped back out and asked where the operator was. For decades, buildings kept paying people to run machines that could run themselves. What finally changed things was a crisis: in 1945, elevator operators in New York went on strike and brought the city to a standstill. Building owners demanded automatic elevators, and the industry set out to make people trust them.
It did not do it by building a better motor. It did it with design. A calm recorded voice told riders what was happening. A big red button let anyone stop the car. A telephone connected them to a person. Even so, it took more than fifty years from the first automatic elevator until riders were truly comfortable with it. [6]
This is where Velocity Architecture, Velocity Engineering and HLRF work together. Velocity Architecture identifies the trust boundaries and trust limits, the PACER floor, the current PROBE potential and the applicable SPEC constraints. It helps the business decide which work to automate, which work to keep human, and where investment or redesign is needed. It also makes the People limits visible: not just whether a person can review an output, but whether the process preserves the human capability and judgment the business depends on.
The fastest speed or the lowest cost isn’t automatically the best result. A business should capture the productivity AI creates without quietly destroying the human capabilities that made the business valuable in the first place. Velocity Architecture helps define the limits. HLRF helps keep people capable and engaged as those limits move. The business still has to decide what kind of work, and what kind of organization, it wants to build. If those decisions affect or include your people and customers you are likely building more than a new application or tool. You are deciding what type of factory you want to build
Six Principles
- Productivity Must Not Require Abandoning Understanding. AI can do the work, but people still need enough knowledge to exercise competent judgment over it when the function is moved to another layer.
- Reading Is Not Evidence of Understanding. Summaries and explanations are inputs to learning, not proof that it happened.
- Demonstrated Judgment. Explaining, predicting, reviewing, debugging, threat modeling and correcting the AI’s output are all stronger evidence than reading about it.
- Reinforcement Should Match the Stakes. Don’t interrupt every interaction; step in when something consequential isn’t understood.
- People Must Know What Is Missing. Spotting wrong assumptions, missing requirements, security weaknesses and hallucinations is now a core skill in the new world.
- People Must Stay Engaged. Take away the part of the work that drives people and you lose their judgment first, then the people. Velocity Architecture finds that limit too: People is the first question PROBE asks.
Moving the Human Limit
The People limit is not fixed. Training, deliberate practice, meaningful participation and better tools can increase the capability people bring to the work. Passive review, loss of purpose, turnover and lack of practice can reduce it. The point of measuring human understanding is not to label people or create a surveillance score. It is to identify what capability the role requires, determine whether it is present, and invest where it can be strengthened.
As people gain capability, the safe potential velocity of a process may increase. If knowledge or judgment decays, the potential may fall and the process may need more sampling, slower operation or a return of work to people. HLRF therefore supports a continuous cycle: establish the required capability, assess it through demonstrated judgment, reinforce what is missing, and reassess. This is one way the framework helps move a PROBE limit rather than simply accepting it.
Thanks for reading.
Jay Titus
Left Hand Security
© 2026 Left Hand Security · CC BY-ND 4.0 · lefthandsecurity.com/papers/velocity-architecture
