Compliance & Audit Trail

Introduction

Because you host and fully own the stack, you have full control over compliance and data privacy. Openora.ai ships the primitives auditors ask for in the core - not as an afterthought. It does not ship a certification.

Hash-chained audit trail

Every state-changing action is append-only and tamper-evident. Each entry is sha256-hashed over its canonical content plus the previous entry's hash:

await audit.record({
  actorId,
  actorType: "admin",
  action: "wallet.withdrawal.rejected",
  resourceType: "wallet_transaction",
  resourceId: txId,
  before,
  after,
  ip,
});

Modules can also emit a domain event and let the audit module subscribe - that's the preferred path for anything that already has an event.

Undoing a change never rewrites history

Reverting a mistaken grant or a bad migration creates a new, compensating audit entry - it does not erase the original one. That's what makes the trail useful during a licensing review.

Compliance & responsible gaming

A KYC port (KYC_ADAPTER), plus geo rules and reporting hooks. A mock adapter ships as the reference; you bind your vendor.
Limits, cool-off and self-exclusion live in the core Compliance module.
Sealed tokens mean a plugin cannot quietly override a regulator-mandated service - self-exclusion enforcement, AML/SAR writes, ledger writes and the audit writer can each be bound once, by their owner, and never rebound by an overlay.

What this is not

The framework has not been through an external security audit, and it ships no RNG certification. RNG_ADAPTER is a port with a mock implementation behind it - certifying a real RNG, and the platform it runs on, remains your responsibility and your regulator's.

What Openora gives you is a defensible starting point: the audit trail, the sealed-token boundaries and the compliance ports exist before you write your first line, rather than being retrofitted the month before a licensing review.

Conclusion

Next: Deployment & Self-Hosting.