Skip to content
Experience

Juristic · Engineering case study

Approval evidence you can audit

Redesigned how a peer-review module ties evidence to each approval step.

My role
Owned the correction and redesign end to end
Team
Full-stack Developer in a seven-developer product team
Technologies
TypeScript · React · Redux · WebSockets · AdonisJS · Node.js · SQL

Approval evidence model

  1. Step 1

    Approved

    Reviewer 1

    Evidence for this step

  2. Step 2

    Approved

    Reviewer 2

    Evidence v1 · superseded, kept in history

    Evidence for this step (v2)

    Mandate scoped to this step

  3. Step 3

    Approved

    Final approver

    Evidence for this step

ExportStep 1/Step 2/Step 3/
After: each step has its own evidence, send-backs supersede without deleting, and mandates apply only where granted.

01The problem

What was wrong, and why it mattered.

A four-eyes review module lets organisations upload work, route it through an ordered chain of reviewers, record approvals or send-backs, approve on someone’s behalf through mandates, and export the full evidence trail. Evidence belonged to the whole review instead of the exact step, so it could satisfy unrelated approvals. Mandates carried across steps, send-backs left old evidence active, and proxy rules were not strict enough.

My responsibility

I took ownership of the problem from diagnosis to production: redesigning the evidence model, correcting the approval rules and delivering the change across frontend, services and data.

02Constraints

What the solution had to respect.

  • Reviews already in flight must keep working
  • Every approval stays auditable, including superseded evidence
  • Authorization never trusts identifiers sent by the client
  • Ten product locales
  • A licensed module that customers rely on

03Technical approach

What I built.

  1. 01Introduced step-scoped approval evidence
  2. 02Corrected mandate and proxy-approval rules
  3. 03Prevented evidence from one step satisfying another
  4. 04Expired superseded evidence after a send-back, kept as history
  5. 05Re-derived authorization server-side
  6. 06Corrected inconsistent document-version handling
  7. 07Reorganised exported evidence into per-step folders
  8. 08Improved the review interface, send-back flow and evidence visibility in all ten locales
  9. 09Automated tests and full manual end-to-end testing

04Decisions and trade-offs

The calls that shaped it.

  1. 01

    Scope evidence to the step

    Evidence belongs to the review step it supports, not to the review as a whole.

    The trade-off

    More structure in the data model and interface, in exchange for approvals that only their own evidence can satisfy.

  2. 02

    Supersede, never delete

    A send-back expires earlier evidence but keeps it in the audit trail.

    The trade-off

    More states to present clearly, but nothing that happened disappears from the record.

  3. 03

    Backward compatible by default

    New step links are nullable, so active legacy reviews keep working unchanged.

    The trade-off

    The code handles both shapes for a while, instead of a risky migration of live reviews.

  4. 04

    The server decides who may act

    Permissions are re-derived on the server rather than taken from client-provided identifiers.

    The trade-off

    Slightly more work per request, and a whole class of spoofing mistakes removed.

05Systems touched

Across the stack.

  • React frontend
  • Redux and WebSocket state
  • API gateway services
  • Shared TypeScript types
  • Database migrations and models
  • Document download service
  • Authorization and validation

06Outcome

The result.

Rolled out company-wide. Evidence now satisfies only its own step, send-backs leave a clean audit trail, and exports are organised per step.

Described at a public level of detail. No customer names, internal identifiers or proprietary code.