Skip to content

Convention — audit-first discipline

What it is

The engineering process ManpowerIQ's sprints run by: each phase of a feature is gated by a read-only audit before the next phase starts. The audit verifies the plan against the real code/schema, logs numbered decisions, and flags anything unconfirmed — and a phase only advances once its audit and build-decision are signed off. This is a process convention, not a code pattern, but it's the reason the codebase's claims are trustworthy.

When it applies

To any non-trivial change run as a multi-phase sprint (MIQ-131/132/133, Sprint 10/11, RosterPublishApproval, the PB items, and — visibly — this wiki effort itself). Each phase transition (0→1→2→3) is a gate.

The lifecycle

  1. Phase N — build. Implement the phase; run tests locally.
  2. Phase N — audit (read-only). Produce a Phase_N_AuditReport.md (or BuildDecision) that records:
  3. Build status — build green, test sweep pass/fail (or documented skips).
  4. Numbered decisions — each change is Decision #X, cited to the code/test that embodies it.
  5. Regressions checked — verified against the prior phase.
  6. A "do NOT assume" list — unconfirmed items the next phase must verify before relying on them.
  7. Reality checks — data/code inconsistencies surfaced rather than silently "fixed".
  8. Architect review. The audit is reviewed; on approval a Phase_N_BuildDecision.md records the go-ahead plus any constraints for N+1.
  9. Phase N+1 starts only after N's audit + build-decision are signed off.

The audit is read-only: the auditor verifies against migrations, EF configs, and service source — citing file:line — and where code contradicts the brief, code wins and is flagged. Verification SQL is handed back to the developer to run; the auditor doesn't mutate the DB.

Why it's built this way

The discipline catches wrong assumptions at the cheapest moment. A real example: a Phase-0 publish-identification query used ar.state = 4 (an int) for allocation runs, but runs store state as a string ('Locked'); the audit gate caught it before Phase 1 built on it, and it was corrected and re-verified (Sprint 11 Phase 1 audit). Without the gate, the error would have propagated.

Gotchas / constraints

  • Audit gates block progression. If a phase's audit finds a defect, the next phase does not start until it's fixed and re-audited. Don't push forward intending to "fix it later".
  • "Do NOT assume" lists are load-bearing. They name unconfirmed architectural points; the next phase must verify them before wiring against them.
  • Decisions are immutable once signed off. If a later phase finds an earlier decision was wrong, it files a new superseding decision citing the finding — it doesn't silently rewrite the old one.
  • The auditor writes no production code and runs no migrations — it's a verification pass, deliberately separated from building.

Build status

Available — the discipline is visible throughout Sprint/ (the *_AuditReport.md, *_BuildDecision.md, and Phase*_Decisions.md series for MIQ-131/132/133, Sprint 10/11, RosterPublishApproval, and the PB items).

  • §G discipline — the extraction-decision rule those audits apply.
  • Test patterns — what the audits check the tests do.
  • Source: Sprint/ audit/decision series (e.g. MIQ-131_Phase0_Decisions.md, Sprint11_Phase1_Audit.md, RosterPublishApproval_Phase0_AuditReport.md).