“Write like me” sounds harmless until the system fills in the rest without evidence.

It may get a cadence right. It may return a sentence that sounds confident. It may even spot a verbal habit I recognize immediately. And still invent the part that matters most: background, position, limit, responsibility.

That is why I do not treat authorship as makeup applied to a text at the end. Before asking for tone, I need to know what is fact, what is a confirmed position, what is still a hypothesis, and what the system has no authorization to infer.

TL;DR

I use harness for the environment of contracts, memory, tools, and validations that supports the operation. In it, AUTHOR.md is a convention for gathering verifiable author context. It is not a public biography, a style guide, a magic prompt, or permission for AI to complete gaps about a person. A useful file records confirmed facts, positions, criteria, limits, sources, and a rule not to infer. Its value is not in the filename: it is in the curation, evidence, integration, and maintenance that prevent a fluent response from becoming an invented version of its author.

The problem is not a lack of style. It is too much invention

I have already written about how writing with AI did not make me less of an author. The point remains the same: authorship is not the number of keys pressed. It is direction, choice, refusal, and responsibility for what was said.

But there is a risk before the finished text.

When someone asks a system to “write like me,” they are often asking for something small and expecting something enormous. They want to adjust tone but receive an improvised personality. They want to avoid generic sentences but get a biography with details they never confirmed. They want consistency but receive a well-written caricature.

I prefer another question:

What, exactly, does this system have evidence to say it knows about me?

I asked something close to that when I turned old context into verifiable hypotheses in “ChatGPT Already Knows a Lot About You”. What looks like knowledge must be shown, confirmed, limited, or refused before it gains an operational role.

What I call an AUTHOR.md file

AUTHOR.md is a convention in my harness: a reference file that keeps verifiable author context close to work that needs to respect it.

It is not a universal standard. Another system may use another name, another format, or need no file at all. I use this name because it makes the question explicit: which author material was confirmed, what is it for, and which gaps remain gaps?

In practice, this kind of reference can gather simple categories:

Category	What it can contain	What it does not authorize
Confirmed facts	background, professional scope, or stated preferences with clear origin	inventing episodes to “humanize” a text
Confirmed positions	theses, decision criteria, exceptions, and counterexamples confirmed by the author	treating a preference as eternal dogma or a hypothesis as conviction
Limits	topics, data, or conclusions that require a question first	filling silence with a convenient assumption
Sources	where an assertion can be checked	turning a reference into a truth greater than it supports
Do not infer	fields the system must leave open	diagnosing, guessing intent, or building a plausible biography

Notice what this list does not promise: it does not turn a person into a closed set of parameters. It only makes part of the context more legible and contestable.

Four things it is not

A public biography introduces a person to readers. It can be excellent for an About page. It is not, by itself, safe instruction for a system to operate. Biography involves selection, narrative, and often simplification. Working context needs to say what was confirmed, what is relevant, and what must not be extrapolated.

A style guide helps keep a piece recognizable: vocabulary, sentence length, tone, examples of what works and what does not. In my harness, STYLE.md is another convention: it looks after how the voice organizes thought, rhythm, humor, intensity, and linguistic choices. It answers “what does this sound like?” It does not answer by itself “what does this person defend?”, “what did they experience?”, or “what needs to be asked before making a claim?”.

The two files fail differently when isolated. AUTHOR.md without STYLE.md may produce correct facts in a generic voice. STYLE.md without AUTHOR.md may produce a convincing imitation that invents biography or position. Their combination does not make either file a universal standard or remove the need for review; it only separates responsibilities that are commonly mixed together.

A system prompt is an instruction that guides one execution. It can use author context, but it does not replace its curation. Instruction without source becomes an elegant order with little support.

And memory is recoverable continuity from a conversation or operation. It can carry useful clues; it should not receive, without review, the power to define who someone is. Mixing memory with identity is an efficient way to turn repetition into portraiture.

There is a third responsibility I use as a convention in my harness: Character. It does not rewrite biography or invent a personality; it is an operational and contextual stance used to counterbalance patterns and blind spots. That is the subject of “I Turned My Blind Spots into Contracts for My AI Agents”. AUTHOR.md answers for what may be attributed to me and its provenance; STYLE.md for how the voice expresses itself; Character for when a pattern calls for a counterweight rather than confirmation.

