Pathrule
Intelligence

Workspace Intelligence

Workspace Intelligence is the layer that learns how one project works. Its scope, sources, authority over agent behaviour, and the lifecycle a piece of project knowledge goes through.


Workspace Intelligence is the answer to one question: how does this project work?

Not what the files contain. An agent can read those, and it reads them well. What it cannot read is the working knowledge a repository accumulates around its code, which is exactly the knowledge that decides whether a change is right or merely plausible.

What it models

  • Architecture decisions, and the reasoning that produced them.
  • Hidden constraints that are not visible anywhere in the code.
  • Verification requirements: what has to be checked before something counts as done.
  • Previous fixes: what actually worked the last time this specific problem appeared.
  • Conventions a team follows without writing down.
  • Procedures: the ordered way a recurring job is done here.
  • Contextual facts that change the right approach, such as a database being a read-only replica.
  • Technical rationale, which is what stops an agent from helpfully undoing a deliberate decision.
  • Preferred implementations among several that would all work.
  • Superseded decisions, so an old one stops being delivered as current.
  • Precedence relationships between two pieces of knowledge that both apply.
  • Recurring failure patterns, derived from how the work actually went.

Scope

Workspace Intelligence is scoped to a repository, and inside it to paths.

This is the mechanism that stops a knowledge layer from becoming the problem it was meant to solve. Everything true about a monorepo is not relevant to a change in one package, and delivering all of it makes the three sentences that matter compete with two hundred that do not. Knowledge attaches to the path it governs, and a task in that path receives what governs it.

Path scoping is also why a workspace can keep growing without each turn getting heavier. See how retrieval works.

Authority

Workspace Intelligence is the layer that can hold hard requirements.

Two of the knowledge primitives are requirements rather than advice:

  • A CONSTRAINT states what must not happen. It is the only primitive that can deny an alternative outright.
  • A CHECK states a verification that must happen before the work is finished.

These are properties of the project. They are not dropped because a personal preference would be more convenient, and User Intelligence cannot override them. Everything else Workspace Intelligence holds is advisory and carries its authority band with it, so a remedy is never delivered as if it outranked a constraint.

Sources

Two kinds, and it matters which is which.

Authored. Memories, rules and skills a person wrote on purpose. These are the ones a team can point at and argue about, and they are the backbone.

Evidence from real work. What agent sessions reported about themselves: which knowledge was delivered, which was actually consulted, how the turn went, which files moved together, where an agent kept getting stuck. See what Pathrule computes.

What is not a source: reading your repository. Pathrule does not index your source, scan your files or upload your code. Derived knowledge is built from authored entries plus what the work reported, never from the contents of the repo.

Lifecycle

  1. Proposed. Either a person writes it, or an agent that discovered something worth keeping proposes it with the evidence behind it.
  2. Approved. Nothing enters the workspace's knowledge without a person accepting it. This is what keeps upkeep near zero and keeps the layer trustworthy.
  3. Compiled. The local model turns it into typed, grounded knowledge. See compilation.
  4. Delivered. The part relevant to a task is compiled into an Agent IR and reaches the agent before its first tool call.
  5. Measured. Delivery and outcome are recorded, so the entry's standing reflects what happened rather than who wrote it.
  6. Superseded or retired. A decision that a later one replaced stops being delivered as current, and stale knowledge is flagged with a concrete proposed edit that a person approves. See suggestions and self-audit.

What changes when you switch projects

All of it. Workspace Intelligence belongs to the repository, and opening a different one means a different body of project knowledge, shared with whoever else works in it.

What does not change is User Intelligence, which belongs to you.