build.allanninal.dev

Part 5 of 7 · Compliance tracker series ~5 min read

How evidence gets captured

A reminder lands in Maria’s Slack DM at 8:03am. The monthly fire-safety walk-through is due today. There’s a Done button. What happens when she taps it? The honest answer is “it depends on what she actually did.” This post walks through the three things the tracker can do on a reminder — mark done, attach evidence, snooze — and how the task list, the cycle state, and the audit trail all stay in sync.

Key takeaways

  • Three actions per reminder: done (stamp the date, compute the next due date), attach evidence (a note or file as proof), snooze (delay).
  • Each action updates the task list via the Sheets API and writes an audit row.
  • Marking done archives the old cycle to a separate sheet for history.
  • Snooze is bounded — you can only snooze a few times before the tracker escalates anyway.
  • The Done button is a Slack interactive message backed by a Function URL.

Three actions on Done

Three actions on the Done button A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three action paths. Far left: a "Reminder in Slack DM" box showing a typical reminder message — task name, due date, what proof to keep, link to the row — with three Slack-button placeholders below: Done, Attach, Snooze. The owner taps one button. The middle column shows the three branches. Branch one, Done: a one-tap action that stamps today's date as the last-done date, computes the next due date from the repeat rule, archives the old cycle's reminder history to a separate sheet, clears the cycle state in the ct-reminders DynamoDB table, and writes a done event to the audit trail. Branch two, Attach evidence: opens a small Slack modal with a note field and a file upload; on save, a Function URL Lambda stores the file in S3 under the task's evidence prefix, runs Textract plus Bedrock Haiku 4.5 to pull a short summary of what the proof shows, links it on the task row, and records the task done in the same step. Branch three, Snooze: opens a smaller Slack modal asking how many days to snooze (default 3); on save, the Function URL Lambda writes a snooze row to the ct-done table that suppresses reminders for that task until the snooze ends. The cycle itself isn't changed. Snooze can only be applied a limited number of times per cycle (default three) before the next tick ignores it and reminds anyway. The right side shows the convergence: every action writes a row to the ct-audit DynamoDB table with timestamp, task id, action, by-user, and notes. A note at the bottom: Done stamps the proof and rolls the cycle forward — the next due date is computed and the task goes quiet until then. Reminder in Slack task, due, proof, link [Done] [Attach] [Snooze] Action 1 Done • Stamp today as last-done • Compute next due date • Sheets API updates row • Old cycle archived Action 2 Attach evidence • Modal: note + file upload • File stored in S3, summarized, linked on row • Records the task done Action 3 Snooze • Modal: snooze N days (default 3) • ct-done row suppresses reminders until it ends Audit trail DynamoDB ct-audit timestamp · task_id action · by-user notes Done stamps the proof and rolls the cycle forward — the next due date is computed and the task goes quiet.
Fig 5. Three actions per reminder, three different effects. Done stamps the date and computes the next due date. Attach evidence keeps the proof. Snooze delays without dismissing. Every action writes to the audit trail.

Action 1: done (the most common)

Maria did the walk-through and signed the checklist. She taps Done. That’s a one-tap action — no modal — for the common case where the proof is the fact that a trusted owner says they did it. The button submits to a Function URL Lambda, and three things happen, in order. First, the Sheets API updates the row in the task list: last_done set to today, and a small note in the done_by column with the user who acted. Second, the existing cycle’s rows in ct-reminders are copied to ct-reminders-archive with a cycle id, and the live cycle state is cleared. Third, a action: done row is written to ct-audit with the user, timestamp, the cycle that was due, and the computed next due date.

Tomorrow’s tick reads the task list, sees the last-done date is recent and the next due date is a month out, and lands at on-track. The owner won’t hear from the tracker about this task again until the next cycle’s first window crosses.

Action 2: attach evidence (when proof has to be on file)

Some controls aren’t done until there’s a record of them. The insurer wants a photo of the signed fire-safety sheet. The auditor wants the access-review export. The board wants the signed-off policy. For those, “trust me, I did it” isn’t enough — the proof is the point.

Attach evidence opens a small Slack modal with a note field and a file upload. Maria types a one-line note and drops in the photo. On save, a Function URL Lambda stores the file in S3 under that task’s evidence prefix (s3://ct-evidence/<task_id>/<cycle>/), runs Textract and a short Bedrock Haiku 4.5 call to pull a one-line summary of what the proof shows (“signed fire-safety checklist, all items ticked, dated June 1”), links the file on the task row, and records the task done in the same step. The summary is a convenience for the monthly board view — the file itself is the real evidence, kept versioned in S3 for years.

This is the one owner-facing place Bedrock touches in the whole system, and even here it’s optional: if the model is unavailable, the file is still stored and the task is still recorded done — you just don’t get the auto-summary that day. The proof never depends on the model.

Action 3: snooze (the deferral)

Some checks slip for reasons the reminder chain doesn’t plan for. The contractor who runs the equipment inspection is out this week. The data review is stuck behind a holiday. The only person who can sign the policy is travelling. Maria isn’t ready to mark it done, but she’s also handling it — she just needs the tracker to be quiet for a couple of days.

Snooze opens a small modal asking for the number of days, with a 3-day default and a max of 7. On save, a row is written to ct-done with (task_id, snooze_until). The next day’s tick reads that row in the “already done this cycle?” check from Part 3 and treats the task as on-track until the snooze ends. When the snooze ends, the tracker re-evaluates the cycle from where it was — if the task is now past its due date, the next reminder is an overdue one or an escalation.

Snooze is bounded. The rules doc has a configurable max_snoozes_per_cycle setting (default three). After that many snoozes on the same cycle, further snooze attempts are rejected with a “You’ve hit the snooze cap on this task; please mark it done or escalate” reply, and the next tick reminds normally regardless. This is a soft constraint that exists because the most dangerous failure mode is repeatedly snoozing a control to nowhere.

Every action is logged, every action is reversible

The ct-audit table records every done, attach, and snooze with the user who took the action, the timestamp, and a snapshot of the row before and after. If a wrong done date gets entered, a manager can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row. The undo is itself an audit row, so the trail of edits stays clean.

This kind of reversibility matters most for the controls you’ll only think about once a quarter or once a year. The next time the annual policy sign-off comes up, it might be Maria again or it might be the person who took her job after she got promoted. Either way, the audit trail — and the evidence files in S3 — are the only memory the next person has.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why it’s one of the cheapest systems in the series.

All posts