These differences matter because a harness is not merely a larger text box. It is an environment that needs to know where each piece of information belongs, what it permits, and where it stops.

A deliberately small — and fictional — example

I will not publish my real file or turn an article into a reverse-engineering manual for my operation. The principle is more useful than the display case.

A fictional start could look like this:

# AUTHOR.md — fictional example

## Confirmed facts
- Works with software and automation for many years.
- Prefers technical claims to include a source when they are verifiable.

## Confirmed positions
- Efficiency does not justify skipping review.
- A pleasant answer is not worth more than a verifiable one.

## Limits
- Do not invent experiences, clients, numbers, or diagnoses.
- Ask before turning a hypothesis into the author's position.

This is not a complete schema. It should not be copied as a recipe for instant authority. It is only a slice that shows the difference between writing “imitate my style” and declaring what exists, what is confirmed, and what needs to remain open.

A short, honest file is better than an encyclopedia of self-image with no origin.

The file does not grant permission to invent

There is a predictable temptation here: to think that, after recording a few facts, AI can connect the dots by itself.

It cannot.

It can propose a connection. It can say two decisions appear coherent. It can ask whether a preference applies in another context. But it should not turn “appears” into “is” just because the sentence reads better that way.

That limit connects directly to “A Hypothesis Does Not Become Fact Because AI Repeated It”. Author context also needs to survive a question: where did this come from, what is the evidence, who confirmed it, and when does it stop applying?

If there is no answer, the right output is not to complete the story. It is to leave the space marked and return the question to the author.

That reduces one of the most dangerous forms of algorithmic flattery. The operational hypothesis here — not direct proof of an internal mechanism — is that context and conversation patterns can favor a pleasant, apparently deep version of you, especially when that kind of answer tends to receive positive feedback.

A starting prompt that does not begin with self-fiction

If you want to test this principle in your own system, start small. A prompt organizes a task; it does not replace human confirmation of identity and background.

Help me create an initial AUTHOR.md file for this project.

Do not invent biography, experience, preference, position, diagnosis, or style.
Separate every item as: confirmed fact, confirmed position,
limit, source, or open question.

Treat attributable facts and positions as AUTHOR.md context; treat rhythm,
humor, and expressive choices as STYLE.md context. Do not use either one to
fill gaps in the other.

For every suggestion, show the available evidence and say when it is not enough.
If I do not confirm a hypothesis, keep it out of the file.

Produce a short, reviewable version. Before proposing use of this context in
other texts or decisions, say which passages are relevant and which limits
still apply.

The first result does not need to impress anyone. It needs to be reviewable without confusing assumption with a résumé.

The value is in the work that continues after the file

Saving an AUTHOR.md does not solve authorship. At most, it creates a better surface to care for it.

Value appears when content is curated, an assertion has an origin, an exception is not erased, and the system can say: “I do not have enough basis to speak for you.”

That is why I do not sell the idea of a miraculous file. What makes a difference is the combination of context, criteria, review, and maintenance throughout the operation.

At i-9.ai, this is the kind of care that matters: not placing AI on top of unresolved context to make it sound smart, but building systems that make clear what they know, what they do not know, and who still needs to decide.

A recognizable voice is not born when the machine learns to praise its author.

It is born when the machine receives enough context not to need to invent it.

Keep reading

• Writing with AI did not make me less of an author
• ChatGPT Already Knows a Lot About You. Before You Trust It, Make It Prove It
• AI forgot exactly what I had already decided
• A Hypothesis Does Not Become Fact Because AI Repeated It

Go deeper

• Biography: an encyclopedic starting point for distinguishing public narrative from verifiable operational context.
• Prompt engineering: context on writing instructions; it is not the author-curation method described here.
• Markdown: the plain-text format used in the example to record reviewable context.

References and limits of use

• OpenAI, “Prompt engineering”: supports only that structured instructions guide AI-system execution and should be treated as part of interaction design. It does not define AUTHOR.md, create verifiable author identity, or replace human review.

The cover is a synthetic editorial scene: Felipe appears beside translucent sheets representing facts, voice, sources, and boundaries being organized before they guide the system.