Back to HALMAI™
WhitepaperControls
Runtime Enforcement Layer

Runtime Governance Framework

HALMAI operates above agent frameworks and execution targets as the runtime enforcement layer — a structured model for evaluating governance maturity for autonomous agent actions, from passive monitoring to deterministic enforcement

Control Plane vs Execution Plane

Control Plane

Policy definition, rule management, and authorization decisions for autonomous actions — regardless of which agent framework generates the proposal. Operates on metadata and action proposals without executing side effects.

  • Policy rule storage and versioning
  • Authorization computation
  • Decision logging

Execution Plane

Financial side-effect execution with valid authorization tokens. The boundary where transaction proposals become real-world fund movements.

  • Token validation
  • Exactly-once execution
  • Effect propagation

Deterministic vs Stochastic Layers

Stochastic Layer

LLM inference, reasoning, proposal generation. Probabilistic outputs.

Deterministic Layer

Transaction authorization, policy evaluation, execution. Deterministic outcomes.

The enforcement kernel ensures that stochastic proposals pass through deterministic authorization before funds move or financial systems are affected. This is the fiduciary safety boundary — distinct from cybersecurity, which protects credentials and perimeters but not transaction intent.

Governance Maturity Levels

A progression from reactive monitoring to proactive, machine-verified transaction governance.

0

Level 0: Monitoring Only

Observability without enforcement. Transaction anomalies detected after occurrence. No prevention capability.

Capabilities

  • Log aggregation
  • Anomaly detection
  • Alerting

Limitations

  • No prevention
  • Post-hoc analysis
  • Unbounded exposure
1

Level 1: Manual Approvals

Human review required for sensitive financial actions. Bottleneck at scale. Inconsistent enforcement.

Capabilities

  • Human review gates
  • Approval workflows
  • Basic audit trails

Limitations

  • Does not scale
  • Inconsistent decisions
  • Latency overhead
2

Level 2: Policy Enforcement

Rules evaluated automatically. Transactions blocked based on policy. Audit logging enabled.

Capabilities

  • Automated policy evaluation
  • Block/allow decisions
  • Structured audit logs

Limitations

  • Policy-execution gap
  • No replay verification
  • Mutable logs
3

Level 3: Deterministic Execution Boundary

HALM

Zero-bypass enforcement gate. Hash-linked decisions. Exactly-once execution semantics.

Capabilities

  • Secure executor
  • Tamper-evident ledger
  • Execution tokens
  • Budget gates

Limitations

  • Manual invariant verification
  • Periodic audits
4

Level 4: Continuous Invariant Verification

HALM

Kernel invariants verified continuously. Public integrity endpoints. Machine-provable guarantees. Planned: structured evidence export for underwriter and institutional workflows.

Capabilities

  • 6 kernel invariants
  • Public transparency
  • Deterministic replay
  • Strict mode lockdown

HALMAI™ operates at Level 3–4: Deterministic Transactional Integrity.A framework-agnostic runtime enforcement kernel with continuous invariant verification — purpose-built for safety in autonomous agent actions, starting with fiduciary enforcement for agentic financial transactions.

Incident Lifecycle

1

Detection

Transaction invariant violation or anomaly identified

2

Classification

Severity and type determined

3

Response

Transaction lockdown or escalation triggered

4

Investigation

Root cause analysis with replay

5

Resolution

Fix applied, lockdown released

Read the WhitepaperView Control Mapping