[mjatin2007]

What changed

Validates parsed, correlated Guardian decision responses against the canonical response-envelope.json schema and its method-specific AcsResult branch before the host adapter accepts them. A canonical-schema or method-result violation is audited and denied even under on_decision_failure: proceed; inability to run the local validator remains a host-side failure and follows the negotiated posture.

This follows the accepted issue's fail-closed direction, but under proceed it deliberately differs from the literal current §6.4 treatment of a malformed response. Validation covers the complete canonical response envelope, not only deny.reasoning. This draft should not be treated as conformant until §6.4 is clarified, and it should not merge ahead of that clarification unless maintainers direct otherwise. Response-signature verification is separate and remains pending in #229.

Which issue does this implement

Part of #182

• This is an editorial correction (typo, grammar, link, formatting) with no change in
  meaning, so it needs no issue

Base branch

• integration, because this touches the specification, schemas, a reference
  implementation, an adapter, tests, or CI
• main, because every changed path is on the documentation lane allowlist in
  CONTRIBUTING.md

Type of change

• Specification change (schema, hooks, events, AgBOM)
• Reference implementation or adapter
• Documentation
• Tooling or CI
• Governance (licensing, security policy, contributor docs)

I tested this

• I synced my branch with the base branch before opening this
• uv run pytest -v passes on my machine
• uv run mkdocs build --strict passes on my machine

The AGT validation also passes on the repository's pinned Bun 1.3.11: TypeScript succeeds, and the complete Bun suite reports 1,123 passed, 1 skipped, 0 failed across 68 files.

Checklist

• Commits are signed off with git commit -s (required by the DCO)
• Prose follows STYLE.md
• No secrets, tokens, or internal URLs in the diff

Security

• This change has no security impact

Security impact: schema-invalid or method-invalid Guardian responses are blocked and audited. Local validator unavailability remains posture-governed and is attributed to the host rather than the Guardian.

[mjatin2007]

Hi @shivang-sec and @President, may I check how you’d prefer to sequence this? Section 6.4 on integration still treats a malformed response as a decision failure governed by on_decision_failure, while this draft intentionally denies a parsed schema-invalid response under either posture. Would you prefer that I open a Discussion and propose the specification clarification first, or keep this draft open for implementation review in parallel? I’m happy to follow either route.

[shivang-sec]

Thanks for checking, @mjatin2007 . I’d lean toward opening a Discussion for the Section 6.4 clarification first, while keeping this draft open for implementation review in parallel. That should let us resolve the intended behavior for parseable but schema-invalid Guardian responses before merging a change that deliberately differs from the current wording.

I agree with keeping protocol violations distinct from technical failures, with the exact fail-closed behavior and its relationship to on_decision_failure made explicit in the spec. For #182, I think validating the incoming Guardian response against the canonical response-envelope.json schema at the host/client boundary is the right approach, rather than duplicating field checks in validateDecision().

I’ll defer to @President on the preferred sequencing before we treat the behavior as settled.