[Mayur021]

Implements #6.

Adds a reversibility class so an Execution Receipt records not only what happened but whether the action was safe to run unattended. Three constraints from the discussion on #6:

1. The tool declares its reversibility class at design time (Section 2.1); the securing runtime copies it into the receipt so the agent cannot assert its own class at runtime.
2. An unclassified tool defaults to irreversible, so the runtime fails closed.
3. The Merkle ledger governs a call chain by the worst-case class across linked receipts, so multi-step escalation cannot bypass the gate.

Vocabulary is the OWASP AISVS v1.0 reversibility classification (C9.2.3). The same field is proposed on the AEL evidence-record spec (pipelab-org/agent-evidence-levels#1). Section 4.3 adds conformance + two test vectors.

[cyberfascinate]

The three constraints address the threat model cleanly. Copying the design-time class at the proxy prevents self-assertion. The fail-closed default blocks unclassified escalation, and the worst-case chain rule covers the multi-step bypass.

Using the OWASP AISVS C9.2.3 vocabulary keeps the taxonomy standard.

Two points to resolve before merge:

1. Section 4.3 test vectors: Should we add a vector for the fail-closed fallback? Explicitly testing that an unclassified tool defaults to irreversible will help implementers validate their proxies.

2. Schema enforcement: Section 2.1 says tools "MUST" declare reversibility, but Section 4.1 defines fallback behavior if they do not. Should we make this field required in the schema directly, or keep it optional and rely on the runtime default? Making it required at build-time prevents runtime surprises.

[Mayur021]

Thanks for the review. Both are good catches and I have pushed edits for both.

Fail-closed test vector: agreed, and I would treat it as the primary one, since the unclassified path only fires on the manifest author's mistake and that is the case implementers are most likely to miss. Section 4.3 now includes a third vector: an invoked tool that declared no reversibility class, where the runtime MUST record action.reversibility as irreversible, and a receipt that records a softer class or omits the field MUST be rejected.

Schema-required vs runtime-default: I kept both, because they guard different layers. Making the field required in the tool schema is the right call and Section 2.1 now states it that way, so a manifest that omits it is nonconformant and fails at build time. But the runtime fail-closed default in 4.1 has to stay, because a security control cannot assume the schema validator ran. Tools can reach the runtime by paths that skip build-time validation: dynamic or federated registration, a tool delegated in from a parent agent, or a manifest written against an earlier schema version. In each of those the proxy still has to produce a safe class, and irreversible is the only safe default. So 2.1 is the conformance gate and 4.1 is the safety gate; requiring the field is additive to the default, not a replacement. I added a sentence in 2.1 making that two-layer relationship explicit so it no longer reads as a contradiction.

[cyberfascinate]

The dual-gate approach (build-time schema constraint and runtime proxy fallback) is solid. It handles bypass vectors like federated delegation cleanly while forcing explicit declarations at build time. The third test vector covers the fallback validation requirement. Merging the PR now.