This article shows developers how to record plan approval, material revisions and final acceptance. The gate defines what is approved, who may approve it and which changes require renewed approval.
A recorded plan gives implementation and review a common reference point without claiming that planning alone improves delivery.
Record the plan
A plan captures decisions expected to remain stable during implementation:
- Intended behaviour
- Relevant business rules
- System boundaries
- Failure handling
- Testing strategy
- Evidence required for acceptance
Product and engineering participants agree the outcome and constraints. The implementer decides how to meet them within the repository.
Without this agreement, reviewers reconstruct more of the requirement from implementation choices. Those choices can anchor the discussion. Replacing an unsuitable approach appears more expensive after implementation than selecting one before work begins.
The plan should not prescribe incidental code structure. Excess detail takes time to review, becomes stale and restricts implementation decisions that do not affect the agreed outcome.
Use an explicit approval gate
The gate requires three decisions:
- Approve or reject the plan before implementation.
- Continue, pause or seek renewed approval when a material change arises.
- Accept or reject the completed change against the current approved plan.
Rules for each risk band must state:
- How the risk band is assigned
- Who is authorised to approve the initial plan
- Who is authorised to approve revisions
- Who is authorised to give final acceptance
- Whether those authorities may be the same role
- Whether independent challenge is required
- Whether implementation pauses during revision
- How unresolved disagreement is escalated
- What evidence final acceptance requires
Plan approval, revision approval and final acceptance are separate decisions. The control model must identify the authorised role for each rather than assume that one approval covers the full lifecycle.
A risk label without these rules cannot determine which controls apply.
Keep one lifecycle record
The following synthetic table defines the minimum lifecycle record. It is a proposed template, not evidence that the control has operated.
| Stage | Field | Required entry |
|---|---|---|
| Identification | Work item | Identifier linking the plan to implementation |
| Planning | Intended behaviour | Observable outcome of the change |
| Planning | Business rules | Rules the implementation must preserve |
| Planning | Boundary | Included and excluded systems or components |
| Planning | Failure handling | Required behaviour when the operation fails |
| Planning | Acceptance conditions | Testable conditions for acceptance |
| Planning | Validation method | Tests, checks or inspection used as evidence |
| Classification | Risk band | Assigned classification |
| Initial approval | Plan approver | Role or person authorised for the assigned classification |
| Initial approval | Approval state | Draft, approved, rejected or superseded |
| Initial approval | Approval record | Decision, date and recorded location |
| Revision | Revision trigger | Material change requiring reassessment |
| Revision | Revision record | Changed field, reason, proposer and decision |
| Revision | Revision approver | Role or person authorised to decide the revision |
| Revision | Work status | Continue or pause while approval is pending |
| Implementation | Code reference | Link between the approved plan and implementing code |
| Validation | Acceptance evidence | Links to tests, checks and review findings |
| Final acceptance | Acceptance authority | Role or person authorised to accept the completed change |
| Final acceptance | Acceptance state | Pending, accepted or rejected |
| Final acceptance | Accepted plan version | Exact approved version used for final review |
Each approved version should link to the version it supersedes. Missing records should remain visible rather than be inferred from surrounding entries.
Define material change
A material change affects the approved intent or the basis on which it was approved. It requires reassessment through the revision fields in the lifecycle record.
| Area | Material change | Normally not material |
|---|---|---|
| Behaviour | An operation returns a different result for an accepted input | Internal refactoring preserves the same result |
| Boundary | The change writes to a component excluded by the plan | Code moves between files inside the approved component |
| Risk | New information meets the defined criteria for another risk band | An implementation detail changes without affecting the assigned criteria |
| Acceptance | A required test is removed, weakened or replaced with different evidence | The same acceptance condition is tested at a different internal layer |
| Failure handling | A specified rejection becomes a retry or partial success | Error construction changes while externally observable handling remains unchanged |
These examples define the decision test, not the risk-band rules. Each organisation still needs operational criteria for assigning risk and identifying authorised approvers.
When a material change arises, update the lifecycle record with the affected field, reason, risk classification, work status, decision and superseded plan version.
Review against the plan
An approved plan reduces initial requirement discovery and business-rule interpretation during normal code review. It does not remove them. Review can still uncover mistaken assumptions, unrecognised dependencies or missing requirements.
Reviewers can ask:
- Does the implementation preserve the agreed behaviour and invariants?
- Are error paths handled as specified?
- Do tests exercise each acceptance condition?
- Has the change stayed within its declared boundary?
- Is every material departure recorded and approved?
- Does the acceptance evidence refer to the current plan version?
If a finding changes behaviour, boundaries, risk or acceptance conditions, the plan requires reassessment. Otherwise, the reviewer can treat it as an implementation issue within the approved scope.
Apply the workflow
This synthetic example demonstrates the mechanics rather than a delivery result:
- A plan states that a component must reject an invalid input without writing outside its declared boundary.
- Acceptance requires a test showing the rejection and confirming that no external write occurs.
- An authorised plan approver approves the plan under the assigned risk band.
- During implementation, the engineer finds that the proposed path requires a write to a component excluded by the plan.
- The engineer records the boundary change and requests reassessment.
- Work continues or pauses according to the rule for that risk band.
- The authorised revision approver accepts or rejects the revised boundary.
- Code review checks the implementation and tests against the approved version.
- The authorised acceptance role records the final decision and links it to the supporting evidence.
The external write is material because it changes the declared boundary. A local refactoring that preserves the rejection behaviour, boundary and acceptance test does not require renewed approval.
The example does not establish whether the three approval decisions should be made by the same person or by separate roles. That choice belongs in the organisation’s authority rules.
Link repository controls to evidence
Planning cannot compensate for a repository that cannot reproduce or enforce its validation process. Repository controls should support named acceptance evidence rather than form a general checklist.
| Repository control | Acceptance evidence it supports | Review question |
|---|---|---|
| Runtime pinning | Test results produced under the declared runtime | Was validation run with the recorded runtime version? |
| Continuous integration with observed checks | Recorded execution of required tests and checks | Did the required checks run against the accepted change? |
| One-command validation | A repeatable command covering the stated validation method | Can a reviewer repeat the required validation from the repository? |
| Default-branch protection | Enforcement of required checks before integration | Could the change enter the default branch without the recorded checks? |
A plan should not imply that evidence is repeatable unless the repository provides the required mechanism. The lifecycle record should link the approved plan, implementing code, validation results, review findings and final acceptance decision.
Define delivery measures
Planned and unplanned work can only be compared when each measure has an operational definition.
| Measure | Proposed definition |
|---|---|
| First-pass result | Whether the change meets all recorded acceptance conditions at its first formal acceptance review |
| Review finding | A recorded issue raised during review that requires a response or change |
| Finding classification | The defined category and severity assigned under the review process |
| Final acceptance result | Accepted or rejected against the current approved plan |
| Change size | The organisation’s declared sizing method, applied consistently to both cohorts |
| Change complexity | The organisation’s declared complexity method, applied consistently to both cohorts |
| Revision frequency | Number of approved-plan revisions per change |
| Approval latency | Time between submission for approval and the recorded decision |
| Missing data | A required field or record that is absent, unavailable or cannot be linked to the change |
Teams must define sizing, complexity and severity schemes before collecting results. Retrospective classification risks inconsistent comparisons.
Do not force ambiguous records into a category. Record them as unknown and state why. A missing approval or acceptance record is not evidence of rejection, acceptance or an absence of findings.
Reports should include:
- Definitions and reporting period
- Planned and unplanned cohort sizes
- Risk band, repository and scope
- Change size and complexity
- First-pass and final acceptance results
- Finding counts and classifications
- Revision frequency
- Approval latency
- Missing and ambiguous records
Compare work with similar risk, repository and scope characteristics. Where direct matching is impractical, group results by those factors and report size and complexity within each group. This can reduce unsuitable comparisons, but it cannot establish causation.
Evidence limitations
This article proposes a control model and synthetic record. It does not include a real change record, repository artefacts, operational risk-band rules, defined outcome measures or a source-backed separation of approval roles. No governance, change-management or software-assurance standard has been cited because no supporting source was provided.
No reported percentage is justified without its source, population, numerator, denominator and definition. The model therefore does not demonstrate that planning improves delivery or makes intent clearer in practice.
What this means
An approval gate gives implementation and review a recorded reference for intent, revision and acceptance. Claims about delivery impact require complete lifecycle records, repeatable repository checks and consistently defined comparisons between planned and unplanned work.
Originally published at AFT Group Engineering Insights.
