The question behind it
A coding agent can say it ran the tests without having run them. It can also produce a check that looks convincing but says little about the change. Synrail asks what evidence should be required before that work is accepted.
The local tool ties a task to a patch and its verification. When the evidence is missing, stale, or inconsistent, it returns a reason and a bounded next step.
Keeping acceptance separate
Recording a claim and accepting it are separate operations. A claim about runtime behavior needs a verification command to run and produce a fresh receipt. A changed workspace can make earlier evidence insufficient.
The false-green demo makes this small enough to inspect: a failing unit test sits beside plausible-looking evidence. The work only reaches an accepted state after real verification.
What I’m working on now
The newer protected-admission experiment looks at the pull-request boundary. It observes changes to paths that can affect how work is checked or admitted, including tests, workflows, policy, permissions, and deployment configuration.
It currently runs in shadow mode. It is a path-based observation, not a semantic security scan, and it does not make merge decisions. The experiment needs evidence from real use before stronger enforcement makes sense.
Where the boundary is
Synrail complements tests and code review. Its local receipts do not establish a security boundary against an agent with the same machine access as the operator. These limits are part of the documentation and the work still ahead.