A PASS Is Not Execution Authority

Tomohiro Iida · Published September 30, 2026 · Updated September 30, 2026

Before a multi-agent coding workflow starts, someone has already written down which roles exist, what each role may write, where each task type is routed, and which role does the review. Agent Role Contracts takes those declarations as input and checks them offline for conflicts, without executing anything. As of September 30, 2026, the checker and the package that ships it are both public: the GitHub v0.1.0 tag and the npm registry package have each passed unauthenticated readback and a fresh installation.

Running the starter

The v0.1.0 starter bundle declares two roles. The implementer may write within a declared scope. The reviewer is read-only and declared under a different role ID from the implementer. The single starter task is routed to the implementer. The public package.json requires Node.js 22.5 or newer and declares no runtime dependencies or install scripts, and the README states that the starter needs no API key and no network. Earlier drafts of this page could only show repository-local commands, because the npm package was not yet published. On September 30, 2026, we installed the package from the public registry into a clean directory and ran the same starter bundle from inside the installed package; the results matched the GitHub checkout exactly.

npm install @netsujo/agent-role-contracts@0.1.0

npx agent-role-contracts validate --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json

npx agent-role-contracts explain --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json --task node_modules/@netsujo/agent-role-contracts/examples/starter-task.json --format text

npx agent-role-contracts explain --bundle node_modules/@netsujo/agent-role-contracts/examples/starter-bundle.json --task node_modules/@netsujo/agent-role-contracts/examples/starter-task-outside-scope.json --format text

The validate command answered with valid: true. The explain command printed a line stating PASS for the explain operation, noting in parenthesis that this covers declarations only and execution is not authorized. Both commands exited 0. In JSON output, seven result fields make that disclaimer explicit, and every one of them reports false: execution authorized, runtime enforcement, identity verified, evidence verified, source files checked, sensitive data scanned, and output schema validated.

A second starter task exists to fail: it requests a write scope that lies outside anything the implementer is allowed to write. Running explain against that task returned FAIL with the rule code TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY and exit code 1, matching what the public release’s own test suite expects.

The rules behind a PASS

The rule codes implemented in public v0.1.0 at commit c987c44… fall into the areas below. Read the table as that exact release’s inventory; future versions may change it.

The public v0.1.0 release was accepted only after deterministic tests, package and fresh-install smoke tests, the declared hosted platform matrix, and an independent exact-candidate review. Individual rule codes should not be read as claims beyond the documented check.

Each command checks a different set

The three CLI commands take different inputs, and each can apply only the rules its inputs allow. validate takes a bundle and an optional output format; it applies bundle-level rules such as role and route integrity, authority contradictions, reviewer declarations, relation cycles, and knowledge references, but has no task document, so task-dependent checks are not exercised. explain adds one task and therefore also runs the task routing and write-scope checks. handoff takes a bundle, a task, and a handoff document; it is the only command that validates a supplied handoff document, and the only one that can emit a HANDOFF code.

A starter explain PASS therefore carries no information about handoffs. explain has no way to read a handoff document, and supplying one to it ends in a CLI error with exit code 2. The starter ships no handoff fixture either; the public release’s handoff example uses a larger bundle that declares coordinator, implementer, and reviewer roles. On September 30, 2026, running the handoff command against that bundle, its task, and a supplied handoff document printed a PASS for the handoff operation and exited 0. A workflow that moves work between roles through handoff documents has to send each document through the handoff command specifically; the explain result covers only the bundle and the task.

npx agent-role-contracts handoff --bundle node_modules/@netsujo/agent-role-contracts/examples/team.json --task node_modules/@netsujo/agent-role-contracts/examples/task.json --handoff node_modules/@netsujo/agent-role-contracts/examples/handoff.json --format text

Write scope and human-only roles

The write-scope rule is skipped unless the task’s routed executor has its authority mode set to write-scoped or operator. For such an executor, the task’s scope input must hold exactly one portable relative scope: path segments built from letters, digits, dots, underscores, and hyphens, each beginning with a letter or digit, with no dot-only segment, and optionally ending in a wildcard suffix. Any other value is invalid. A well-formed scope that no entry in the executor’s allowed write scopes contains is treated as outside authority. “Contains” is a plain string comparison between two declarations: the requested scope either equals a declared scope or starts under a declared scope that ends in the wildcard suffix. The checker touches no filesystem path, expands no glob, and grants nothing.

