Add web4-governance plugin for AI governance with R6 workflow

[dp-web4]

Web4 Governance Plugin for Claude Code
Lightweight AI governance with T3 trust tensors, entity witnessing, and R6 audit trails.

Note: "web4" = trust-native internet infrastructure for the AI agent era (cryptographic provenance, verifiable
accountability). Generic descriptor, not a trademark claim.

R6 = Rules + Role + Request + Reference + Resource → Result (structured audit record format)

Features
-Entity Trust - T3/V3 tensors (6D each) for MCP servers, agents, references
-Witnessing - Bidirectional trust flow through observation
-R6 Workflow - Formal intent→action→result with hash-linked provenance
-Rust Backend - (auto Python fallback)
-Trust Decay - Unused entities decay toward neutral over time

Components
governance/ - Trust tensors, witnessing, R6 ledger, session management
hooks/ - session_start, pre/post_tool_use, heartbeat
web4-trust-core/ - Rust crate with PyO3 + WASM bindings

Test Plan
Entity trust + witnessing (12 tests passing)
Rust backend verification + Python fallback
Real session integration
See README.md for full documentation.

[dp-web4]

Comment for PR #20448

Clarification: Scope, Foundations, and Positioning

Thanks to everyone reviewing this PR. Based on feedback from external reviewers, I wanted to clarify a few points about what this plugin is (and isn't), and where it fits in the broader landscape.

What This Is

The core contribution isn't any single element (audit logs, policy gates, trust metrics), but the combination of:

1. Pre-action gating (not just after-the-fact logging)
2. Hash-linked provenance (tamper-evident audit chain)
3. Structured intent capture (R6 workflow formalism)

...implemented as a developer-portable, hook-based plugin rather than a platform-locked or enterprise-only system.

What This Isn't

To be explicit about scope:

• This doesn't make agents "safe" or "correct" — only inspectable, accountable, and governable
• T3 trust tensors are operational heuristics for permissioning, not epistemic confidence or alignment signals
• Completeness is bounded by the host's hook surface — we can only govern what the hooks expose

We're building governance infrastructure, not claiming to solve alignment.

Foundational Research

This plugin implements concepts from the Web4 trust-native architecture. For deeper context on trust tensors, entity witnessing, coherence metrics, and the broader theoretical framework, see:

Web4 Whitepaper: https://dp-web4.github.io/web4/

The whitepaper covers:

• Linked Context Tokens (LCT) — unforgeable entity identity
• T3/V3 Trust and Value Tensors — multi-dimensional trust mechanics
• R6 Workflow Formalism — structured intent capture
• Markov Relevancy Horizons (MRH) — context boundaries
• ATP/ADP Economics — attention allocation

How This Fits the Big Picture

Web4 Architecture provides the theoretical foundation — trust-native societies for humans and AI.

Governance Tiers define implementation depth:

Tier	Name	Capabilities
1	Observational	R6 audit, hash chain, soft LCT
1.5	Policy	Rules, presets, rate limiting ← This PR
2	Authorization	Full T3/ATP, hardware LCT
3	Training	Meta-cognitive, developmental

Runtime Implementations demonstrate portability:

Runtime	Implementation
Claude Code	This plugin (hooks/) ← This PR
Moltbot	extensions/web4-governance/
Hardbound	Full Rust implementation (Tier 2)

Competitive Context

For reviewers familiar with the space:

Alternative	Comparison
Jackson et al. (policy engines)	Strong theory, less developer-portable
AWS Bedrock AgentCore	Similar gates, but AWS-native, not intent-aware
Enterprise audit tooling	Good logs, weak agent semantics

Our lane: lightweight, open, agent-native, intent-aware.

Summary

This is missing infrastructure, not speculative architecture. Happy to address specific questions or concerns.

---

Related: A parallel implementation exists for Moltbot using the same R6 framework, demonstrating portability across runtimes.