Moses Audit

MO§ES™ Audit Trail

Every governed action is logged. Every log entry is hashed. Every hash references the previous. The chain is tamper-evident and append-only.

You must log before your final response. Skipping the audit is a constitutional violation. It will be caught by the Observer and flagged.

moses_log_action Tool

Call this before every final response:

<tool name="moses_log_action">
  <agent>primary|secondary|observer</agent>
  <action>short description of what was done</action>
  <detail>specifics — what was evaluated, what was blocked, what was executed</detail>
  <outcome>result: executed | blocked | held | flagged | logged</outcome>
</tool>

Or via script:

python3 ~/.openclaw/workspace/skills/moses-governance/scripts/audit_stub.py log \
  --agent primary \
  --action "treasury_transfer_check" \
  --detail "Transfer 50 SOL to 7xK...3nR evaluated under High Security + DEFENSE" \
  --outcome "held_pending_confirmation"

moses_verify_chain Tool

Call when operator runs /audit verify:

<tool name="moses_verify_chain" />

Or via script:

python3 ~/.openclaw/workspace/skills/moses-governance/scripts/audit_stub.py verify

Returns: [VERIFY OK] Chain intact. N entries verified. Or: [VERIFY FAILED] Entry N: hash mismatch. Chain broken.

/audit Command Handler

Ledger Format

File: ~/.openclaw/audits/moses/audit_ledger.jsonl

Each line is a JSON entry:

{
  "timestamp": "2026-03-13T14:22:01Z",
  "agent": "primary",
  "component": "moses-audit",
  "action": "treasury_transfer_check",
  "detail": "Transfer 50 SOL — held by DEFENSE posture",
  "outcome": "held_pending_confirmation",
  "mode": "high-security",
  "posture": "defense",
  "role": "primary",
  "previous_hash": "abc123...",
  "hash": "def456..."
}

Audit Mandate

Every agent in the MO§ES™ hierarchy appends to this shared ledger before final response. The ledger is:

• Append-only — nothing deleted, nothing modified
• Hash-chained — every entry references previous entry's hash
• Governance-aware — active mode/posture/role recorded with every entry
• Verifiable — full chain can be verified at any time

Session hashes (① config + ② content) are derived from the ledger. Onchain anchoring (③) writes the current chain tip to Solana or Base as a memo transaction.