One violation, from detect to audit.
A production bucket with a public-read grant. The detector trips, and the system produces six artifacts in order. No human writes any of them. No human reviews the ones that don't touch production.
Asset
s3://acme-prod-customer-exports (AWS us-east-1)
Framework tags
CIS 1.20 · SOC 2 CC6.6 · ISO 27001 A.9.4.1
A continuous scan against the library lands on AllUsers: READ for a bucket tagged env=prod. The detector matches CIS 1.20, tags the record with its SOC 2 and ISO 27001 siblings, and hands it to the remediation chain without a pause.
Ticket
A change record opens with the violation pattern, the asset, the framework tags, the severity level, and the owner inferred from the account tagging map. No free-form prose anywhere on it. Every field maps to a column the auditor already asks for on their spreadsheet.
violation: CIS 1.20 public-read bucket asset: s3://acme-prod-customer-exports framework: SOC 2 CC6.6 · ISO 27001 A.9.4.1 severity: high owner: platform-security@acme.com detected: 2026-04-15 03:12:47 UTC
Approval
Production-touching actions wait on the approver's phone until somebody reads them. One tap runs the plan. One tap denies it and closes the ticket as a won't-fix with the stated reason on the record. Nothing ever happens in the middle of those two states.
CHG-2026-0418-114 action: remove public-read grant asset: acme-prod-customer-exports scheduled: pending approval expires: 2026-04-15 04:12 UTC [ Approve ] [ Deny ]
Backup
Before anything writes, the current state gets snapshotted against the change ID. The snapshot is what the rollback step reads from if the fix has to be reversed later. It lives in a separate bucket with its own 30-day retention policy.
grants captured: 3 bucket-owner: FULL_CONTROL AllUsers: READ log-delivery: WRITE stored at: s3://acme-rollback-vault/ retention: 30 days
Fix
The remediation command is reproducible byte-for-byte against a given input. It runs, then verifies the new state matches the shape the plan predicted. If the verification read doesn't match, the chain halts immediately and the rollback from step three runs on its own.
aws s3api put-bucket-acl \
--bucket acme-prod-customer-exports \
--acl private
verify: acl returns 1 grant
(bucket-owner, FULL_CONTROL)
status: appliedRollback
The reverse of the fix is computed from the backup and stored alongside the ticket in the same vault. Anyone with the change ID can revert the action for the next 30 days. After that window, the rollback bundle expires and the change is considered settled for the audit.
aws s3api put-bucket-acl \ --bucket acme-prod-customer-exports \ --access-control-policy \ file://acl-snapshot-CHG-2026-0418-114.json bound to: CHG-2026-0418-114 TTL: 30 days
Alert
A close-out record posts to the audit channel and the compliance log. The shape is identical on every run. The auditor exports the channel at the end of the quarter and reads it like a ledger, not a chat log from a stressed engineer.
CHG-2026-0418-114 closed CIS 1.20 remediated on acme-prod-customer-exports approver: nina.ramirez (tap, 03:14:02 UTC) duration: 01m 15s (detect → close) rollback: available until 2026-05-15
The full chain. One violation. The library handles the rest the same way.
The library covers a growing set of violation patterns across SOC 2, CIS, HIPAA, PCI-DSS, GDPR, and ISO 27001. Every one of them runs through this chain, in this order, with this structure. The shape of the output is what makes it auditable in the first place.