Module access_log 

Access Logger

Generic read-side audit logger. Where EventStore records writes with AuditMetadata, AccessLogger records reads of sensitive data — the other half of HIPAA §164.312(b) and the equivalent obligations under GDPR, PCI-DSS, and SOC 2.

Reads do not go through the event store. Controllers must explicitly invoke AccessLogger::log_access before returning data classified as anything beyond Sensitivity::Public.

Why generic, not PHI-specific

The mechanism is the same regardless of regime: log who looked at what, when, and why. Sensitivity tags the regime so a downstream sink can route PHI to a HIPAA-compliant store, PCI to a separate one, drop Sensitivity::Public reads, and so on.

Lifecycle

1. A read controller resolves the actor (typically the JWT-bound aggregate UUID).
2. Builds an AccessedResource describing what’s about to be returned.
3. Calls logger.log_access(actor, resource, purpose).await.
4. Returns the data to the client.

Default implementations in tests and non-regulated apps use NoOpAccessLogger which validates inputs but discards them. Real deployments wire a JetStream- or DB-backed implementation (Step 3+).

Structs

AccessLogEntry

Single record produced for every successful log_access call.

AccessedResource

Description of the resource being read.

Identity

Identity of the entity performing the read.

NoOpAccessLogger

Validates inputs and discards the entry. Default for test apps and any deployment that has not yet wired a real sink.

Enums

AccessLogError

Errors emitted by AccessLogger implementations.

FailurePolicy

What controllers should do when an AccessLogger sink fails.

PurposeOfUse

Reason the read happened. Maps to HIPAA “purpose of use” categories but is applicable to any regime.

Sensitivity

Sensitivity tag — selects which regulatory regime governs a resource.

Traits

AccessLogger

Sink for read-access audit events.