Slim ACS-Core: relax MODIFY, system/ping, and wrapped MCP to SHOULD

[bar-capsule]

Summary

Lowers the ACS-Core adoption floor by relaxing three items to conditional requirements within Core, without removing anything from Core or introducing new profiles. The behavior contract that makes ACS distinct (SessionContext + Intent, the hook lifecycle minimum, decision honoring) stays mandatory.

Three changes

Item	Before	After
MODIFY disposition	MUST-support	SHOULD-support. Composition rules (§6.3) still normative for implementers. Deployments that do not implement MODIFY declare so in the handshake; Guardians MUST NOT return MODIFY to such deployments (substitute DENY with audit).
Liveness system/ping	MUST-implement	SHOULD-implement. MAY be omitted by deployments where both parties co-locate or rely on transport-level liveness.
Wrapped MCP protocols/MCP/*	MUST-implement	SHOULD-implement by deployments that govern MCP tool calls. MAY be omitted by deployments that do not use MCP. Support is declared in the handshake.

What stays mandatory in ACS-Core

The seven things that make ACS a meaningful runtime governance contract, not a stateless single-call policy evaluator:

1. Handshake with capability negotiation
2. JSON-RPC 2.0 envelope with required fields (request_id, timestamp, acs_version, metadata)
3. Hook taxonomy minimum: sessionStart/agentTrigger, userMessage, toolCallRequest, toolCallResult, agentResponse, sessionEnd
4. Dispositions ALLOW, DENY, ASK, DEFER (the four needed to express any policy outcome)
5. SessionContext with rolling chain_hash and the Intent invariant (the runtime context that makes governance meaningful, not just per-call yes/no)
6. Replay protection (request_id UUID + timestamp + Guardian replay rejection)
7. Baseline integrity (HMAC-SHA256 over the canonical envelope)
8. Decision-honoring behavior contract (the Observed Agent MUST wait for and apply the verdict; this is what distinguishes ACS from a hook surface a framework can ignore)

Why these three specifically

All three add real deployment friction without being load-bearing for the spec's core property (preventing the agent from acting on injected reasoning):

• MODIFY requires the agent to rewrite its own outbound payload according to Guardian-provided modifications. That's qualitatively different from ALLOW/DENY/ASK/DEFER, which are state-machine outcomes the agent doesn't have to construct. A framework that doesn't implement MODIFY can still ALLOW/DENY/ASK/DEFER cleanly.

• system/ping is useful for managed-Guardian deployments where the agent needs to verify reachability before sending real traffic. Co-located deployments don't need it; transport-level liveness covers the same property.

• Wrapped MCP forces every conformant framework to be MCP-aware, including frameworks whose deployments don't use MCP at all. Declaring MCP support in the handshake is the right cut.

• ACS picks "stateful and meaningful on hooks." SessionContext with a hash-chained audit and an immutable Intent are required in Core; the dispositions you actually implement track the policy outcomes a framework can produce. Compositional risk is governable because the Guardian sees the running session, not just one call. The cost is that ACS-Core is a slightly higher implementation bar than "wire up one hook and return a verdict."

This PR reduces the gap on the implementation-bar axis without giving up the statefulness or the meaningful hook minimum that distinguish ACS.

What this is NOT changing

• Section 6.3 MODIFY composition rules: still normative for implementers
• SessionContext and Intent in Core: explicitly preserved (this is our differentiation from a stateless evaluator)
• The hook taxonomy minimum: 6 hooks remain MUST-implement
• Decision honoring (§6.4): unchanged
• Fail-open default (on_decision_failure: proceed): unchanged

Open questions for working-group review

1. Handshake field for MODIFY-incapable clients. The PR says deployments not implementing MODIFY "declare so in the handshake," but doesn't pin the field name. Suggest a follow-up that adds a dispositions_supported field to ClientHello, parallel to the existing approver_types_supported. Could ride this PR or land separately.

2. FIDES interaction. FIDES-style enforcement uses MODIFY for redaction (modifications.redactions). A FIDES Guardian targeting a MODIFY-incapable client would need to substitute DENY for actions that would otherwise be redaction-rewritten. Worth flagging in the FIDES paradigm-binding docs.

3. Wrapped MCP signalling. The PR says MCP support "is declared in the handshake." Today the handshake's wrapped_protocols field carries this implicitly. Worth making explicit in a follow-up that absence of MCP from wrapped_protocols means the deployment is MCP-incapable.

Test plan

• Existing schemas under specification/v0.1.0/ remain valid (no schema changes in this PR)
• Markdown lint passes on docs/spec/conformance.md
• No internal links broken

🤖 Generated with Claude Code

[bar-capsule]

Update: subagent hooks promoted to mandatory (per Ariel)

Added subagentStart and subagentStop to the mandatory Core hook set in commit 3ec047f.

Net Core after both relaxations and this addition:

What was Core	Status now
Handshake	MUST (unchanged)
JSON-RPC envelope	MUST (unchanged)
Hook taxonomy minimum	MUST, now 8 hooks (sessionStart, userMessage/agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd, subagentStart, subagentStop)
ALLOW / DENY dispositions	MUST (unchanged)
ASK / DEFER dispositions	MUST (unchanged)
MODIFY disposition	SHOULD (relaxed)
SessionContext + chain_hash + Intent	MUST (unchanged)
Replay protection	MUST (unchanged)
HMAC-SHA256 baseline	MUST (unchanged)
Decision honoring	MUST (unchanged)
system/ping liveness	SHOULD (relaxed)
Wrapped MCP	SHOULD when MCP used (relaxed)

Rationale for the subagent promotion (Ariel's reasoning): a sub-agent is itself an Observed Agent operating under delegated authority. Without subagentStart / subagentStop on the Core floor, the Guardian is structurally blind to cross-agent propagation — the confused-deputy attack class. The schemas already exist, the AgBOM models subagent components, the wire shape is identical to other steps. The cost of mandating is marginal; the cost of leaving optional is a gap in runtime governance.

Frameworks without a sub-agent abstraction satisfy this vacuously (the hooks never fire). Same shape as the existing "implement when observable" pattern.

Shape of the slim: dropping the three things that add infrastructure burden (MODIFY composition rules, system/ping plumbing, MCP awareness for non-MCP deployments), adding the two things that close a structural governance gap. The PR's adoption-floor goal still holds — a framework can implement the 8 hooks and the rest of Core in one focused session — and the security floor is materially better.

FAQ updated in parallel (PR #20, commit 27c9d07).

[rocklambros]

Merge-order note (for whoever lands these): this one sets the ACS-Core floor, so it should go in before #20 and #22.

It promotes the subagent hooks to MUST and relaxes MODIFY, system/ping, and wrapped MCP to SHOULD. Two things downstream depend on that:

• Add FAQ to docs/topics #20's FAQ already calls the subagent hooks mandatory (faq.md:124). If the FAQ lands first, main's FAQ and main's conformance.md disagree on whether those hooks are required.
• Add adapters/ with Claude Code, Cursor, and NAT reference implementations #22's adapters mark system/ping and Wrapped MCP as "not implemented." That's only a conformant posture once this PR relaxes them to SHOULD.

No git conflict with either (this only touches conformance.md), so the ordering is about content staying consistent, not about rebasing. Suggested sequence: #21, then #20, then #22. @bar-capsule

[afogel]

this work should actually also bump the patch version @bar-capsule