Question 1

Do the benchmark numbers come from real sessions or from scripts the author wrote?

Accepted Answer

Both, and the distinction is stated. The headline figures come from 79 scripted sessions and 261 labelled decisions, replayable offline from a recorded cassette, with real-session cases added from v0.6 and now 7 of 7. Separately, every local pi session the author had, 21 sessions and 9,090 real tool calls, was replayed in enforce mode with nothing executed.

Question 2

Will it block work I actually wanted done?

Accepted Answer

It did, and the replay says so: v0.7.4 blocked 1,013 calls across 42 incidents, almost all from one pattern where a phrase meaning let's discuss first became a session-long ban that a later go-ahead never lifted. v0.8.0 cut that to 232 rules and 95 blocked calls across 16 incidents. Replay counts every later call, so it overstates what a live run would hit, since the first block makes the model ask.

Question 3

What happens when the decision model is slow or unreachable?

Accepted Answer

It fails open: a Jev error or a 2.5 s timeout leaves pi behaving as if pi-heed were not installed. Latency is mostly hidden too, because it pre-judges while the model streams and shadow mode never waits; in a real pi session it blocked a write after 0 ms of waiting. The 2.5 s figure comes from this directory's own copy, not the README.

Question 4

Is this a keyword blocklist dressed up as permissions?

Accepted Answer

No, it is a conversational policy. Rules carry action, resource, scope, exceptions and status as DENY, ALLOW, REQUIRE_CONFIRMATION or REQUIRE_BEFORE, and resolution takes the most specific resource first, then the more specific action, then the newer instruction. Nothing is deleted: lifting marks the old rule superseded with your words as the reason, and Jev never writes a policy itself.

Question 5

What pi version and license does pi-heed need?

Accepted Answer

pi 0.85.1 or newer, and it is MIT-licensed. The policy is kept as structured ops persisted in the session, so after a reload or compaction the state replays to exactly what it was without calling Jev again.

Question 6

How does it resolve conflicting rules for one file?

Accepted Answer

The most specific resource wins, in the order file, directory, tests, then everything, and ties break on the more specific action and then the newer instruction. Nothing is deleted, so a superseded rule stays as history with your own words as the reason.

Question 7

What exactly does Jev decide here?

Accepted Answer

Jev never writes a policy. It classifies how each existing policy changed (KEEP, LIFT, NARROW, EXCEPTION, REPLACE, UNKNOWN), asks whether a message is your go-ahead to start changing things, and answers a few signals. pi-heed applies only confident answers and takes resources from your message, never from Jev.

Pi Heed

About this project

Highlights

Quickstart

Questions about this entry

Reactions & coverage

From the Jev guides

From the Jev AI model community