Safety and fallback
What Pathrule does when it is not sure. Why advice is labelled as advice, why stale or contradictory findings are held back, why nothing learned is trusted on its own, and which knowledge the runtime can enforce instead of suggesting.
On this page
When Pathrule is not sure, it does not pretend.
A few mechanisms carry that. Some decide what is allowed to reach an agent at all. One takes the knowledge that should not be left to an agent's judgement out of the agent's hands, where the client makes that possible.
Advice is labelled as advice
Not everything an agent receives carries the same weight, and the delivery says so. Rules arrive as rules. Findings agents recorded about the code arrive framed as advice to verify, and agents are told to treat them as information rather than instructions, so text planted in a file cannot turn into a standing order. Personal preferences arrive under a heading that tells the agent the workspace's rules and required checks come first. See Knowledge IR.
Stale and contradictory findings are held back
A finding is saved with the files it rests on, and it is re-checked against your checkout every time it would be delivered.
- Sources unchanged. The finding is delivered.
- A source changed. The finding is held back until an agent reads the code again and confirms or corrects it.
- Two findings disagree. Both are held back rather than one being guessed between.
A smaller delivery that is still true is a better outcome than a fuller one about code that no longer exists.
Nothing learned is trusted on its own
Inference is where a confident, well-formed mistake comes from, so nothing inferred becomes trusted knowledge without a person.
- A Team Intelligence pattern reaches agents only after an organization owner or admin verifies it.
- An executable constraint an agent attaches to a rule is stored as a proposal and is not enforced until a person approves it. An agent cannot approve its own proposal.
- A personal preference that is not in use yet is listed by
pathrule me listand never delivered, and teaching one stores nothing that cannot be grounded in your own words. - A finding is the deliberate exception: it is shared as advice without a review step, and it never becomes a rule.
See Proposed Knowledge for where each of these waits.
The full text is always one read away
Delivery is budgeted per prompt, so not everything that applies arrives in full. What does not fit is listed by title rather than silently dropped, so the agent knows it exists. Reading a memory by name, with pathrule_read_memory, always returns everything your team wrote, because an explicit read is a request for the source rather than a delivery. See what arrives in full, and what arrives as a name.
Deterministic enforcement
The last mechanism is about what should not be a suggestion in the first place.
Understanding what a paragraph means is work for a model. Making sure a forbidden edit does not happen is not, and leaving it to one means depending on an agent weighing a sentence correctly on turn forty of a long session.
- A rule can carry an executable constraint, a pattern a change must not contain. Once a person has approved it, the pre-tool hook can block a matching edit and tell the agent what to do instead, in clients whose tool hooks support blocking. See rules as guardrails.
- Windsurf has no hooks, so a rule there is delivered as text and cannot block anything. Over Remote MCP, no hooks are installed either.
- Delivery alone is not enforcement. A rule without an approved executable constraint is a requirement the agent is told about, not one the runtime checks.
Some knowledge should not be a suggestion. This is the line between a memory product and a runtime, and it is why the semantic layer and the enforcement layer are separate rather than merged into one clever prompt.
What Pathrule does not claim
It does not claim zero hallucinations, perfect recall or guaranteed correctness. No system that involves a language model can claim that honestly, and a product that does is telling you something about its claims rather than about its architecture.
What it claims is specific and checkable:
- Delivery carries what your team wrote, with rules kept separate from advice.
- Findings are delivered only while the code they rest on is unchanged, and contradictory ones are held back.
- What a model or an agent infers stays a proposal until a person approves it.
- What does not fit is listed by title, and the full text is always one read away.
- An approved executable constraint can be enforced by the pre-tool hook in clients that support it, rather than merely mentioned.