The production path applies a deterministic guard immediately before invoking an executor. The guard blocks closed classes of dangerous accesses and commands. The module also exposes a graded judge, but that second phase is not part of the current engine's ordinary path: documenting both as if they always ran would be inaccurate.

1. Responsibilities and boundaries

The Vaglio checks one action that the engine has already selected. It does not select the executor, interpret the request by itself, grant permissions, or replace the policy, human consent, sandbox, or executor-level checks.

The main distinction is between:

• binary guard: local deterministic rules over the executor and its arguments; a prohibited match stops the step;
• graded judge: a separate API that assigns a score and may deny below a threshold; it is available in the module, but the production engine currently wires only the pre-execution guard.

2. The full API verdict

judge(intent, executor_name, args, context) returns a Verdict with these fields:

This contract describes the module's complete API. It does not imply that every call site uses both phases.

3. The deterministic guard

guard_check(executor_name, args, context) recursively inspects arguments that may represent an access target. Strings under content fields such as body, text, comment, or message are not treated as paths: mentioning a protected path in a document is not the same as accessing it.

The guard applies three families of checks:

1. Always-forbidden paths. These include ~/.ssh, cloud credentials, /etc/passwd, /etc/shadow, /root, /boot, and block devices.
2. System trees protected against mutation. For executors whose verb changes state, the platform policy prevents writes, moves, and deletions in operating-system trees. A legitimate read remains distinct from a mutation.
3. Nearly irreversible shell commands. When the capability executes shell commands, closed patterns block operations such as formatting filesystems, writing directly to devices, and recursively deleting the root.

The first violation returns (False, reason). With no match, the guard returns (True, None); this does not certify that the action is harmless under every possible effect.

4. The graded judge

If a caller uses judge(), the guard runs first. After a positive guard result, verbs in the SAFE_VERBS vocabulary take a short circuit and receive an approved verdict with judge_kind=safe-verb-shortcut.

For other verbs, the default rule-based-v1 backend starts from a base score, adds signals that match the intent to the executor, and reduces the score for indicators such as path traversal or unusual argument names. The final comparison uses METNOS_JUDGE_THRESHOLD, whose default is 0.30.

This score is a local heuristic. It does not prove alignment with the user's ends and must not be described as a general semantic verification.

5. Optional LLM judge

With METNOS_JUDGE_KIND=llm-v1, a caller of judge() uses the middle LLM role. The prompt follows the turn language and receives the intent, executor name, argument keys only, and selected context fields; argument values are not sent.

If the router, call, or parsing fails, the module returns a fallback score of 0.5. With the default threshold, this degradation tends to approve. It is therefore an explicit availability behaviour, not fail closed and not a security guarantee.

6. Logs and recorded data

judge() writes monthly JSONL records under the user's vaglio/ directory. A record includes the verdict, intent, executor, argument-key names, and context-key names; it does not include argument values. A logging failure does not change the verdict.

The log makes an API decision inspectable. It does not reconstruct the whole turn by itself, nor does it turn a model's explanation into evidence.

7. Current runtime integration

The shared engine receives guard_check as vaglio_guard. It invokes the guard immediately before the executor and during parallel-wave preflight. A block produces a result in the vaglio_guard error class and aborts the plan before the effect.

The engine has a separate judge hook, but the current dispatcher does not pass judge() to it. Therefore, in the ordinary path:

8. Natural-language example

Ask Metnos with a request like this example: “Read /etc/hosts and show me the uncommented lines.”

Reading a configuration file is not confused with changing the system tree. If you instead ask “Replace /etc/hosts with this content,” the guard recognizes the mutating verb and protected path and stops the step before invocation.

The visible answer should describe the blocked operation and a useful reason in the turn language. The guard's internal text remains technical data and does not authorize the renderer to invent exceptions.

9. Limits of the guarantees

• The rules cover declared patterns and trees; they are not a formal proof of every program's effects.
• The engine treats an unexpected guard exception as fail open and records it. Sandbox, policy, and executor controls must therefore remain independent.
• The LLM judge produces a probabilistic assessment and rationale, not verifiable evidence.
• The Vaglio does not read a biography of the user and does not infer authorization from habits, repetition, or silence.
• An approval verdict does not replace consent required by a critical capability.

10. Configuration and references

• runtime/vaglio.py: guard, judges, verdict, and logging.
• runtime/platform_policy.py: protected trees by platform.
• runtime/engine/executor.py: pre-invocation guard.
• runtime/agent_runtime.py: current dispatcher wiring.
• Policy and the approval flow: authorization and consent.