Product · Approvers, change managers and the engineers who wait on them.
Approvers see the change in plain words, the risk and why, the evidence, the business service it could disrupt and the way back. They approve with a passkey, and the signature covers exactly what they saw.
- The problem
- Approvals live in Slack threads and tickets. Nobody can say which version was approved, and approvers rubber-stamp because the context isn’t there.
- What it does
- Approves routine changes by policy, sends risky ones to the right people with a card that carries everything they need, and binds each passkey approval to the change’s hash.
- The result
- People approve only what deserves their attention, and every approval proves exactly what was approved and by whom.
Allow partial refunds from the merchant dashboard
Asked by A. Patel, with Claude Code · change CHG-2291 · 7d3a9c…41fe
- The change, in plain words
- Merchants can refund part of a payment instead of all of it. Adds a
refund_amountcolumn and one endpoint.14 files · +412 −38 · 1 migration - Risk, and why
- Touches payments code
- Includes a database migration
- Written with an AI agent
- Evidence
- 1,284 tests passed
- No secrets, 0 critical CVEs
- Built in CI, signed
- Verified in staging for 26 h
- Blast radius
- Business service Card payments. Impact tolerance: no more than 2 hours of disruption.Canary 5% → 25% → 100%, halts if errors pass 0.5%
- Backout plan
- One-step rollback to v4.17.3. The migration has a tested down-migration; the 06:00 verified backup is the fallback.
2 approvers, never the requester
- R. Lindqvist (you)
- Waiting
- J. Osei, Risk
- Waiting
- Rollout
- Not started
Your signature will cover change 7d3a9c…41fe and nothing else.
- PathsOnly site copy, no protected paths
- Risk from the diffLow
- Tests and scansPassed on the final commit
- Work itemWEB-412 linked, 2 acceptance criteria
- OverlapNo other open change touches these files
Approved by policy standard-copy-v3
No one was paged. The policy version, its inputs and the result are signed into the change record.
Routine changes, approved by policy
A copy change with passing checks and no protected paths doesn’t page anyone. The record says which policy approved it, and which version.
- Risk is worked out from the diff. Migrations, auth, payments, personal data and workflows raise it, and automation can raise it but never lower it.
- A policy edited to approve more is itself a protected change.
Risky changes, to the right people
Approvers get the card in Slack, Teams, WhatsApp or email. The approval itself is a passkey on Aspian’s page, never a bare chat button.
- Two-person control, and the person who asked can never approve.
- If the change moves after approval, the approval no longer counts.
- Every production change carries a backout plan, linked to the rollback that actually ran.
Emergencies and freezes
At 2 a.m. the fix ships first. Next morning, it can’t close until someone else has reviewed it.
- Emergency changes are time-boxed, need a written reason, and must be approved afterwards within your deadline.
- Freezes protect payroll, year-end or launch day. An override needs its own passkey and a typed reason, and it is recorded.
See what shipped without approval in your last 90 days.
Install the GitHub App and the scan arrives in minutes: every repo scored, every unreviewed merge and unapproved deploy named. Nothing is blocked until you choose.
Ship like a startup. Prove it like a bank.