Engine Five: Own the Data and the Relationships

Tom has translated and rewritten industrial equipment manuals for twenty years.

In that time he has seen roughly four thousand documents from perhaps sixty manufacturers, in two languages, across hydraulics, packaging lines, and food processing equipment.

Somewhere in his files and his head is a list of the mistakes that recur: the phrases that regulators query, the safety warnings that get mistranslated in a particular way, the seven document types that always come back for revision.

An AI system has read far more text than Tom. It has not read those four thousand documents, because they are confidential, they are not on the public internet, and nobody has ever labelled which of them were rejected and why.

That last part is the whole lesson. The scarce thing is not information. It is information that exists nowhere else, tied to outcomes.

Engine Five is the work of turning what you already see, know, and can reach into something you own. It is the engine most compatible with keeping the job you have.

Why This Is the Most Underrated Engine

The other four engines require you to buy something, build something, or become visible.

Engine Five usually requires none of those. You already sit inside an information flow and a set of relationships; what is missing is the decision to record it, structure it, and hold it in your own name.

A model can replicate your reasoning, but not the fact that thirty people in a niche answer your messages within the hour.

Four Things You Might Already Own

A small dataset of outcomes

Not a large dataset. A small one, with outcomes attached.

Four hundred rows of "we tried this, here is what happened, here is what it cost" beat four million rows of public text, because the public text has no outcome column.

A recruiter's record of which candidate profiles lasted three years. A contractor's record of what twelve kitchen renovations actually cost against quote.

These are proprietary datasets, and almost nobody treats them that way.

A list you may contact

A list is not names; it is people who have agreed to hear from you. The permission is the asset, and without it you hold contact details that carry legal risk rather than value.

Exclusive access

Access is a position, not a possession. Being the person who can get a meeting with the four buyers who matter in a small industry is an asset, even though nothing about it is written down.

A network position between two groups

The most durable form is structural: you sit between two groups who need each other and do not talk.

Someone who knows both the compliance officers and the equipment engineers occupies a position that neither group can occupy. Value flows through the gap, and the person in the gap can charge for the crossing.

Turning Tacit Knowledge Into a Proprietary Process

Most of what experienced people know is tacit: it guides their decisions but has never been written down, and it retires when they do.

Written, structured knowledge becomes an asset that can be licensed, sold, taught, or embedded in a workflow.

The conversion has four steps.

First, extract. Sit down and write the decision rules you actually use, in the form "when I see X, I check Y, because Z happens otherwise." Aim for fifty rules, not five.

Second, structure the rules into a sequence someone else could follow: a checklist, a review protocol, a scoring rubric.

Third, validate against outcomes. Go back through past work and mark where each rule was right and where it was wrong. The outcomes are what make it a dataset rather than an opinion.

Fourth, embed. Put the process to work where it earns: as the specification behind an automated workflow you supervise, as a paid audit, as a training program, or as the reason your review is worth three times the going rate.

A written process validated against your own outcomes is the closest thing a single person can own to a trade secret.

Consent, Privacy, and Who Owns What

This engine touches other people's information, so it carries obligations that the other engines do not.

Two questions decide whether what you are building is an asset or a liability, and a third, in the section after this one, decides whether it is wise.

Does your employer or client own it?

If you developed the knowledge on an employer's time, using their systems, their documents, and their customer data, then in many jurisdictions the work product and the data belong to them, and your contract may say so explicitly.

What is yours is almost always different from what is theirs. The client list and the specific documents are theirs.

Your general skill, your judgment, and your professional relationships are usually yours, though the boundaries differ by country and by contract.

The safe practice: build your process from your own generalized knowledge, not from copied files.

Do not take documents, exports, or customer databases when you leave, and keep your written rules free of any client's confidential specifics.

Do you have permission to hold and use personal data?

Data protection rules vary considerably by country and sometimes by state or province, and they are changing. Several regimes require a lawful basis for processing personal data, a clear purpose, a way for people to see and delete what you hold, and an easy way to unsubscribe.

The practical version for a small operator: collect the minimum, say plainly what you will use it for, get an explicit opt in where it is required, keep the record of when and how consent was given, and honour deletion requests promptly.

This lesson is not legal advice, the rules differ substantially between countries, and anyone building a data asset of real size should confirm the requirements in their own jurisdiction with a professional.

The Comfort Test

Beyond the law there is a stricter reputational test, and it is the one that protects Engine Four. If a contact would be uneasy to learn you had recorded something about them, the entry is a liability. Record outcomes and patterns, not private details about people.

How the Asset Earns

A data or relationship asset rarely earns directly. It earns by raising the price and the win rate of something else.

Suppose Tom's process lets him review a safety document in forty minutes where an unaided reviewer takes two hours, with fewer misses. He does not sell forty minutes. He sells a reviewed document with his name on it at $600, an effective $900 an hour, and the margin exists because of the process rather than the typing.

That is the quiet compounding of this engine: the data improves the offer, the offer wins clients, the clients generate more outcome data, and the list grows.

What the Three Readers Do

Maya

Maya's proprietary data is sitting in her employer's systems, and she is careful about that line. She does not export anything.

