Durable audit trail — persist PHI access, append-only

Featurekamo-shared-library
Shipped
August 3, 2026 at 3:04 PM UTC
Author
Kamo
Commit
c25bef6

Turns §164.312(b) from a log line into evidence. The capture layer has been wired across seven services for a while, but it wrote through Slf4jPhiAccessLogWriter — 14-day retention against a six-year obligation, and unqueryable. The control was architecturally present and evidentially useless. PhiAccessLog is append-only: @PreUpdate and @PreRemove refuse mutation, because an audit trail the application can edit is not evidence. The database half (REVOKE UPDATE/DELETE) is in the KamoInitializer migration. It carries identifiers and never content, and a test asserts the entity has no content-shaped field. A trail that reproduces what it audits has simply relocated the PHI into a second store — one that by design is never deleted. JpaPhiAccessLogWriter is deliberately NOT annotated as a bean. Every service component-scans com.kamo, so a stereotype would make all ~40 construct it, and since it needs a repository each would then have to add this package to its own explicit @EnableJpaRepositories list or fail to start. That exact mistake took every login on the platform down earlier today. A service that wants durable audit declares the bean and adds the scan; the rest keep the Slf4j default unaffected. SharedLibBeanSafetyTest enforces this. Fields are truncated rather than allowed to throw. On a fail-closed access kind an exception here refuses the user's read, so a pathological URL or 4KB user-agent losing the row would also deny legitimate access — the audit layer must never be the thing that breaks the product. Table already exists in the cluster (KamoInitializer fb89b3d), so nothing is armed.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing