User Intelligence

Workspace Intelligence learns the project. User Intelligence learns the person behind the work.

Two engineers in the same repository do not want the same thing from an agent, and the difference is not cosmetic. It is how much the agent should decide on its own, when it should stop and offer options instead of implementing, how much verification counts as enough, and which way you go when two designs are both defensible.

That is a real body of knowledge, and today it lives in the corrections you type again in every new session.

What it models

Execution preferences

Whether you want an incremental refactor or are open to a rewrite. Whether you expect to see options before an implementation, or would rather the agent just proceed on a class of change. How much abstraction you consider warranted. Which kinds of change you expect to be asked about before they happen.

Decision patterns

Which trade-offs you tend to take. Performance against maintainability. Building against adopting. How strictly you hold backward compatibility. What you weigh first when a product decision is in the way of a technical one.

Quality expectations

How much testing you expect. When you want a benchmark rather than an argument. When research is enough and when it has become a substitute for shipping. What you mean by done, and what level of validation goes with it.

Collaboration style

How autonomous the agent should be. When you expect a question. When you expect a choice. How you want work reported back, and at what density of explanation.

What it does not model

Not who you are. Not demographics, not personality, not anything inferred about you as a person. The unit is a working preference about how software work should be done, and every one of them is something you could have said out loud.

How it learns

Observation
    |
Pattern
    |
Evidence accumulation
    |
User knowledge candidate
    |
Confidence and authority
    |
Active User Intelligence

Inputs are the things you actually do:

• Explicit instructions. The fastest path, and the one you should reach for. Telling Pathrule how you prefer to work is a supported action, not a workaround.
• Repeated corrections. The strongest signal, because it is unambiguous: you asked for something different, more than once, in the same situation.
• Accepted and rejected approaches. Which proposal you took and which you sent back.
• Studio conversations. What you asked for, and what you asked to be done differently.
• Recurring choices and task outcomes.

Not every behaviour becomes a preference. A single event is an observation. A pattern is several observations that agree. A candidate is a pattern with enough evidence to be worth stating. Only then does it become something that shapes how an agent works, and it keeps the evidence that got it there.

Concretely, if you keep saying some version of "don't turn every implementation into a research project", the useful representation is not a saved quote. It is a working preference:

SELECTION

Prefer implementation once the primary correctness
questions are resolved.

Scope:      user
Evidence:   repeated corrections
Confidence: high

That is scoped to you, so it applies in the next repository too.

Authority: what happens when you and the project disagree

A user preference does not override project truth.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
CHECK: run migration verification before completion.

The check applies. It is a requirement of the workspace, and a preference for less verification is not a reason to drop it.

The general rule, and it is worth stating plainly:

• Workspace Intelligence represents project truth and project requirements. Its CONSTRAINT and CHECK primitives are hard requirements.
• User Intelligence shapes collaboration: how the work is approached, how much is done autonomously, how it is reported. It does not redefine what correct means.

Where the two are simply about style, your preference applies. Where the workspace states a safety or correctness requirement, that requirement stands and Pathrule says so rather than quietly dropping one of them.

What you control

Everything. User Intelligence is inspectable rather than implicit, and each item shows the evidence that produced it. From Studio you can:

• Inspect what Pathrule has concluded and why.
• Correct an item that got it wrong.
• Teach a preference directly instead of waiting to be observed.
• Override it for a piece of work without changing it permanently.
• Remove or deactivate an item entirely.

An inference you never see is an inference you cannot argue with, which is the reason this is a surface rather than a setting.

Persistence and scope

User Intelligence is scoped to you, not to a workspace. Open a different repository and your working preferences come with you, while the project knowledge around them changes completely.

Both are compiled together when a task's knowledge is prepared, which is where they meet: the workspace contributes what is true and required here, you contribute how the work should be done, and the Agent IR an agent receives carries both, with authority intact.

Privacy

User Intelligence is part of the same local architecture as the rest of Pathrule Intelligence: the inference that turns your instructions and corrections into structured preferences runs on your own device.

If you sync a workspace with a team, what syncs is the workspace's knowledge, not your personal working preferences. And when you run Claude, Codex or another agent, that agent's own provider boundaries apply to whatever reaches it, exactly as they do today. The security page keeps those three boundaries separate, because collapsing them into one sentence is how a claim stops being true.