What she builds instead is her own record, kept in her own notes: for each campaign workflow change, what the hypothesis was, what the measured effect was, and what broke. Two years of that is a small dataset about how shrunken marketing teams actually operate.

She also keeps a private contact record of every good person she has worked with, and contacts twenty of them a quarter with something useful and no request.

When she eventually advises other teams, that record is her pipeline, and her generalized process, not her employer's data, is her product.

Tom

Tom spends six weeks, roughly eight hours a week, writing down what he knows. He produces a hundred and forty rules across seven document classes, phrased as observable checks rather than opinions, and validates them against his own past work rather than against client files he no longer has the right to hold. Ninety survive.

He now has something that did not exist before: a written review protocol for safety and compliance documentation in industrial equipment, tested against twenty years of outcomes, held in his own name.

He uses it three ways. It is the specification for an AI assisted first pass that he checks, the basis of a two day training he sells to a manufacturer's documentation team for $4,500, and the reason his signed review is worth $600 rather than $180.

He builds his list by hand, asking each contact for permission in plain words and keeping a note of the date. By the end of the second year the list is about two hundred and forty people, and he has never sent a message to anyone who did not ask for it.

His income recovers to roughly $71,000, and unlike his old translation income, most of it now depends on an asset rather than on hours.

Leo

Leo has no twenty year archive. What he has is a front row seat.

In customer success he sees every support failure at a logistics startup, and he starts a personal log: the issue type, the root cause, the time to resolve, whether the customer renewed. After eighteen months he has about eleven hundred rows of his own observations, containing no customer identifiers.

At 24 the value is mostly optionality: it is the foundation of a service, a job offer at a better company, or an internal proposal that makes him the owner of a workflow rather than its operator.

Worksheet

1. List every information flow you see regularly that most people in your field do not see. Write at least five.
2. Pick one and describe the outcome column: what happened afterwards, and how you would know.
3. Write ten decision rules you use in your work, in the form "when I see X, I check Y, because Z."
4. For each rule, mark whether you can point to a past case where it was right and a case where it was wrong.
5. Count the people you could contact today who would reply within a week. Write the number, and mark which ones have given you permission to write to them.
6. Identify one structural gap you sit in: two groups who need each other and do not talk. Name them.
7. Read your employment or contractor agreement and write down, in one sentence, what it says you own and what it says the company owns.
8. Write your data practice in five lines: what you collect, why, where it is stored, how someone opts out, and how long you keep it.
9. Set a date, within thirty days, to finish the first version of your written process.

Common Mistakes

Waiting for the dataset to be big

People delay because four hundred rows feels unimpressive next to what large models are trained on. That comparison is the wrong one.

You are not competing on volume. You are competing on having the one column nobody else has.

Taking the files instead of the knowledge

Copying a former employer's documents, exports, or customer database is the fastest way to turn an asset into a legal problem, and it is usually unnecessary.

The rules you carry in your head are almost always the valuable part, and in most jurisdictions they are yours in a way the files are not.

Treating contact details as a list

Ten thousand addresses collected without permission are worth less than eighty people who asked to hear from you, and they can carry real penalties under several countries' rules.

Permission is the asset. Collect it explicitly and keep the record.

Leaving knowledge tacit

The most common failure is simply never writing it down. Knowledge that lives only in your head cannot be licensed, taught, embedded in a workflow, or sold, and it retires when you do.

Giving the process away inside a job

An architect who builds a documented process into an employer's systems, with no agreement about ownership, has created an asset for someone else.

That is the subject of Lesson 26, Who Owns the Upside of the Systems You Build, and it is worth settling before you start, not after.

The RW Finance Perspective

Analysts have a name for the thing this lesson builds: an intangible asset that does not appear on the balance sheet.

When you look at a company through the Stock Quality Flower or a Company Page, a high return on capital with modest physical assets is often a sign that the real asset is data, process, or relationships rather than machinery. The question worth asking is whether that advantage is accumulating or decaying.

The test is the same for a company and for you. Does the asset get better with use, and would a well funded competitor need time, rather than money, to replicate it?

Lesson 26 closes Part V by asking the ownership question directly: when you build the system, whose asset is it, and what do the contracts actually say?

Key Takeaways

• The scarce resource is not information but information that exists nowhere else and is tied to outcomes.
• Engine Five is the engine most compatible with keeping a job, because you already sit inside the flows and relationships it depends on.
• A few hundred rows of your own outcome data in a narrow field can be worth more than enormous volumes of public text.
• Tacit knowledge becomes an asset only when it is extracted into written rules, structured into a process, validated against outcomes, and embedded where it earns.
• A written process validated against your own results is the closest thing an individual can own to a trade secret.
• Permission is what turns contact details into a list, and data protection rules vary by country, so confirm your obligations with a professional.
• Build your process from generalized knowledge rather than from an employer's files, and read your contract to learn where the line sits.
• Data and relationship assets rarely earn directly; they raise your price, your win rate, and lower your cost of finding the next client.
• A network position is structural: you sit between two groups who need each other, and value flows through the gap.