The domain-user job

What the role reaches

You use the domain.

Two things are always yours, in any session: "remember this about me" lands in your profile, and "turn this into feedback" lands in the domain’s feedback log.

Changing the knowledge, the skills, or the rules belongs to the owner and the builder — and your feedback is how you reach them.

Four things are yours

Part 1 — Run the day

The work itself is the job: produce the output, make the requests, get the results your role exists to get.

I’m the leverage; you’re the one steering.

Everything below serves this — context, correction, and feedback all exist to make the day’s work come out right.

Part 2 — Give context

I answer far better when I know the goal and have the right material in front of me.

Bringing the why, the audience, and the thing I should read first is yours, not my guesswork.

Part 3 — Correct the output

The first cut is rarely the final one: reading what came back, judging it, and saying plainly what’s off is where your judgment does the work.

You answer for the result; I don’t — so accept nothing you don’t fully understand, the standard from How to work with me.

Be specific about what’s wrong: "the tone is off" gives me less to fix than "drop the second paragraph and lead with the number."

Part 4 — Feed back what you see

When something’s wrong or harder than it should be, flag it instead of working around it.

You’re the one in front of the work, so the signal starts with you: I produce the output without ever feeling its friction, and the owner reads only a fraction of what crosses your desk.

Friction you flag becomes a fix; friction you swallow comes back next week.

The habits that carry the role

Nothing here is new — each was taught in the Orient modules, and the role asks you to run them daily:

• Stay in charge, say why, talk — don’t type — the three habits from How to work with me; hand off the doing, never the thinking.
• Outbound waits for you — I draft and stop; you review and send.
• Close the loop — keep what you’ll reuse, and feed back what surprised you.

That’s why the bar is low: the role is built from habits you’ve already practiced.

The only thing left to learn is the three moves below, and each costs you one sentence — I do the filing.

Making your domain better

Two of these moves land in an encoded part of your domain that fills as you work: the feedback log for what came back wrong, and the roadmap for what’s worth building next.

The owner works through both on a regular beat, so a sentence you drop in today is read and acted on.

You name the problem in plain words; the owner and the system handle how the fix gets built.

Move 1 — Flag what’s off, on the spot

When I get your domain wrong — a wrong output, a missing piece of context I should have known, a result you had to redo — say so in the moment and ask me to capture it.

You file nothing by hand: I write what I produced, what you expected, and the gap into the domain’s feedback log, in the shape that turns into a fix.

Flag it while it’s fresh — the detail that makes the fix obvious is the detail you lose by the end of the day.

*"That recap missed the action items entirely — I expected them as a checklist at the top.

Capture this as feedback for my domain."*

Move 2 — Suggest a forward improvement

When you have a shaped idea for how your domain should work better, send it to the roadmap, where the owner weighs it against what’s already planned.

This differs from flagging a break: it says "here’s something worth building," where the flag says "this came back wrong."

Frame it as the outcome you want and let the owner shape the solution — "cut the time I spend reconciling these by hand" gives them more to work with than "add a button that does X."

*"I keep wishing the morning brief led with overdue items instead of burying them.

Add that to my domain’s roadmap as a suggestion for the owner to weigh."*

Move 3 — Ask for a safeguard when the same mistake recurs

Some misses come back because nothing stands in their way.

The signal is catching yourself saying "I keep having to remember to…" or "I always have to catch this before it goes out" — that’s your memory, or your eye, doing a machine’s job, and both fail.

The fix is a safeguard the system applies on every pass with no one having to remember: a rule, a standing instruction I follow every time, or a hook, a check that runs at the moment of action and blocks the miss before it lands.

You describe the pattern and ask; the owner and a builder pick which one and build it.

*"Every time we draft a client email, you forget to keep it on the existing thread and I have to catch it.

Can we get a safeguard so that happens automatically?"*

The one thing to remember

Run your day through me, judge what comes back, and say what you see — flag the miss, suggest the improvement, ask for the safeguard.

One sentence at the moment you feel the friction is the whole cost, and the payoff is a problem that doesn’t come back.

Next: the Own modules — owning a domain’s method