The Human Is the Missing Model
What do millions of office workers actually contribute to the systems they use every day?
They receive messages, open records, compare documents, check conditions, move information between applications, resolve inconsistencies, make routine decisions, and trigger the next action.
Most of the work already happens inside software. The data is digital. The rules are usually written somewhere. The operations are available through applications and services.
Yet the activity still depends on people.
The usual explanation is that people contribute judgment, experience, common sense, and knowledge that software cannot reproduce.
There is another possibility.
Perhaps people are not primarily supplying intelligence.
Perhaps they are supplying the missing model of the work.
The Person Inside the Automation
Modern organizations often describe their operations as automated because software performs many individual steps.
An order system stores the purchase. A payment provider processes the transaction. A support system records the request. A shipping system records delivery. An accounting system records the financial result.
But the complete activity may still depend on a person.
Consider a routine refund.
The employee may need to determine:
- which order the customer means;
- whether payment was actually completed;
- whether a refund already exists;
- which policy applies;
- whether the amount is valid;
- whether an exception is authorized;
- which system should be changed first;
- what to do when two systems disagree.
The software performs operations.
The person preserves the meaning that connects them.
This arrangement is human-machine automation.
The machine executes the part that has been made explicit. The person executes everything the system has failed to model.
What Employees Really Know
Experienced employees are often described as holders of hidden organizational knowledge.
In routine operational work, much of this knowledge describes gaps in the company’s systems and procedures.
It shows where the company functions as a collection of disconnected parts.
The employee knows:
- which field cannot be trusted;
- which instruction should not be followed literally;
- which status must be checked somewhere else;
- whom to contact when the formal process fails;
- which manual step prevents a duplicate action;
- which exception exists only because two systems were never connected.
This knowledge is real. The organization may depend on it every day.
Its existence often points to an activity that has never been fully modeled.
The person has learned the shape of the gaps and how to bridge them.
Experience as Compensation
This changes the meaning of experience.
Experience is usually treated as an asset simply because it has accumulated over time.
But experience can have two very different sources.
One kind of experience reflects a real discovery. A person encounters a new situation, identifies a relationship, creates a better method, or changes the understanding of an activity.
Another kind exists because the same defect has been encountered repeatedly. A person becomes skilled at compensating for unclear rules, disconnected systems, unreliable data, accidental job boundaries, and missing conditions.
The first kind expands what is known.
The second kind allows an incomplete system to continue operating.
Both may be useful, but they should not be capitalized in the same way.
A genuine discovery may need to be preserved and incorporated into a model.
A repeated workaround should be treated as evidence that the model is missing or that its implementation is defective.
The best use of compensatory experience may be to make that experience unnecessary.
Job Advertisements Reveal the Same Problem
The absence of a model is often visible before a person even joins an organization.
Job advertisements frequently ask for:
- strong communication skills;
- comfort with ambiguity;
- the ability to work in a fast-paced environment;
- cross-functional collaboration;
- ownership;
- the ability to manage multiple priorities.
These phrases sound meaningful, but they rarely describe the activity itself.
They leave several practical questions unanswered:
- which processes the person will perform;
- which facts those processes require;
- which decisions are permitted;
- which conditions allow or block an action;
- which results the person is responsible for producing.
The company describes the kind of person it hopes will survive the uncertainty because it cannot clearly describe the work.
The candidate is expected to reconstruct the missing structure after being hired.
This is also why a job title is a poor unit of modeling.
A title such as “manager” may refer to one coherent process or to twenty unrelated activities that accumulated on the same person over time.
That is a staffing arrangement. The activity still needs its own model.
The proper unit is the process itself: its inputs, facts, conditions, actions, changes, and results.
A person may perform many processes. A process may involve many people.
The model should separate the activity from its accidental staffing container.
Why Automating the Current Job Fails
Many automation projects begin with the wrong object.
They ask:
How can we automate what this employee does?
The answer is often a list of visible actions: read the email, open the record, copy the value, make a decision, update the system.
But the current shape of the job is historical.
It contains useful activity, inherited workarounds, organizational accidents, missing integrations, duplicated checks, and responsibilities that were assigned together for convenience instead of logic.
Automating that shape reproduces the disorder.
Attempting to automate a job title inherits its accidental structure.
This is one of the quiet reasons automation projects failed long before generative AI. They automated the arrangement that happened to exist instead of the activity’s underlying logic.
Automating disorder produces disorder at greater speed and scale.
The Model and Current Practice
A model cannot be built by observing what a company currently does and writing it down.
That would formalize the company's dysfunction as if it were the standard.
Observation provides evidence. The model captures the logic of the activity.
A model of a refund, an approval, a shipment, or a hiring process describes what the activity requires by its own logic.
It identifies:
- the relevant objects;
- the facts that must be known;
- the possible states;
- the valid actions;
- the conditions under which actions are allowed;
- the results that may follow;
- the failures that prevent execution;
- the evidence that must remain traceable.
The company's current practice is then compared against that model.
The model serves as the reference.
Where the practice corresponds, it can become reproducible and automatable.
Where it diverges, the difference deserves examination and, in many cases, correction.
No Physical Referent , No Meaning
Natural language makes weak descriptions appear more precise than they are.
A phrase may sound professional while pointing to nothing that can be checked.
This leads to a simple test:
No physical referent — no meaning.
A term in a model is meaningful only when it resolves to a specific, observable fact in the world or in an external system.
“Verify the payment” becomes a modeled condition only after it identifies what must be observed.
payment.status == Captured does.
“Strong communication skills” remains a broad label without a single referent.
“A response was sent to the identified recipient within the required time” does.
“Take ownership” becomes executable only when tied to a defined responsibility and observable result.
“The assigned decision was completed, recorded, and linked to its supporting facts” is.
A model requires terms that resolve to observable things, states, relationships, events, or results.
Its terms must resolve to things, states, relationships, events, or results that can be observed, checked, and traced.
AI and the Missing Model
Generative AI appears to solve this problem because it can interpret vague language and produce plausible actions.
The same ability can make the missing model harder to notice.
A language model is trained on the accumulated text of human work.
That text includes the same vague job descriptions, informal workarounds, contradictory instructions, undocumented exceptions, and compensatory language described above.
Its statistical average therefore contains the compensation as well as the underlying activity.
An AI system can read documents, identify candidate structures, compare formulations, and propose model fragments.
The definition of the activity requires more than an average of descriptions produced before the activity was modeled.
If an agent is asked to infer the meaning, rules, facts, valid actions, and boundaries while executing the activity, it involves more than performing the automation.
It is attempting to construct the model during execution.
Every run becomes another probabilistic reconstruction of what the system should already know.
From Experience to Model
This is where Experience Capitalization becomes concrete.
Experience Capitalization turns what work has revealed into reusable structure.
It is the process of determining what work has revealed and converting that result into a reusable form.
Sometimes the experience reveals a new fact or a better method.
Sometimes it exposes a missing condition.
Sometimes it shows that two systems disagree.
Sometimes it demonstrates that a rule is incomplete.
Sometimes it proves that an entire manual responsibility exists only because the activity was never properly modeled.
The story records the event. The improved model is the capitalized result that remains afterward.
The model can then be used to:
- execute known activity reliably;
- identify what is still missing;
- prevent repeated mistakes;
- expose defective automation;
- compare different implementations;
- support future changes;
- provide components for creating something new.
Work becomes cumulative when it leaves behind a better model than existed before.
Glages
Glages is a practical system for constructing and using formal models of activity.
It begins not with the question:
How can an AI agent perform this job?
It begins with a more basic question:
What has been modeled well enough to be performed at all?
The model defines what exists, what facts are required, which states matter, what actions are valid, which conditions allow them, what results may follow, and what remains outside the modeled boundary.
A program, a service, a person, or an AI system may then perform a part of the activity inside that model.
The mechanism may change.
The model remains the source of operational meaning.
This is the relationship between Glages and Experience Capitalization.
Experience Capitalization asks what work has taught.
Glages turns the part that has become stable, repeatable, and formally expressible into a model that can be checked and used.
Where human experience merely compensates for a missing model, Glages makes the defect visible and removes the need to preserve the workaround as permanent knowledge.
The Real Form of Experiential Capital
Experiential Capital takes the form of a growing system of models rather than a larger archive of documents, stories, and employee memories.
Those models preserve what has been learned about existing activities. They support reliable execution of what is already understood. They also provide the elements, relationships, and constraints from which new models can be constructed.
This gives Experience Capitalization two practical outcomes:
Work
-> Experience
-> Models
-> Automation of the known
-> Creation of the new
An incomplete model keeps the organization dependent on people who reconstruct the activity each time.
With a model, what was learned becomes available independently of the original person, case, or system.
The model preserves meaning independently of the particular person who once supplied it.
The experience has become capital.