How your corrections make me better

A one-time miss — correct it where you see it

When the answer in front of you is wrong, say so plainly, in the chat, the moment you notice.

State what’s off — don’t ask me whether it’s right.

*"No — they’re the CEO, not the CFO.

Fix it."*

I fix it in the artifact right then: the draft, the recap, the brief in front of you is corrected on the spot.

That fix lives in this one artifact, though — it does not carry to the next one I write.

If the same thing is wrong again tomorrow, you correct it again, until you tell me it is a pattern.

When the miss is a preference about you — how you like your briefs, which pipeline you read first — it belongs in your profile, the saved record of you the system loads at the start of every session.

"Remember this about me: I read the New Jersey numbers first."

Once it is in your profile, every future session starts already knowing it, so you say it once and never again.

Those are the two destinations for a one-time miss: the artifact gets the fix, your profile gets the preference.

A recurring miss — turn it into feedback

When something fails the same way every time — every recap drops who owns each action — the fix belongs in the method itself, not in one artifact.

Describe the pattern: which output, what it gets wrong every time.

"Turn this into feedback."

I write it to the domain’s feedback log — a FEEDBACK.md file kept at the domain’s root, like this curriculum’s own feedback log.

The log is the inbox the domain owner drains: every signal sits there with its diagnosis until the owner works through it.

The owner reads each one, decides what holds up, and folds the fix into the domain’s knowledge and skills.

Not every signal becomes a change — the owner can edit it, fold it in, or close it as already handled, and either way your correction is recorded.

Folded into the method, the fix reaches everyone who works in that domain — your conversations and your team’s both — without anyone repeating the correction.

What you noticed once becomes what the domain does on every answer after.

That is the difference between the two paths: a one-time fix helps the artifact in front of you, a fed-back fix changes what every future answer starts from.

Who can change what — the role ladder

Three roles, and the ladder tells you which fixes you can make yourself and which you reach through feedback.

• End user — you use the system; you can always say "remember this about me" (lands in your profile) and "turn this into feedback" (lands in the domain’s feedback log); you cannot change knowledge, skills, or rules — feedback is how you reach the people who can.

• Domain owner — you change your domain’s knowledge and skills right then and there, and you are accountable for both, plus every artifact the domain’s agent carries; for deeper machinery you write it on the roadmap for the builder.

• Builder — the full anatomy: rules, hooks, commands, connectors, the wiring.

Each rung up the ladder changes more of the system and answers for more of it.

A domain owner who needs a new rule or connector does not build it — they put it on the roadmap, and the builder picks it up, the same way you hand a recurring miss up to the owner.

Whatever your role, feedback is exactly how you reach above it: the log is read by the people who hold the levers you don’t.

So even as an end user you are never stuck — a recurring miss you cannot fix yourself becomes a signal to the owner who can.

What makes a correction land

Tell me three things: what was wrong, what you expected, and what you got.

"It was bad" gives me nothing to change.

"The recap left out who owns each item — I expected an owner on every line, and there were none" gives me exactly what to fix.

Say it the moment you see it, while it’s still accurate.

The strongest signals become standing rules

A clear should-always or a flat never-do can be promoted past the log into a standing rule — encoded into the system, so the whole workspace follows it on every action without anyone repeating it.

"This one should always hold — flag it as a candidate rule for the whole workspace."

The owner promotes it; from then on the rule fires on every action, in every session, for everyone — a step beyond a fed-back fix, which lives inside one domain.

You spot the candidate; the people above you on the ladder decide it earns a rule.

When the teaching is bigger than a correction

A whole body of method — how your domain handles renewals, an entire reference set — is a job for the Knowledge Builder, a domain expert agent I bring in to turn what you know into structured, sourced knowledge your agent reads from then on.

"Bring in the Knowledge Builder — let’s turn how we handle renewals into proper knowledge for the domain."

Check what it captured the way you’d check any first draft.

The one thing to remember

Correct a one-time miss where you see it — I fix the artifact or your profile on the spot — and say "turn this into feedback" for the misses that recur, because the feedback log is how your correction reaches past your role and into the method everyone uses.

Next: the Run modules — running your domain day to day