Two things about the v1 scope section, one procedural and one internal.
The success picture is missing
How a Project Comes to Life lists what needs to be true at merge, including:
A v1.0 success picture. What would prove the idea.
The v1 scope section is a feature list (daemon, four layers, three profiles, hash chained log, Rust, macOS and Linux binary). It says what will be built, not what would prove it worked. For a security project the difference matters, because a gateway that blocks everything and a gateway that blocks nothing both ship the same feature list.
Three numbers would make this reviewable, and they are also the numbers that decide whether the project succeeded a year later:
- An attack corpus. N documented scenarios (indirect injection leading to exfiltration, secret path reads, egress to a pastebin, chained tool escalation) that must all be blocked, with zero bypass, and the corpus published in the repo so anyone can rerun it.
- An interruption budget. Review prompts per hour on a real session under the balanced profile. This is the number that decides whether users reach for
allow: "*", which the document already names as the project's main risk.
- An overhead budget. p95 added latency per mediated call, and the file heavy case specifically, since that is where an interposition approach hurts most.
The section also settles two open questions
v1 scope says:
Local daemon operating at the process boundary.
Written in Rust for minimal overhead and memory safety.
Open questions says:
Implementation Language: ... The current proposal leans toward Rust.
Mediation Placement: Should Agentveil be an in-process SDK or an out-of-process daemon?
A reader cannot tell which of these is a proposal and which is a decision. "Leans toward Rust" and "Written in Rust" are different claims, and the daemon case is sharper still: v1 scope states it flatly while the open question presents it as undecided.
What would help: add the success picture to v1 scope, and either soften the two scope bullets to "proposed" or close the corresponding open questions with the reasoning recorded. Other whitepapers in the collective use a "Resolved in review" section for exactly this.
Raised during the public review window (closes 2026-09-19).
Two things about the v1 scope section, one procedural and one internal.
The success picture is missing
How a Project Comes to Life lists what needs to be true at merge, including:
The v1 scope section is a feature list (daemon, four layers, three profiles, hash chained log, Rust, macOS and Linux binary). It says what will be built, not what would prove it worked. For a security project the difference matters, because a gateway that blocks everything and a gateway that blocks nothing both ship the same feature list.
Three numbers would make this reviewable, and they are also the numbers that decide whether the project succeeded a year later:
allow: "*", which the document already names as the project's main risk.The section also settles two open questions
v1 scope says:
Open questions says:
A reader cannot tell which of these is a proposal and which is a decision. "Leans toward Rust" and "Written in Rust" are different claims, and the daemon case is sharper still: v1 scope states it flatly while the open question presents it as undecided.
What would help: add the success picture to v1 scope, and either soften the two scope bullets to "proposed" or close the corresponding open questions with the reasoning recorded. Other whitepapers in the collective use a "Resolved in review" section for exactly this.
Raised during the public review window (closes 2026-09-19).