Implementation profile: validate external-verdict RFC against Microsoft AGT / ACS

[Knapp-Kevin]

Purpose

This is a conformance / implementation follow-up to #219, not a second interoperability architecture and not a request for DashClaw to depend on Microsoft AGT.

The external-verdict RFC is intentionally vendor-neutral. A useful way to prove that boundary is real is to wire a second, independently designed governance runtime against it and demonstrate that DashClaw does not need provider-specific policy semantics in its core.

Microsoft's Agent Control Specification (ACS) is a good comparator because its current draft runtime separates policy evaluation from the host that acts on the resulting verdict. ACS currently normalizes allow, warn, deny, escalate, and transform; DashClaw's proposed v1 contract deliberately accepts only the first four semantic outcomes and excludes transforms.

Architecture

Keep the language and ownership boundary explicit:

DashClaw guard / approval / evidence
  existing TypeScript / JavaScript architecture
                |
                | #219 external-verdict wire contract
                v
         provider adapter
                |
                v
        AGT / ACS runtime

The DashClaw application should not acquire a Python, Rust, or AGT runtime dependency merely because a provider happens to use that language internally. Cross-language interoperability belongs at the versioned provider boundary.

This should strengthen the existing repository architecture, not create a multi-language policy subsystem inside app/.

Proposed conformance mapping

For a DashClaw guard evaluation, the adapter should construct the ACS host snapshot from the same minimized act/context already covered by #219, invoke a configured ACS pre_tool_call policy evaluation, and map:

ACS allow     -> DashClaw external allow
ACS warn      -> DashClaw external warn
ACS escalate  -> DashClaw external escalate -> require_approval
ACS deny      -> DashClaw external deny -> block

Then DashClaw performs the existing monotonic stricter-wins join from #219.

transform handling

transform is intentionally outside DashClaw's external-verdict v1 contract. The adapter must not silently apply, discard, or reinterpret a transform as an allow.

For the first conformance slice, either:

1. use an ACS manifest/workload whose relevant intervention point cannot produce transform; or
2. treat an emitted transform as an unsupported provider result and enter DashClaw's configured provider-unavailability/failure posture.

Adding transform semantics to DashClaw would require a separate design decision and is not part of this issue.

Invariants

• No AGT-specific vocabulary in DashClaw's canonical guard result.
• No new DashClaw policy language.
• No AGT/Python/Rust runtime embedded in the DashClaw server solely for this integration.
• Provider allow can never loosen a stricter local result.
• Provider deny remains absolute for the evaluated act.
• The returned input_identity must bind the exact DashClaw act being evaluated.
• Provider id, ACS/spec/policy version, reason, latency, and posture remain reconstructable in decision evidence.
• Decision evidence remains distinct from approval evidence and execution witness evidence.
• Timeout, malformed response, identity mismatch, unsupported verdict, and provider failure remain explicit rather than masquerading as successful external governance.
• Existing enforcement-honesty language remains unchanged: an external verdict is not proof of enforcement.

Adversarial / compatibility cases

At minimum:

1. local allow + ACS deny -> block;
2. local block + ACS allow -> block;
3. local allow + ACS escalate -> require_approval;
4. local require_approval + ACS allow -> require_approval;
5. input-identity mismatch -> provider failure posture, never reuse;
6. ACS runtime failure / fail-closed deny remains conservative;
7. timeout / unavailable provider is visibly unavailable;
8. unsupported transform cannot become an implicit allow;
9. provider evidence cannot be mistaken for an execution witness;
10. behavior remains identical when no external provider is configured.

Repository fit

DashClaw-side implementation should follow the existing Node/TypeScript conventions, full verification gates, surface-budget discipline, and HUMAN-EXPERIENCE.md requirements. Configuration and posture should reuse the generic #219 surfaces rather than add AGT-specific UI.

Sequencing

This should remain subordinate to #219. The generic provider seam should land first or be implemented in the same bounded workstream; this issue exists to prove the abstraction against a second real governance runtime, not to widen the v1 contract.

I'm happy to write the repo-native decision record / ADR-equivalent and implementation spec, implement the DashClaw-side conformance work, build the provider adapter/reference harness, add the tests, and follow the contribution through the repository's normal verification process if the maintainer wants this comparator.

[ucsandman]

Sequencing confirmed: this stays subordinate to #219. The demand gate there is now satisfied (Agent Memory is the committed first provider), so this becomes the second conformance target once the seam is live against a real workload.

Two things from this issue are adopted into the build plan now rather than later:

• Your adversarial list is the test matrix for the generic seam itself, not an ACS extra. All ten cases ship as mock-provider tests with the DashClaw-side implementation, before any real provider connects. The RFC records this.
• Transform handling exactly as you wrote it: an emitted transform is an unsupported provider result and takes the configured unavailability posture. It can never be silently applied, discarded into an allow, or reinterpreted. If transform semantics ever earn a place, that's a separate design decision with its own RFC.

No other action here until the Agent Memory integration proves the seam.