A human-only role represents zero machine authority: its declaration carries empty lists for both capabilities and allowed write scopes. Such a role marks the point where a person decides or approves, and it holds no authority to change anything by machine. Filling either list on a human-only role produces an authority contradiction.

Outside the PASS

• Whether the planned work is right, safe, or something the model can actually do.
• Whether the reviewer named in the bundle acted independently when the review took place.
• Whether any identity or piece of evidence is authentic.
• Whether source files were read or secrets looked for.
• Whether runtime permissions were enforced, or whether anything may be merged, deployed, or changed in production.
• Whether the checker itself has gaps or bugs.

According to the CLI help, no command executes agents, evidence commands, or network requests, and none writes files. Knowledge URIs stay unfetched, and evidence command strings are handled as inert data. One candidate test loads the core source into an in-memory VM with fetch trapped, runs validate, explain, and handoff, and asserts that application I/O is zero.

Two more limits come from how this candidate is built. Schema validation is bundled and covers a closed subset of JSON Schema Draft-07 keywords; a schema using any keyword outside that subset fails loudly. The runtime-specific check knows a small, finite list of configuration keys plus some Claude- and Codex-specific path forms. When none of them appears, the check passes, and that pass is all it means: the declaration has not become runtime-neutral, and nothing has been scanned for security issues, secrets, malware, or prompt-safety problems.

Exit codes and refusals

• A task whose type had no explicit route was refused as unrouted, with exit 1; the checker does not pick a default executor.
• The public self-review fixture was refused for a declared self-review and a reviewer that was not read-only, with exit 1.
• A task carrying an unknown field failed schema validation, with exit 1.
• A task path pointing at no file returned a CLI error, with exit 2.
• explain given a handoff document it cannot use returned a CLI error, with exit 2.

In a pipeline, let only exit 0 through to the next step. On exit 1, send the declarations back to whoever wrote them. On exit 2, look at the command line and the input files; that code carries no verdict on the contract. One objection is that runtime permissions and code review already exist, so checking declarations adds little. What the check adds is timing and a clean split between outcomes: it catches a plan that contradicts itself, such as a role reviewing its own work or a write scope outside granted authority, before any agent, provider, or filesystem action, and exit codes 1 and 2 keep “the contract is wrong” apart from “the check never ran.” It enforces nothing by itself; unless the workflow refuses to start execution without exit 0, running the check changes nothing.

Existing pages that own the neighboring questions

Netsujo has already published pages on the concepts around this check, and the checker introduces no new terms alongside them.

Netsujo Agent OS（日本語）Nor is the checker Netsujo Agent OS, the internal operating platform behind Netsujo’s own AI-agent development work. According to the candidate README, the package “is not a runtime sandbox, execution controller or a replacement for an existing company Agent OS,” and imports no company configuration. For v0.1, the release plan draws the boundary at shipping the current declaration checker only: agent startup and provider calls, runtime or OS permission enforcement, identity and evidence authentication, merge or deploy authority, runtime adapters, a console, and billing are all left out.

Release status

The source-rights gate is closed for the selected v0.1.0 scope, and Netsujo authorized MIT publication. A fresh public history was created rather than exposing the private preparation repository. The exact public release candidate is commit c987c44f4e187a8ec4c8173142dfe1806f8b5125, tree 54d40645161944190e37a3ffc26a110fade580fe, tagged v0.1.0.

That exact candidate passed 198 of 198 deterministic tests. Pack, fresh install, root API, schema import, normal CLI, and intentional fail-closed smoke all passed in sequence. The hosted matrix succeeded on Ubuntu with Node 22.5, Ubuntu with Node 24, macOS with Node 22, and Windows with Node 22. A separate independent review named the exact public HEAD and tree and returned zero P0, P1, and P2 findings, with an approve and safe-to-release verdict. The GitHub boundary is public: unauthenticated readback succeeds for the repository, the MIT license, and the v0.1.0 tag-bound schema.

On September 30, 2026, the npm boundary closed too. We fetched @netsujo/agent-role-contracts@0.1.0 from the registry and confirmed that the distributed tarball’s SHA-256 matches the SHA-256 of the GitHub release asset. Installing the package into a clean environment and running validate, explain, and handoff each returned the same results as running the same commands from the repository checkout.

With that gap closed, the behavior this page describes can be reproduced by installing the package, not only by reading the GitHub source.

Separate the Role from the RuntimeThe Task Contract this checker’s task schema is a narrow subset of.

A repeated instruction is a system bugThe Controller, Evidence Ledger, and post-execution Scope Gate that sit after this checker.